Public Key Infrastructure Explained | Everything you need to know

Here on the Hyper-V Dojo Blog I, of course, focus on Hyper-V, but it frequently intersects several other technologies that administrators need to work with which means those are also highly relevant for Hyper-V users. Of these, public key infrastructure (PKI) and its components – most importantly, certificates – remain poorly understood, and therefore poorly implemented. In Hyper-V, we employ PKI for Shielded VMs and replication. Beyond that, we have hordes of other uses for certificates; websites, code signing, secure e-mail, and Windows Admin Center, to name a few. With the complexity behind encryption technologies and the arcane nature of related tools, I find that many in IT tend to avoid the entire technology group as too complex. In reality, I could probably stand in front of a classroom and deliver all of the most important aspects of PKI in fifteen minutes.

Since I haven’t got a classroom handy and I would like to distribute this information far and wide, I will use this article to explain the technology. I will refer back to it in future articles.

Before we get started, here’s a quick table of contents if you want to skip to a certain section.

1. 1. What is Public Key Infrastructure (PKI)
   2. The Core Use of PKI and Certificates
   3. A Very Brief Introduction to Digital Encryption
      1. Encoding and Encryption Ciphers
      2. Keyed Encryption Ciphers
      3. Symmetric Encryption
      4. Asymmetric Encryption
   4. PKI Identification
   5. The PKI Certificate Issuance Process
   6. The PKI Certificate Validation Process
      1. Why Not Contact the Certification Authority During Validation?
   7. The PKI Certificate Revocation Process
   8. PKI Identity Verification Visualization
   9. Certificate Signing Operations
   10. SSL Encrypted Communications
   11. Offline Certification Authority
       1. The Risks of an Online Root Certification Authority
       2. Offline CA Creation Process
       3. An Offline CA Without a CRL
   12. What IS a Certification Authority?
       1. Does a Certification Authority Require a CRL?
   13. The Dangers of Self-Signed Certificates
   14. Going Further with PKI

1. What is Public Key Infrastructure (PKI)?

A public key infrastructure or PKI establishes a digital trust hierarchy in which a central authority securely verifies the identity of objects. We commonly use PKI to certify users and computers. It functions by maintaining, distributing, validating, and revoking SSL/TLS certificates built from the public key of public/private key pairs.

There are many associated terms connected to public key infrastructure you’ll need to be familiar with so I’ll lay them out here. You don’t necessarily need to memorize these, or even understand all of them at this stage – you might even want to skim or even skip this section and just use it as a reference later. I have deliberately kept these descriptions simple to stay within the scope of the article.

• SSL: “SSL” stands for “Secure Sockets Layer”. SSL was designed to secure digital communications traveling over insecure channels. TLS has supplanted SSL, but we still use the term SSL, mostly for familiarity reasons. It has cemented itself into the common vernacular, so there’s little use in fighting it. After this point, I will use “SSL” in its generic sense.
• TLS: “TLS” stands for “Transport Layer Security”. This technology group serves the same fundamental purpose as SSL and depends upon the same basic components and concepts, but the technologies cannot be used interchangeably.
• Cipher: an algorithm used for encoding or encryption. In SSL, the term often refers to a collection, or “suite” of ciphers, each with a different purpose in an SSL conversation.
• Key: A digital key used with SSL/TLS is just a sequence of bits, usually expressed in hexadecimal characters. Ciphers use keys to encrypt and decrypt data. Keys used in standard PKI are expected to be a certain number of bits, a power of 2 starting at 1024 (ex: 2048, 4096, etc.). A longer key provides stronger defense against brute-force cracking when used in a cipher, but also requires more computing overhead. In PKI, keys come in pairs:
  • Private key: a key that is held by its owner and never shared with anyone else. The private key in a private/public pair is the only key that can be used to decrypt data that was encrypted by the public key. A private key that is accessed by anyone other than its owner is considered “compromised”.
  • Public key: a key that can be shared with anyone. The public key in a private/public pair is the only key that can be used to decrypt data that was encrypted by the private key. The “PK” in “PKI” comes from its usage of public keys. It also serves as a reminder: we use “public key” in PKI but never “private key”, because no private key should ever enter the infrastructure.
