According to the Digicert CPS
<http://www.digicert.com/docs/cps/DigiCert_EV-CPS.pdf>,
that DigiCert root is cross-certified by the Entrust root. Some trusted
certificate bundles include only the Entrust root CA and will need the
Entrust-signed "cross" intermediary certificate to validate, other trusted
certificate bundles include the Digicert self-signed root for this key
directly.
It is expected from the standards and the behavior of other X.509
libraries that
upon seeing the "keyid" of a known root, the library should stop
following the
chain and ignore any extra certificate provided by the entity being
verified.
On 10/21/2011 3:10 AM, Dave Thompson wrote:
From: owner-openssl-us...@openssl.org On Behalf Of Lucas Clemente Vella
Sent: Wednesday, 19 October, 2011 22:44
<snip: connect to graph.facebook.com:443 using
cafile="DigiCertHighAssuranceEVRootCA.crt" gets rc=20>
Then I found this directory in my system, "/etc/ssl/certs", containing
my installed CA roots, which I provided to OpenSSL, instead of the
certificate file:<and got rc=0>
It seems to me that there is one certificate installed in
/etc/ssl/certs, which is different from the on I was providing, that
is being used to verify the host. If it is so, how can I know what
certificate is being used? And why Firefox and Chrome both use the
former certificate I provided, while OpenSSL is unable to use it for
the same host?
s_client shows that host is providing a chain which has at #2
"Digicert High Assurance EV Root CA" not actually a root but instead
isssued by "Entrust.net Secure Server Certification Authority".
Such a cert with SHA1 99A6 9BE6 1AFE 886B 4D2B 8200 7CB8 54FC 317E 1539
found at www.entrust.net "Download roots" does verify the chain,
and is in my Windows/IE(7) and FF3.6 and Java(6u24) truststores
"out of the box", so if your /etc/ssl/certs was put together with
the "usual suspects" (a la Casablanca) very likely it's in there.
The #2 from graph.facebook.com and the root from digicert.com have
the same public key and keyid so either one can verify the children
(which (both) have AKI.keyid). I don't know why both forms exist
and I don't see anything obvious on the Digicert website about it.
The dates are different: the #2 is 20061001 to 20140726 while the
true root is 20061110 to 20311110; possibly digicert initially got
cross-signed by entrust and then established their own root(s).
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
