[SSL Observatory] openssl patch: A way to display which root certificate in the browser a SSL certificate is rooted to

[Peter Eckersley]

On Thu, Jun 30, 2011 at 01:13:28AM -0500, Walter Goulet wrote:
> Hi,
> 
> My perusal of the observatory data is that the acerts and vcerts tables
> include the issuing cert and a flag indicating whether or not the given SSL
> cert is in the mozilla or microsoft trusted root repositories. 

No, moz_valid and ms_valid contain the output of openssl verify called with
their trusted root repositories /and/ any intermediate CA certs that were in
the chain presented by that webserver.  The intermediates are included with
the -untrusted flag, so OpenSSL checks signatures from roots before using them.

The transvalid column contains the output of openssl verify valled with the
above /plus/ extra intermediate CA certs that look like they were missing from
the chain presented by the webserver.

> But, the
> issuing cert is usually just an intermediate cert unless a misbehaving root
> CA is directly signing SSL certs. What I really want to know is which
> particular root cert in the mozilla/microsoft root repositories is vouching
> for a SSL cert.

The answer will often be several, because of cross-certification of
intermediate CAs (look at the map of CAs PDF).  It's possible to estimate
which root CAs are at the tops of the chain by Subject/Issuer and AKID/SKID
matching amongst the set of valid CAs.

Much of this logic is actually implemented in the root_CA_importance.py (and
SubordinateTracking.py) scripts that you can find in questions/ca_graph/.  You
could probably modify root_CA_importance.py to answer your questions.
Apologies that they aren't neater and better documented, we wrote them in a
hurry ;).

It is possible that these scripts will slightly overestimate the set of root
CAs ultimately validating a given valid end-entity certificate.  If I make
some untested assumptions about how openssl implements SKID/AKID matching, I
think this type of overestimation would only happen for CA certs that don't
have SKID/AKIDs, and where several different CA certs with different keys
share the same Subject, but some of those keys never signed along this path.

> 
> Currently, this doesn't appear to be possible because the openssl verify
> command at the heart of the observatory scripts doesn't print out which root
> CA in it's CApath directory actually issued the cert. This patch modifies
> the verify application so that when the 'verbose' flag is passed to the
> verify command, the issuer of the self-signed certificate at the top of the
> chain is printed. This patch applies to the latest 1.0.0d version of
> OpenSSL. I feel pretty confident in this patch as I tested it against debug
> printouts that I added to the raw X509_verify_cert function in x509_vfy.c

I suspect OpenSSL builds chains until it finds one that works, and then
stops.  In that case, this strategy will not tell you about
cross-certification from multiple roots.
> 
> To really make this patch useful, additional fields would have to be added
> to the acerts/vcerts tables to store the root issuing cert name and the
> python scripts would have to be re-run. I'll probably work on that over the
> next few days myself, but if anyone out there with a EC2 account that is
> more handy with the data/scripts could probably apply this patch and make a
> new snapshot of the data for us all to use.

If for some reason you still want to pursue this route, I'm happy to try to
answer particular questions about the scripts and schema.  #https-everywhere
on irc.oftc.net would be one place to ask in realtime.

> 
> And I really hope I didn't miss something obvious and this data is captured
> somewhere else that I just plainly missed.
> 
> Thanks,
> Walter
> 
> --- /home/wgoulet/Downloads/openssl-1.0.0d/apps/verify.c    2009-10-31
> 12:21:47.000000000 -0700
> +++ verify.c    2011-06-29 22:47:33.127029311 -0700
> @@ -257,6 +257,7 @@
>      {
>      X509 *x=NULL;
>      int i=0,ret=0;
> +    char buf[2048];
>      X509_STORE_CTX *csc;
> 
>      x = load_cert(bio_err, file, FORMAT_PEM, NULL, e, "certificate file");
> @@ -280,6 +281,11 @@
>      if (crls)
>          X509_STORE_CTX_set0_crls(csc, crls);
>      i=X509_verify_cert(csc);
> +    X509_NAME_oneline(X509_get_issuer_name(csc->current_issuer),buf,2048);
> +    if(v_verbose)
> +        {
> +        fprintf(stdout,"Trusted certificate at top of chain: issuer=
> %s\n",buf);
> +        }
>      X509_STORE_CTX_free(csc);
> 
>      ret=0;

-- 
Peter Eckersley                            pde at eff.org
Senior Staff Technologist         Tel  +1 415 436 9333 x131
Electronic Frontier Foundation    Fax  +1 415 436 9993