Linux Certificate Authority root stores have a too simple view of 'trust'

View Summary

Raw Text

Chris Siebenmann

CSpace » blog » linux » CARootStoreTrustProblem

Let's start with the background. Pretty much every Linux system (really, every Unix system) has a 'system CA root store', by which we mean 'the list of all CA root certificates that are trusted by default by most TLS-using software'. For various sensible reasons, many Linux distributions reuse Mozilla's CA root store for their system root store, possibly with some tweaks.

The recent TLS news is that Mozilla (and Microsoft) are distrusting the TrustCor CA certificates ( see this entry for more on TrustCor ). Over on the Fediverse, Filippo Valsorda reported the news and said :

Mozilla is distrusting TrustCor. Certificates issued from December 1st onward won't be trusted, roots will be removed once current certificates expire. Note that this probably means systems like Linux distros that just consider the Mozilla root store a bag of certificates will fully trust TrustCor for at least another year, likely longer due to release lag.

You might reasonably be confused about why Linux systems would trust TrustCor certificates for so long. The lesser reason is delays in updating their packaged copies of the Mozilla root store (and then getting you to apply the updates). But the major reason is that on Unix, the traditional 'CA root store' model is too limited.

Mozilla is not removing TrustCor's root certificates from their root store, not yet. Instead, in their root store there will be 'Distrust for After Date' markers for these certificates, dated December 1st. Certificates signed by TrustCor that were issued before December 1st will still be trusted (for now); certificates issued on December 1st or later will not be. This is fine and reasonable for Mozilla and for browser vendors (Microsoft has already done something similar, although their trust cutoff date was November 1st).

The problem for Linux distros is that most code that uses a 'CA root store' doesn't support this sort of nuanced trust decision. Instead, it expects a 'root store' that contains a bunch of fully trusted CA certificates. If a certificate chains up to a TLS certificate in the root store, it's trusted; if a certificate doesn't, it's not trusted. To use Valsorda's words, this is the 'bag of certificates' model. As long as the TrustCor root certificates are in the root store bag, all of TrustCor's TLS certificates are trusted, regardless of when they were issued; if TrustCor's root certificates aren't in the bag, none of those certificates will be trusted. There's no support for trusting only some of those certificates, or indicating this to programs.

(Some Linux distributions may choose to drop TrustCor entirely from their CA bundle, which is a reasonable decision. But they'd have to know about this issue and make a decision; if they just extract all of the CA root certificates in Mozilla's store that are 'trusted' to at least some degree, they will get the TrustCor certificates too.)

In theory, Linux distributions could collect this sort of additional trust information from the Mozilla root store and include it in their packages of root certificates (in both Ubuntu and Fedora, this package is called 'ca-certificates' and already contains a variety of things other than just the certificates). In practice, there's no standard for the format of this additional information and no code that would consume it and do the right thing. Perhaps as a result, I don't think anyone actually tries to capture this additional information anywhere in their CA certificates package.

(Arguably this is a real flaw in modern TLS packages and libraries. Browsers have been selectively distrusting CAs for years now, but I think most TLS packages still have no support for this sort of thing, not even loading distrust information into them by hand.)

(This elaborates on something I said on the Fediverse .)

PS: As mentioned, Mozilla will remove the TrustCor roots once they can't verify anything, ie once all TrustCor certificates issued before December 1st have expired. That will probably take about a year, assuming TrustCor doesn't do something before then. Once the TrustCor certificates aren't in the Mozilla root store at all, this will propagate to Linux distros.

2 comments

01

December

2022

Using Dovecot 2.3's 'events' system to generate log messages

Apache 2.4's event MPM and oddities with ServerLimit

These are my WanderingThoughts ( About the blog )

Full index of entries Recent comments

This is part of CSpace , and is written by ChrisSiebenmann . Twitter: @thatcks Mastodon: @cks

* * *

Categories: links , linux , programming , python , snark , solaris , spam , sysadmin , tech , unix , web Also: (Sub)topics

This is a DWiki . GettingAround ( Help )

