PKI Use Cases: HTTPS, S/MIME, and Code Signing

Public Key Infrastructure (PKI) is the invisible backbone of secure digital communications. The certificates and CAs you've studied are applied in dozens of real-world scenarios daily. The Security+ exam tests your ability to recognize PKI use cases, understand which certificate type is appropriate for each, and identify what protection PKI provides in each context. The three most important use cases on the exam are HTTPS/TLS (web security), S/MIME (email security), and code signing (software integrity).

HTTPS (HTTP over TLS) is the most visible PKI use case. When you connect to https://bank.com, your browser: (1) receives the server's TLS certificate, (2) verifies the certificate chain leads to a trusted root CA, (3) checks the hostname against the SAN fields, (4) verifies the certificate isn't revoked, and (5) uses the public key for a Diffie-Hellman key exchange to establish an encrypted session. The padlock icon in your browser signifies all these checks passed. A missing or invalid certificate results in a browser warning that stops most users from proceeding.

S/MIME (Secure/Multipurpose Internet Mail Extensions) uses PKI certificates to provide two security services for email. Encryption: the sender encrypts the email body with the recipient's public key, so only the recipient can decrypt it — protecting confidentiality even if the email is intercepted in transit or stored on a compromised server. Digital signatures: the sender signs with their private key, proving to the recipient that the email genuinely came from the sender and has not been altered — protecting integrity and providing non-repudiation. S/MIME requires each user to have their own certificate issued by a CA.

Code signing uses PKI to digitally sign software — executables, scripts, drivers, and installers — so users can verify the software came from a trusted publisher and has not been tampered with. The software vendor signs their code with a private key from a code-signing certificate issued by a trusted CA. When a user runs the software, the OS verifies the signature using the vendor's public key from the certificate chain. Windows SmartScreen, macOS Gatekeeper, and iOS/Android app stores all rely on code signing to establish software provenance. Unsigned software may be blocked or trigger security warnings.

Client certificate authentication (also called mutual TLS or mTLS) extends the standard TLS model by requiring the client to present a certificate as well. In standard TLS, only the server is authenticated by certificate; in mTLS, both parties are mutually authenticated. This is used for: VPN authentication (smart cards or client certs instead of passwords), API authentication (machine-to-machine authentication where the client is a service, not a human), and privileged admin access (requiring administrators to use hardware tokens with embedded certificates).

SSH uses public key cryptography for two purposes: server authentication and client authentication. Server authentication: when you first connect to an SSH server, it presents its host key (public key). Your SSH client stores this in ~/.ssh/known_hosts. On subsequent connections, if the host key changes (which could indicate a MITM attack or server rebuild), SSH warns you. Client authentication: instead of passwords, administrators use key pairs — the public key is added to the server's authorized_keys, and the private key (never sent) proves identity. SSH host keys are separate from PKI certificates but serve the same trust function.

PKI enables legally binding digital document signing in many jurisdictions. Adobe PDF signatures, DocuSign, and government e-signature systems all use PKI certificates to sign documents. A critical complement to document signing is timestamping: a Trusted Timestamp Authority (TSA) countersigns the document's hash with a trusted time, proving the document existed at a specific point in time. Timestamping is essential for code signing as well — without a timestamp, code signatures become invalid when the signing certificate expires, even for software distributed before the expiry.

As IoT devices proliferate, PKI provides a mechanism to authenticate devices at scale. Each device is provisioned with a unique certificate during manufacturing (a process called device identity provisioning), allowing servers to authenticate individual devices by their certificates. This enables scenarios like: a smart meter proving its identity to the utility's server, a medical device authenticating to a hospital network, or a fleet of vehicles authenticating to a manufacturer's backend. IoT PKI must handle millions of devices with constrained resources, driving adoption of ECC certificates for their small size and fast verification.

Certificate-based VPN authentication is significantly more secure than password-based VPN authentication. Each VPN user or device is issued a client certificate by the organization's internal CA. When connecting, the VPN gateway verifies the client certificate (ensuring it was issued by the trusted internal CA, is within its validity period, and hasn't been revoked via CRL/OCSP). When an employee leaves, revoking their certificate immediately prevents VPN access — more reliable than hoping they haven't shared their password with others.

Security professionals must be able to diagnose common certificate errors. Certificate expired: notAfter date has passed — renew the certificate. Hostname mismatch: the certificate's SAN does not match the requested hostname — verify CNs and SANs, may need a wildcard or multi-SAN cert. Self-signed certificate: no CA has vouched for this certificate — add to local trust store or replace with CA-signed cert. Incomplete chain: intermediate CA certificate not provided by the server — configure the server to send the full chain. Certificate revoked: CRL or OCSP shows revocation — immediate key compromise response needed.

Two certificate types handle multiple hostnames. A wildcard certificate covers all first-level subdomains of a domain: *.example.com covers www.example.com, mail.example.com, api.example.com, but NOT sub.api.example.com (two levels). One certificate, one private key for all services — convenient but risky if the key is compromised (all services affected). A multi-SAN certificate explicitly lists multiple specific domains in the SAN extension (e.g., example.com, www.example.com, api.example.com). More granular but requires updating the certificate when new domains are added.

Test your understanding of CompTIA Security+ (SY0-701) concepts from this lesson.

In this lesson you learned: HTTPS/TLS uses server certificates to encrypt web traffic and authenticate servers; S/MIME certificates enable email signing and encryption; code signing certificates prove software integrity and publisher identity; and client certificates enable mutual authentication for VPNs and APIs. Next up we explore Password Policies and Multi-Factor Authentication.