They said – I’ve done some reading and I can see how you can set up a private network between your onw corporate network and Azure. I’ve also read how you can exposes services running on VMs to the Internet. But I can’t find anything on how you can link those 2 ideas together. It makes me think you might not actually be able to do it.

Well – yes you can do it and hopefully this is the article you need to explain how it works…

It’s a bit of a generic T-shirt (budum tish! Well you were all thinking it…) but it’s one of those jokes that only works for a certain number of people. There was a great one that Oxford Computer Group did a few years ago. It looked a bit like this:

Worked well for anybody who was in to Lightweight Directory Access Protocol and knew about the LA Police Department…

I’ve been thinking of a few other designs.

above: an oldie but goldie…

Has anybody got any better ideas?

@plankytronixx

• Putting multiple VMs in to availability sets
• Creating multiple instances of each role in Cloud Services

I can’t remember exactly but Igal Figlin from Microsoft did some background research in to this and found that 40% (it might be higher I can’t remember exactly – you can watch the video here) of deployments are not in availability sets. Have a read of the email below and you’ll start to realise how much risk you are putting yourself to if you don’t use multiple VMs in availability sets.

When you put VMs in to availability sets they are also distributed across up to 5 update domains. When Microsoft updates Azure, they’ll walk from one update-domain to the next. You can see what they are saying in this email – they’ll leave 30 minutes between updating each update domain. Let’s say you have 2 machines in an availability set. They’ll be spread across 2 fault domains and 2 update domains. That means if an infrastructure fault occurs (like say power or a network segment), only one of your VMs will be affected. It also means if Microsoft has to do an update, it will take one of your machines out of the configuration at a time.

If you want to be super-cautious, you could protect against the scenario that while Microsoft is walking the update domains in your availability set, you also get an infrastructure failure – that could take out a further machine. The table below shows how.

Imagine the update process had done the update on the instance in Update Domain 0, it had then walked on to Update Domain 1 and was in the middle of updating that instance. Instance 1 is now offline. At the same time a power failure occurs to the rack on Fault Domain 0. That would cause Instance 0 and instance 2 to also be taken offline. You’d now have an availability set with no running machines. You can counter this by adding a VM to the availability set. Because there can only ever be one Update Domain in an availability set undergoing an update – you are protected. Let’s say you are in the middle of updating one of the services yourself. Your update will be stalled, the Microsoft update will complete and then your update will continue. In other words updates are applied to an update domain synchronously. And if you are in the middle of updating one Update Domain, Microsoft won’t start simultaneously updating a different Update Domain. So the following table will remove all risk from simultaneous Update Domain and Fault Domain operations.

The failure of any Fault Domain will take out 2 instances and a simultaneous update can take out only one Update Domain. This means a maximum of 3 instances can be offline because of simultaneous Update Domain/Fault Domain operations. That would leave you with one running instance.

You’d have to be very unlucky to get an infrastructure failure occur while an update is going on. The availability SLA takes the above scenarios in to consideration – you only have to have 2 instances in your availability sets to enjoy the uptime guarantee. If you are unlucky enough to suffer a double problem and the availability drops below the guarantee then Microsoft compensates you.

I made a post about Update Domains and Fault Domains a couple of weeks ago. Interesting stuff if you’re going to take the Azure Infrastructure exam.

Anyway – here’s the email:

---- cut here -----

Have fun – Planky == @plankytronixx

First – I’d recommend you read my post on how SSL actually works first. You might then find, you don’t know enough about the relationships between keys, certificates and signatures, so I’d recommend you watch my crypto primer video.

There is a video of the whole article here...

 Watch the video full-size on Channel 9.

SSL is already enabled on your Azure WebSite/WebApp

Yes, that’s right. Let’s imagine you go to the portal and create an entirely naked website in the Free tier called plankytronixx.azurewebsites.net, it will already be enabled for SSL. You can just type in to the browser address bar https://plankytronixx.azurewebsites.net and it will work just fine.

I created plankytronixx.azurewebsites.net 90 seconds ago, as shown above in the figure. I’ve done absolutely nothing to the site since I created it. When I connect to it over SSL it works! And this is a Free WebSite/WebApp.

