FAQ SSL/TLS Certificate Authority Root Stores

From Overbyte
Revision as of 14:54, 27 October 2019 by Magsys (talk | contribs) (ICS CA Trusted Stores)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

CA Trusted Store Background

The whole SSL/TLS certificate verification process depends upon finding a trusted root certificate that signed the next certificate up the chain, and so on. But who chooses those trusted roots?

The answer is the author of the application that accepts an SSL/TLS certificate, or maybe the operating system the application is running on, or the SSL library used to build the application.

The bad news is that root certificates come and go, old roots stop being accepted for various reasons, and new roots are introduced for new security standards or new businesses.

Historically most roots were RSA Sha1 digest signed and most still are, despite Sha1 being banned for new certificates. Increasingly Sha256 and ECC root certificates are being introduced and required by new intermediate certificates. Typically, active certificate authorities have at least four roots, with 2,048 and 4,096 bit RSA keys and 256 and 394 bit ECDSA keys (which are much smaller than RSA).


Sources of CA Trusted Stores

SSL/TLS trusted root certificate bundles and always changing, annually perhaps for major changes, although Microsoft officially Windows roots every two months. The Common CA Database (CCADB) https://www.ccadb.org/ is a repository of information about Certificate Authorities (CAs), and is used by a number of different root store operators to manage their root stores.

But it's not easy to create root bundles from CCADB and another developer got frustrated with updating roots, and created a Trust Stores Observatory Git repository:

https://github.com/nabla-c0d3/trust_stores_observatory

which contains over 500 root certificates and lists of which trust store contain which roots by different operating systems. But even this does not contain certificates in a form easily used by OpenSSL, so Magenta Systems Ltd has written a small tool that converts the YAML files from TSO into PEM bundle files, one each for the different operating systems.


New PEM Bundle CA Trusted Store Files

There are six different PEM CA bundle files, built from the Trust Stores Observatory Git repository:

apple.pem -  174 Certificates
google_aosp.pem - 137 Certificates
microsoft_windows.pem - 289 Certificates
mozilla_nss.pem - 137 Certificates
openjdk.pem - 88 Certificates
oracle_java.pem - 88 Certificates

Each certificate is prefixed by it's description, issuer fields, expiry, public key type and SHA256 hash, so the bundles are self documenting rather than being just cryptic base64 blocks. These PEM bundles may be loaded into an OpenSSL context as a root store.

These bundles may be downloaded at:

https://www.magsys.co.uk/download/software/ca-root-bundles.zip

Magenta Systems Ltd will periodically update these bundles, as needed.


ICS CA Trusted Stores

ICS includes three CA CA Trusted Store, two as PEM bundle files, one in a source unit, and access to the Window Certificate Store directly:

1 - RootCaCertsBundle.pem is a large file that was originally created 15 years ago by exporting the Windows certificate store using the OverbyteIcsPemTool sample. But Windows 10 no longer has a complete local certificate store and instead downloads new certificates as needed by Windows browsers. So with ICS V8.63, it is now the same as the new microsoft_windows.pem bundle mentioned above. It currently contains 289 certificates and is 595 Kbytes in size and may be found in the Samples/Delphi/SslInternet/ directory.

2 - TrustedCABundle.pem is a smaller file, with certificate for major commercial issuers manually updated as newer sites are found to have missing root certificates. But this file is more dynamic than RootCaCertsBundle.pem. It currently contains 51 certificates and is 88 Kbytes in size and may be found in the Samples/Delphi/SslInternet/ directory.

3 - To avoid distributing bundle files and as a fail safe if a file can not be found, ICS includes 34 built-in hard coded certificates in OverbyteIcsSslX509Utils.pas which can be returned as a string by the function sslRootCACertsBundle. Again this unit may be dynamic with new certificates added as needed. Note only the TSslHttpRest, TIcsIpStrmLog, TIcsFtpMulti, TIcsHttpMulti and TIcsMailQueue components use the built-in bundle by default, other components need to add it manually to avoid the extra program code involved.

4 - ICS also includes a component TMsCertChainEngine in the unit OverbyteIcsMsSslUtils.pas which allows applications to avoid using bundle files and instead access the Windows Certificate Store directly to validate certificates. There is a very slight overhead as the store is opened and Windows may need to download missing root certificates. Only the TSslHttpRest, TIcsIpStrmLog, TIcsFtpMulti, TIcsHttpMulti and TIcsMailQueue components includes TMsCertChainEngine by default, with the CertVerMethod property selecting CertVerNone, CertVerBundle or CertVerWinStore. TMsCertChainEngine does include one extra optional feature to check if any certificates in the chain have been revoked by their issuer, perhaps for fraudulent use, beware revoke checks involve contacting each issuer and can slow down chain validation by a few seconds or even longer.

Either of the certificate bundle files may be loaded into an SslContext by using the SslCAFile property. The built in bundle may be specified before the SslContext is initialised using SslCALines.Text property, or the LoadCAFromString method after initialisation.

If checking a certificate chain, OpenSSL will issue the error message 'unable to get local issuer certificate' if a trusted certificate is not found in the store.

The contents the three certificates bundles are listed at FAQ - ICS SSL/TLS CA Trusted Store Contents