Warning! I am about to bring up a topic that others have talked about before: Name Constraints (as it applies to SSL, that is). Name Constraints is a way for a Certificate Authority (a CA) to say “All of the certificates issued by me should only be used for these domains (x.net, or y.z.com, or all of .org, etc.). Any other certificate should not be trusted.”
Name Constraints are not supported by everything yet, but they are supported in some places. Not only would Name Constraints make things easier for sysadmins, it would give a new revenue stream for CAs, browsers would have an easier time accepting them, and it would “streamline the user experience” (whatever that means).
iOS 8.0 ships with a number of trusted certificates (also known as “root certificates” or “certificate authorities”), which iOS implicitly trusts. The root certificates are used to trust intermediate certificates, and the intermediate certificates are used to trust web site certificates. When you go to a web site using HTTPS, or an app makes a secure connection to something on the Internet (like your mail server), the web site (or mail server, or whatever) gives iOS its certificate, and any intermediate certificates needed to make a “chain of trust” back to one of the roots. Using the fun mathematical property of transitivity, iOS will trust a web site’s certificate because it trusts a root certificate.
iOS 8.0 includes two hundred twenty-two trusted certificates. In this post, I’m going to take a look at these 222 certificates. First I’m going to look at them in the aggregate, giving CA counts by key size and by hashing algorithm. Afterwards, I’m going to look at who owns these trusted roots.