More strict Server Certificate handling in iOS 13 macOS 10.15
Daniel Nashed – 5 June 2019 06:12:23
Beginning with iOS13 and macOS 10.15 the more stricter handling could have quite high impact and lead to untrusted certificates specially for internal certificates.
An official CA should have taken care of this already and certificates should be correctly issued.
But this can impact internal certificate authorities (CAs). Existing certificates are not impacted by the stricter key usage checking and the existing expiration will not change.
For new certificates you have to have a careful check of the following Apple statement which I commented in blue.
I know certificate stuff can be kind of boring and complicated. But you have to look into those changes!!
-- Daniel
https://support.apple.com/en-us/HT210176
Let me comment the new announcement in green.
-- snip --
All TLS server certificates must comply with these new security requirements in iOS 13 and macOS 10.15:
TLS server certificates and issuing CAs using RSA keys must use key sizes greater than or equal to 2048 bits. Certificates using RSA key sizes smaller than 2048 bits are no longer trusted for TLS.
This isn't new and nobody should use have a key size below 2048.
TLS server certificates and issuing CAs must use a hash algorithm from the SHA-2 family in the signature algorithm. SHA-1 signed certificates are no longer trusted for TLS.
Certificates and intermediate CA certs already needed to be SHA-2 before.
The root CA's certificate is verified in a different way and should still not be effected. Even the statement isn't that clear about it.
But if that would not be OK any more, many CAs would be in trouble.
TLS server certificates must present the DNS name of the server in the Subject Alternative Name extension of the certificate. DNS names in the CommonName of a certificate are longer trusted.
The SAN name (Subject Alternate Name - DNS name) is something that is already required by browsers etc. And I don't see this as a big surprise.
Additionally, all TLS server certificates issued after July 1, 2019 (as indicated in the NotBefore field of the certificate) must follow these guidelines:
TLS server certificates must contain an ExtendedKeyUsage (EKU) extension containing the id-kp-serverAuth OID.
This is a big deal for you own CAs. EKU isn't used by all private CAs. And for openssl it's not simple to configure the extended key usage.
The OID and name is the following: TLS Web Server Authentication (1.3.6.1.5.5.7.3.1).
To check your certificate you can look into what your browser tells you about it. Or you use openssl to dump your certificate.
Here is a command-line example and the result should look like this:
openssl x509 -text -noout -in domino.crt
...
X509v3 extensions:
X509v3 Extended Key Usage:
TLS Web Server Authentication
X509v3 Subject Alternative Name:
DNS:domino.nashcom.loc
...
The name and the OID are the following:
TLS Web Server Authentication (1.3.6.1.5.5.7.3.1)
To create a certificate properly your openssl command-line gets more complicated or you need a configuration file.
But in combination with a SAN you want to write the file dynamically...
Here is an example command-line from one of my scripts:
-- snip --
openssl x509 -passin pass:$CA_PASSWORD -req -days $CLIENT_VALID_DAYS -in $CSR_FILE -CA $CA_CRT_FILE -CAkey $CA_KEY_FILE \
-out $CRT_FILE -CAcreateserial -CAserial $CA_DIR/ca.seq -extfile <(printf "extendedKeyUsage = serverAuth \n subjectAltName=DNS:$SANS") > /dev/null
-- snip --
TLS server certificates must have a validity period of 825 days or fewer (as expressed in the NotBefore and NotAfter fields of the certificate).
Wow this is a big deal! That's a bit more than two years and two month! So this will impact customers getting 3 year certificates and also long vaild internal certificates.
In some cases customers generate internal certificates for much longer periods which would not work any more when you issue them after July, 1st, 2019!
So you might want to create those certificates before 1. July 2019 ;-)
Connections to TLS servers violating these new requirements will fail and may cause network failures, apps to fail, and websites to not load in Safari in iOS 13 and macOS 10.15.
-- snip --
So the two biggest surprises are the reduced certificate expiration days! Two years and two month is not really much!
And I am curious how the certificate vendors react on it.
-- Daniel
- Comments [3]
![[HCL Domino]](../lotus-domino.gif){kind=small}
![[Domino on Linux]](../domino-linux.gif){kind=small}
![[Nash!Com]](../nashcom.gif){kind=small}
![[Daniel Nashed]](../daniel-nsh.gif){kind=small}