Microsoft Forefront UAG: Preparing, Creating, and Publishing an HTTPS Trunk

Preparing for an HTTPS trunk

We have chosen to talk about HTTPS first, because these trunks are the most used by UAG customers and because, well, HTTP trunks are as easy as pie. Creating an HTTPS trunk is not difficult but, before going there, you need to have a certificate, and this can make your whole day rainy.

The HTTPS protocol provides better security as it encrypts the traffic between the user and the server. This is an age old protocol that has stood the test of time well, but it may still be a bit challenging to use, because just like real-life certificates, digital ones can’t just be handed out by anyone. Many books have been written about PKI (public key infrastructure), so we won’t go into much detail about it, but it’s important to understand the basics, so here goes.

Encryption is based on a simple concept. You want to send data to someone without anyone else being able to read it. You take the data, and change it in a way that only you and the future recipient know. If that data falls into the wrong hands, it will look like meaningless garbage. The intended recipient, though, knows how to reverse the process and read it.

Encryption is done by taking a key, which is a very long and unique number, and using it to perform a mathematical function on the data, resulting in encrypted data that appears to be meaningless. To decrypt the data, you do the opposite, with the same number, and obtain the original data. Let’s do a simple example:

Suppose you want to encrypt the word RIDDLE:

1. First, you convert each letter to a number. If we start with A=1, B=2, we get 18, 9, 4, 4, 12, and 5.
2. Second, we “encrypt” the data with our key. Let’s say our key is “50”, so we just add the key to each number, and end up with 68, 59, 54, 54, 62, and 55.
3. Now, when it’s time to decrypt this sequence, we just subtract the same number back, and convert font to letters.

Naturally, that level of secrecy wouldn’t be too hard to break, but real key-based digital encryption is much more complicated – trust me!

The previous process is known as “symmetric” encryption, because the same key is used to encrypt and decrypt. In old-school espionage, the recipient would be equipped in advance with the knowledge or means to do the decryption. The problem with the internet is that the sender and recipient hardly ever meet, so we need to come up with a way to provide the recipient with the know-how, without it being intercepted along the way, because that will allow anyone who’s smart enough to intercept internet traffic (which isn’t very hard, really) to decrypt anything and listen in. To our help comes ASSYMETRIC encryption, and digital certificates.

Asymmetric encryption

Asymmetric encryption uses a special mathematical formula that generates two different keys, instead of one. We then use a special encryption formula that cannot be reversed with the same key. If you encrypt using the first key, you need the second to decrypt, and vice-versa. It’s really quite a headache, but computers can do this sort of thing almost instantly. What happens when computers need to encrypt data is that the server (this could be your web server, for that matter) creates these two keys randomly. One is called the public key, and the other one the private key. Now, when that server wants to communicate securely with some other computer (say, your client), it sends it its public key (which is not secret—anyone is free to have it at any time), and then the client creates a unique and random regular key (like the one we discussed earlier). The client then encrypts the regular key using the server’s public key, and sends it to the server. If you recall, the encrypted regular key stays secret, because even if someone intercepts that message, he can’t decrypt it because, to do so, they would need the server’s PRIVATE Key, which is kept really private and secret.

So, the encrypted regular key is received by the server, which decrypts it, and now both sides have a regular key that no one else knows, and they can start using it to encrypt and decrypt messages back-and-forth. Fantastic. One thing, though, still needs to be taken care of is—trust. Say you are a client, and a server sends you this nice encrypted key, how do you know it’s really a genuine partner, and not some other server that impersonates it? Well, for that, we have digital certificates.

Digital certificates

A digital certificate, like a real-world certificate, is a way to prove one’s identity. When you want to get on a plane, you convince the security guard that you really are who you say you are by showing him a certificate given to you by the government—a passport or ID card, usually. It would have some unique seal or mark to prevent you from photo-shopping someone else’s ID, and that allows the guard to trust you because he trusts the body that gave you that certificate. After all, the government (at least ours) won’t hand out a passport randomly, right?

Well, a digital certificate is given out by special companies who give them out only after verifying the recipient’s identity properly, and so everyone trusts them. Even if you have never heard of VeriSign, Thawte, Valicert, or Entrust, your computer has heard of them. If you open your local certificate store, you can see them, as well as several others. To do so, open the Internet Control Panel, and switch to Content. Click on Publishers, and switch to Trusted Root Certificate Authorities, and voila:

Once you have a digital certificate, you install it on the server it was intended for, and then, your server can present it to clients which attempt to connect to it. These clients check if the certificate is a match to the server by comparing the server’s URL to the Common Name listed in the certificate. They also check if the certificate has not expired, if the certificate’s issuer is a trustworthy one, and if that issuer hasn’t revoked that certificate. If that is good and well, the whole encryption process discussed previously can continue. If something fails, the browser will alert you to that fact, and you can then decide if you want to take a risk and go ahead anyway, or walk away.

If you look at the previous screenshot, or your own computer’s Trusted Root Certification Authorities, you will notice that your browser comes with a pre-populated list of all major Certificate companies, but some companies don’t want to buy a certificate from them because it can cost a lot of money, hundreds of dollars in some cases. Instead, they set up their own Certificate Authorities within the organization. Anyone can do that really. In fact, all versions of Windows Server come with a built-in Certificate Authority server that can be enabled for free.

The challenge here is that such a server, by default, is not trusted by other computers unless they are configured to do so. This is done by installing the company’s Certificate Authority’s own certificate into each computer that needs to trust it. That could be a tedious process but, sometimes, it is inevitable.

So, going back to our HTTPS trunks, to enable computers on the internet to communicate with it securely, it has to be able to prove its identity to these computers by having a digital certificate. The rest of the encryption process is done automatically and there’s no need to worry about it. Getting the certificate, though, requires some planning. We already said that the client checks four things:

1. The certificate is issued by a trusted authority
2. The certificate’s URL matches the one it’s assigned to
3. The certificate has not expired (calendar-wise)
4. The certificate has not been revoked by the publisher