View Source

Add Comment

Recent Comments

Single Line Text

Chris Siebenmann. CSpace » blog » linux » CARootStoreTrustProblem. Let's start with the background. Pretty much every Linux system (really, every Unix system) has a 'system CA root store', by which we mean 'the list of all CA root certificates that are trusted by default by most TLS-using software'. For various sensible reasons, many Linux distributions reuse Mozilla's CA root store for their system root store, possibly with some tweaks. The recent TLS news is that Mozilla (and Microsoft) are distrusting the TrustCor CA certificates ( see this entry for more on TrustCor ). Over on the Fediverse, Filippo Valsorda reported the news and said : Mozilla is distrusting TrustCor. Certificates issued from December 1st onward won't be trusted, roots will be removed once current certificates expire. Note that this probably means systems like Linux distros that just consider the Mozilla root store a bag of certificates will fully trust TrustCor for at least another year, likely longer due to release lag. . You might reasonably be confused about why Linux systems would trust TrustCor certificates for so long. The lesser reason is delays in updating their packaged copies of the Mozilla root store (and then getting you to apply the updates). But the major reason is that on Unix, the traditional 'CA root store' model is too limited. Mozilla is not removing TrustCor's root certificates from their root store, not yet. Instead, in their root store there will be 'Distrust for After Date' markers for these certificates, dated December 1st. Certificates signed by TrustCor that were issued before December 1st will still be trusted (for now); certificates issued on December 1st or later will not be. This is fine and reasonable for Mozilla and for browser vendors (Microsoft has already done something similar, although their trust cutoff date was November 1st). The problem for Linux distros is that most code that uses a 'CA root store' doesn't support this sort of nuanced trust decision. Instead, it expects a 'root store' that contains a bunch of fully trusted CA certificates. If a certificate chains up to a TLS certificate in the root store, it's trusted; if a certificate doesn't, it's not trusted. To use Valsorda's words, this is the 'bag of certificates' model. As long as the TrustCor root certificates are in the root store bag, all of TrustCor's TLS certificates are trusted, regardless of when they were issued; if TrustCor's root certificates aren't in the bag, none of those certificates will be trusted. There's no support for trusting only some of those certificates, or indicating this to programs. (Some Linux distributions may choose to drop TrustCor entirely from their CA bundle, which is a reasonable decision. But they'd have to know about this issue and make a decision; if they just extract all of the CA root certificates in Mozilla's store that are 'trusted' to at least some degree, they will get the TrustCor certificates too.) In theory, Linux distributions could collect this sort of additional trust information from the Mozilla root store and include it in their packages of root certificates (in both Ubuntu and Fedora, this package is called 'ca-certificates' and already contains a variety of things other than just the certificates). In practice, there's no standard for the format of this additional information and no code that would consume it and do the right thing. Perhaps as a result, I don't think anyone actually tries to capture this additional information anywhere in their CA certificates package. (Arguably this is a real flaw in modern TLS packages and libraries. Browsers have been selectively distrusting CAs for years now, but I think most TLS packages still have no support for this sort of thing, not even loading distrust information into them by hand.) (This elaborates on something I said on the Fediverse .) PS: As mentioned, Mozilla will remove the TrustCor roots once they can't verify anything, ie once all TrustCor certificates issued before December 1st have expired. That will probably take about a year, assuming TrustCor doesn't do something before then. Once the TrustCor certificates aren't in the Mozilla root store at all, this will propagate to Linux distros. 2 comments. 01. December. 2022. Using Dovecot 2.3's 'events' system to generate log messages. Apache 2.4's event MPM and oddities with ServerLimit. These are my WanderingThoughts ( About the blog ) Full index of entries Recent comments. This is part of CSpace , and is written by ChrisSiebenmann . Twitter: @thatcks Mastodon: @cks. * * * Categories: links , linux , programming , python , snark , solaris , spam , sysadmin , tech , unix , web Also: (Sub)topics. This is a DWiki . GettingAround ( Help ) View Source. Add Comment. Recent Comments.