Learn PKI - Core Concepts & Main Architecture

#Introduction

In episode 1 you understood the history and reasons PKI was born: preventing fake identity and guaranteeing authentication, integrity, and confidentiality through a chain of trust. Now it is time to open the box and see the components that make up PKI directly.

This episode's roadmap: we dissect the X.509 certificate anatomy, understand the role of CSR, assemble the chain of trust, map the PKI hierarchy with Root CA and Sub CA, and then trace three important flows — issuance, verification, and revocation. By the end of this episode you will have a complete mental map of how a single certificate is born, trusted, and revoked.

#X.509 Certificate Anatomy

An X.509 certificate is not just a file; it is a structured document with several important fields:

• Subject: who owns the certificate, for example a server host name or an organization's identity.
• Issuer: who issued and signed this certificate.
• Validity: the validity period, from notBefore to notAfter.
• SAN (Subject Alternative Name): the list of domain names or IPs valid for this certificate.
• Public key: the owner's public key, used for verification and encryption.
• Signature: the issuer's signature that binds all the fields above together.

openssl x509 -in cert.pem -noout -subject -issuer -dates
openssl x509 -in cert.pem -noout -ext subjectAltName
openssl x509 -in cert.pem -noout -text

The first command shows the subject, issuer, and validity period; the second shows the SAN; the third shows all the details including the public key and signature algorithm. Before a certificate is shared, check its conformance with openssl x509 -in cert.pem -text.

#CSR: Certificate Signing Request

Before a certificate is issued, the requester usually creates a CSR. A CSR is a formal request containing the public key and the desired identity, signed with the requester's private key as proof of ownership. A CSR is not yet a certificate; it is still a request waiting for the CA's signature.

In short: the requester creates a key pair, packages the public key and identity into a CSR, then sends the CSR to the CA. The CA examines the information, adds the validity period and extensions, then signs and returns the certificate. We will practice creating a CSR directly in episode 3.

#Chain of Trust

The chain of trust is a sequence of certificates that sign each other: the root signs the intermediate, the intermediate signs the leaf. You trust the leaf because the leaf was signed by the intermediate you trust, and you trust the intermediate because it was signed by the root that is in your trust store.

This is the key idea of PKI: trust is passed down through signatures, not through self-claims. As long as the chain from leaf to root can be built and every signature is valid, the certificate is considered trusted.

#PKI Hierarchy

#Root CA and Sub CA

Enterprise PKI is usually shaped as a two-tier hierarchy:

• Root CA: the highest authority, self-signed, held most securely and often offline.
• Sub CA (Intermediate CA): the middle authority that issues day-to-day certificates, sitting beneath the root.

An offline root means its private key never touches the network — a practice that reduces the risk of misuse. Almost all roots on the internet work this way. We will build a similar hierarchy in episode 4.

#CRL and OCSP

An issued certificate can stop being trusted earlier through revocation. The two main mechanisms are:

• CRL (Certificate Revocation List): a list of revoked certificate serial numbers, published periodically by the CA.
• OCSP (Online Certificate Status Protocol): a real-time service to query the status of a single certificate.

OCSP stapling is a variant in which the server carries proof of valid status from an OCSP responder during the TLS handshake, so clients do not need to ask the CA each time.

#Issuance Flow: from Key Pair to Certificate

The entire issuance process can be summarized in four steps:

1. Generate key pair: the requester creates a private key and a public key.
2. Create CSR: the public key and identity are packaged into a CSR.
3. CA signature: the CA validates and signs, producing a certificate.
4. Distribution: the certificate is installed on the server or application that needs it.

Steps one through two are done by the requester, step three by the CA, and step four involves both. This is the sequence you will practice over and over.

#Verification Flow: Building the Chain

When a client receives a certificate, it does not trust it immediately. The verification process runs:

1. Take the leaf certificate sent by the server.
2. Find its issuer in the trust store or among the provided intermediate certificates.
3. Verify the signature: the issuer's public key must validate the leaf's signature.
4. Repeat until you reach a root that is in the trust store.
5. Check the validity period and revocation status.

The key here is the trust store: the list of roots the system considers valid. If the leaf does not connect to any root in the trust store, verification fails. This trust store concept will be fully discussed in episode 5.

#Certificate Lifecycle

Every certificate goes through the same lifecycle, and understanding its stages helps you manage a CA well:

1. Issuance: the certificate is issued through the flow we already discussed.
2. Distribution: the certificate and intermediate are installed on the server that needs them.
3. Renewal: before expiry, the certificate is renewed with the same key or a new key.
4. Revocation: when a key leaks or identity changes, the certificate is revoked early.
5. Expiration: a certificate that is not renewed stops being valid automatically.

The two stages most often forgotten are renewal and revocation. Modern systems automate renewal with protocols such as ACME, while revocation still relies on CRL and OCSP as we discussed.

openssl x509 -in cert.pem -noout -dates

The output shows notBefore and notAfter. Get into the habit of checking validity before installing a certificate into production, because this is the most common cause of failures in the field. This small habit will save you from incidents that could actually have been prevented.

#Closing

In episode 2 you dissected the PKI architecture: the X.509 certificate anatomy with subject, issuer, validity, SAN, public key, and signature; the role of CSR as an issuance request; the chain of trust as the basis of trust; the Root CA and Sub CA hierarchy; and the issuance, verification, and revocation flows with CRL and OCSP.

Key takeaways:

• An X.509 certificate carries the owner's identity, issuer, validity period, SAN, public key, and signature.
• A CSR is an issuance request waiting for the CA's signature, not a certificate.
• Trust is passed down through signatures in a chain of trust from root to leaf.
• The Root CA is offline and the Sub CA handles daily issuance.
• Verification builds the chain from leaf to root using the trust store.
• Revocation is handled through CRL and OCSP, with OCSP stapling as a practical variant.

In the next episode, episode 3, we will get hands-on with the terminal: OpenSSL for creating keys, CSRs, and self-signed certificates — the practical foundation that will be used when building a private CA in episode 4. Get your terminal ready!