You can see the certificate that is being used to protect it. More interesting is the cert path up to the Microsoft Internal Corporate Root….

Of course the disadvantage of this SSL implementation is that you have to use the .azurewebsites.net address. Even if you map to a new custom domain, like say, plankytronixx.co.uk, the .azurewebsites.net configuration is still there, it still exists, you can still connect to it… But users might get suspicious if you ask them for a password over SSL and they now appear to be on an entirely different site. Most of them won’t know how Azure works so their suspicions would be reasonable…

You can actually see in the screenshot above that a wildcard cert exists for every single Azure Web Site/Web App in the world. *.azurewebsites.net…. Plus – this certificate is included in the price (and that means the Free tier as well!). SO free SSL is available, but but but…

Custom Domain Names

This is the bit where it gets a bit more complicated and this is the bit everybody talks about: when you want to SSL-enable a site to give a URL like https://plankytronixx.co.uk… First things first – you can’t get a custom domain name in the Free Tier. So you can now start to see where the confusion comes in? People say SSL is not available for Free sites because of that. But as you’ve just seen, you do get SSL, only it comes with a collection of limitations. You have to move up to Basic or Standard to get SSL on custom domain names.

To set up a custom domain name you have to set up a mapping between the IP address of the web server and the DNS name. You do this at a Domain Registrar. I use Go Daddy. The record you add is called an A (address) record. So plankytronixx.co.uk might get mapped to say 104.45.81.79. It’s dead easy to configure this at a domain registrar – you just update the zone file. They’ll give you some kind of tool to do it, usually web-based. This is what it looks like on Go Daddy…

To get Azure to recognise it involves a hurdle to jump. If you just update the A record and nothing else, Azure will give you this error:

It’s because Azure wants to be assured that you “own” this domain. It wants you to prove that you own it. It does this using the “azure websites verify” process – more normally known as awverify.

Anatomy of an HTTP GET request

Let’s have a quick review of what happens when you type http://plankytronixx.com.uk in to a web browser.

1. The browser does a DNS query against the name plankytronixx.couk.
2. The DNS server returns the IP address – let’s say it’s 104.45.81.79.
3. The web browser formats an HTTP GET and sends it to IP address 104.45.81.79.
4. In the header of the GET request is the host name – plankytronixx..co.uk
5. Azure is sat at IP address 104.45.81.79; it inspects the host name in the header and looks to see if it has a site that matches the name. If it does…
6. It returns the page.
7. If it doesn’t – you get the error in the screenshot above.

When you are setting this up for the first time, Azure gives you a piece of DNS information which you add to your DNS registrar’s zone file for your domain (plankytronixx.co,uk in this case). When you set up the Azure end of the configuration, Azure sends a query to your domain registrar and expects to see the DNS information it gave you. By this mechanism you are proving that you have control of the records in the domain you are trying to configure: that you “own” the domain.

If this works, any requests received in steps 5 and 6 above return the correct page. If you can’t prove you “own” the domain, Azure won’t configure the domain for you and it returns the blue-page 404 you can see in the screenshot above.

Proving Domain Ownership

To prove you own the domain, Azure gives you some instructions on the Domains configuration page…

I’ll go through it assuming the custom domain name I want is plankytronixx.co.uk and the default Azure Website/WebApps name is plankytronixx.azurewebsites.net.

1. Add a CNAME record called “awverify” and point it to “awverify.plankytronixx.azurewebsites.net”. I’m showing this in the Go Daddy screen below:
2. 
3. You might have to wait a few minutes (or even a few hours in some cases) for the DNS records to propagate (don’t forget to save the changes)…
4. If you get it right, when you type your domain name in to the Azure configuration page – you’ll get a little green tick in the text-box.
5. 
6. If something has gone wrong (or the domain update hasn’t yet propagated), you get a little red exclamation mark.
7. You can now save the configuration. You’ll see both the custom domain name and the raw Azure Websites/WebApps name in the portal screen.
8. 

Essentially what Azure did during this process was send a DNS query for awverify.plankytronixx.co.uk and it expected to see back, exactly what it told you to configure in the first place – awverify.plankytronixx.azurewebsites.net. If it gets that back, it reasons that you must have the power to make that record change at the DNS registrar and you must therefore own that domain name.