• Certificate: A certificate is a digital file used for identity and authorization. You will often see these referred to as “SSL certificates”. However, SSL implies communications, whereas certificates have more purposes. The term has lodged itself in common jargon, so it too will continue despite its technical inaccuracy. When I remember, I say “PKI certificate” instead.
  Certificates contain many components. Some of these items:
  • Identifying information. There are several defined fields, and most certificates contain only a subset. Examples:
    • Common Name: The name of the object that the certificate identifies. Sometimes that is a fully qualified domain name, such as www.altaro.com. Sometimes, it is just a name, such as “Eric Siron”.
    • Locality: The city, or equivalent, of the entity represented by the certificate
    • Organization: The name of the organization that owns the certificate
  • A public key
  • Validity period
• Encoding: Passing data through an algorithm to transform it for the purpose of facilitating a process or conforming to a standard. For instance, base-64 encoding can turn character string sequences from a human-readable form that might cause problems for simple string handlers (like URLs) into strings that computers can easily process but humans would struggle with. Text can be encoded in UTF8 (and others) so that it fits a common standard. “Decoding” is a convenience term that we use to mean “reversing encoding”, although it could be argued that there is no such thing. We simply perform a different encoding pass on the new data that generates output that matches the original data. The most important thing to understand: encoding does not provide any meaningful security. We only use encoding for convenience.
• Encryption: Encryption is similar to encoding, but uses algorithms (usually called ciphers in this context) to obscure the data as opposed to adapting it for a functional purpose. “Decryption” reverses encryption.
• Cracking: a term that traces its origins to the same concepts behind physical-world activities such as “cracking a safe”. It refers to the action of decrypting data without having access to the private key. I previously mentioned “brute-force” cracking, which means trying all possible keys one at a time until finding the correct one. I’ll leave further research on other techniques to you.
• Certification Authority: Sometimes shortened to “certificate authority”. Often abbreviated to “CA”. An entity that signs and revokes certificates.
• Self-signed certificate: A certificate in which the identity represented by the certificate also signed and issued the certificate. The term “self-signed” is often used erroneously to describe a PKI that an organization maintains internally. A certificate signed by any authority other than the certificate holder is not self-signed, even if that authority is not reachable on the public Internet or automatically trusted by computers and devices.
• Root Certification Authority: The top-most entity of the PKI, and the only entity that expects others to blindly trust it. Uses a self-signed certificate. Can sign, issue, and revoke certificates.
• Intermediate Certification Authority: Sometimes referred to as a “subordinate CA”. A  CA whose certificate was signed and issued by another CA. Generally identical in function to a root CA, although the root or a superior intermediate CA can place restraints on it.
• Certificate chain: a single unit that contains all of the information needed to trace through all intermediate CAs back to and including the root CA.
• Server certificate and client certificate: technically incorrect, yet commonly used terms. In typical usage, these terms mean “the certificate used by the server in a given SSL communication” and “the certificate used by the client in a given SSL communication”, respectively. However, you cannot correctly say, “this certificate file is a client certificate”. “Server” and “client” are arbitrary designations for a digital transmission and have no meaning whatsoever when you’re only referring to a single entity (the certificate holder). A certificate is a certificate.
• Constraints, key usage, and enhanced key usage: actions that a CA has authorized the certificate holder to perform. For instance, consider a development application that uses a private key to sign a piece of code. If the CA has signed the matching certificate for code signing usage, then a computer that runs that code and trusts the CA will treat the code as properly signed. However, a private key can be used for any purpose — constraints only limit the actions the issuing certification authority will validate. That means that you still cannot correctly refer to a certificate with the Client Authentication key usage as a “client certificate”.
• Certificate Revocation List (CRL): A list of certificates that the CA has marked invalid. If a certificate appears on this list, then no client should consider it reliable. The CA signs the CRL to make it tamper-proof so that it can be freely distributed and trusted.
• Online Certificate Status Protocol responder (OCSP responder): CRL’s are just simple lists. A client must download the entire CRL and search through it to check on any given certificate. For very long CRLs and/or low-powered clients, that can take a lot of time. An OCSP responder keeps a copy of the revoked certificate list and can perform the search for any client that asks.

