How PKI Works: Key Pairs, Certificate Authorities, and the Root of Trust(OBJ.1.3)

Your browser has never met your bank's web server, yet within milliseconds of connecting it decides the server really belongs to the bank. Nobody phoned the bank to check. The browser trusts the server because an organization it already trusts has vouched for the server's public key, the same way a border officer who has never met you accepts your passport because they trust the government that issued it.

That system of vouching is public key infrastructure, or PKI: the keys, certificates, certificate authorities, policies and software that let strangers verify each other's identity. On the CompTIA Security+ SY0-801 exam, PKI sits under objective 1.3, which expects you to explain why choosing the right cryptographic solution matters, including public and private keys, certificate authorities and the root of trust. This lesson covers what each key does, what a certificate contains, how certificate authorities chain together, and how public and internal PKIs differ.

The private key proves identity and the public key lets anyone check it

PKI is built on asymmetric cryptography. Each participant has a key pair: two mathematically related keys generated together. The public key can be given to anyone. The private key stays with its owner and ideally never leaves the device or hardware module that created it. Knowing the public key doesn't reveal the private key, which is what makes publishing it safe; the math is covered in the encryption section.

The two keys do opposite jobs, and the exam checks that you can pick the right one:

• To send something only one person can read, encrypt it with the recipient's public key. Only the recipient's private key can decrypt it. That provides confidentiality.
• To prove you created something, sign it with your own private key. Anyone with your public key can verify the signature. That provides integrity, authentication and non-repudiation.

A question that asks which key a sender uses to sign an email wants the sender's private key. A question that asks which key encrypts a file for the CFO wants the CFO's public key. The tempting wrong answer is usually the correct person's other key.

Public keys rarely encrypt bulk data. In a TLS 1.3 connection, the server's private key signs part of the handshake to prove its identity, while a separate ephemeral key exchange produces the symmetric keys that protect the traffic.

That leaves a problem. If a server sends you a public key, how do you know it belongs to the bank and not to an attacker? Anyone can generate a key pair and claim any name. Certificates solve that.

A certificate binds a public key to a name, and a CA signs that binding

A digital certificate is a signed statement that says, in effect, "this public key belongs to this subject, for this period, for these purposes." The standard format is X.509 version 3, used for websites, VPNs, email, smart cards and code signing alike. The certificate authority (CA) that issues it signs the whole structure with the CA's private key, so changing any field breaks the signature.

Here is a trimmed view of a web server certificate as an administrator would inspect it:

$ openssl x509 -in www.example.com.crt -noout -text
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            5a:3e:91:0c:7d:22:e4:18:b6:0f:4c:93:a1:2d:77:e5
        Signature Algorithm: ecdsa-with-SHA384
        Issuer: C=US, O=Example Trust Services, CN=Example TLS Issuing CA R2
        Validity
            Not Before: Sep 14 00:00:00 2026 GMT
            Not After : Mar 31 23:59:59 2027 GMT
        Subject: CN=www.example.com
        Subject Public Key Info:
            Public Key Algorithm: id-ecPublicKey
                Public-Key: (256 bit)
                NIST CURVE: P-256
        X509v3 extensions:
            X509v3 Subject Alternative Name:
                DNS:www.example.com, DNS:example.com
            X509v3 Key Usage: critical
                Digital Signature
            X509v3 Extended Key Usage:
                TLS Web Server Authentication
            X509v3 Basic Constraints: critical
                CA:FALSE
    Signature Algorithm: ecdsa-with-SHA384

Each field answers a question a client will ask:

• Serial number: a value unique among every certificate this CA has issued. Revocation lists and OCSP responses identify certificates by it. Public CAs must include at least 64 random bits.
• Issuer and subject: who signed the certificate and who it identifies.
• Validity: the Not Before and Not After times. Outside that window the certificate is rejected.
• Subject public key info: the public key the CA is vouching for, and its algorithm.
• Subject Alternative Name (SAN): every DNS name, IP address or email address the certificate covers. Modern browsers check only the SAN list and ignore the common name (CN) for hostname matching.
• Key usage and extended key usage: what the key may be used for. A certificate marked for TLS server authentication can't be used to sign software.
• Basic constraints: CA:FALSE means this certificate can't sign other certificates. A CA's own certificate says CA:TRUE.
• Signature algorithm and value: the CA's signature over everything above.

Notice what a certificate doesn't contain: the private key. A certificate is public by design, and a server hands it to every client that connects. Files that bundle a certificate with its private key, such as PKCS #12 files with a .pfx or .p12 extension, are a different thing and need the same protection as a password.