If You Plan To Use SSL, Read This First

2 keysIf you plan to use secure communications over the internet, then you will use SSL, either to encrypt some types of VPN traffic, encrypt WebDAV file transfers, or for HTTPS. SSL requires you to become familiar with certificates and several otherwise obscure and abstract concepts. Some people have a head for this and grasp SSL easily. I suspect most will find it difficult to keep all the bits and pieces straight and will have to go over this a few times. I will keep it as simple as possible. If you decide you are fascinated with SSL and have discovered a new career, Amazon has many books on PKI, SSL, and web encryption.

SSL requires certificates. With respect to SSL, the word certificate is quite abstract and the newcomer will quickly become confused with all the nuanced ways the term is applied. I’ll step through it slowly and simply, but still give you enough information to move forward.

By the way, a certificate is just a little file. If you opened one up in a text editor, you would see a long string of characters. It would look unintelligible, except for the first line and last line, which says ‘BEGINNING OF CERTIFICATE’ and ‘END OF CERTIFICATE’. It is fairly common to open up one of these files with notepad and use copy and paste to transfer the contents to an online form, rather than import the file. Sometimes you can import and export the entire file. It depends on the application.

Why not get a free commercial certificate?

At this point, you might be thinking, “Thanks, but I’ll just get a free one from or someone else.” OK by me, if they let you. Some of the commercial providers, called Certificate Authorities, offer free and low cost SSL certificates to small sites for various purposes. Maybe someday later you’ll upgrade to a more costly one that offers greater assurance. But even to get a free one, you need to provide proof of identity. If you are using free or low cost Dynamic DNS (DDNS) for a small home site, then a verifiable email address associated with your DDNS name will be nearly impossible to provide. In general, you can’t buy an SSL certificate for a website you don’t own. No whois record is available for the address associated with a DDNS site. There’s nothing for the certificate authority to validate.

More on DDNS later.

If you can’t buy one, you’ll have to make one

If you are interested in keeping your network personal and the only people who access it over the internet will be you and people known to you, then you can become you own Certificate Authority and use self-signed certificates. You can make them yourself using a free open source program called OpenSSL or by using features of Windows Server 2012. If you plan to make a public web site and expect to offer HTTPS, then you will need to purchase a signed certificate from a public Certificate Authority such as GoDaddy.

The signed certificate associated with the secure web site, among other things, states that the entity who signed it guarantees the web address is who it claims to be. A public Certificate Authority is a third party who guarantees a web site identity, much like the state guarantying your driver’s license.

If you are using self signed certificates, then you are proving your own identity to yourself. This is fine for small home networks where no outsiders will need secure access.

What do the big sites do?

Amazon, for example, could not use a self signed certificate for customer transactions. In principle, it would be no different from you printing your own driver’s license. A public Certificate Authority must first validate that Amazon is really Amazon. When it signs Amazon’s certificate and the signing authority has a copy of its root certificate in the trusted certificate store of your browser or pc, then you can be sure Amazon is Amazon.

All public certificate authorities provide root certificates that are automatically installed into the trusted root certificate store all browsers and all personal computers. The trusted root certificate store is a standard feature of the browser and operating system. If the web site certificate is signed by a Certificate Authority known to your browser or computer via the root certificate, and if some special encryption things and other validations behind the scene check out, then you won’t get a warning that the site you are browsing is not secure.

What do home sites do?

At home, if you are using the certificate for SSL based VPN connections, it probably won’t connect without a valid SSL certificate that ties back to a valid root certificate. The properly authenticated root certificate (on the PC) and SSL certificate (at the server) will encrypt all communication between you and your endpoint and assure you that you are communicating with who you think you are communicating. With self signed certificates, you make your own root certificate and SSL certificate. You install your root certificate in the same place as the commercial root certificates. The SSL certificate is installed on the server.

How do you make certificates?

Windows Server 2012 Active Directory Certificate Services requires an elaborate method to create an SSL certificate suitable for an SSTP VPN. Microsoft  Information Information Services (IIS) can also create secure certificates for private use.

If your interests don’t include Windows Server 2012, you use an open source program called OpenSSL to make your certificates. It’s free. You download it from the internet. OpenSSL is a powerful program that is well known, trusted, and in common use. IBM and Citrix are two companies that have web pages explaining how to use OpenSSL in relation to products they promote.

