loading...

Windows Server 2019 – Obtaining a public-authority SSL certificate

How to install docker on windows 10

We are now pretty comfortable with grabbing certificates from our own CA server inside our own network, but what about handling those SSL certificates for our web servers that should be acquired from a public certification authority? For many of you, this will be the most common interaction that you have with certificates, and it’s very important to understand this side of the coin as well. When you need to acquire an SSL certificate from your public authority of choice, there is a three-step process to do so: create a certificate request, submit the certificate request, and install the resulting certificate. We are going to use my WEB1 server, on which I have a website running. Currently the site is only capable of handling HTTP traffic, but when we turn it loose on the internet we need to enable HTTPS to keep the information that is being submitted onto the site encrypted.

In order to use HTTPS, we need to install an SSL certificate onto the WEB1 server. This web server is running the Microsoft web services platform, Internet Information Services (IIS). The three-step process we take is the same if you are running a different web server, such as Apache, but the particular things that you have to do to accomplish these three steps will be different, because Apache or any other web server will have a different user interface than IIS. Since we are working on a Windows Server 2019 web server, we are utilizing IIS 10.

Public/private key pair

Before we jump into performing those three steps, let’s discuss why any of this even matters. You have probably heard of the term private key, but may not quite understand what that means. When we send traffic across the internet, from our client computers to an HTTPS website, we understand that the traffic is encrypted. This means that the packets are tied up in a nice little package before leaving my laptop so that nobody can see them while they travel, and are then unwrapped successfully when those packets reach the web server. My laptop uses a key to encrypt the traffic, and the server uses a key to decrypt that traffic, but how do they know what keys to use? There are two different kinds of encryption methodology that can be used here:

  • Symmetric encryption: The simpler method of encryption, symmetric means that there is a single key, and both sides utilize it. Traffic is packaged up using a key, and the same key is used to unwrap that traffic when it reaches its destination. Since this single key is the all-powerful Oz, you wouldn’t want it to get into the wrong hands, which means you would not be presenting it out on the Internet. Therefore, symmetric encryption is not generally used for protecting internet website traffic.
  • Asymmetric encryption: This is our focus with HTTPS traffic. Asymmetric encryption utilizes two keys: a public key and a private key. The public key is included inside your SSL certificate, and so anyone on the internet can contact your website and get the public key. Your laptop then uses that public key to encrypt the traffic, and sends it over to the web server. Why is this secure if the public key is broadcast to the entire internet? Because the traffic can only be decrypted by using a corresponding private key, which is securely stored on your web server. It is very important to maintain security over your private key and your web servers, and ensure that key doesn’t fall into anyone else’s pocket.

Creating a Certificate Signing Request

If your first step in acquiring an SSL certificate from your public CA entity was to log into their website, purchase a certificate, and immediately download it—you’ve already missed the boat. That certificate obviously would have no way of knowing about a private key that you might have sitting on your web server, and so that certificate would be effectively useless when installed anywhere.

When you install an SSL certificate onto a web server, it is very important that the certificate knows about your private key. How do we make sure that happens? This is where the Certificate Signing Request (CSR) comes into play. The first step in correctly acquiring an SSL certificate is to generate a CSR. When you create that file, the web server platform creates the private key that is needed, and hides it away on your server. The CSR is then created in such a way that it knows exactly how to interact with that private key, and you then utilize the CSR when you log into the CA’s website to request the certificate.

The private key is not inside the CSR, and your CA never knows what your private key is. This key is ultra important, and is only ever stored on your web server, inside your organization.

To generate a CSR, open up IIS from the Tools menu of Server Manager, and then click on the name of the web server from the navigational tree on the left side of your screen. This will populate a number of different applets into the center of the console. The one we want to work with is called Server Certificates. Go ahead and double-click on that:

Now, inside the Server Certificates screen, you can see any existing certificates that reside on the server listed here. This is where we ultimately need to see our new SSL certificate, so that we can utilize it inside our website properties when we are ready to turn on HTTPS. The first step to acquiring our new certificate is creating the certificate request to be used with our CA, and, if you take a look on the right side of your screen, you will see an Actions section, under which is listed Create Certificate Request…. Go ahead and click on that Action:

