2021-04-12

Certificate Deep Dive - Part 1 - What's a Certificate?

[Nothing to do with the Operating System at the moment I'm afraid, but this is an article I have wanted to write for a while.]

A few years ago, if you had asked me what technical subjects felt I should know more about, I would have said Time Zones, Character Encoding, and most definitely Certificates, which we'll look at today.

Despite their widespread use and amazing utility, the lack of good information and the obscurity of the tools for working with them lead many software developers to never grasp the benefits of them.  Over the next few posts, we'll do a deep dive into Certificates and attempt to cover off as much information as possible to give a good grounding and reference of what certificates are, why you might want to use them, and much more besides.

So buckle up, everybody, this is going to be a long few articles just because there is a lot to cover.  This first one is broken down into a "Question & Answer" form where the questions should logically follow each other and each adds progressively more detail.  I have tried to ensure that everything in here is correct and isn't misleading, but I can't be held liable for anything you do with this and you're encouraged to do your own research as well.

[Speaking of character encoding, if you want to weep for the species about how little software developers understand the topic, this StackOverflow Question is a disturbing read.]

Contents


What is a Certificate?

A certificate is a file for storing a Subject Name and an Encryption Key (with a few other pieces of information) to make them easier and more secure to manage and distribute.  If we were to represent a certificate in JSON, it would look like this:

{
	"SubjectName": "example.com",
	"EncryptionKey": "b4e62412a4cacaa0943d64f58afa58f2",
	"OtherInformation": {  }
}

From a practical standpoint, this is all a certificate contains.  The Subject Name identifies the owner of the certificate (which can be an individual, a company, a website, etc.), and the Encryption Key provides a means of securely communicating with that owner.

This is clearly a massive simplification, but this is what should spring to mind when someone talks about a certificate.  If you're not previously familiar with certificates, this is probably the most important take away from this entire article.


To understand how a certificate provides a means of securely communicating with the subject, we need to understand more about how that all-important encryption key is used.  If you're already familiar with encryption, feel free to skip ahead, otherwise ...

What is Encryption?

[This is a brief overview to support the discussion on Certificates.  Please consult one of the many better and more authoritative descriptions of this process if you intend to use this as a basis for security.]

Encryption is the process of taking some data (which we call "Plain-Text" or "Clear-Text" data) and applying an algorithm and a key to convert the data into different data (which we call "Cipher-Text") which can then be converted back into the original plain-text with the algorithm and key.  The aim of the game is to deliver a message to someone without anyone else being able to read it.  The cipher-text data appears to be meaningless garbage and is useless to anyone who doesn't have the correct key to decrypt it.  The algorithm can be one of many different encryption algorithms (which people smarter than me have invented) such as AES, RC4, RSA, BlowFish, etc. and the "key" is a small blob of data, typically between 32 and 512 bytes depending on the algorithm.  Some algorithms can use any random bytes as the key, whereas others have a specific process for generating a valid key.

The encryption algorithms fall into one of two types; "Symmetric Encryption" is where a single Key is created which is used to both encrypt and decrypt the data, and "Asymmetric Encryption" where a Key Pair is created and one part of the pair used to encrypt the data and the other part used to decrypt.

For this article, we're only interested in Asymmetric encryption.  The two parts of the Key Pair are typically referred to as the Public Key and the Private Key.  The Public key is used to Encrypt some data, and that data can then only be decrypted by the corresponding Private Key.  The creator of the Key Pair will keep the Private Key secret so only they can decrypt data which was encrypted with their Public Key.  This behaviour can be used to prove that someone has the corresponding Private Key without them having to reveal it, and this can be used to provide "authentication" that the other party is who they claim to be. 

But wait, there's more! 

In addition to encryption, the Asymmetric Key Pair can also be used for a process called "Signing" which is where a Hash of the data (using an agreed Hashing Algorithm such as SHA-2, SHA-1, MD5, CRC32, etc.) is signed using the Private Key, and that signature can be verified using the Public Key.  This is used to ensure that the data has not been modified.  The signature can only be generated by someone who holds the corresponding Private Key, so again allows someone to prove they hold the Private Key without them having to reveal it.  In practice, "Signing" is a nearly identical process to encryption with the keys being used the other way around, but to keep things clear the convention is that:

  • The Public Key is used for Encryption and Verifying a Signature, and
  • The Private Key is used for Decryption and Creating a Signature.

For the rest of this discussion, when I talk about encryption, I'll be specifically talking about Asymmetric RSA Encryption.  While certificates containing RSA keys are becoming less common these days, the principles with regard to certificates apply all the same.

How does Asymmetric Encryption help with security?

This is best demonstrated with a worked example.  In cryptography, examples are usually given in terms of Alice and Bob, two fictional characters who want to communicate securely across the lawless internet where all data is up for grabs, and where nefarians lurk around every router and behind every proxy.
[Would you like to know more? Wikipedia or XKCD.]

The first step to secure communication is for Alice and Bob to each create an RSA Public-Private Key Pair.  Alice runs a key pair creation tool which outputs the public and private keys as two blobs of data, and saves these out to two files.  It uses random data in the process so that her key is unique.  She puts the private key blob (typically as a PVK or PFX file) somewhere safe, and does not share it with anyone.  Meanwhile, Bob does the same, keeping his private key safe.  The two then meet up in person and Alice gives Bob a copy of her public key file, and Bob gives Alice a copy of his public key file.  The two are now set up to communicate securely.

Alice now wants to send a message to Bob so that only he can read it.  She writes out her message, encrypts it with Bob's public key, and sends the encrypted message over the internet.  Bob receives the encrypted message and uses Bob's private key to decrypt it and read it.  As this data can only be decrypted by Bob's private key (which Bob keeps private), Alice knows that only Bob can read her message.  Similarly, Bob can reply by encrypting a message with Alice's public key, and send the data over the internet knowing that only Alice's private key (which Alice keeps private) can decrypt it.  There we have the basics of secure communication, tada.wav.

[As an aside, Asymmetric encryption is typically much slower than Symmetric encryption, and usually has a limit on the amount of data that can be encrypted.  It is more likely that Alice will encrypt the message with a Symmetric algorithm such as AES using a key she generates for that message (a Session key).  She would then use Bob's public key to encrypt the AES key, and send the AES-encrypted message along with the RSA-encrypted key, but that's not important right now.]

While using the keys in this manner prevents Information Disclosure (because no-one can read the message except the intended recipient), it doesn't prevent Spoofing.  Meet the nefarious Mallory.  Mallory wants to send a message to Bob, but pretending to be from Alice.  As long as Mallory has Bob's public key (which is not considered secret data) and remembers to end her message with "Love, Alice x", Bob may have no way to spot the deception.  As you may have guessed, this is where Signing comes in.

Alice can write a message, and then use a Hashing Algorithm to generate a short Hash of the original content.  Alice then uses her private key and the Hash value to generate a Signature (again, this can be thought of as Alice using her private key to "encrypt" the Hash data ready for her public key to "decrypt", but by convention it is called "Generating a Signature").  Alice then Encrypts the original message with Bob's public key just as before, and both the encrypted message and the signature (the "encrypted" hash value) are sent to Bob.  Bob receives the encrypted message and decrypts it as before, except now he also has the signature value.  Bob generates his own hash of the decrypted message using the same hashing algorithm, and can use the signature he received and the hash he generates along with Alice's public key to verify the signature and determine if the message has been tampered with.

The choice of hashing algorithm is critical in situations such as this.  If a nefarious individual can change the body of the message in such a way that it hashes to the same value (they deliberately cause a "hash collision"), then the signature verification will still succeed, even though the data has been changed.  In recent years, both MD5 and SHA-1 have been demonstrated to be weak to collision attacks like this (because of the discovery of weaknesses and the availability of greater computing power), so there has been a push to use stronger hashing algorithms for security applications, such as SHA-2 (SHA-256, SHA-384, SHA-512, etc.)  (Note that even though MD5 and SHA-1 should not be used for security-sensitive operations, they are still useful algorithms for many other situations.)

So, certificates?

As we said above, a certificate is a file for storing a Subject Name and an Encryption Key to make them easier and more secure to manage and distribute. While Alice could have given Bob a raw file with her public key in it, it would be much better for her to have put her public key into a certificate and give that to Bob, a little bit like this:

{
	"SubjectName": "Alice",
	"EncryptionKey": "43b91deb3c14737a909408257e9fc411",
	"OtherInformation": {  }
}


Not only does this file now identify that the encryption key is the public key for Alice, it allows the use of several other features of certificates to prevent various possible attacks on this part of the process, such as adding a signature to the certificate to prove it hasn't been tampered with.

What is a Certificate Signature?

The certificate above is great for transporting the required Subject Name and Encryption Key, but it isn't secure.  All the data in the certificate is considered public and there is no protection against tampering, so a nefarian could take a certificate, replace the encryption key, and send it on to someone.  If the recipient then used the encryption key, the nefarian could decrypt and alter any messages with a classic Man-In-The-Middle (MITM) attack.

To protect against this, a certificate takes the idea of message signing, and applies it to the certificate file itself.  That way, any tampering with the certificate file can be detected.

As above, to generate a signature of some data we need a Hashing Algorithm (such as SHA-2, SHA-1, MD5, CRC32, etc.) and a private key.  In the certificate, we'll separate the data that is included in the hash from the signature itself by adding a new level into our certificate file, and include the signature value and the algorithm.  We will also need to identify which public-private key pair was used to generate the signature by including the Subject Name of a certificate that contains the public key.

Our simple model of a certificate now looks like this:

{
	"TBSCertificate":
	{
		"SubjectName": "example.com",
		"EncryptionKey": "b4e62412a4cacaa0943d64f58afa58f2",
		"Issuer": "SigningKeySubjectName",
		"OtherInformation": {  }
	},
	"SignatureAlgorithm": "MD5-RSA",
	"SignatureValue": "fGJjfShPI1tcREE9SERveFF8WHhh"
}

We'll shortly come onto why the key used to sign this certificate is called the "Issuer", but for now know that it identifies another certificate, and therefore a public-private key pair.

The recipient of the certificate can now check that it is valid by fetching the certificate identified by the "Issuer" field to get the public key, then hashing and verifying the signature.  This assumes that the person who is verifying the signature either already has or can get (and validate and trust) the matching certificate from the issuer.  Most systems (such as TLS) will send both its own and the issuer certificate at the same time.

What is a Self-Signed certificate?

Having talked about certificate signatures above (and added a few more fields to our JSON certificate), I should add that all certificates contain a signature.  Most will have been signed using the key pair from a trusted third party (an "issuer"), but they can also have been signed using the key pair that the certificate represents.  This is called a "Self-Signed" certificate".

When Alice generated her first certificate, it would have been a self-signed certificate.  The tool she used would have created a Public-Private key pair, put the Public Key into a new certificate, then used the Private Key to sign the certificate it just created.  It would have looked something like this:

{
	"TBSCertificate":
	{
		"SubjectName": "Alice",
		"EncryptionKey": "43b91deb3c14737a909408257e9fc411",
		"Issuer": "Alice",
		"OtherInformation": {  }
	},
	"SignatureAlgorithm": "MD5-RSA",
	"SignatureValue": "cDVmM2soOF8yLUZuV340eWc6IndHV1A="
}

Anyone receiving this certificate can check that it is valid (as the Public Key it contains should validate its own signature).  However, as anybody could create a new certificate with "Alice" as the subject name, a self-signed certificate should not necessarily be considered genuine.  The authenticity of the certificate should be checked by other means, such as exchanging in person, or some other communication which is secure and the identity of the other party has already been confirmed. 

Self-signed certificates are used for a Certificate Authority's Root certificate (more on them later), and are also commonly used for testing or personal certificates.

How does a Certificate help with trust?

In our above example, Alice and Bob can trust that the certificate (and therefore the Public Key) they have for each other is genuine because we had them meet in person to exchange them.  So what if they can't meet up?  For this, we need what is called a "Trusted Third Party".  This is someone that both Alice and Bob trust that can take Alice's Public Key and give it to Bob, and Bob's Public Key and give it to Alice, such as their mutual friend, Ted.

Ted has his own Public-Private key pair, and he has previously met up with Alice to exchange public keys, and with Bob to exchange public keys.  Now Alice asks Ted to give her Public key to Bob.  Ted could go to see Bob in person and deliver it that way, but Bob lives far away.  Given that Ted can already communicate securely with Bob, he could also just send Alice's Public Key securely and directly that way.  This might work to share Alice's key in one or two instances, but it doesn't scale well.  We can use the the idea of certificate signing to do better.

Ted takes Alice's self-signed certificate (which contains Alice's name and her Public Key) and generates his own signature of it, as detailed above.  He then creates a version of Alice's certificate with himself as the Issuer and the signature he just generated as the Signature Value.