2. The Core Use of PKI and Certificates

We use PKI and certificates for a multitude of purposes. Functionally, though, they all derive from two central needs: identification and encryption. I first learned about PKI through encryption, so I’ll start there.

3. A Very Brief Introduction to Digital Encryption

I only intend to talk enough about encryption to explain the problems that PKI solves. A fulfilling lifetime career could be made from this subject. I recommend that you find experts if you want to know more.

3.1 Encoding and Encryption Ciphers

At its simplest, a cipher is an algorithm. We apply the term “cipher” to an algorithm when it has uses in encoding or encryption. Let’s look at a trivial cipher: ROT13. It involves only the 26 characters used in the English alphabet. It encrypts character-by-character, replacing the character to be encrypted with the character 13 places forward, wrapping around at “A” if passing “Z”. “A” becomes “N”, “B” becomes “O”, etc.

The ROT13 cipher exhibits two major problems:

• You only need to know that ROT13 was used to encrypt in order to restore the original data. Even if you don’t know that, it usually does not require a great deal of effort to discover. In simpler terms, ROT13 does not require a key for decryption.
• You cannot effectively use ROT13 on any message that contains characters outside the 26 characters in the English alphabet. It does not define a way to encrypt a “1” or a “ñ”, nor does it define any way to output those characters.

Therefore, ROT13 depends on a specific, limited range of source material and cannot provide any guarantee of safety.

Keyless ciphers find their primary value in blocking casual access to data. You might use a keyless cipher in a puzzle game in which you want the player to eventually figure out the message. In the larger world of encoding, keyless algorithms find a great many more uses, such as base-64 encoding and the various text encoding schemes. I briefly covered those in the terminology section above.

For meaningful secrecy, we turn to keyed ciphers.

3.2 Keyed Encryption Ciphers

A keyed cipher differs from the previously-discussed ciphers in that it depends upon at least one key. These ciphers come in two types:

• Symmetric ciphers: The algorithm uses the same key to encrypt and decrypt. Furthermore, the encrypted data is usually the same size as its unencrypted source.
• Asymmetric ciphers: The algorithm uses one key to encrypt and a different key to decrypt. Data encrypted asymmetrically tends to be larger than its unencrypted source

3.3 Symmetric Encryption

Symmetric encryption is the easiest to understand. Imagine if you decided to use ROT13, but moved to the character immediately after. You could consider the 1 to be a key in an algorithm defined as “ROT13 + k“.  Just knowing the cipher is no longer enough; you also need to know (or figure out) the key.

A real-world corollary to symmetric encryption would be a standard home safe. The physical locking mechanism correlates to a digital algorithm. It can be opened with a physical key or combination. Anyone in possession of an identical copy of the physical key or knowledge of the combination can open the safe.

A practical discussion involves a “real” symmetric encryption cipher. Let’s choose 3DES (3-pass Data Encryption Standard). Jim wants to share data with Jane and only Jane. So, he chooses to encrypt it with 3DES. He then gives the encrypted data (usually called ciphertext) to Jane. In order for Jane to decrypt it, she must know the key. Once he gives it to her, it becomes a “shared key”.

The good parts: DES3 depends only on a key and an algorithm. Technically, it can work with any kind of data. Contrast that against ROT13, which can only work with the 26 characters that make up its algorithm. Because DES3’s algorithm does not depend on the data, the ciphertext is useless without the key. Knowing that DES3 created the ciphertext does nearly nothing for an attacker. The other nice thing: the ciphertext from most symmetric algorithms is the same size as the plaintext.