In the resulting wizard, you need to populate the information that will be stored within your SSL certificate. The Common name field is the most important piece of information here, it needs to be the DNS name that this certificate is going to protect. So basically, you enter the name of your website here. Then continue with filling out the rest of your company-specific information. A couple of special notes here that often seem to trip up admins are that the Organizational unit can be anything at all; I usually just enter the word Web. Make sure to spell out the name of your State; do not use an abbreviation:

On the Cryptographic Service Provider Properties page, you typically want to leave the Cryptographic service provider set to its default, unless you have a specialized crypto card in your server and are planning to use it for handling encryption processing for this website. On an IIS server, you will almost always have Microsoft RSA SChannel Cryptographic Provider listed here. What you do want to change, however, is the Bit length. The standard bit length for many years was 1,024, and that continues to be the default choice in Windows Server 2019. The general industry for SSL encryption has decided that 1,024 is too weak, and the new standard is 2,048. When you head onto your CA’s website to request a certificate, you will more than likely find that your request needs to have a minimum of 2,048 bits. So go ahead and change that drop-down setting to 2048:

The only thing left to do for our CSR is to give it a location and filename. Saving this csr as a text file is the normal way to go, and serves our purposes well because all we need to do when we request our certificate is open the file and then copy and paste the contents. You have now created your csr file, and we can utilize this file to request the certificate from our public CA.

Submitting the certificate request

Now, head over to the website for your public certification authority. Again, any of the companies that we mentioned earlier, such as GoDaddy or Verisign, are appropriate for this purpose. Each authority has its own look and feel for their web interface, so I cannot give you exact steps that need to be taken for this process. Once you have an account and log into the authority’s site, you should be able to find an option for purchasing an SSL certificate. Once that certificate has been purchased, there will be a process for requesting and deploying that certificate.

Once you enter the interface for building your new certificate, generally the only piece of information that the CA will ask you for is the contents of the csr file. If you open up the text file we saved earlier, you will see a big lump of nonsense:

This mess of data is exactly what the CA needs in order to create your new SSL certificate so that it knows how to interact with your web server’s private key. Only the server that generated the CSR will be able to accept and properly utilize the SSL certificate that is based on this CSR. Typically, all you need to do is copy the entire content of the csr file and paste it into the CA’s website.

Downloading and installing your certificate

Now you sit back and wait. Depending on which authority you are using and on how often your company purchases certificates from this authority, your certificate might be available for download almost immediately, or it could take a few hours before that certificate shows up in the available downloads list. The reason for this is that many of the CAs utilize human approval for new certificates, and you are literally waiting for someone to put eyes on the certificate request and your information to make sure you really work for the company and that you really own this domain name. Remember, the real benefit to a public SSL cert is that the CA is guaranteeing that the user of this certificate is the real deal, so they want to make sure they aren’t issuing a certificate for portal.contoso.com to someone in the Fabrikam organization by mistake.

Once you are able to download the certificate from the CA website, go ahead and copy it over to the web server from which we generated the CSR. It is critically important that you install this new certificate onto the same server. If you were to install this new certificate onto a different web server, one that did not generate the CSR this certificate was built from, that certificate would import successfully, but would not be able to function. Once again, this is because the private key that the certificate is planning to interact with would not be present on a different server.

Back inside the IIS management console, we can now use the next Action in that list on the right, called Complete Certificate Request…. This launches a short little wizard in which you find the new certificate file that you just downloaded, and import it into our server. Now that the certificate resides on the server, it is ready to be used by your website.

There is one additional item that I always check after installing or importing an SSL certificate. You can now see your new certificate listed inside IIS, and if you double-click on your new certificate you will see the properties page for the cert. On the General tab of these properties, take a look near the bottom. Your certificate should display a little key icon and the  You have a private key that corresponds to this certificate text. If you can see this message, your import was successful and the new certificate file matched up with the CSR perfectly. The server and certificate now share that critical private key information, and the SSL certificate will be able to work properly to protect our website. If you do not see this message, something went wrong in the process to request and download our certificate. If you do not see the message here, you need to start over by generating a new CSR, because the certificate file that you got back must not have been keyed appropriately against that CSR, or something along those lines. Without the you have a private key text at the bottom of this screen, your certificate will not validate traffic properly.

Here is an example of what it should look like when working correctly:

Comments are closed.

loading...