{
	"TBSCertificate":
	{
		"SubjectName": "Alice",
		"EncryptionKey": "43b91deb3c14737a909408257e9fc411",
		"Issuer": "Ted",
		"OtherInformation": {  }
	},
	"SignatureAlgorithm": "MD5-RSA",
	"SignatureValue": "d3tNfTg6XGhUZHR8QjNuVXx7WDxvb2x7YA=="
}

With this, Ted is saying "I trust that this is Alice's certificate" and that anyone that trusts Ted (and has Ted's certificate) can verify the signature of this certificate, and trust that it is genuine and has not been tampered with.

Alice can now send this new certificate (that is signed by Ted) over to Bob without any encryption or authentication.  As Bob already has Ted's Public Key, he can verify the signature to confirm that "Ted says this is Alice's certificate" and that the certificate wasn't changed between Ted signing it and him receiving it.  Bob now has Alice's Public Key, and can trust that it is genuine (as far as he can trust Ted).

By having one certificate as the Issuer for another like this, we start to build up a certificate chain ...

What is a Certificate Chain?

The certificate that Ted signed for Alice above is now part of a certificate chain with two links.  One link in the chain is Alice's certificate, the other is Ted's certificate which is used to verify the signature in Alice's certificate.  Alice can send her certificate to Bob, and as Bob already trusts Ted, he can trust that certificate is Alice's and has not been tampered with.  

We could theoretically create certificate chains that are infinitely long, or that contain loops, but both scenarios are interesting curiosities and neither serves to improve security.  The more certificates there are in the chain, the greater the chance that a private key will be leaked or cracked, or that a hash-collision is found, or that one issuer didn't properly check the identity of the requestor, or that some other vulnerability could be exploited.

All certificate chains will start as with what is called a "Root" certificate, which is a self-signed certificate that has to be explicitly trusted.  From there, the Root certificate signs several other certificates, called "Intermediate" certificates, then finally the Intermediate certificates are used to sign "End-Entity" certificates that actually represent some person, website, or other entity.  While the End-Entity certificate can look back toward the Root certificate and sees only a chain of certificates, from the Root certificate's perspective the certificates form a tree.

[Aside: There is one more wrinkle here in that because a certificate identifies the Issuer certificate by its Subject Name, it's possible to have multiple possible certificates that match this subject name, and it's possible that more than one of these potential Issuer certificates can successfully validate the End-Entity certificate.  This is sometimes (but rarely) done deliberately in a process called "Cross-Signing".] 

What use are Intermediate Certificates?

A Certificate Authority will have a small number of Root certificates, sometimes only one or two, which will last for possibly 20 to 50 years.  The Private keys to these Root certificates are extremely closely guarded because anyone who has these can sign any certificate they like, and anyone who trusts the Certificate Authority, will trust these new certificates.  Also, replacing Root certificates is complicated.

By introducing Intermediate certificates into the mix, the Certificate Authority gain several benefits, such as:

  • The closely guarded Root certificate Private key can be locked away, and only ever used to sign a new Intermediate Certificate.
  • Intermediate certificates allow the Certificate Authority to break up the certificates they issue into smaller groups, so if one Intermediate certificate Private key is compromised, only certificates issued from that Intermediate need be distrusted.
  • The main Certificate Authority can authorise resellers of their certificates by issuing them an Intermediate certificate.  The reseller never gets to see the Root certificate Private key.
  • Intermediate certificates can be created and retired much more frequently then Root certificates as they do not have to be explicitly trusted by everyone.

There is a process whereby a Certificate Authority can make people aware if a Private key is leaked or a signed certificate discovered to be fraudulent, by publishing what is called a Certificate Revocation List (CRL).  Briefly, when certificate software is validating a certificate, it should download the Issuer's CRL file from a URL that is stored in an extension of an Issuer certificate, and check to see if the End entity certificate has been flagged as revoked.

I've never Trusted any Certificate Authorities, how am I using secure websites?

Most computer users don't explicitly manage the Root certificates that their computer trusts (I'm certain some do, hence why I said "most"), and instead the creator of their Operating System or TLS software has decided which Root certificates to trust on your behalf.