However, we still have a problem, which I hope the diagram made clear. How can Jim securely deliver the key to Jane? Symmetric encryption works well for protecting information intended only for personal consumption. But, we want to communicate with others. So, we turn to asymmetric encryption.

3.4 Asymmetric Encryption

Asymmetric encryption solves the secret key problem. The encryption cipher requires one key while the decryption cipher requires a different one.

Asymmetric encryption has no perfectly analogous physical-world examples. You can see similarities in the mailbox of an apartment complex or other multi-tenant building. The mail carrier uses one key to load the boxes with incoming mail and the tenants use their individual keys to retrieve their mail. The analogy fails in that even though any given key, whether the carrier’s or a tenant’s, can only open one door, the contents of the mailbox (the data) can be equally accessed from either side.

You can see a different analogy on your own front door. You can control the inside of a lock with a simple twist of the knob. You could call that a public key — anyone can turn it. However, the outside of a lock requires a specific key that you protect — you could call that a private key. This analogy fails to align with asymmetric encryption in that either “key” can freely lock and unlock the door.

The important thing to keep in mind for asymmetric encryption: data encrypted by one key can only be decrypted using another. Even the key that was used to create the ciphertext cannot be used to return it to plaintext.

This fact serves as the basis for PKI. Keys are created in pairs. The owner permanently holds on to one key (the private key) and freely distributes the other (the public key). When the key holder wants to securely distribute data, it uses the private key to encrypt it. When someone wants to send data that only the key holder can read, they can encrypt the data with that entity’s public key.

This all looks really good right? The downside: asymmetric ciphertext cannot be the same size as the plaintext. It is usually much larger — often over double. That translates to increased storage, transmission, and decryption effort costs.

4. PKI Identification

We have more to talk about in encryption, but first, we need to cover the greater purpose of public key infrastructure: identity. In our earlier example, Jim wants to share data with Jane. How can Jane be certain that Jim sent the data that she received? If they only use symmetric encryption, she only knows that the sender has the correct key. She also has that key, so she knows that it has been shared at least once. She has no certainty that Jim did not share it with a malicious third party. Similarly, Jim can’t be certain that Jane is the person that received his transmission, or that a person that intercepted the secret key does not also have a way to intercept the ciphertext. We use PKI certificates to solve the identity problem.

Certificates represent the very core of PKI. A certificate’s primary purpose is to establish identity, verified by a central authority. One perfect real-world analogy is state-issued identification:

At the very top of this “certificate”, we find the central authority. We find identifying information for the individual. We also have a validity period and a bar-coded sequence that we could think of like a serial number. The picture corresponds to a public key. When “James P. Keiai” needs to prove his identity, he presents this identification card. The person evaluating it goes through these elements:

• Is the “certification authority” trusted? A government-issued ID might only be accepted within that government’s borders. In any case, the authority must be known and trusted in order for the certificate to have value. In PKI, we typically address that by pre-installing CA certificates. On Windows systems, you can see them in the Certificates snap-in under Trusted Root Certification Authorities and Intermediate Certification Authorities.
• Is the “certificate” genuine? Government-issued IDs typically include some tamper-resistant elements. PKI certificates include a signature created by the certification authority that provides tamper-proofing
• Was the “certificate” issued to the person presenting it? This “certificate” includes a photograph which can be compared to the person holding the “certificate”. A PKI certificate includes a public key. Only the matching private key can supply data that can be decrypted using that public key.
• Is the certificate within its validity period? Given sufficient time, any tamper-proofing can be circumvented. An issuer might also lose trust in the entity. We use validity periods to address those problems.

5. The PKI Certificate Issuance Process

To best understand PKI certificates, let’s start by looking at the issuance process.

