httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Stradling <>
Subject Re: mod_ssl patch: use new OpenSSL features to autofix cert chains
Date Thu, 27 Mar 2014 16:29:26 GMT
On 26/03/14 15:29, Emilia Kasper wrote:
> Wow, thanks for all the great feedback!
> On Wed, Mar 26, 2014 at 2:47 PM, Daniel Kahn Gillmor wrote:
>     This is a pretty perverse situation, though, and perhaps the answer is
>     that CA X just shouldn't do that kind of weird/chained reissuance over
>     the key in Y.  I've also done no certificate surveys to see if this sort
>     of scenario has actually happened anywhere in the modern landscape.
> Cross-signing happens all the time but afaik the other way around, i.e.,
> an intermediate Y' corresponding to a _newer_ root cert Y is
> cross-signed by some _older_ root cert Z. So an old client would usually
> know only Z and a newer client would know Z and Y (or even Y' - some
> clients directly trust intermediates these days).

That's true in many cases, but...

Comodo gained entry into the CA marketplace by purchasing one set of 
roots (from AddTrust) that were in the Netscape trust store, and another 
set of roots (from The USERTrust Network, aka UTN) that were in the 
Microsoft trust store.  Neither set of roots were "older" or "newer".

UTN cross-certified AddTrust.  A few years later we were able to get one 
of the AddTrust roots added to the Microsoft trust store.  After that, 
it made more sense to have the cross-certification relationship the 
other way around, and so AddTrust cross-certified UTN.

(Cue various cross-certification loop bugs in Mozilla's code, but I digress)

Oh, BTW, bi-directional cross-certification also occurs in Bridge CA 
scenarios such as the Federal PKI.

>     CT might be a good place to gather this information from -- are there
>     plans to ensure that all intermediate CAs are logged publicly?
> No current plans for CT to require logging intermediates. But actually,
> if we go the autocorrect route then we should just implement AIA
> fetching. Modern certs should have a CA Issuers field in the
> AuthorityInformationAccess extension in them that the chain builder
> could follow recursively. I've now looked a bit more at the mod_ssl code
> and it's a bit of work but maybe not all that different from doing OCSP,
> really?

So, we arrived at the point where "AddTrust External CA Root" became our 
primary root certificate, but we still needed to involve UTN in the cert 
chain in order to be trusted by old Windows platforms (i.e. Windows 
2000, and XP boxes that have Automatic Root Update disabled).

Noting that Windows clients do AIA fetching, we started including a 
carefully constructed pair of AIA->caIssuers URLs in many of the 
intermediate certs we issue and still use today.

CA Issuers - URI:
CA Issuers - URI:

Most platforms trust "AddTrust External CA Root", so they don't chase 
either of these AIA URLs.
Old Windows boxes download the first URL (a PKCS#7 "certs only" bundle 
containing the self-signed "AddTrust External CA Root" root and a 
cross-cert issued to it by one of the UTN roots), and are able to build 
a chain up to AddTrust, or failing that, UTN.
Even older Windows boxes don't support PKCS#7 AIA caIssuers URLs, so 
they then download the second URL and build a chain up to UTN.

A correctly configured TLS server that uses one of our certs will send a 
cert chain terminating with "AddTrust External CA Root".

I do _not_ want mod_ssl to "autocorrect" this by following the AIA 
URL(s) and deciding to also send the cross-certificate issued by UTN.

Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

View raw message