Apple Certificate Transparency requirements

daniil_michine · November 11, 2018, 10:09pm

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: Apple's Certificate Transparency policy - Apple Support

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:

zmahesh · December 6, 2018, 7:33pm

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

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

daniil_michine · December 11, 2018, 10:41pm

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

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

petar · December 12, 2018, 9:27am

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.

Srikanthg · December 12, 2018, 10:59am

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.

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

petar · December 12, 2018, 4:48pm

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

Srikanthg · December 12, 2018, 5:42pm

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

petar · December 12, 2018, 5:57pm

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

Dara · December 19, 2018, 3:50pm

Hi @petar ,

I have used our Apple enterprise Support for your questions
Here is the reply from Apple Support:

Thank you for contacting us. My name is XXXXXX, I am an AppleCare Enterprise Support Engineer and I will be working with you on this.
These are very good questions and will try to answer them best of ability. There is one thing to theorise and second to how it actually will work to a specific infrastructure therefor we would recommend testing in your own infrastructure to avoid unexpected issues.

End-user certificates for Exchange ActiveSync authentication. In this case I assume only the Exchange server HTTPS connection certificate would be affected and the client certificate authentication would not be checked for CT conformity, right?

While CBA happens (eventually) during the TLS handshake it should not be affected by CT

Would CT affect TLS connections for Email protocols - IMAP/POP/SMTP?

Since these are TLS connections and using "Publicly-trusted Transport Layer Security (TLS) server authentication certificates” I assume CT policy applies.

Would CT affect Wi-Fi (e.g., EAP-TLS) and VPN authentication setups?

This one needs testing

Would CT affect MDM servers and more precisly the case where MDM servers are signing payloads with a certificate before sending them to the device. The device would need to verify the signature of a payload, but would it also verify that the signing certificate conforms to the CT policy?

Signing is not TLS and should not be affected by CT policy

petar · December 21, 2018, 11:07am

@Dara Amazing! Thanks a lot for doing this. It didn’t occur to me to send these to Apple’s Enterprise Support. Perhaps I didn’t have a good experience there in the past.

I guess there’s no escape from testing the Wi-Fi and VPN setups ourselves, but so be it. If your ticket is still open, maybe you could also ask about enrollment on MDM servers that are using self-signed certificates (for development purposes).

daniil_michine · March 26, 2019, 2:22pm

Apple configurator 2 (version 2.9) now has the Certificate Transparency payload

Here is a XML example

		<dict>
		<key>DisabledForCerts</key>
		<array>
			<dict>
				<key>Algorithm</key>
				<string>sha256</string>
				<key>Hash</key>
				<data>
				TXZCSGRwK2NjcXZVRmphR1locVQ0OHo3WGhG
				cEdQSXVOb1BIQVJnYW5FTT0=
				</data>
			</dict>
		</array>
		<key>DisabledForDomains</key>
		<array>
			<string>mobile-mentor.com</string>
		</array>
		<key>PayloadDescription</key>
		<string>Configures Certificate Transparency</string>
		<key>PayloadDisplayName</key>
		<string>Domains</string>
		<key>PayloadIdentifier</key>
		<string>com.apple.security.certificatetransparency.61DEBDBB-170F-450C-84D4-CAEEAEAE8DDC</string>
		<key>PayloadType</key>
		<string>com.apple.security.certificatetransparency</string>
		<key>PayloadUUID</key>
		<string>61DEBDBB-170F-450C-84D4-CAEEAEAE8DDC</string>
		<key>PayloadVersion</key>
		<integer>1</integer>
	</dict>

You can also use SSL labs to get the certificate/public key hash

Alternatively via OpenSSL for remote certs
openssl s_client -servername emm.how -connect emm.how:443 | openssl x509 -pubkey -noout | openssl rsa -pubin -outform der | openssl dgst -sha256 -binary | openssl enc -base64

daniil_michine · December 8, 2020, 1:43am

Google have a service for checking the CT logs
https://transparencyreport.google.com/

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