1. An entity (computer, user, device, etc.) generates its own private and public key pair
2. The entity generates a certificate signing request (CSR) including the public key and identifying information to include on the certificate (common name, locality, subject alternate names, etc.)
3. The CSR is submitted to a certification authority
4. The authority generates a certificate including all of the above information and usage authorization (such as server authentication and code signing) and writes a record of the issuance into its database

Some things to note:

• The entity never discloses the private key, not even to the certification authority
• The entity decides on the keys, not the CA. A CA can refuse to issue a certificate for a key of insufficient length, but it has no other say on the composition of the key
• The CA decides which key usages it will apply to the final certificate

The entity can now present that certificate to anyone that asks. By presenting a certificate, the entity makes a statement: “I am who I say am and the certification authority will vouch for me”.

6. The PKI Certificate Validation Process

A simple process verifies a certificate. When a certification authority creates a certificate, it includes signing information. It creates the signature from its own private key, which means that only the authority’s public key can be used to verify it. With that, it effectively states that it vouches for the validity of the presented certificate. Because it has signed the certificate that includes the entity’s public key, the CA also vouches that any encrypted data that can be read or any signature that can be verified by the entity’s public key must have been created by the entity’s private key.

An important thing to note: no one contacts the certification authority during this process to validate the certificate; its signature on the certificate has done that. The system, trying to verify the certificate, either trusts the issuer or it does not. We expect the system to keep a local list of certificate authorities that it trusts. We also expect that it will automatically accept certificates signed by them. If the issuer does not exist in the system’s local list, then we expect the system to prompt for an override or reject the certificate. These are conventions; nothing in the technology requires any of this.

Even though the system won’t contact the certificate authority, it can look for revocation information. The issuer must have included revocation information in the certificate for that check to occur. Revocation information might be published in a location other than the certification authority.

6.1 Why Not Contact the Certification Authority During Validation?

It might seem like an oversight — shouldn’t someone trying to validate a certificate have the ability to contact the issuer? That requirement would create two problems:

• The certification authority would need to be online all the time — we’ll look at problems with that in a bit
• The client seeking verification would need to be online. Even though that seems like a guaranteed condition today, it certainly wasn’t at the dawn of PKI and should never be taken as a given even in today’s connected world

Requiring the CA to always be available represents a problem, but PKI already solved it. If the client has the CA’s certificate and the certificate that it signed, then it already has all the information it needs to know that the CA signed the certificate. The revocation process deals with bad certificates.

7. The PKI Certificate Revocation Process

If a private key becomes compromised, anything that it ever signed or encrypted becomes suspect. The certification authority must be deliberately told to revoke the certificate; it has no automatic way to know of compromise.

To revoke a certificate, the CA marks it as revoked in its own database. It can then issue or update a Certificate Revocation List (CRL). Alternatively, it can make revocation information available to an Online Certificate Status Protocol responder (OCSP). The location of a CRL and/or OCSP responder must be included in all certificates signed by the certification authority or they will never be checked.

Important: any system can host CRLs and OCSP responders. The certification authority only needs to generate the revocation information. CRLs must carry the CA’s signature, so they need no particular security. Therefore, you can take the CA offline but keep the system(s) that host its CRLs and perform OCSP operations online.

8. PKI Identity Verification Visualization

The following image shows the most salient components of the preceding explanations:

In order:

1. Entity generates a private/public key pair
2. Entity crafts a certificate signing request and submits it to the certification authority
3. The certification authority issues a certificate and records it in the database
4. Entity presents the certificate to the client
5. The client presumably has the signing certification authority’s certificate or can get it
6. Client checks that the certificate does not appear on the CRL
7. If 4, 5, and 6 all checks out, the client will accept the certificate

That wraps up PKI identity. With identity established, we can continue our encryption discussion.

9. Certificate Signing Operations

Remember how we wanted certainty that Jim was sending data and Jane was receiving it? We can do that, and add tamper-proofing, using signatures created by private keys. We have two general ways to accomplish our goals.