[April 13, 2014 Heartbleed bug update: OpenSSL has a recently discovered security bug called Heartbleed that is said to have been repaired starting with version 1.01g and above. Version 1.02 will be secure, according to articles available on the internet. The bug will allow a knowledgeable hacker to pierce a part of the encryption so that much is in the clear. More information is available here.]

Before getting too wrapped up with OpenSSL, you first have to decide if you will be using Windows Server 2012 Essentials to a significant degree. Windows Server 2012 is tightly integrated with Active Directory Certificate Services (AD CS) and it’s installed by default on Windows Server 2012 Essentials. Anywhere Access will not work with OpenSSL, but you can use an Internet Information Services (IIS) option to configure an SSL domain certificate that does.

If most or all of what you plan is Windows Server centric then using AD CS may be a better choice for filling your SSL certificate needs.  While OpenSSL will work for a couple of functions on Windows Server 2012, it’s not a standard way to approach certificate management.

OpenSSL works well with with Windows clients configured as WebDAV servers. You can also add HTTPS to your web site, providing you intend to keep access private.

OpenSSL is the only available tool for SSL access to network attached storage (NAS) devices unless you can purchase a certificate.

And, if you want, you can use OpenSSL to manage limited forms of secure communication on Windows Server 2012.

Then what do you do?

If you plan to use Windows Server 2012 AD CS exclusively, then what follows will be informative, but less applicable. Windows Server does a lot for you behind the scene, but not everything. Being familiar with the following concepts will make all aspects of certificate management easier to understand and implement.

If you plan to use OpenSSL for your SSL needs, then read on.

This is where the terminology gets a little confusing if you’ve never been exposed to it. The terms to remember are private key, root certificate, public key, trusted root certificate store, certificate signing request (CSR), and SSL certificate. They follow a logical sequence in the process.

First,  you create a private key. You then use the private key to create the root certificate. The private key helps calculate the public key that goes into the root certificate. You set the private key aside for other purposes, later. You do this only once.

Afterward, for every PC that will connect to the server as a VPN or WebDAV client, you import that root certificate into your PC’s trusted root certificate store. If you plan to use a browser and HTTPS, you import your root certificate into each browser that does not use the client computer certificate store. The root certificate also resides in the server’s trusted root certificate store. The root certificate will validate the SSL certificate you create later.

If you make a mistake anywhere along the way, just delete what you imported, fix the mistake, and import a new certificate.

When you are ready to make the SSL certificate for your web site or VPN, you will take the root certificate, the private key, and a certificate signing request and use OpenSSL to create an SSL certificate. More about the CSR later.

If you’re using Windows Server 2012, all domain members automatically receive a copy of the root certificate that was created when the Active Directory Certificate Services role  was installed.  Clients not a part of the domain need to have the root certificate installed manually.

Finally, you might have to add a line to a section of the windows registry on each computer that will use SSTP based communication, even if you use a purchased certificate a purchased certificate. More on that later.

How does SSL work?

When a computer, tablet, or phone connects to a secure site, the SSL certificate and the PC negotiate a bit and check each other out. The SSL certificate sends some info back to the client. The trusted root certificate verifies the SSL certificate was signed by a known certificate authority then they verify that nothing is expired or revoked. If there’s a problem you get the ‘untrusted site’ browser message or the VPN may not connect.

If there’s no problem, the SSL certificate sends its public key to the client. Then the two sides agree on a session key, which does most of the actual encryption in the overall connection. The session key may change during the transaction for the purpose of additional security, but you never notice as a user. The client and server do the work.

Basically, the public key encrypts and the private key decrypts. Anyone can get a copy of the public key. You keep the private key a secret. A message encrypted by a public key can only be decrypted by its associated private key. Both sides share the same session key, which they make up. It takes less computing power to use a shared session key. The public key encrypts the session key and the private key decrypts it. The decrypted session key does the rest of the work.


Learning about certificates and the theory behind them is difficult. This explanation was intentionally kept light. Most traditional explanations of PKI (Public Key Infrastructure) follow a pattern that quickly gets into jargon and encryption theory. Bob and Alice are the official representatives of PKI education and show up in most, if not all books on the subject. SSL may or may not even be mentioned in your reading material. Then, after learning about PKI, you usually have no idea how to implement PKI. A lot of what Google offers is dense, fragmented, wrong, correct but not applicable to you, but plentiful. Some is also pretty good. YouTube has videos about everything.

I chose to keep it lighter and focus on what you need to know to complete tasks important to you.


Have Something To Add?

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.