How Safari Validates SSL/TLS Certificates on macOS and iOS

This article provides a comprehensive overview of the process the Safari web browser uses to validate SSL/TLS server certificates on macOS and iOS devices. It covers the steps from the initial TLS handshake and chain-of-trust verification against the built-in Apple Root Certificate Program to policy enforcement, real-time revocation checks, and Certificate Transparency validation.

The TLS Handshake and OS Integration

When a user navigates to an HTTPS website in Safari, the browser initiates a TLS handshake with the web server. During this process, the server presents its leaf SSL/TLS certificate along with one or more intermediate certificates.

Safari does not maintain its own independent certificate store or validation engine. Instead, it delegates this responsibility to the underlying operating system (macOS or iOS). Safari passes the received certificate chain to the system’s Security.framework, specifically a background daemon known as trustd, which executes the cryptographic verification against the Apple Root Certificate Program store.

Building and Verifying the Chain of Trust

The trustd daemon attempts to construct a valid cryptographic path from the website's leaf certificate up to a known root certificate.

  1. Leaf Certificate: The certificate issued specifically to the website's domain.
  2. Intermediate Certificates: Certificates that act as a bridge, signed by a root authority to issue leaf certificates.
  3. Root Certificate: A self-signed certificate held by a Certificate Authority (CA).

Each certificate in the chain must be digitally signed by the entity immediately above it. For the chain to be trusted, it must terminate at a Root CA that is actively included in the Apple Root Certificate Program. These root certificates are pre-installed on macOS and iOS and are updated securely by Apple through operating system updates. If the chain cannot be linked to an Apple-trusted root (or a root manually installed and trusted by the device administrator), validation fails immediately.

Enforcing Apple’s Certificate Policies

Once a valid chain to a trusted root is established, the operating system evaluates the certificate against strict structural and security policies set by Apple:

  • Domain Name Matching: The domain name in Safari’s address bar must exactly match a name listed in the certificate's Subject Alternative Name (SAN) extension. Checking the legacy Common Name (CN) field is no longer sufficient.
  • Validity Period: The current system date and time must fall between the certificate's "Not Before" and "Not After" timestamps. Furthermore, Apple enforces a strict maximum lifespan policy: any TLS server certificate issued on or after September 1, 2020, will be rejected by Safari if its validity period exceeds 398 days.
  • Cryptographic Standards: The certificates must utilize strong cryptographic algorithms. Apple rejects certificates using SHA-1 hashes or RSA keys smaller than 2048 bits (or Elliptic Curve Cryptography keys smaller than 256 bits).

Certificate Revocation Checking

A cryptographically valid certificate may still be untrustworthy if its private key was compromised. To ensure the certificate has not been revoked by the issuing CA, macOS and iOS use three mechanisms:

  • Apple's "Valid" Service: Apple aggregates revocation data (CRLs) from trusted CAs, compiles it into a compact format, and periodically pushes this data directly to macOS and iOS devices. trustd checks this local cache first, which preserves user privacy and speeds up validation.
  • OCSP Stapling: A web server can include a timestamped Online Certificate Status Protocol (OCSP) response directly within the TLS handshake. If present, the OS validates this stapled response without needing to make an external network request.
  • Live OCSP Check: If the certificate is not covered by Apple's local cache and does not include a stapled response, trustd will query the issuing CA's OCSP server directly over the network to confirm the certificate is still active.

Certificate Transparency (CT) Enforcement

As a final step, Safari enforces Apple’s Certificate Transparency policy to protect against misissued or rogue certificates.

When a CA issues a certificate, it must submit it to multiple public, append-only CT logs, which return a Signed Certificate Timestamp (SCT). The server must deliver these SCTs to Safari during the TLS handshake (typically embedded in the certificate itself or via OCSP stapling). The operating system verifies that the certificate is accompanied by the required number of valid SCTs from distinct, Apple-approved CT logs.

If the certificate passes chain building, policy checks, revocation verification, and Certificate Transparency validation, trustd informs Safari that the connection is secure, and the webpage loads. If any critical step fails, Safari terminates the connection and displays a warning to the user.