LFCA 98 🐧 What Certificates Are
A TLS certificate is a digital document that binds a public key to an identity — typically a domain name, an organization, or a person. It is the mechanism that makes secure communication on the internet possible. When a browser connects to an HTTPS website, the server presents a certificate. The browser checks the certificate against its trust store. If the check succeeds, the browser and the server establish an encrypted channel using the public key in the certificate. If the check fails, the browser warns the user.
The LFCA exam places certificates under Security Fundamentals, which carries 14–16% of the total weight. Certificates are the practical implementation of asymmetric encryption. They solve the key distribution problem: how does a client know that the public key it received actually belongs to the server it wants to talk to? A certificate is the answer. It is a public key wrapped in a signed statement from a trusted third party.
Key point: A certificate is not just a public key. It is a public key plus a set of claims about who owns that key, all signed by a certificate authority (CA). The CA’s signature is what makes the certificate trustworthy. Without the signature, the certificate is just a self-declared claim. The trust comes from the CA, not from the certificate itself.
Why Certificates Matter
The public key infrastructure (PKI) exists to solve a specific problem: how do you know that the public key you received belongs to the entity you think it does? Without certificates, an attacker could intercept the key exchange, substitute their own public key, and read all the traffic. This is the man-in-the-middle attack.
The impersonation problem. A client connects to example.com. The server sends a public key. How does the client know that the key belongs to example.com and not to an attacker who intercepted the connection? A certificate binds the public key to the domain name. The client checks the binding.
The trust problem. The client does not know the server. It has never communicated with it before. The client does know a set of CAs — organizations whose certificates are pre-installed in the operating system or browser. If the server’s certificate is signed by one of those CAs, the client trusts it.
The expiration problem. A certificate has a validity period. It is not valid before its start date or after its end date. This limits the damage if a private key is compromised. The CA can revoke the certificate, and the client checks revocation status before trusting it .
The integrity problem. The certificate contains the server’s public key. The CA’s signature covers the entire certificate. If an attacker modifies any part of the certificate — the public key, the domain name, the expiration date — the signature no longer verifies. The tampering is detected.
a. The X.509 Standard
The X.509 standard defines the format of public-key certificates. It is an ITU-T standard, and it is the foundation of TLS, S/MIME, and most PKI systems in use today . The current version is X.509 v3, which added the extensions field that supports subject alternative names, key usage constraints, and other features.
An X.509 certificate contains the following fields:
| Field | Purpose |
|---|---|
| Version | X.509 version (v1, v2, or v3) |
| Serial Number | Unique identifier assigned by the CA |
| Signature Algorithm | The algorithm the CA used to sign the certificate |
| Issuer | The CA that issued the certificate |
| Validity | Start and end dates |
| Subject | The entity the certificate belongs to |
| Subject Public Key Info | The public key and its algorithm |
| Extensions | Additional constraints (v3 only) |
The subject field identifies the entity the certificate represents. For a TLS certificate, the subject includes the domain name. The issuer field identifies the CA that signed the certificate. The validity field defines when the certificate is valid. The subject public key info field contains the public key itself.
The extensions field in X.509 v3 is where most of the modern functionality lives. The subject alternative name (SAN) extension allows a certificate to cover multiple domain names. The key usage extension restricts what the public key can be used for. The basic constraints extension indicates whether the certificate is a CA certificate or an end-entity certificate .
b. The Certificate Chain
A certificate is rarely used alone. It is part of a chain of trust that connects the server’s certificate to a root CA certificate that the client already trusts .
The chain has three levels:
Root CA certificate. The root CA is the top of the hierarchy. Its certificate is self-signed — the issuer and the subject are the same. The root CA certificate is pre-installed in the client’s trust store (the operating system or browser). The client trusts the root CA without question. The root CA’s private key is kept offline and used only to sign intermediate CA certificates .
Intermediate CA certificate. The intermediate CA is signed by the root CA. It is used to sign end-entity certificates. The intermediate CA’s certificate is provided by the server during the TLS handshake. The client uses the root CA’s public key to verify the intermediate CA’s signature. The intermediate CA allows the root CA’s private key to remain offline .
End-entity certificate. The end-entity certificate is the server’s certificate. It is signed by the intermediate CA. It contains the server’s public key and the domain name. The client verifies the end-entity certificate using the intermediate CA’s public key .
The chain validation works backward. The client starts with the end-entity certificate. It verifies the signature using the intermediate CA’s public key. It verifies the intermediate CA’s signature using the root CA’s public key. It finds the root CA in its trust store. If all the signatures verify and all the certificates are valid, the chain is trusted.
A common failure mode is an expired intermediate CA certificate. The server certificate is valid, but the intermediate that signs it has expired. The client rejects the connection because the chain is broken. The server administrator must update the intermediate certificate .
c. Certificate File Formats
Certificates are stored in different file formats. The two most common are PEM and DER.
PEM (Privacy-Enhanced Mail) is a Base64-encoded format. The certificate is wrapped between -----BEGIN CERTIFICATE----- and -----END CERTIFICATE----- lines. PEM is the most common format on Linux systems. It is text-based and can be opened in a text editor. Both certificates and private keys can be stored in PEM format .
DER (Distinguished Encoding Rules) is a binary format. It is the raw ASN.1 encoding of the certificate. DER is more compact than PEM but is not human-readable. It is used in Java keystores and some Windows applications .
PKCS#12 (PFX) is a container format that can hold a certificate, a private key, and intermediate certificates in a single encrypted file. It is commonly used on Windows and in Java applications .
On a typical Linux system, trusted CA certificates are stored in /usr/lib/ssl/certs (Ubuntu/Debian) or /etc/pki/tls/certs (RHEL/CentOS). The certificates can be stored as individual .crt or .pem files, or as a single bundle file like ca-bundle.crt .
The environment variables SSL_CERT_DIR and SSL_CERT_FILE tell OpenSSL where to find the trusted certificates. SSL_CERT_DIR points to a directory containing individual certificate files. SSL_CERT_FILE points to a single bundle file .
d. Certificate Signing Requests
A certificate signing request (CSR) is the mechanism used to request a certificate from a CA. It contains the public key and the information that will go into the certificate: the domain name, the organization name, the locality, and the country .
The CSR is generated on the server where the certificate will be used. The server generates a private key and a public key. The public key is included in the CSR. The private key is kept secret and never sent to the CA. The CA uses the CSR to generate the signed certificate. The certificate will only work with the private key that was generated with it. If the private key is lost, the certificate is useless .
The CSR is typically created in PEM format. It begins with -----BEGIN CERTIFICATE REQUEST----- and ends with -----END CERTIFICATE REQUEST-----. The openssl req command generates a CSR. The -new flag creates a new request, the -key flag specifies the private key, and the -out flag specifies the output file .
The Common Name (CN) field in the CSR is the most important. It is the domain name for which the certificate is requested. If the client connects to a host that has a certificate for a different domain, the certificate is invalid . Modern certificates also use the Subject Alternative Name (SAN) extension to cover multiple domains. The SAN is the field that browsers actually check; the CN is largely ignored .
e. Validating a Certificate
When a client receives a certificate, it performs a series of checks before trusting it.
Chain validation. The client verifies the signature on the server certificate using the intermediate CA’s public key. It verifies the intermediate CA’s signature using the root CA’s public key. It finds the root CA in its trust store .
Expiration check. The client checks the current date against the certificate’s validity period. If the current date is outside the period, the certificate is rejected .
Hostname check. The client checks that the domain name in the certificate matches the domain name it is trying to reach. The check uses the SAN extension. If the SAN contains a wildcard like *.example.com, the wildcard matches only the leftmost label — www.example.com matches, but sub.www.example.com does not .
Revocation check. The client checks whether the certificate has been revoked by the CA. This is done through a certificate revocation list (CRL) or the Online Certificate Status Protocol (OCSP). Revocation is used when a private key is compromised before the certificate expires.
The openssl s_client command is a diagnostic tool for inspecting the certificate chain a server presents. The -showcerts flag displays all the certificates the server sends. The -verify_return_error flag aborts the handshake if any verification error occurs. Without that flag, s_client continues the handshake even after verification errors, which is useful for debugging but dangerous for production use .
Complete Example Session
This session demonstrates how to inspect a certificate and its chain using OpenSSL.
# ============================================
# PART 1: CONNECT TO A SERVER AND VIEW THE CERTIFICATE
# ============================================
openssl s_client -connect example.com:443 -showcerts
# Output (abbreviated):
# CONNECTED(00000003)
# depth=2 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global Root CA
# verify return:1
# depth=1 C = US, O = DigiCert Inc, CN = DigiCert TLS RSA SHA256 2020 CA1
# verify return:1
# depth=0 CN = www.example.org
# verify return:1
# ---
# Certificate chain
# 0 s:CN = www.example.org
# i:C = US, O = DigiCert Inc, CN = DigiCert TLS RSA SHA256 2020 CA1
# -----BEGIN CERTIFICATE-----
# MIIF...
# -----END CERTIFICATE-----
# ...
# The output shows the certificate chain:
# depth 0: the server certificate (www.example.org)
# depth 1: the intermediate CA (DigiCert TLS RSA SHA256 2020 CA1)
# depth 2: the root CA (DigiCert Global Root CA)
# ============================================
# PART 2: EXTRACT THE CERTIFICATE
# ============================================
openssl s_client -connect example.com:443 -showcerts </dev/null 2>/dev/null | \
openssl x509 -outform PEM > example.crt
# The command extracts the server certificate and saves it to example.crt.
# ============================================
# PART 3: INSPECT THE CERTIFICATE
# ============================================
openssl x509 -in example.crt -text -noout
# Output (abbreviated):
# Certificate:
# Data:
# Version: 3 (0x2)
# Serial Number: 0a:...
# Signature Algorithm: sha256WithRSAEncryption
# Issuer: C = US, O = DigiCert Inc, CN = DigiCert TLS RSA SHA256 2020 CA1
# Validity
# Not Before: Jan 15 00:00:00 2026 GMT
# Not After : Jan 14 23:59:59 2027 GMT
# Subject: CN = www.example.org
# Subject Public Key Info:
# Public Key Algorithm: rsaEncryption
# Public-Key: (2048 bit)
# X509v3 extensions:
# X509v3 Subject Alternative Name:
# DNS:www.example.org, DNS:example.com, DNS:example.net
# The subject is www.example.org.
# The issuer is the intermediate CA.
# The validity period is one year.
# The SAN extension covers three domain names.
# ============================================
# PART 4: CHECK THE EXPIRATION DATE
# ============================================
openssl x509 -in example.crt -noout -enddate
# Output:
# notAfter=Jan 14 23:59:59 2027 GMT
# ============================================
# PART 5: CHECK THE SUBJECT ALTERNATIVE NAMES
# ============================================
openssl x509 -in example.crt -noout -ext subjectAltName
# Output:
# X509v3 Subject Alternative Name:
# DNS:www.example.org, DNS:example.com, DNS:example.net
# ============================================
# PART 6: VERIFY THE CERTIFICATE AGAINST THE CHAIN
# ============================================
openssl verify -CAfile /etc/ssl/certs/ca-certificates.crt example.crt
# Output:
# example.crt: OK
# The certificate is valid and signed by a trusted CA.
# ============================================
# PART 7: GENERATE A CSR
# ============================================
openssl req -new -newkey rsa:2048 -nodes \
-keyout server.key -out server.csr \
-subj "/C=US/ST=CA/L=San Francisco/O=Example Inc/CN=example.com"
# The command generates:
# - server.key: the private key (unencrypted with -nodes)
# - server.csr: the certificate signing request
# ============================================
# PART 8: INSPECT THE CSR
# ============================================
openssl req -in server.csr -noout -text
# Output (abbreviated):
# Certificate Request:
# Data:
# Version: 0 (0x0)
# Subject: C = US, ST = CA, L = San Francisco, O = Example Inc, CN = example.com
# Subject Public Key Info:
# Public Key Algorithm: rsaEncryption
# Public-Key: (2048 bit)
# The CSR contains the subject and the public key.
# The private key is not in the CSR.
# ============================================
# PART 9: GENERATE A SELF-SIGNED CERTIFICATE
# ============================================
openssl req -x509 -days 365 -newkey rsa:2048 -nodes \
-keyout selfsigned.key -out selfsigned.crt \
-subj "/CN=localhost"
# The command generates a self-signed certificate.
# The certificate is its own issuer.
# ============================================
# PART 10: THE SUMMARY
# ============================================
# A certificate binds a public key to an identity.
# The identity is a domain name, an organization, or a person.
# The certificate is signed by a CA.
# The CA's signature makes the certificate trustworthy.
# The certificate chain connects the server certificate to a trusted root.
# The CSR is the request to the CA.
# The private key never leaves the server.The ten parts cover viewing the certificate chain, extracting the certificate, inspecting the certificate, checking the expiration date, checking the subject alternative names, verifying the certificate, generating a CSR, inspecting the CSR, generating a self-signed certificate, and the summary.
Quick Reference
The X.509 Fields
| Field | Purpose |
|---|---|
| Version | X.509 version (v3 is current) |
| Serial Number | Unique CA-assigned ID |
| Signature Algorithm | Algorithm used to sign |
| Issuer | The CA that signed the certificate |
| Validity | Start and end dates |
| Subject | The entity the certificate represents |
| Public Key | The public key and its algorithm |
| Extensions | SAN, key usage, basic constraints |
The Certificate Chain
| Level | Signed By | Stored |
|---|---|---|
| Root CA | Itself | Trust store |
| Intermediate CA | Root CA | Server provides |
| End-entity | Intermediate CA | Server provides |
The File Formats
| Format | Encoding | Extension |
|---|---|---|
| PEM | Base64 | .pem, .crt |
| DER | Binary | .der, .cer |
| PKCS#12 | Binary container | .p12, .pfx |
The Common Commands
| Command | Purpose |
|---|---|
openssl s_client -connect host:443 | View the certificate chain |
openssl x509 -in cert -text -noout | Inspect a certificate |
openssl req -new -newkey rsa:2048 | Generate a CSR |
openssl verify -CAfile ca.crt cert.crt | Verify a certificate |
Best Practices
✅ Do This:
# Use the SAN extension for modern certificates
# Browsers check SAN, not CN # ✅# Check the expiration date before deployment
openssl x509 -in cert.crt -noout -enddate # ✅# Keep the private key secret
# The private key never leaves the server # ✅# Use the certificate chain
# The server must provide the intermediate CA certificate # ✅❌ Don’t Do This:
# Don't use self-signed certificates in production
# Use a certificate from a trusted CA # ❌# Don't forget to renew before expiration
# An expired certificate causes an outage # ❌# Don't rely on the Common Name alone
# The SAN is what modern clients check # ❌# Don't share the private key
# The private key is the identity of the server # ❌Common Pitfalls
| Pitfall | Why It Happens | Fix |
|---|---|---|
| Certificate not trusted | Self-signed or missing intermediate | Use a CA-signed certificate |
| Hostname mismatch | SAN does not include the domain | Add the domain to the SAN |
| Expired certificate | Not renewed before expiration | Renew on time |
| Chain broken | Missing intermediate certificate | Install the intermediate |
| Browser warning | Untrusted CA | Install the root CA |
Real-World Examples
1. View the Certificate Chain
openssl s_client -connect example.com:443 -showcerts2. Inspect a Certificate
openssl x509 -in cert.crt -text -noout3. Check the Expiration Date
openssl x509 -in cert.crt -noout -enddate4. Check the SAN
openssl x509 -in cert.crt -noout -ext subjectAltName5. Verify a Certificate
openssl verify -CAfile ca.crt cert.crt6. Generate a CSR
openssl req -new -newkey rsa:2048 -nodes -keyout server.key -out server.csr7. Inspect a CSR
openssl req -in server.csr -noout -text8. Generate a Self-Signed Certificate
openssl req -x509 -days 365 -newkey rsa:2048 -nodes -keyout key.pem -out cert.pem9. Convert PEM to DER
openssl x509 -in cert.pem -outform DER -out cert.der10. Convert PEM to PKCS#12
openssl pkcs12 -export -in cert.pem -inkey key.pem -out cert.p12Visual
The Certificate Chain
┌──────────────────────────────────────────────┐
│ ROOT CA │
│ └─ Self-signed │
│ └─ Pre-installed in trust store │
│ │ │
│ ▼ │
│ INTERMEDIATE CA │
│ └─ Signed by root │
│ └─ Provided by the server │
│ │ │
│ ▼ │
│ END-ENTITY CERTIFICATE │
│ └─ Signed by intermediate │
│ └─ Contains the server's public key │
│ └─ Contains the domain name │
│ │
└──────────────────────────────────────────────┘The X.509 Certificate
┌──────────────────────────────────────────────┐
│ X.509 CERTIFICATE │
│ │
│ Version: 3 │
│ Serial Number: ... │
│ Signature Algorithm: sha256WithRSA... │
│ Issuer: DigiCert TLS RSA SHA256 2020 CA1 │
│ Validity: 2026-01-15 to 2027-01-14 │
│ Subject: CN = www.example.org │
│ Public Key: RSA 2048-bit │
│ Extensions: │
│ Subject Alternative Name: │
│ DNS: www.example.org │
│ DNS: example.com │
│ │
└──────────────────────────────────────────────┘The CSR
┌──────────────────────────────────────────────┐
│ CERTIFICATE SIGNING REQUEST │
│ │
│ Subject: │
│ C = US │
│ ST = CA │
│ L = San Francisco │
│ O = Example Inc │
│ CN = example.com │
│ Public Key: RSA 2048-bit │
│ │
│ The private key is NOT in the CSR. │
│ The CA uses the CSR to create the cert. │
│ │
└──────────────────────────────────────────────┘The Trust Store
┌──────────────────────────────────────────────┐
│ TRUST STORE │
│ │
│ Ubuntu/Debian: │
│ /usr/lib/ssl/certs/ │
│ │
│ RHEL/CentOS: │
│ /etc/pki/tls/certs/ca-bundle.crt │
│ │
│ Environment variables: │
│ SSL_CERT_DIR → directory │
│ SSL_CERT_FILE → bundle file │
│ │
└──────────────────────────────────────────────┘Summary
| Item | Value |
|---|---|
| Certificate definition | Binds a public key to an identity |
| Standard | X.509 v3 |
| Issuer | The CA that signed the certificate |
| Subject | The entity the certificate represents |
| SAN | Subject Alternative Name; covers multiple domains |
| Chain | Root CA → Intermediate CA → End-entity |
| Trust store | Pre-installed root CA certificates |
| CSR | Certificate Signing Request; sent to the CA |
| Private key | Never sent to the CA; kept on the server |
| Format | PEM (Base64), DER (binary) |
| Validity | Start and end dates |
Key takeaways:
- A certificate binds a public key to an identity. The identity is typically a domain name. The certificate is signed by a CA. The CA’s signature is what makes the certificate trustworthy .
- The certificate chain connects the server certificate to a trusted root. The root CA is pre-installed in the trust store. The intermediate CA is provided by the server. The end-entity certificate is the server’s certificate. The client validates the chain from the end-entity back to the root .
- The X.509 standard defines the certificate format. The current version is v3, which added the extensions field. The extensions include the Subject Alternative Name (SAN), key usage, and basic constraints .
- The Subject Alternative Name (SAN) is what modern clients check. The Common Name (CN) is largely ignored by browsers. A certificate must include the domain name in the SAN to be valid for that domain .
- A CSR is the request to the CA. The CSR contains the public key and the subject information. The private key is generated at the same time but is never sent to the CA. The certificate will only work with the private key that was generated with it .
- Certificates have a validity period. The client checks the current date against the certificate’s validity. An expired certificate is rejected. The server administrator must renew before expiration .
- The certificate is the foundation of trust on the internet. Without it, a client cannot know that the public key it received belongs to the server it wants to talk to. The certificate, the chain, and the CA are the mechanisms that make secure communication possible.
Remember: A certificate is a public key wrapped in a signed statement of identity. The CA signs the statement. The client trusts the CA. The chain connects the server certificate to the root CA. The SAN identifies the domains. The CSR is the request. The private key is the secret. The certificate is the public part. The chain is the trust path. And the trust store is where the trust begins.
Stop using slow, ad-bloated tool sites! 🤮
🔎 Search “KandZ Tools” on Google to use many professional utilities for free.
KandZ.me is the ultimate minimalist hub for:
✅ Finance (Mortgage, Interest, Inflation)
✅ Tech (Base64, JSON, Dev Suite, IP)
✅ Health (BMI, BMR, TDEE)
✅ Productivity (Timer, Workspace, QR)
⚡️ Fast & Private
🔒 No data leaves your device
💎 100% Free
🔗 Use it now: https://tools.kandz.me
🔖 Bookmark it—you’ll need it later!