Apple Certificate Transparency requirements


#1

Apple have stated that publicly trusted TLS certificates used for server authentication must adhere to Apple’s certificate Transparency policy as of iOS 12.1.1

Certificate Transparency

Starting in iOS 12.1.1 publicly-trusted Transport Layer Security (TLS) server authentication certificates issued after October 15, 2018 must meet Apple’s Certificate Transparency (CT) policy to be evaluated as trusted. Please see Knowledge Base article HT205280 for details on Apple’s Certificate Transparency policy.

From Apple Article: https://support.apple.com/en-us/HT205280

Certificate Transparency policy

Publicly-trusted Transport Layer Security (TLS) server authentication certificates issued after October 15, 2018 must meet our Certificate Transparency (CT) policy to be evaluated as trusted on Apple platforms. Certificates that fail to comply will this policy will result in a failed TLS connection, which can break an app’s connection to Internet services or Safari’s ability to seamlessly connect.

The enforcement of this policy will be deployed with a software update later this year. Previously, only publicly-trusted Extended Validation (EV) TLS server authentication certificates were required to meet this CT policy.

Policy requirements

Our policy requires at least two Signed Certificate Timestamps (SCT) issued from a CT log—once approved* or currently approved at the time of check—and either:

  • At least two SCTs from currently-approved CT logs with one SCT presented via TLS extension or OCSP Stapling; or
  • At least one embedded SCT from a currently-approved log and at least the number of SCTs from once or currently approved logs, based on validity period as detailed in the table below.
Certificate lifetime # of SCTs from separate logs
Less than 15 months 2
15 to 27 months 3
27 to 39 months 4
More than 39 months 5

From iOS 12.1.1, MacOS 10.14.2, tvOS 12.1.1, and watchOS 5.1.1 Apple have added a new payload “Certificate Transparency Payload” that allows you to disable Certificate Transparency checks for specified domains or certificates.

Key Type Value
DisabledForDomains Array of Strings Optional. List of domains where certificate transparency is disabled. A leading period can be used to match subdomains, but a domain matching rule must not match all domains within a top level domain (”.example.com” and ”.example.co.uk” are allowed while ”.com” and”.co.uk” are not allowed).
DisabledForCerts Array of Dictionaries Optional. A list of hashed subjectPublicKeyInfo dictionaries defining the certificates where certificate transparency is disabled. For certificate transparency enforcement to be disabled, one of the following conditions must be met: The hash is of the server certificateʼs subjectPublicKeyInfo. The hash is of a subject PublicKeyInfo that appears in a CA certificate in the certificate chain, that CA certificate is constrained via the X.509v3 nameConstraints extension, one or more directoryName nameConstraints are present in the permittedSubtrees, and the directoryName contains an organizationName attribute. The hash is of a subject PublicKeyInfo that appears in a CA certificate in the certificate chain, the CA certificate has one or more organizationName attributes in the certificate Subject, and the serverʼs certificate contains the same number of organizationName attributes, in the same order, and with byte-for-byte identical values.

The hashed subjectPublicKeyInfo dictionary contains the following keys:

Key Type Value
Algorithm String Required. Currently, must be ”sha256”.
Hash Data Required. Created by applying the specified hash algorithm to the DER-encoding of the certificateʼs subjectPublicKeyInfo.

To generate the data specified by the Hash key in the subjectPublicKeyInfo dictionary, use this command for a PEM encoded certificate:
openssl x509 -pubkey -in example_certificate.pem -inform pem | openssl pkey -pubin - outform der | openssl dgst -sha256 -binary | base64

If your certificate is DER encoded, use this command:
openssl x509 -pubkey -in example_certificate.der -inform der | openssl pkey -pubin - outform der | openssl dgst -sha256 -binary | base64

If your certificate does not have a .pem or .der extension, use the file command to identify its encoding type.
$ file example_certificate.crt example_certificate.crt: PEM certificate $ file example_certificate.cer example_certificate.cer: data

This is taken from:


#2

Can you elaborate on how this will currently impact EMMs and organizations? What steps need to be taken?

  1. Do organizations have to check if the services they use have got their certificates CT logged?
  2. How to check?
  3. Do all CA’s respect this policy requirement from October?

#3

Yes if your certificates do not meet the requirements iOS devices will fail to connect

Have a look here: http://www.certificate-transparency.org


#4

I’ve placed some questions about CT in Apple’s support forums months ago, but sadly no reply to this day.

I think CT concerns only server side certificates. I do not know of a CA that does not support CT. I think most major CAs have support for it for some time already. However, it could be the case that CT is not supported by domestic CAs in some countries.

For me the biggest issue is probably that self-signed server certificates will no longer by supported when doing local test enrollments for developer purposes and this is something that really bugs me. :frowning:


#5

For me the biggest issue is probably that self-signed server certificates will no longer by supported when doing local test enrollments for developer purposes and this is something that really bugs me. :frowning:

@petar In Earlier versions and Latest 12.1.2 beta , devices are enrolling using self-signed certificates.


#6

That’s good info. Was the certificate issued before October 15, 2018 or after?


#7

@petar , Self signed certificates issued after Oct 15,2018.


#8

Nice! Let’s see if it stays that way. I hope so.