If you’re planning to take the SY0-501 version of the Security+ exam, you should have a basic understanding of implementing public key infrastructure. This includes understanding certificate formats that provides the ability to establish a secure session.
For example, can you answer this question?
Q. You need to request a certificate for a web server. Which of the following would you MOST likely use?
A. CA
B. CRL
C. CSR
D. OCSP
More, do you know why the correct answer is correct and the incorrect answers are incorrect? The answer and explanation are available at the end of this post.
Certificate Chaining and Trust Models
CAs are trusted by placing a copy of their root certificate into a trusted root CA store. The root certificate is the first certificate created by the CA that identifies it, and the store is just a collection of these root certificates. If the CA’s root certificate is placed in this store, all certificates issued by this CA are trusted.
The figure shows the Trusted Root Certification Authority store on a Windows computer. You can see that there are many certificates from many different CAs. In the figure, I’ve selected one of the certificates from COMODO Certification Authority.
Trusted Root Certification Authorities
Public CAs such as Symantec and Comodo negotiate with web browser developers to have their certificates included with the web browser. This way, any certificates that they sell to businesses are automatically trusted.
The most common trust model is the hierarchical trust model, also known as a centralized trust model. In this model, the public CA creates the first CA, known as the root CA. If the organization is large, it can create intermediate and child CAs. If you look back at the figure, you can see that it includes a section used to store intermediate CA certificates. A large trust chain works like this:
• The root CA issues certificates to intermediate CAs.
• Intermediate CAs issue certificates to child CAs.
• Child CAs issue certificates to devices or end users.
Certificate chaining combines all the certificates from the root CA down to the certificate issued to the end user.
Another type of trust model is a web of trust or decentralized trust model, sometimes used with PGP and GPG. A web of trust uses self-signed certificates, and a third party vouches for these certificates. For example, if five of your friends trust a certificate, you can trust the certificate. If the third party is a reliable source, the web of trust provides a secure alternative. However, if the third party does not adequately verify certificates, it can result in the use of certificates that shouldn’t be trusted.
Certificate Formats
Most certificates use one of the X.509 v3 formats. The primary exception is certificates used to distribute certificate revocation lists which use the X.509 v2 format.
Certificates are typically stored as binary files or as BASE64 American Standard Code for Information Interchange (ASCII) encoded files. Binary files are stored as 1s and 0s. BASE64 encoding converts the binary data into an ASCII string format. Additionally, some certificates are also encrypted to provide additional confidentiality.
The base format of certificates is Canonical Encoding Rules (CER) or Distinguished Encoding Rules (DER). CER and DER formats are defined by the International Telegraph Union Telecommunication Standardization Sector (ITU-T) in the X.690 standard. They use a variant of the Abstract Syntax Notation One (ASN.1) format, which defines data structures commonly used in cryptography. CER is an ASCII format and DER is a binary format.
DER-based certificates include headers and footers to identify the contents. As an example, the following text shows a header and a footer for a certificate:
—–BEGIN CERTIFICATE—– MIIDdTCCAl2gAwIBAgILBAAAAAABFUtaw5QwDQYJKoZIhvcNAQEFBQAwVzELMAkG
… additional ASCII Characters here… HMUfpIBvFSDJ3gyICh3WZlXi/EjJKSZp4A==
—–END CERTIFICATE—–
Each header starts with five dashes (—–), BEGIN, a label, and five more dashes. The footer starts with five dashes, End, the same label, and five more dashes. In the previous example, the label is CERTIFICATE. Other labels include PUBLIC KEY, PRIVATE KEY, ENCRYPTED PRIVATE KEY, CERTIFICATE REQUEST, and X509 CRL. CER-based certificates are binary encoded so they do not have headers and footers.
Certificate files can have many extensions, such as .crt, .cer, .pem, .key, .p7b, .p7c, .pfx, and .p12. However, it’s worth stressing that a certificate with the.cer extension doesn’t necessarily mean that it is using the CER format.
When comparing the different formats, it’s important to know what they can contain and how to identify them.
PEM is derived from the Privacy Enhanced Mail format, but that is misleading. It implies that PEM-based certificates are used for email only. However, PEM-based certificates can be used for just about anything. They can be formatted as CER (ASCII files) or DER (binary files). They can also be used to share public keys within a certificate, request certificates from a CA as a CSR, install a private key on a server, publish a CRL, or share the full certificate chain.
You might see a PEM-encoded certificate with the. pem extension. However, it’s more common for the certificate to use other extensions. For example, a PEM-encoded file holding the certificate with the public key typically uses the.cer or.crt extension. A PEM file holding just the private key typically uses the. key extension.
P7B certificates use the PKCS version 7 (PKCS#7) format and they are DER-based (binary). They are commonly used to share public keys with proof of identity of the certificate holder. Recipients use the public keys to encrypt or decrypt data. For example, a web server might use a P7B certificate to share its public key. P7B certificates can also contain a certificate chain or a CRL. However, they never include the private key.
P12 certificates use the PKCS version 12 (PKCS#12) format and they are CER-based (ASCII). They are commonly used to hold certificates with the private key. For example, when installing a certificate on a server to supports HTTPS sessions, you might install a P12 certificate with the private key. Because it holds the private key, it’s common to encrypt P12 certificates. It’s also possible to include the full certificate chain in a P12 certificate.
Personal Information Exchange (PFX) is a predecessor to the P12 certificate and it has the same usage. Administrators often use this format on Windows systems to import and export certificates.
Q. You need to request a certificate for a web server. Which of the following would you MOST likely use?
A. CA
B. CRL
C. CSR
D. OCSP
Answer is C. A certificate signing request (CSR) uses a specific format to request a certificate.
You submit the CSR to a Certificate Authority (CA), but the request needs to be in the CSR format.
A certificate revocation list (CRL) is a list of revoked certificates.
The Online Certificate Status Protocol (OCSP) is an alternate method of validating certificates and indicates if a certificate is good, revoked, or unknown.
See Chapter 10 of the CompTIA Security+: Get Certified Get Ahead: SY0-501 Study Guide for more information on cryptography and PKI.