On Windows, most secure communications such as TLS are done using a part of Windows called SChannel (Secure Channel), which has a set of "Trusted Root Certificate Authorities" which it considers trustworthy.  Microsoft decides which Certificate Authorities to trust, and periodically sends Windows Updates to update this set of Trusted Certificates as new certificates are to be added or old ones removed.  [At least it used to be Windows Updates, these days it might actually be polled from the computer.]

If you want to see these, you can use the Windows Run command to run "certmgr.msc" to see what is in here.  However, I would recommend against adding or removing anything from here as you can break your Windows very very quickly.  Here's a snapshot of what this looks like:

Mozilla Firefox has its own implementation of TLS and its own trusted certificates, regardless of the operating system it's running on.  To see these, open the Firefox settings, select "Privacy & Security", then "View Certificates...".  This looks like this:



On Linux and Unix, TLS is normally provided by the OpenSSL project, but the decision of which certificates to trust may be made by the creator of the distribution in question, such as Ubuntu.

Unfortunately, there have been incidents where companies have overstepped their bounds and jeopardised the security of their customers by adding Root certificates into the trusted store that should not have been there.  One infamous example is when Lenovo included the "Superfish" advertising software when they pre-installed Windows with their laptops in 2014.  The software installed a Superfish trusted root certificate onto all Lenovo machines so that the software could inject adverts into paged served over HTTPS.  However, the software used the same Root certificate on all machines, and included the Private key.  This meant that a nefarian could get the Private key from any of these laptops and use it to sign their own certificates that would be trusted by any Lenovo laptops.

