What is a trusted root certificate?
A trusted root certificate is a fundamental component of public key infrastructure (PKI) that serves as the anchor for the entire certificate chain. It is issued by a trusted certificate authority (CA) and is used to authenticate the validity of other certificates within the chain. By being pre-installed in operating systems and browsers, trusted root certificates allow for secure communication over networks by verifying the identity of websites and other entities, making sure that data is exchanged between trusted parties. If compromised, they can lead to significant security vulnerabilities.
When you (or, more likely, software you are running) needs to decide whether another entity on the network is trustworthy, you usually judge them based on the information they provide in an x.509 digital certificate.
What information is in that certificate depends on several parameters. But assume it all checks out. How do you know that some other party didn’t just fabricate the information to make it look right? You “know” this because the issuer digitally signed the certificate, and you trust the issuer. How do you know the issuer’s certificate isn’t forged? Because the entity that issued the issuer’s certificate signed it.
Because this can’t go on forever, there must be a top entity in the trust chain that we all trust by convention. This is where a trusted root certificate becomes important. About a year and a half ago, I discussed the implications of trust and root certificates with a previous colleague and Venafi blog contributor Larry Seltzer. And the following is what he had to write about the nuances of root certificates.
The software that performs the trust analysis (typically operating systems or web browsers) has a list of these roots. My copy of Windows 10 has the list shown below (the program is certmgr.msc).
The list of roots is not a very long list, and most of the names are big ones you may know and trust, like Microsoft, DigiCert, and Venafi. These are primarily certificates that Microsoft includes with Windows and Windows updates. But IT can add to or remove from the list when the system is deployed or afterward.
Like leaf certificates at the other end of the trust chain, the roots may be issued for specific purposes, such as client authentication or code signing, and not others. Most on this system are for “Client Authentication” which, for practical purposes, is really system authentication or domain authentication. Most of these are the certificates at the root for those used in conventional browser SSL/TLS, such as for the web site you’re probably looking at now. The names are sometimes obscure; the one named “ISRG Root X1” is from the Internet Security Research Group and is mainly for the free CA Let’s Encrypt.
Several of the roots are expired, and one expired in 1999. Why is it still in there? The answer is backward compatibility. Consider a code-signed program, and eventually, the root certificate of the trust chain with which it was signed expires; the program will fail. One way to look at this is that the developer should reissue the program signed with a new certificate, but even if the company is still in business, it’s not going to happen most of the time. In the meantime, people run very old software all the time and would find it unacceptable that the program they bought had an expiration date. The fact that it doesn’t expire demonstrates that expiration dates in root certificates aren’t always checked, or at least no action is taken if they are found to be expired.
On the flip side, while best practices have been pushing certificate expirations to be as short as possible, root certificates have long expirations. A decade or more is common. Two in my list, issued by ManageEngine, expire in 2119 and 2120 (yes, those are years). [This is absurd and has to be bad practice. Why not make the year 9999? Or 99999? Or make a boomer joke and set it for 2525?] In 2021, Let’s Encrypt’s ISRG Root X1 certificate replaced a different root certificate that expired, causing problems for systems and devices that weren’t updated to contain the new root certificate. Incidentally, that expired root certificate is the DST Root CA X3 certificate that’s still in my trusted root list many months after expiring.
SSL/TLS Certificates and Their Prevalence on the Dark Web
Should software check for the expiration of root certificates and block their use? There’s a best-practices case for doing so, but that ship sailed many years ago. The backward compatibility factor has won. In the long term, it shouldn’t be a significant problem. The need to update software frequently, modern DevOps practices that result in rapid updates, and the emergence of free and high-volume certificate issuance systems will ensure that few certificates will remain active as the expiration bells of their roots toll. In the case of the Let’s Encrypt root expiration, Let’s Encrypt includes a handy list of programs that would fail when DST Root CA X3 expired. It is filled with very old software that you should not be running for many good reasons.
There isn’t a real scenario in which root certificates can be “compromised.” If the corresponding private key were compromised, that would be a disaster for the CA, but it doesn’t take that level of breach to ruin a CA. Several have been ruined over the years over bad security practices. These generally involve a lower-level breach or irresponsible practice that led to the issuance of illegitimate certificates, such as in June 2011 when an attacker compromised the Dutch CA DigiNotar and caused the issuance of fraudulent certificates, including a wildcard for google.com. By August, major browsers had untrusted DigiNotar roots. Within weeks, the company was bankrupt, and the government took over what was left of operations.
The biggest such incident was the untrusting of Symantec, once the biggest player in the business, having purchased the interests of CA pioneer VeriSign. Researchers and developers realized that Symantec’s trust infrastructure was broken, resulting in affiliates issuing certificates based on inadequate authentication. Faced with a trust death sentence issued by Google, Mozilla, and other actors large and small, Symantec gave up and sold their business to DigiCert.
Only a government entity could survive a major CA trust failure. In 2015, the China Internet Network Information Center (CNNIC, a Chinese government entity) [https://www.cnnic.com.cn/ - seems impossible to connect to from here] issued an intermediate certificate, capable of issuing other certificates, to an Egyptian CA that went on to issue false google.com certificates. Google and Mozilla both removed CNNIC roots from their trust list. CNNIC lives on and issues many certificates, but most users around the world have trouble seeing them.
One of the interesting characteristics of the PKI is that those who control the list of trusted roots have a great deal of power over CAs. If a CA gets kicked out of a trusted root list, it and its customers could be completely ruined. It happened to DigiNotar and others. In all the examples , the removal of the trusted root was justified by gross failures by the CA, but the fact of the power involved is noteworthy. Many of the entities are large corporations but many are not. All the stories I have read of when a root was removed from trusted lists show the vendor controlling the list taking the issue very seriously and only removing a certificate for good reason.
Machine Identity Security Summit 2024
Help us forge a new era of cybersecurity
☕ We're spilling all the machine identiTEA Oct. 1-3, but these insights are too valuable to just toss in the harbor! Browse the agenda and register now.