iOS 12 Certificate Transparency Requirements Explained

Starting with iOS 12, Apple introduced mandatory Certificate Transparency (CT) enforcement to safeguard users from fraudulently issued or compromised TLS/SSL certificates. This security protocol mandates that all publicly trusted server certificates issued after a specific cutoff date must be publicly recorded in verifiable, append-only logs to be trusted by the operating system. By requiring cryptographic proof of logging before establishing secure HTTPS connections, iOS 12 ensures that Safari and other network-dependent apps reject unlogged certificates, significantly reducing the window of opportunity for man-in-the-middle attacks.

The Mandatory Cutoff Date

Apple’s Certificate Transparency policy in iOS 12 applies to all publicly trusted server certificates issued on or after October 15, 2018. Any public certificate issued after this date that fails to comply with Apple’s CT policy is treated as untrusted, causing the secure connection to fail immediately. Certificates issued prior to October 15, 2018, were grandfathered in and exempt from mandatory CT validation.

Delivery of Signed Certificate Timestamps (SCTs)

For a certificate to satisfy CT requirements in iOS 12, the server must present Signed Certificate Timestamps (SCTs) during the TLS handshake. SCTs serve as cryptographic proof that the certificate has been submitted to a qualified log. iOS 12 accepts SCTs delivered through any of the following three standard mechanisms:

• X.509v3 Extension: SCTs embedded directly within the leaf certificate by the issuing Certificate Authority (CA).
• TLS Extension: SCTs sent via a dedicated TLS extension during the handshake.
• OCSP Stapling: SCTs included within a stapled Online Certificate Status Protocol (OCSP) response provided by the server.

SCT Quantity and Log Diversity Rules

iOS 12 evaluates the validity of the presented SCTs against Apple’s list of recognized and qualified CT logs. Simply providing timestamps is not sufficient; the connection must present a minimum number of valid SCTs from distinct, independently operated logs depending on the certificate's validity lifetime:

• Lifetimes up to 15 months: At least two SCTs from distinct approved logs are required.
• Lifetimes between 15 and 27 months: At least three SCTs from distinct approved logs are required.
• Lifetimes between 27 and 39 months: At least four SCTs from distinct approved logs are required.
• Lifetimes greater than 39 months: At least five SCTs from distinct approved logs are required.

Furthermore, Apple requires log diversity, meaning SCTs must come from logs operated by different entities to prevent a single compromised log operator from validating malicious certificates.

Connection Behavior and Failure Handling

When a web browser or application on iOS 12 attempts to connect to an HTTPS domain, the system’s network security stack validates the TLS certificate and checks for compliant SCTs. If the certificate falls under the CT mandate and fails to meet the required number of valid SCTs, iOS 12 aborts the TLS handshake.

Safari displays a certificate trust warning indicating that the connection cannot be established securely. Because iOS treats CT failures as severe security risks, users cannot bypass this error screen for public domains, preventing insecure data transmission.

Enterprise and Private CA Exemptions

Apple designed the iOS 12 CT policy to impact only publicly trusted certificates. Connections using enterprise-managed credentials or private internal CAs are handled differently:

• Privately Installed CAs: Certificates chaining to a manually installed or MDM-deployed root certificate are automatically exempt from CT validation.
• Configuration Profiles: Enterprise administrators can deploy configuration payloads via Mobile Device Management (MDM) to disable CT enforcement for specific internal domains or certificates, ensuring that private corporate infrastructure functions without needing to publicly disclose internal hostnames to public CT logs.