Authenticated Sender, Anonymous Receiver

In some cases, we only want to authenticate the sender, or signer, of an object. To continue our example, Jim wants to ensure that anyone who reads his e-mail knows that he wrote it and sent it. The process to enable that works like this (simplified):

1. Jim creates a message.
2. Jim passes the message through a “hashing” algorithm — a fancy word meaning that the algorithm crunched the data and produced a number.
3. Jim uses his private key to encrypt the hash.
4. Jim attaches the resulting cipher to the end of the message and transmits it to Jane.
5. Jane uses the same hashing algorithm on the message.
6. Jane uses Jim’s public key to decrypt the signature.
7. If the hash computed by Jane matches the hash in the decrypted plaintext, Jane has verified the condition and authenticity of the message; Jim’s private key signed the message and no one altered it.

Most e-mail applications can do all of that automatically. You just tell Outlook to sign your e-mail and tell it which certificate to use. As long as your system has a matching private key, Outlook will handle the rest. You can’t just pick any old certificate from your store though; this all depends on ownership of the correct private key.

This type of signing works for sending signed e-mail to anyone. You do not need to know anyone else’s public key; some recipients might not even have one. We use the same technique when we want to sign PowerShell scripts, driver packages, and software.

Authenticated Sender, Authenticated Receiver

In our example, we did want Jane to know that Jim sent her the message, but we also wanted Jim to know that only Jane received it. Signing got us halfway there. To get it all, we need encryption.
If we only wanted the other half, Jim could encrypt the message with Jane’s public key. That would ensure that only Jane could open it. However, Jane cannot verify anything about the message except that the encryptor used her public key — by definition, anyone might have that. To fully authenticate both sender and receiver, Jim would sign the message with his private key and then encrypt the message with Jane’s public key. Only Jane can decrypt the message, but only Jim’s public key can verify the signature.
I want to reiterate that I am describing this in simple terms. We rarely use asymmetric keys for general-purpose encryption. End-to-end authentication and encryption almost always involves the key pairs of both parties and a temporary symmetric key during the encryption phase. The actual process looks more like the steps in the SSL Encrypted Communications section.

10. SSL Encrypted Communications

After all that, we can now absorb the gist of SSL communications rather easily. I don’t want to dig too far into the depths of encrypted communication because that extends beyond my goal of simplicity. I’m going to trim down to the minimal steps of typical communications in an HTTPS conversation, such as reading a web page:

1. A client contacts the server.
2. The client and server exchange information about the communications they intend to perform, such as the ciphers to use (SSL handshake).
3. The server transmits its certificate to the client.
4. The client checks that it trusts the certification authority that issued the certificate. If it does not recognize the CA and does not get an override, the communication ends.
5. The client checks for revocation information on the certificate. If the certificate is revoked or revocation information is unavailable, then the client might attempt to obtain an override. Implementations vary on how they deal with null or unreachable CRL information, but almost all will refuse to communicate with any entity using a revoked certificate.
6. The client generates a portion of a temporary key for symmetric encryption.
7. The client uses the server’s public key to encrypt the partial temporary key.
8. The client sends the encrypted partial key to the server.
9. The server decrypts the partial key using its own private key.
10. The server completes the secret key.
11. The client and server agree to use the secret key. All communications in the same conversation are encrypted with that key.

It would be possible to use asymmetric encryption for the entire conversation. However, as we talked about earlier, asymmetric encryption results in ciphertext that greatly exceeds the size of the unencrypted source. To solve that problem without exposing a plaintext key, SSL only uses asymmetric encryption while the client and server establish identity and work together to create a symmetric shared key. From that point forward, they only use symmetric encryption. That keeps the size of transmitted data to a minimum. Even better, if an attacker manages to break any point of the transmission besides the initial negotiation, they will only gain a temporary key.

All of that explains why we use suites of ciphers: we need multiple algorithms to make this work.

[thrive_leads id=’17165′]