Custom Domain SSL

Now you have a custom domain name, you can set up SSL for it (in this case, plankytronixx.co.uk). But there are 2 types of SSL certificate. Traditional certificates, known as IP-based SSL certs. And SNI certs (Server Name Indication).

Let’s go back to 1994 when SSL was first introduced by Netscape. There weren’t really all that many web servers running. And the assumption made at the time was that each web site ran on a single server with a single IP address. But these days, IP addresses are very scarce resources. It’s not unusual to have many thousands, or even tens of thousands of web sites all running at the same IP address. One of the things that helped this was the introduction of the host name in the HTTP header as mentioned in Anatomy of an HTTP GET request above.

You can still use IP-based certificates for SSL with Azure. But there’s a 1:1 mapping between the certificate and the site it’s attached to. For an IP-based certificate, it will run on exactly one IP address. You’d think it must be possible to use the host-header trick I mentioned above. But the trouble is that the SSL session is set up before the HTTP request is executed. It’s therefore not possible for the server to see what site to route the traffic to. When there’s only one site to send the traffic to, there’s no decision to make. But it means the site needs to have its own dedicated public IP address. The disadvantage is that it costs more as a result.

SNI certificates were introduced to get round the problem of the 1:1 mapping between sites and IP addresses. When an SNI certificate is used, the browser sends the host name as part of the SSL setup. But you’ve probably already spotted the problem? Older browsers that don’t support SNI certificates won’t work. So you have to decide between high coverage and higher costs (IP-based certs) or lower coverage and lower costs (SNI-based certs). Your ball…

The certificate needs to be in a format that can transport not only the public key, but also the private key. This usually means there is some form of protection on the file that contains the certificate, like a password. But there’s another problem. Normally, the server on which the certificate sits will generate both the public and the private key. You will then send the public key, plus some information about your site (it’s DNS name for example) and yourself as the site admin. All this gets wrapped up in to a Certificate Signing Request (CSR). Azure Websites don’t give you access to the underlying server (in the way that say Cloud Services do). You keep the private key, well, private (you don’t even reveal the private key to the certificate provider). You add the private key in to the certificate file. THe file has to be in .pfx format.

Probably the easiest way to do this is to fire up IIS Manager on a machine and create a Certificate Request on it. Open the root then on the main pane double-click Server Certificates. You’ll see an option in the panel on the right hand side to Create  Certificate Request. Go through the wizard and save the text file in a convenient location. This process generates a public and a private key. The public key is in the CSR text file. The private key is kept on the machine and is, well, private.

Now you need to present this Certificate Request to a Cert Issuer such as VeriSign, InstantSSL, Thawte and so on. Or your own CA… Quite a few of the providers will give you a 30-day or 90-day trial certificate. Typically if you apply for a certificate for say, plankytronixx.co.uk, you’ll need an email address at plankytronixx.co.uk. Each issuer has its own process: some ask for lots of information, others ask for a little. What you will end up with is a signed certificate. They will email the response to you.

Remember that when you created the request, the private key was kept private? Well, it’s still hanging around. When you complete the certificate request in IIS, it will marry up with the file the CA sent you in email. You go back and click "Complete Certificate Request.

You’ll be asked for the file the CA sent you. Put all the details in and click OK.

You now get the option to export the certificate and it and that’s a good thing because you can export the certificate in .pfx format which is exactly what Azure WebSites/WebApps requires.

The easiest way to do this is to find your certificate in the Server Certificates section of IIS. Identify your certificate, right-click it and select Export. You’ll end up with a .pfx file.

You go to the Azure Portal and click upload a certificate on the Configure page (this is as long as you are in the Basic or higher tier).

That’s not the end of the process. You now have a certificate in Azure – to get your Azure Website/WebApp to use it – you need to configure the SSL Bindings section of the page. You’ll specify which DNS name you want to protect with SSL, you’ll select the certificate you just uploaded and, depending on the type of cert you bought, you’ll select either SNI or IP based certificate.

Once you save those settings you’re done. Try it out by connecting a browser to your site. If you used an EV certificate, the address bar turns green. A padlock icon appears in the address bar of most browsers. If you click it in IE you can actually view the certificate plus its certification path – all the way up to the root authority.