What is a Certificate Signing Request (CSR)?

Above, when Alice wanted to have Ted sign her certificate, she sent a complete, self-signed certificate to Ted for him to sign.  However, more usually, Alice would use her software to create a Certificate Signing Request (CSR) file, which she would have then sent to Ted.  In practice, a CSR contains almost all the same information as a certificate, but its intended use is specifically to send to a third party to have them create a signed certificate from it.  One difference is that a CSR doesn't contain an "Issuer" field as it can only ever be self-signed.

When Alice ran the key generation tool on her computer, it would generate a new Public-Private key pair, put the Public key into a Certificate Signing Request, use the Private Key to sign the CSR, and would then save out two files, one containing the CSR itself and the other containing Private Key.

Alice would then send the CSR to Ted, and Ted would create a certificate from the information in the CSR, sign it with his Private key, and send the completed and signed certificate back to Alice.  Along the way, Ted would also have performed some checks to ensure that it was really Alice making the request so that he didn't give his signature to a certificate that had "Alice" as the subject name, but wasn't for Alice (I bet it's that Mallory again).

Note as well that just like the Certificate, the CSR only contains the Public Key from the Public-Private key pair, so it is not considered secret data.  The big benefit of this is that the Private key (the really super secret part of the process) never has to leave the computer that generated it.

What is Cross-Signing?

While it sounds complicated, Cross-Signing is where two Intermediate certificates have the same Subject and the same Public key, but are signed by different Root certificates.  Technically this means that any End-Entity certificates with that as their Issuer is part of two separate Certificate Chains.  They are used in situations where one of the two Root certificates is not trusted, but the other is.

TLS software typically checks all Subject matches recursively when looking for the correct Issuer certificate to validate a signature, so will try each of the chains until it finds a trusted Root certificate.

The only time I know of cross-signing having been widely used was in 2018.  The Symantec corporation used to be a Certificate Authority, and had their Root certificates included on most devices as trusted Root certificates.  However, after several incidents where Symantec-issued certificates were found to be issued mistakenly or to non-genuine requests, many TLS-providers decided to stop trusting Symantec Root certificates.

Symantec decided to stop being a Certificate Authority and transferred that part of their business to a separate Certificate Authority called DigiCert.  In order to allow anyone with a Symantec-Issued certificate to continue using it until it expired, DigiCert signed and distributed a copy of Symantec's Intermediate certificate.  That way, Symantec's Root certificate was no longer required to be trusted as the End-entity certificates would validate via this new Intermediate certificate to DigiCert's Root certificate.

The investigation and decision to no longer trust Symantec's Certification Authority was performed by a group called the CA/Browser Forum.

[Would you like to know more?  Chromium discussion on Google Groups, Mozilla list of Symantec issues]

Who are the CA/Browser Forum?

From their website https://cabforum.org/ :

"Organized in 2005, we are a voluntary group of certification authorities (CAs), vendors of Internet browser software, and suppliers of other applications that use X.509 v.3 digital certificates for SSL/TLS and code signing."

They are responsible for agreeing how Certificate-based trust should work on the internet (with a particular focus on HTTPS).   They produce a document called the Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates which details how Certificate Authorities should check the requestor's identity, agree how long a certificate should be valid for, what features should be used to protect against certain attacks, and much more besides.

While the forum members don't have to abide by the decisions of the forum, having an organisation such as this in the background prevents widescale problems with HTTPS and others uses of TLS.  When was the last time you found a website that was trusted in Firefox, but not in Edge?  Can you imagine the frustration that webmasters globally would face trying to work out why their site wasn't considered secure in that one browser, and then trying to argue with either the Certification Authority or the browser supplier to fix the discovered issue?

How does a Certificate Authority become a Certificate Authority?

From a technical standpoint, becoming a certificate authority is easy; generate a root certificate and some intermediate certificates, and start offering a service to take a certificate signing requests and return a signed certificate.

If you want to become your own certificate authority for experimenting, that's easy as you should be able to trust yourself.  Once you have generated a root certificate, install that certificate into the trusted root store of your computers.  Don't forget to protect the root certificate's private key from theft.

The bigger problem is convincing people to add your Root certificate to their store of Trusted Root certificates, and therefore trust that you will only issue certificates to genuine requests.  You can do this for fun with a few friends easily enough, but companies spend a lot of time and money auditing and demonstrating that they are trustworthy enough to be included in global trusted root stores.

You may find that even after you have generated and installed all the required certificates, the website is not trusted by browsers, or has security warnings displayed.  Usually this is down to the browser itself performing extra checks on the values in the certificate, as defined by the CA/Browser Forum Baseline Requirements discussed above.  For example, certificates must contain a Subject Alternate Name (SAN) extension field which includes the domain name as well as it being the certificate Subject, and the expiry date of the certificate cannot be too far in the future.

Secure Sockets Layer (SSL) is just what Transport-Level Security (TLS) was called before Netscape (who created it in 1995) gave it over to the Internet Engineering Task Force (IETF) in 1999.  Given that it was called SSL for only four years, and has been TLS for over twenty, can we please stop calling it SSL?  /soapbox

Transport-Level Security (TLS) is used across the internet to protect lots of different protocols by adding an encrypted layer to it, and uses certificates to establish the identity of the server (and sometimes the client).  Web traffic, file transfer, email transfer, and many many other protocols which were initially unencrypted now have variants which use TLS to authenticate and encrypt their traffic.

What are these Certificate Tools you keep talking about?

As certificates and their private keys are simply files to be manipulated, you might think that there are plenty of tools around to work on them, but that is unfortunately not the case.  I have detailed some tools below (apologies for the Windows-centric view, but that is the platform with which I am most familiar).

Windows PowerShell:

Windows' own command line PowerShell has several cmdlets for handling certificates in the PKIClient module including one to generate a new self-signed certificate from scratch.  However, I'm not sure this includes the ability to generate arbitrary CSRs or to convert a CSR into a signed certificate against an issuer.

Windows Makecert:

Another Windows command-line tool called Makecert is a deprecated tool for handling certificates.  It can be used to generate new self-signed certificates, and can create new Intermediate and End-entity certificates signed by an issuer.  However, it cannot process CSR files so cannot use a given Public key, instead generating a new Public-Private key pair with each certificate.  Because of this, the Private key has to be moved from computer to computer, making it vulnerable to theft.

OpenSSL:

Another command-line tool is OpenSSL, and it's the big daddy of command line tools outside of Windows.  It can (probably) do everything that you might want to sensibly do with a certificate, CSR, or Private key.

However, understanding the command arguments is an art in itself as they are arcane.  Another consideration is that OpenSSL does not provide Windows binaries themselves, instead relying on third parties.

Windows Certificate Manager:

A GUI tool on Windows (provided as a snap-in to MMC) is certmgr.msc.  This can be started from the Windows "Run" box (with Windows key + R), or can be added into a running instance of MMC using the "Add/Remove Snap-ins" menu option.

As well as providing the ability to view the trusted Root certificates installed on your machine, it allows the creation of a customer certificate signing request with custom subject and private key parameters.



Windows IIS Manager

Another MMC snap-in is the Windows IIS Manager (inetmgr.exe).  The Server Certificates module provides the ability to generate Certificate Signing Requests.  However, last I checked, this method of creating a CSR would only ever use SHA-1 as the signature hash algorithm which has not been considered sufficiently secure for several years now.


Are there any online tools I can use?

BadSSL.com

This site can test how your system handles various certificate and TLS features by using its various subdomains, each configured in a specific way.  The root page makes requests to all the subdomains to give a report of how your system performed.  It's also useful to see examples of different certificate features.  Of particular interest is 10000-sans.badssl.com which attempts to use a certificate that is nearly 200KB in size, I'll talk more about this in the next instalment.

Qualys SSL Labs

This site provides several tools for testing client and server systems for known certificate and TLS vulnerabilities and weaknesses.  It also contains an analysis of the features and vulnerabilities present on the world's top websites

DigiCert SSL Tools

DigiCert provide very comprehensive instructions on how to generate Certificate Signing Requests for various platforms, as well as having an online tool to take a CSR and display its content.    Remember that the CSR itself does not contain any secret information, so pasting a CSR in here is not a security issue.  The all-important private key never leaves the computer that generated the CSR.

How does a Webmaster get a TLS certificate?

One of the most common scenarios that a webmaster (someone who runs a webserver) would like a TLS certificate to be able to use HTTPS so that visitors can communicate securely with it.

  1. The webmaster chooses a Certificate Authority (CA) to use, such as VeriSign, DigiCert, GoDaddy, etc.
  2. The webmaster runs a tool on the web server to generate a Certificate Signing Request and a Private Key.  The CSR only contains the Public Key, so it can be safely sent to the Certificate Authority.  The secret Private key never leaves the web server.
  3. The webmaster sends the CSR (containing only the Public Key) to the Certificate Authority, along with an order for the type of certificate they want, and usually some payment.
  4. The Certificate Authority will ask the webmaster to somehow demonstrate that they are authorised to have a certificate for the website in question.  Typically this involves the CA asking the webmaster to host a file on the website, or to add a DNS TXT record to the domain in question.
  5. Once the Certificate Authority is satisfied that the webmaster's request is genuine, they create the new certificate by copying the Public Key from the CSR, signing it with their key, and returning the completed certificate to the webmaster.  
  6. The webmaster will take the certificate and put it back onto the web server that generated the request.  The certificate with the Public Key is now reunited with the matching Private Key, and the signing process is complete.
  7. The webmaster then may have to configure any web services (such as a web server like Apache or IIS) to use the newly installed certificate.

What about LetsEncrypt?

While most Certificate Authorities work in the traditional way described above, there are some that work more practically.  LetsEncrypt, for example, has the webmaster install a service on the webserver that can communicate back and forth with the CA on a daily basis.  The LetsEncrypt CA can easily prove that the requestor has authority to request for that domain because their automatic system can send a request to that domain name and have the service answer.   Not only is the entire system of certificate requesting and renewals completely automated, they also (at least at present) provide the service for free.


Closing Thoughts

While this is a huge wall of text, I'm hoping this can be viewed as a brief (lol) overview of certificates, Public key cryptography, TLS, and a lot more besides.  There will be mistakes and issues in here, so please comment any issues you may spot or are unsure about.

In the next part of this series, I'm going to look more at the actual files and the data that underpins this.


Posted by at
Labels:

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)