11. Offline Certification Authority

If you’re going to build a PKI, it will have a root certification authority at its heart. Keeping that authority safe must be your primary concern. Administrators commonly take their root certification authority offline to protect it.

11.1 The Risks of an Online Root Certification Authority

You face a dilemma: if you keep the certification authority online, that increases the odds of a compromised private key. If you take it offline, it can’t sign certificates. Using an offline root certificate in a multi-CA PKI resolves the dilemma with minimal side effects.

PKI always carries some risk of private key compromise. However, there are two problems specific to the root authority:

• If the root is compromised, every certificate that carries its signature is untrustworthy. That includes every certification authority in the PKI. Every single CA, and therefore every certificate they issued, becomes suspect.
• The root certification authority uses a self-signed certificate. No CA database contains it and no one has the authority to revoke it. Even if the CA could revoke its own certificate, it would no longer be trusted to sign the CRL, thereby invalidating its own invalidation. In simpler terms, the root CA’s certificate cannot legitimately appear in any CRL, therefore it cannot be revoked.

As previously mentioned, most PKI certificates say: “I am who I say I am and the certification authority will vouch for me.” The root certification authority says: “I am who I am because I say so.” The only certain thing protecting the root CA from compromise is its validity period. Therefore, stronger steps must be taken to safeguard the root CA’s private key.

11.2 Offline CA Creation Process

I will publish an article containing a complete walk-through on building a standalone and subordinate certification authority set. The essential steps:

1. Create a key pair.
2. Create a self-signed certificate from that pair.
3. Create another key pair.
4. Use the private key from step 1 to issue a certificate for the new pair. Ensure the certificate is authorized to act as a certification authority and has information to reach a CRL for certificates that it signs.

The key pair and certificate in steps 1 and 2 represent the root certification authority. The key pair and certificate in steps 3 and 4 represent an intermediate (subordinate) authority. The CRL information on the subordinate CA’s certificate (in step 4) points to a CRL created by the root CA.

5. Generate a CRL from the root CA. Publish it at the location specified in the intermediate CA’s information.
6. Take the root CA offline.
7. At regular intervals, bring the root CA “online” (not necessarily reachable) and update the CRL.
8. Perform standard certificate issuance and revocation operations with the intermediate CA.

The CRLs for both authorities must be kept online and reachable at all times.

Important: The CRL information on a certificate always refers to the CRL of that certificate’s issuer. That seems straightforward enough on endpoint certificates. However, it can get confusing for CA certificates. If it helps your memory, a certificate contains a reference to the CRL that might list it. Therefore, a well-formed root CA certificate will not contain CRL information because no CRL could ever contain a root certificate. Each intermediate CA’s certificate will contain CRL information for its parent CA, not for itself.

11.3 An Offline CA Without a CRL

You can create an offline CA without a CRL. You simply issue the intermediate CA certificate(s) with no CRL distribution information. If the subordinate’s certificate contains no CRL information, then it will be trusted until it expires. However, doing so is only marginally more secure than just using a single online root CA. If the subordinate CA’s private key ever becomes compromised, then, even though the root CA has the power to revoke it, no one will know how to reach a CRL to find out. Removing the intermediate CA’s CRL would help to remove trust in the certificates that it issued, but not every process checks a CRL and most will ignore a missing CRL.

I understand the temptation of creating an offline root CA without generating a CRL. You would not need to maintain anything. You could even delete the root CA’s files. However, you gain almost no security.

12. What IS a Certification Authority?

I think this article presented a clear idea of the concept of a certification authority and the function of a certification authority. I don’t believe that it cleared up all the mystique of a certification authority, though.

When you’re running the wizard in Windows Server to set up a CA, it throws up all kinds of warnings about the permanence of the computer name and domain membership. I believe that gives the impression that a CA is a dreadful, magical beast. But, a simpler explanation underlies all those warnings. When you make a domain member into a CA, the wizard builds a lot of scaffolding around it in the directory. Microsoft could have fashioned a bunch of brittle triggers and conditional checks and resolution steps on the system’s name and domain membership status. Or, they could just tell you never to change either and (correctly) blame any problems on a failure to comply. Whatever impression that leaves on the unwary, the CA truly has a very simple structure.

