KeyChest blog
KeyChest updates, information, and write-ups

Public-key infrastructure (PKI) is a term for everything that has to do with web encryption beyond. This is a list of main terms to understand what it is and how it works.

Public-key cryptography

Public-key cryptography uses keys of two parts: public key and private key. You need your own pair to "do" things. You only need public keys of others to "validate" things. The main problem is to widely share public keys while ensuring they are linked to their owners.

Public keys can do 2 things:

• Encrypt a message so you can send it securely to the owner of the private key.
• Verify signature of a message with the private key.

Two most common algorithms are RSA (used for both) and ECDSA (only for signatures).

Public-key cryptography is slow and it also increases the size of the data. For these two reasons, nearly all protocols (such as TLS or SSH) only use it to establish a secure channel with a "handshake". This creates a shared symmetric key that encrypts the actual data (e.g., with the AES algorithm).

Hashing

Hashing algorithms (such as SHA) are one-way functions that take any input and compute a unique fixed-size output. The output is called a hash (or sometimes digest). Hashing provides 2 main properties:

1. it is impossible to re-create data from a hash
2. it is hard to find another data with the same hash.

Signatures

Signatures authenticate messages (or people and computers). To sign data you would:

• Take a message, and if it's too long calculate a hash of the message.
• Create a random "padding" that you add to the message/hash to make it random.
• Use the private key to calculate a signature.

To verify a message, you only need the signature and the public key.

As using hash is almost universal, that's why you can see SSL/TLS versions with names that contain 2 or 3 algorithms: "ECDSA with SHA-512."

Certificates

The problem of public keys is to validate that they belong to a particular entity, that's why we use "certificates". Certificate contains a name and a public key and these are signed by a "trusted party". It also contains time validity that makes certificates such a pain.

In the internet, the trusted party is called a certificate authority (CA). The CA is run by a company, like GeoTrust or Let's Encrypt, that has to comply with security and financial requirements of the CA/Browser Forum . With internal PKI, you are free to create your own CAs and define mechanisms to share their public keys.

KeyChest renewal management and monitoring - https://keychest.net

A CA's certificate can be signed by another CA, and so on -this creates a certificate chain. The last certificate in the chain is called a root certificate. Root certificates are trusted and stored locally.

For publicly trusted CAs, browsers and operating systems include public keys of root CAs that have been audited by the CA/Browser Forum. That's why we can trust websites that we visit for the very first time.

Formats

Most often when people talk about certificates, they're referring to X.509. It's a name of a family of standards that has been followed-up by a number of internet standards - RFCs.

The native X.509 certificate encoding is binary and described with the ASN.1 syntax. Windows usually work with the DER encoding of ASN.1. However, for practical purposes, ASN.1 can be wrapped with a number of trivial encodings - e.g., PEM encoding used in linux systems (base64 with a header and footer line).

Verification

Certificate verification consists of making sure the certificate chain is valid and leads to a trusted root certificate. The validation is a rather complex procedure that checks:

1. signatures in the chain all the way to the root certificate;
2. time validity;
3. critical extensions included in certificates;
4. online lists of revoked certificates - CRL;
5. online, real-time validation responders - OCSP.

Bundling

Since verification requires the complete chain, certificates are often distributed as a bundle. In the case of the TLS protocol, the chain is sent during the handshake.

1. DER/BER (i.e., binary version of certs) are wrapped in a special PKCS7 or even PKCS12 files.
2. PEM formatted certs are simply concatenated into one text file.

To use new certificates, you also need a private key. You can store certificate bundles and the private key in a single  PKCS #12 (aka. PFX) file. PEM certificates will be accompanied with a separate file that will contain the private key.

Issuance

When applying for a certificate:

1. you need to create your public and private keys;
2. create a certificate signing request (CSR), which contains your name and public key and is signed by your private key (a self-signed data);
3. send the CSR to the CA
4. the CA will validate that the name inside the CSR is yours (e.g., by sending an email to your domain name address, checking DNS, checking Yellow Pages, giving you a phone call);
5. if everything looks good, the CA generates a certificate from the CSR.

Depending on the thoroughness of step 4, you can get a "domain validated" (DV) certificate, "organization validated" (OV), or "extended validated" (EV) certificate. The more thorough validation, the more expensive is the cert.

EC certs used to be shown with special green bars and company names in browsers. Since last year, there is no visual distinction between OV and EV certificates.

For internal PKI, you can do step 4 whatever way you want.

Issuance Let's Encrypt

Let's Encrypt defined its own protocol for automated issuance of certificates - ACME. Its flow is different from steps above:

1. client sends domain names for which it requires a certificate;
2. the CA will send back "validation secrets" that the client has to either add to DNS records, or make visible via an HTTP server;
3. the CA, once it check the validation secret has been published, will send an authentication secret that is valid for up to 4 weeks;
4. the client generates a CSR, adds to it the authentication secret and sends it to the CA;
5. the CA checks the names match the list from step 1 and issues a certificate. It sends a download link back to the client.

Let's Encrypt starts being used by companies and so we cover this particular certification authority in more details:

• What are disadvantages of Let's Encrypt
• Let's Encrypt Revokes 3,000,000 Certs
• What does Let's Encrypt sell? It's not certs.
• Let’s Encrypt for Companies with KeyChest

Revocation

As certificates can be valid for up to 3 years (and it's not unusual for CA certificates to be valid 20 or more years), we need a mechanism to revoke certificates in case the private key is compromised.

There are 2 ways to advertise revocations:

1. certificate revocation lists (CRLs) - a list of certificates revoked and not yet expired;
2. online certificate validation (OCSP) - a protocol that allows inquiring about a specific certificate. In many cases, OCSP is simply and API using CRLs as its source data.

OCSP can be more accurate but needs the 24x7 availability of OCSP servers. It also adds to the latency of website loading and so web browsers can skip these validations.

Summary

• Server's public key allows us to verify authenticity of the server.
• Browsers use certificates to verify owners of public keys that we see for the first time.
• The internet trust is defined and audited by CA/Browser forum (CA/B).
• We can trust internet certificates only as we trust Google, Apple, Mozilla, Microsoft, etc.

KeyChest is a cloud service to manage expirations and integrate Let's Encrypt, Internal, and commercial certificate management.