I hope you found this useful. Remember, I made a video of how to do it here. Click Here.

@plankytronixx

If you see any of the “martetecture” material on the Internet, you’d rapidly come to the conclusion that VNets are a way to securely bind your on-premises corporate-network to the network you have in Azure on which all your servers and resources are sat. The idea behind this is that the stuff you have in Azure becomes a bit like a branch-office attached to your private network. The connection medium between the 2 is the Internet and the traffic is carried over SSL, which makes it very difficult for an eavesdropper to listen in on your communications. But did you know you can use VNets to also connect let’s say some servers in the Azure Dublin data centre to some servers in the Azure Singapore data centre? You can also use it to connect say an Azure Website running WordPress to an Azure VM running MySQL: it’s a way of bridging the gap between PaaS and IaaS services in Azure. It also gives you a good degree of control over the way the internal network works. This might be important if you intend to deploy core infrastructure such as Active Directory where the sites and services architecture assumes you have control over such things as sites and subnets.

There are 2 things to get your head around: address spaces and subnets. An address space is the contiguous universe of IP addresses between 2 limits – the lower address and the upper address. The subnet is an IP subnet in the traditional sense of the word but in this case, it lives within an address space.

Address Spaces

Address spaces and subnets are usually declared in CIDR notation. A number like 10.0.0.0/8. That’s a 32-bit base IP address plus a mask. This example means “mask off the top 8 bits, and the range of addresses that are left in the last 24 bits is the address space.

Figure 1: Address Space map for 10.0.0.0/8

The above example shows an address space from 10.0.0.0 (the lower address) to 10.255.255.255 (the upper address). Another example might be 10.0.0.0/16 as shown in the following figure.

Figure 2: Address Space map for 10.0.0.0/16

That would mask off the top 16 bits and leave the final 16 bits for an address space range of 10.0.0.0 to 10.0.255.255.

Whatever address space you define, you are creating a “space” with a collection of addresses (from the lowest to the highest), hence the term “address space”. Let’s imagine you had a VNet with a couple of IaaS VMs connected to it like the figure below:

Figure 3: VMs connected to a VNet

The text in red represents the address space. Note it’s the same for each VM. The text in black represents the individual address within that space. These 2 machines can communicate with each other on the VNet. Their addresses are within the permitted range for this address space of 10.0.0.0 to 10.0.255.255. But imagine if the IP address of the machine of the right had somehow got set to 10.1.20.31. It would be unable to communicate because it’s outside the range. Azure’s infrastructure would specifically prevent communication to or from that machine. It would become an island on its own.

Subnets

A subnet must exist within an address space. That means the range of addresses in a subnet must fit inside the address space. So hopefully you can see how subnetting an address space gives you a way to logically divide up the address space.

Look back up at figure 1. The lowest-order 24 bits represent all the possible addresses you could have in the address space. By further dividing those 24 bits, you could segment the network. The higher order bits would determine which subnet you are in, and the lower order bits would define which host on that particular network you are on.

Figure 4: Subnet within an address space.

Figure 4 shows how the remaining 24 bits have been subnetted. The following table gives a few examples of how to break these ideas down.

The table below assumes an address space of 10.0.0.0/8

This is all very easy because I’ve divided the address space and subnet boundaries up on very neat byte boundaries. So the numbers fit exactly in the dotted address notation. But you can also create address spaces and subnets that don’t divide on these boundaries. You could for example have a subnet defined by the top say, 13 bits of a 32-bit address. The reason it makes things more difficult is because part of the subnet identifier would come from the second number and part of it would come from the third number of an IP address. And there’s nothing to be done other than visualise the address space in your mind, or draw it out.

Figure 5: Non byte-boundary subnet.

This would give a CIDR address for the address space as 10.0.0.0/8 and a subnet address of 10.0.0.0/13. If you count in from the most-significant-bit, you can see the subnet ends on the 13th bit. It certainly makes for complexity when trying to do calculations in your head in an exam! I’m hoping you can see that as you make the number of bits you use for the subnet bigger, you take them away from the maximum number of hosts you can have within a subnet. So these things are a compromise against each other. If you have no need (and foresee no need way in to the future) to be really tight up against the boundaries with subnets and address spaces, and you’re not at or near the limit – make life easy for yourself – set address space and subnets up on byte-boundaries. I reckon in the exam, if they want you to calculate something like this – they’ll give you a question with everything lining up on byte boundaries. After all, it’s not a TCP/IP exam…

