Digital Certificate — Certificate fields, formats, CSR, Revocation & OCSP

In this post, we will look at X.509 certificates, CSR, Certificate fields, CRL, and OCSP.

Part 2 of four-part series about digital certificate

Here are the links to other posts in this series.

Digital Certificate series — Part 1

Explained — Digital Certificate — Part 3

Explained — Digital Certificate — Part 4

Let’s take a look at the format of a typical certificate.

A certificate typically follows X.509 industry standards, allowing interoperability between browsers, operating systems, etc.

X.509 has two encoding formats — Base 64 (ASCII) and Binary. The file and the packaging/container format depend on the encoding format. PEM files & PKCS#12 can generally pack certificates and private keys in a single file.

X.509 encoding formats

The below figures show a security certificate (.crt file) opened in two different applications — a text editor and a windows utility (crypto shell extensions).

.crt file opened in a text editor

.crt file opened in a windows utility — GIF shows various sections of the certificate

Let’s now look at how an applicant requests the certificate and CA grants it. The figure below is a high-level representation of what happens behind the scenes for a CSR (Certificate Signing Request).

A high-level overview of the certificate signing request

1. The applicant generates a pair of public and private keys.
2. The applicant sends their identity details (name, email, organization, location, etc.) and public key as part of the CSR to a registration authority.
3. The RA (registration authority) acts as a broker — it may verify the user requests and forward them to an intermediate CA as appropriate.
4. CA may conduct more stringent checks (depending on the type of certificate needed) to verify the user’s identity and intent of usage. If CA finds everything ok, it can sign the certificate with its digital signature and grant the certificate to the applicant.

PRO TIP — Many fields that are published in a leaf (end-entity) certificate directly come from CSR requests. Let’s look into some of the CSR fields.

• Public Key — Public Key shared with everyone as part of the certificate
• Email Address — of contact at the subject’s organization
• Common Name (CN) —represents the server name protected by the SSL certificate e.g., mail.domain.com, *.domain.com, www.domain.com, buy.domain.net, etc.
• Subject Alternative Name (SAN) — for requesting multi-domain certificates or enlisting sub-domains in the certificate, e.g., www. domain1.com, www. domain2.com, www. domain3.net, etc.
• Organization (O)
• Organizational Unit (OU) — Name of the department or organization unit making the request
• City, State, Country

Let’s talk about some of the required certificate fields.

Required fields in a typical certificate

1. The serial number is the Unique ID that helps CA identify the certificate.
2. Signature algorithm and the hash function used by CA to sign the certificate
3. Issuer identifies the CA issuing the certificate — details like CN, O, OU, C, etc.
4. Valid from/to means the start/end date for which certificate is accurate, and the application can trust it.
5. Subject is the end-entity for which the certificate is issued. Generally, CN (Common Name) goes here, but it can have more details.
6. Public Key and Key Exchange Algorithm of certificate

Extension fields in the certificates provide more context to the end users and applications — information about the critical usage, policies, etc., are covered here.

Extension fields in a typical certificate

7. Enhanced Key Usage identifies different purposes for which a certificate can be used such as Server Authentication, Client Authentication, Code Signing, Email protection, Digital Signature, etc.

8. Certificate Policies defines different use of certificates and registration and authentication procedures.

9. CRL Distribution Points denotes the address where the CRL list is published. These locations could be HTTP endpoints⁴, LDAP servers, etc.

Let’s take a look at the CRL in more detail.

The certificates are issued for a given duration, so it is crucial to keep track of the validity of the certificates. CA maintains a list of all revoked and suspended certificates distributed throughout the PKI hierarchy. Some of the common CRL attributes are

• Publish period — when list published (date/time)
• Distribution point — where (locations) published
• Validity period — the period in which CRL is considered authoritative. It is a bit longer than the publish period, e.g., the publishing period can be every 24 hours, but the validity period can be 25 hours.
• Signature — digitally signed by CA

Another related topic to CRL is OCSP and OCSP stapling. Let’s look at it briefly.

OCSP (Online Certificate Status Protocol)

OCSP improves upon the problem the clients/browsers face with CRL. CRL is not a scalable solution as the client application needs to fetch the entire CRL list every once in a while. With OSCP, the client only has to fetch the revocation status of the specific certificate compared to the whole CRL list.

In OCSP, there is an additional entity called OSCP responder (OSCP server). The client makes an OSCP request to the responder, where it asks explicitly about the revocation status of the server in question. It requires more work on the CA side (need the CA to set up an OCSP service) and more latency for the end-user (client makes an additional request to the CA server). This overhead (TCP +TLS handshake + extra OSCP request) quickly adds up; although small, but it is there.

OCSP Stapling

Webserver sends both certificate and OCSP response in one request

OCSP vs OCSP Stapling

In OCSP Stapling, the overhead of validation and proof is transferred from the client to the webserver. The webserver will make a periodic call to the CA (independent of any client request) to get the OCSP response for its own certificate. When the client connects to the webserver, the server will send the server certificate (TLS handshake) and OSCP response.

PRO TIP — This may seem strange to have the webserver verify its own certificate from the OSCP responder, but the CA actually signs the OCSP response, so it’s easy for the browser to tell if the webserver has just made it up or not.

We will deep dive into TLS and related topics in the next post.

I hope you find this article useful and stay tuned for my next blog post.

Until then!

Happy Learning 😎

References:

[1] https://tech401.com/2017/11/08/2017/2017-11-02-ssl-certs-and-certificate-authorities/
[2] https://stackoverflow.com/questions/7539625/does-pem-file-contain-both-private-and-public-keys
[3] http://rockhoppervpn.sourceforge.net/ref_chained_certs_hash_and_url.html
[4] http://www.pkiglobe.org/crl_dist_points.html
[5] https://www.thesslstore.com/blog/crl-explained-what-is-a-certificate-revocation-list/