Difference between revisions of "FAQ SSL/TLS Certificate Authority Root Stores"

From Overbyte
Jump to navigation Jump to search
Line 36: Line 36:
 
https://github.com/nabla-c0d3/trust_stores_observatory
 
https://github.com/nabla-c0d3/trust_stores_observatory
  
which contains over 500 root certificates and lists of which trust store
+
which contains about 600 root certificates and lists of which trust store
 
contain which roots by different operating systems.  But even this does
 
contain which roots by different operating systems.  But even this does
 
not contain certificates in a form easily used by OpenSSL, so Magenta
 
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
 
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.
 
TSO into PEM bundle files, one each for the different operating systems.
 
  
 
== New PEM Bundle CA Trusted Store Files ==  
 
== New PEM Bundle CA Trusted Store Files ==  

Revision as of 12:09, 5 November 2021

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 about 600 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 - 166 Certificates
google_aosp.pem - 129 Certificates
microsoft_windows.pem - 287 Certificates
mozilla_nss.pem - 131 Certificates
openjdk.pem - 90 Certificates
oracle_java.pem - 93 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. Magenta Systems Ltd will periodically update these bundles, as needed. The files are all UTF-8 with a BOM. While the certificates are base64 encoded, the aded comments may include Unicode characters for non-English issuers.

The zip file contains two versions of each bundle, the name above and one ending with -clean.pem which omits all the added textual comments so is smaller and less likely to cause problems with non-English characters. There are also -titles.txt and fprints.txt files which are one line per certificate listing the main details, and fingerprint in the latter file.


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 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 258 certificates and is 575 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 55 certificates and is 100 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 35 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