What’s in a Virtual Network.

The security in Azure works in such a way that IP addresses that are not known to the infrastructure (on other words it didn’t issue them in the first place) are not routed anywhere. The result is that if you want things to talk to each other, you’ve got to let Azure’s infrastructure give you a dynamically assigned IP address. You might be getting all uppity at this point thinking you want to deploy something like an AD Domain Controller and best practice says to avoid DHCP. Well, with VNets you can relax. You will be issued an address over the DHCP protocol, but the lease duration is set to either 168 years or until you delete the VNet, whichever comes first. I’m pretty sure you’ll delete the VNet first and in fact, I haven’t thought about what will happen in 168 years. It’ll be somebody else’s problem by then.

This means whenever you shut a machine down, when it reboots, it’ll get the same IP address back again. So now you can relax about your AD Domain Controller deployments in Azure. The fact that every time you boot the machine and it gets the same address makes it just as good as a statically assigned IP address.

Each VNet reserves a few addresses. You might have noticed whenever you fire up the first machine in a VNet it gets a .4 address. That’s because .0 is reserved for broadcast requests while .1 is reserved for the default gateway (router). .2 and .3 are reserved for a special sort of gateway that you might later configure to communicate with your on-premises network. Note that .255 is also a broadcast address.

In the following figure, I configured a VNet thus:

Figure 6: ipconfig output for a VNet.

You can see this is the first host in the subnet because it is assigned a .4 address. You can see it’s a 16-bit subnet, because the subnet mask (255.255.0.0) masks off the top 16 bits. You can also see the default gateway (router) is at 10.0.0.1 as predicted.

It doesn’t matter how large or small the subnet is, any range of available addresses are automatically reduced by 5 (because of the 5 reserved addresses mentioned above). So for example a 16-bit subnet (which gives a total of 65536 host addresses) is reduced to 65531. An 8 bit subnet has a maximum of 251 addresses (256-5). You can see this illustrated in the following figure.

Figure 7: Subnet range displayed in the Azure portal.

In Figure 7 you can see the 16 bit subnet mask results in 65531 available addresses giving a usable address range of 10.0.0.4 to 10.0.255.254.

Practice Questions

Q: How many hosts can occupy a single subnet in the following VNet?

Address space: 10.0.0.0/16

Subnet: 10.0.0.0/24

A: the “/24” means the first 3 octets fill in from the most significant bit and mask off the first 3 bytes. That leaves one byte (or 8 bits) of subnet space– or 256 hosts. But 5 addresses have to be subtracted which leaves 251 hosts.

Q: How many hosts can occupy a single subnet in the following VNet?

Address space: 10.0.0.0/8

Subnet: 10.0.0.0/24

A: THis is just a question to test that you understand the difference between the address space and the subnet. The subnet definition in this question is the same as the first question, the number of hosts doesn’t change. 251.

Q: You have the following VNet:

Address space: 10.0.0.0/8

Subnet: 10.0.0.0/16

You connect to a VM on this network over RDP and assign the following fixed IP address 10.0.0.100. Will you be able to connect to a VM at IP address 10.0.0.101?

A: No – the Azure VNet infrastructure prevents traffic to/from hosts it didn't assign an IP address to.

I hope this will help you if you’re taking the Azure Infrastructure Exam (533)…

Planky == @plankytronixx

I thought I’d just write a few articles about stuff I’ve found out between now and then which others who are taking the exam might find interesting.

This post: Fault Domains and Update Domains: I’ve known about them for years but never really thought about how they are actually calculated and how machines are provisioned in to them.

First – Azure VMs.

Fault Domains

When you put VMs in to an availability set, Azure guarantees to spread them across Fault Domains and Update Domains. A Fault Domain (FD) is essentially a rack of servers. It consumes subsystems like network, power, cooling etc. So 2 VMs in the same availability set means Azure will provision them in to 2 different racks so that if say, the network or the power failed, only one rack would be affected.