A functional PKI certification authority must contain these things:

1. A public and private key pair. It uses the private key to sign things and the public key to prove that it signed things.
2. A certificate that it or a parent CA signed.
3. A list of issued certificates.

That’s all. Implementations vary, of course. For instance, OpenSSL depends on a couple of files to tell it what the next numbered certificate and CRL will carry. However, all CAs need the three listed components. If you want to take a CA offline but only keep the most important parts, you can’t get by without those. Since #2 can be freely distributed to anyone, only #1 and #3 require security.

Be aware that I don’t know how to fully regenerate a failed Windows CA using only those components. When you use the Windows wizard to build a CA, it allows you to re-use a previously existing private key. I don’t know of a way to make it use a previous certificate database (feel free to use the comment form if you do know). If you want to use Windows Server as your offline root CA, I recommend that you take the entire Windows Server installation offline and keep it safe. Personally, I use something else entirely… details in another post.

12.1 Does a Certification Authority Require a CRL?

We talked about this only a few sections ago, but I focused on security concerns there. Structurally, a CA does not require a CRL. Even more technically, a CA does not include a CRL at all. A CA includes a list of certificates that it issued; its revocation process marks a certificate as revoked on that list. An external tool generates a CRL by making a sublist of only the revoked certificates on the master and having the CA sign the resulting list.

Do go back and read the part about dramatically reduced security when a CA does not publish revocation information if you missed it. Please. It really does matter.

13. The Dangers of Self-Signed Certificates

As more technology requires certificates (e.g., Windows Admin Center), I see more requests for information on creating self-signed certificates. STOP USING SELF-SIGNED CERTIFICATES. People say, “Oh, it’s OK, I only use them in my test lab.” How can you call it a “test” lab if you do things that you would never do in production? What exactly do you believe you are testing? Great, process “alpha” works with self-signed certificates, which the manufacturer probably already stated… so what does that prove? How can you apply that knowledge when you transition to production? A proper test environment duplicates a production environment to the greatest possible extent.

Self-signed certificates represent an overt danger if used in production. Above, you saw how we have no choice but to use them for root CAs, so we go to great lengths to protect them. Think about those problems in the context of a self-signed endpoint:

• No one can revoke a self-signed certificate. If you lost control of the private key, data encrypted by an attacker would forever be just as good as data encrypted by you. Data meant for you could always be signed by your public key and read by your attacker.
• Why should anyone trust a self-signed certificate, even members of your own organization? Literally, anyone can create a certificate and stick your name on it.
• You can’t lock up the private key. You’re actively using it. And, you imported its public key on at least one other machine which now blindly trusts it. That does not qualify as “secure” in any sense of the word.
• A compromised root CA would be terrible, but tearing down the entire PKI would at least address the problem. You can use centralized tools to remove the compromised CA from Windows’ trust lists. If you manually imported a self-signed certificate, you will have to manually hunt it down.

I understand that self-signed certificates seem easy. But, you can almost as easily learn PKI. You can quickly set up and configure PKI. Windows Server PKI offers auto-enroll and auto-renew, so a tiny bit of early pain saves all sort of ongoing effort. You will never regret adding “PKI” to your skills list. Do the right thing, not the expedient thing.

14. Going Further with PKI

I know that the topic of public key infrastructure can seem daunting, but administrators can no longer afford to ignore it. I am appalled by the proliferation of self-signed certificates, especially when it takes such little effort to build a fully functional PKI. If you don’t know how to do that, watch this space for a forthcoming how-to. If you can’t wait that long, head on over to the Altaro Dojo Forums and start a discussion. I’m actively part of that community and answering questions on a daily basis.