I discovered there are always only 2 fault domains: FD0 and FD1. It makes it seem like your VMs only get spread across 2 racks but that’s not the case. They can be spread across more racks if you’ve got lots of VMs. But as far as your availability set is concerned FD0 and FD1 are a way of saying “This bit of infrastructure (FD0) is different to this bit (FD1).  As you boot VMs in to an availability set, they get allocated like this – FD0, FD1, FD0, FD1, FD0, FD1 and so on. The pattern never changes. You’ve probably seen this diagram hundreds of times:

Figure 1: Fault Domains and Availability Sets

You can see IIS1 and 2 are the web-front end. They’re both in different fault domains. If something happens to the power going to rack 1, IIS1 will fail and so will SQL1 but the other 2 servers will continue to operate.

Now, if you add more servers to each availability set, this is what happens:

Figure 2: FD0 and FD1 are populated.

Azure continues to distribute them across fault domains. Looking at a list of the 4 IIS VMs would give a table like this:

They are allocated to FDs in the order in which they boot. So if I’d booted these systems in reverse order then they’d all be in different FDs.

Update Domains

Sometimes you need to update your app, or Microsoft needs to update the host on which your VM(s) are running. Note that with IaaS VMs, Microsoft does not automatically update your VMs. You have complete control (and responsibility) over that. But say if a serious security vulnerability is identified and a patch created. It’s in Microosft’s interest to get that applied to the host underneath your VM as soon as possible. So how is that done without taking your service offline? Update Domains. It’s similar to the FD methods, only this time, instead of an accidental failure, there is a purposeful move to take down one (or more) of your servers. So to make sure your service doesn’t go offline because of an update, it will walk through your update domains one after the other.

Whereas FDs are assigned in the pattern 0, 1, 0, 1, 0, 1, 0, 1…. UDs are assigned 0, 1, 2, 3, 4, 0, 1, 2, 3, 4, 0, 1, 2, 3, 4, 0, 1, 2, 3, 4….

Both FDs and UDs are assigned in the order that Azure discovers them as they are provisioned. So if you provision machines in the order Srv0, Srv1, Srv2, Srv3, Srv4, Srv5, Srv6, Srv7, Srv8, Srv9, Srv10, Srv11 you’ll end up with a table that looks like this:

…you can see that UDs loop around a count of 5 (0, 1, 2, 3, 4).

You can see that in the following screen shot of a collection of 9 VMs in a single availability set.

Figure 3: Fault and Update Domains in a Cloud Service comprised of Azure VMs

Second – Azure Cloud Services

With Azure VMs, FDs and UDs are assigned to the VMs in an availability set in the order in which they are provisioned. With Cloud Servces it’s almost the same but roles are used instead of availability sets. For example you might have a web role with 8 instances. The role would be assigned FDs and UDs as the instances are provisioned and discovered by Azure. The order of the instance numbers is not necessarily the order in which they are successfully provisioned. It’s just a fact of life that some machines that start the provisioning process slow down in the middle and machines that started later, catch up and overtake them.

You can also see in this shot of a Cloud Service, the same pattern:

…but notice how by the time we get to page three (there are 100 servers in this cloud service), it starts to break down:

…that’s because UDs and FDs are assigned in the order that instances are provisioned. Some of them provision more quickly than others and that causes the pattern to break down. But there are still the correct number of FDs and UDs.

In Cloud Services, you can also set the number of update domains in the service model’s .csdef file. By default it’s set to 5 but you can increase that to a maximum of 20.

Practice Questions:

Q: If you add a new VM to an availability set, how many extra fault domains and update domains will you get if there are already 4 instances in the availability set?

A:

Q: In a Cloud Service that has a Web Role with 12 instances, how many FDs and UDs will you get by default?

A: 2 FDs (FD0 and FD1). 5 UDs (UD0, UD1, UD2, UD3, UD4).

Q: You have set the maximum number of UDs in the .csdef for a Cloud Service to 20. You use Azure Virtual Machines to provision 18 VMs. How many Update Domains will you have as a result?

A: This is a bit of a trick question – the .csdef is only used for Cloud Services, not for VMs. So regardless of what you set or even how you try to do it, Azure VM UDs come in groups of 5. With 18 VMs, that means you’ll have 5 UDs. UD0 – to – UD4 a la:

Q: If you have 13 VMs in an availability set, how many VMs will be in UD0?

A: Use the table above. You can see UD0 lines up with VM0, VM5 and VM10. So there will be 3 VMs in UD0.

I hope you find this useful, if you’re going to take the Azure Infrastructure exam (533).

Planky == @plankytronixx

Figure 1: The Certificates tab in Visual Studio.

Figure 2: If you drill in to the underlying file, you get only one option – SHA1:

Well, you can relax. This has nothing to do with making the security of any data transmission less secure, or with validating the data, the certificate or any key material.

Over the years, various encryption and hashing algorithms have been found to have weaknesses and subsequently security experts have recommended using more modern, more secure equivalents. That’s where we are with SHA1 and SHA256.

But that is dealing with all the crypto material inside the certificate. The thumbprint is essentially a moniker for the name of the certificate. In the same way that I have a couple of names that people use to identify me. I will respond to either “Steve” or (more usually) “Planky”. You can do the same thing with certificates. You could use maybe the Subject field to identify a certificate. Maybe the CN (Common Name). Maybe some concatenation of the 2 fields. Some other field maybe.

In a certificate store on a computer, you could have 2 certificates with the same subject name. It’d be like walking in to a room and saying “Steve?” and hitting a momentary period of confusion as both me and my colleague, Steve, say “Yes?”.

That’s no good in the world of computing. So you need a way of absolutely identifying the certificate you want to use. It’s a little bit like the way my thumbprint exactly identifies me and nobody else in the world (as far as we know). That’s what the thumbprint of a certificate is.

It’s not a value that is stored inside the certificate. It’s a calculated value. What happens is that all the binary data that makes up the certificate is run through an algorithm and it produces a value. It gets run through the SHA1 algorithm. SHA1 is a hashing algorithm. That means you can put a string of data in to it and you get a fixed length string out of it. It produces a 160-bit value. That gives you a 40 character hexadecimal value. Look at the value in figure 2 above (and figure 3 below) and you can see the hexadecimal representation of that 160 bit value.

Figure 3: SHA1 certificate thumbprint

So, when you want to use a certificate in your Azure Cloud Service you’ve got 2 things to do. One is to upload the certificate, so it ends up in the certificate store of the machine(s) your cloud service is running on. The other job is to tell the machine which certificate you want to use. The machine has a pretty wide choice of certificates in its certificate store. You want to be sure it selects the right one. You do this by identifying the certificate with its thumbprint.

What will happen is when your app passes over the thumbprint from the .cscfg file, the system will go through every certificate in its store and find one with a thumbprint that matches the one you are talking about in the .cscfg.

How does the machine know the thumbprints of all the certificates in its certificate store if it’s not a value that is contained in the certificate? It calculates it. It simply runs the naked binary data of each cert through the SHA1 algorithm (as shown in figure 3 above) and look for a value that matches. If it finds one, then it’s got the right certificate.

The algorithm used for the thumbprint has now done its job. All the crypto material inside the certificate will be used to protect any data you transfer to and from the server. So – when you see sha1 in the .cscfg for the certificate thumbprint, you don’t have to worry that your website/app/data is insecure, it’s simply using it as a way of identifying the certificateit wants to use…

If any of the detail in this post is confusing and you feel you need a bit of a crypto primer, can I recommend you read this post, or watch this video.

Have fun – and relax, a SHA1 cert thumbprint is not going to compromise your system security….

@plankytronixx

Or the full-sized video is here.

Hope you like it.

Planky - @plankytronixx == GBR-257

Then something really cool happened a few days later. It ended up as an image in the Microsoft Azure VM portal.

You can now provision a Windows Server 2012 R2 with VSCE already installed (and it happens to also have the Azure SDK installed as well). Windows Server 2012 R2 is pretty close to Windows 8/8.1. So you get a very modern development environment which can be provisioned in 9 clicks and a short wait of between 5 and 8 minutes….

You then simply make a remote desktop connection to the machine over the Internet. This has even been made easy by the provision of a “Connect” button in the portal.

What makes this even more incredible is that with a free Azure trial subscription – you can provision this system and use it for free for the 30-day duration of the subscription.

I ran a cloud dev camp yesterday and added this in as the first lab-task. We’ve normally required the delegates to turn up with their laptops pre-configured. But yesterday, they provisioned their own dev machine in the cloud and then used that machine to build further services which they provisioned to the cloud. It’s the very start of one of the huge use-cases we’re seeing for Azure: Dev-and-Test in the cloud. From the conversations I had with people afterwards, it’s really fired a few imaginations as they think of the range of possibilities for their own companies’ dev and test environments.

The first few minutes of this video I just recorded shows you how to use a free Azure subscription (you can sign up for that right here) to provision a dev workstation. I then go on to show you, very quickly, how to provision a couple of Azure services: an Azure website and an Azure Cloud Service. Really just because you might as well use Azure if you’ve got a free subscription.

Have fun.

Planky GBR-257

…

Get-AzureVM | ForEach-Object { $vm = $_.name ; Write-Output "$vm VM Properties" ; Write-Output "---------------" ; Format-List -InputObject $_ -Property * ; Write-Output "$vm VM Endpoints" ; Write-Output "---------------" ; Get-AzureEndpoint -VM $_ ; Write-Output "$vm Virtual Disks" ; Write-Output "---------------" ; Get-AzureDisk | where {$_.AttachedTo.RoleName -eq $vm} ; Write-Output "==================================`n" } | Out-File -FilePath ".\myVMs.txt”

Here’s an example output:::

DeploymentName              : planky1
Name                        : planky1
Label                       :
VM                          : Microsoft.WindowsAzure.Commands.ServiceManagement.Model.PersistentVM
InstanceStatus              : ReadyRole
IpAddress                   : 100.74.110.11
InstanceStateDetails        :
PowerState                  : Started
InstanceErrorCode           :
InstanceFaultDomain         : 0
InstanceName                : planky1
InstanceUpgradeDomain       : 0
InstanceSize                : Small
AvailabilitySetName         :
DNSName                     : http://planky.cloudapp.net/
Status                      : ReadyRole
GuestAgentStatus            : Microsoft.WindowsAzure.Commands.ServiceManagement.Model.PersistentVMModel.Guest
                              AgentStatus
ResourceExtensionStatusList : {Microsoft.Compute.BGInfo}
PublicIPAddress             :
PublicIPName                :
ServiceName                 : planky
OperationDescription        : Get-AzureVM
OperationId                 : 26f35d0c908f2ad8961a2516f4b8c8a1
OperationStatus             : OK

planky1 VM Endpoints
---------------

LBSetName                :
LocalPort                : 5986
Name                     : PowerShell
Port                     : 5986
Protocol                 : tcp
Vip                      : 191.239.212.49
ProbePath                :
ProbePort                : 0
ProbeProtocol            :
ProbeIntervalInSeconds   :
ProbeTimeoutInSeconds    :
EnableDirectServerReturn : False
Acl                      : {}
InternalLoadBalancerName :

LBSetName                :
LocalPort                : 3389
Name                     : Remote Desktop
Port                     : 58168
Protocol                 : tcp
Vip                      : 191.239.212.49
ProbePath                :
ProbePort                : 0
ProbeProtocol            :
ProbeIntervalInSeconds   :
ProbeTimeoutInSeconds    :
EnableDirectServerReturn : False
Acl                      : {}
InternalLoadBalancerName :

planky1 Virtual Disks
---------------
AffinityGroup        :
AttachedTo           : RoleName: planky1
                       DeploymentName: planky1
                        HostedServiceName: planky
IsCorrupted          : False
Label                :
Location             : North Europe
DiskSizeInGB         : 128
MediaLink            : https://plankydevcamp.blob.core.windows.net/vhds/planky-planky1-2014-09-25.vhd
DiskName             : planky1-planky1-0-201409250848400102
SourceImageName      : a699494373c04fc0bc8f2bb1389d6106__Windows-Server-2012-R2-201409.01-en.us-127GB.vhd
OS                   : Windows
OperationDescription : Get-AzureDisk
OperationId          : 0f3e0975-06d0-2059-856c-3c6f6d9d1953
OperationStatus      : Succeeded

==================================

Isn’t that just soooo cool. Thanks Mark!

Yours etc,

Planky