Peer's certificate issuer is unknown while certificates have been added

[Daniel Kahn Gillmor]

Hi Bert--

short version:

 I suspect you didn't need to do any copying of those files at all; you
only need to add the following arguments to your gnutls-cli invocation
(should be all on one line):

  --x509cafile /usr/share/ca-certificates/mozilla/AddTrust_External_Root.crt

longer version below, since there are a couple things that seem amiss here:

On 09/19/2012 08:01 PM, Bert Van de Poel wrote:
> We have correct ldap details but gnuTLS considers the connection to be
> insecure. (I check it could only be tls by allowing insecure ldap
> transactions for a second).
> 
> I went on to test things using gnutls-cli:
> Resolving 'ldap.kuleuven.be'...

You don't show the exact command line you used above,.  It would be
helpful to see exactly what you called in order to know what this comes
from.

For example, when i try connecting to the EFF with gnutls-cli 3.0.22,
the first thing i see is:

0 dkg at pip:~$ gnutls-cli www.eff.org
Processed 94 CA certificate(s).
Resolving 'www.eff.org'...
Connecting to '2607:f258:102:2::2:443'...
[...]

the first line shows me that gnutls-cli has loaded a list of 94 trusted
root certificate authorities by default.

I think earlier versions of gnutls-cli don't load any root CAs by
default, (maybe it was added in 3.0.20 the addition of
withgnutls_certificate_set_x509_system_trust?) so you'd have to specify
your trusted root CAs explicitly with the --x509cafile option, as
described above.

carrying on...

> Connecting to '134.58.127.92:636'...
> - Certificate type: X.509

this server doesn't appear to accept connections from arbitrary public
IP addresses (i et "connection timed out") so i assume it's limited to
the campus or something.

In the discussions below, note that an X.509 certificate has a subject
("who the cert belongs to") and an issuer ("who is doing the certifying")

>  - Got a certificate list of 4 certificates.
>  - Certificate[0] info:
>   - subject `C=BE,L=Leuven,O=Katholieke Universiteit
> Leuven,OU=Competentiecentrum Informatiebeveiliging,CN=ldap.kuleuven.be',
> issuer `C=NL,O=TERENA,CN=TERENA SSL CA', RSA key 2048 bits, signed using
> RSA-SHA1, activated `2012-01-25 00:00:00 UTC', expires `2015-01-24
> 23:59:59 UTC', SHA-1 fingerprint `9dc847d52b4e478b314dccbbf0382645822062db'

the above (Certificate[0]) is called the "end entity" (EE) certificate,
meaning that it is the certificate that belongs to the endpoint itself
(your LDAP server).

>  - Certificate[1] info:
>   - subject `C=NL,O=TERENA,CN=TERENA SSL CA', issuer `C=US,ST=UT,L=Salt
> Lake City,O=The USERTRUST
> Network,OU=http://www.usertrust.com,CN=UTN-USERFirst-Hardware', RSA key
> 2048 bits, signed using RSA-SHA1, activated `2009-05-18 00:00:00 UTC',
> expires `2020-05-30 10:48:38 UTC', SHA-1 fingerprint
> `3a881764472b6441ddb3afdd47c6b8b76ee7ba1d'

Certificate[1] here belongs to an "intermediate certificate authority
"(the "TERENA SSL CA"). they issued your LDAP server's EE certificate.
In turn, their certificate is issued by:

>  - Certificate[2] info:
>   - subject `C=US,ST=UT,L=Salt Lake City,O=The USERTRUST
> Network,OU=http://www.usertrust.com,CN=UTN-USERFirst-Hardware', issuer
> `C=SE,O=AddTrust AB,OU=AddTrust External TTP Network,CN=AddTrust
> External CA Root', RSA key 2048 bits, signed using RSA-SHA1, activated
> `2005-06-07 08:09:10 UTC', expires `2020-05-30 10:48:38 UTC', SHA-1
> fingerprint `3d4b2a4c64317143f50258d7e6fd7d3c021a529e'

Certificate[2] belongs to another intermediate CA, and ...

>  - Certificate[3] info:
>   - subject `C=SE,O=AddTrust AB,OU=AddTrust External TTP
> Network,CN=AddTrust External CA Root', issuer `C=SE,O=AddTrust
> AB,OU=AddTrust External TTP Network,CN=AddTrust External CA Root', RSA
> key 2048 bits, signed using RSA-SHA1, activated `2000-05-30 10:48:38
> UTC', expires `2020-05-30 10:48:38 UTC', SHA-1 fingerprint
> `02faf3e291435468607857694df5e45b68851868'


Based on the sha-1 fingerprint, Certificate[3] here matches the file on
my debian system:

  /usr/share/ca-certificates/mozilla/AddTrust_External_Root.crt

This is not an intermediate CA, but a "root CA" -- that is, the issuer
is the same as the subject.  this certificate is widely distributed in
several public certificate-verifying tools, like the mozilla firefox web
browser.

According to the TLS spec, this last certificate does not need to be
sent at all,

     "Under the
      assumption that the remote end must already possess it in order to
      validate it in any case."

  https://tools.ietf.org/html/rfc5246#page-48

If the admins of this LDAP server want to decrease the size of their TLS
handshakes, they could remove that certificate from the list they offer
on each handshake.

> - The hostname in the certificate matches 'ldap.kuleuven.be'.
> - Peer's certificate issuer is unknown
> - Peer's certificate is NOT trusted

So this is why gnutls-cli can't verify it.  if gnutls-cli doesn't have
*any* trusted root certificate authorities, the ultimate issuer of a
cert is always going to be unknown.

> The procedure I followed to add the certificates was: I created a
> directory /usr/share/ca-certificates/ldap.kuleuven.be and added all
> certificates in seperate files and in one file combined as well. Next I
> edited /etc/ca-certificates.conf to add all of those files and ran
> update-ca-certificates. All certificates turned up nicely in
> /etc/ssl/certs/

I don't think you actually want to add the certificates of these
intermediate CAs to your list of trusted root stores in the first place
-- you just need to give gnutls-cli some indication of where it should
look for its trusted CAs.

In particular, by adding the intermediate CAs to your trusted root list,
you're granting them longstanding independent ability to forge
certificates for remote parties, even if the root on which they depend
has been revoked or deprecated.

And you certainly don't want to place any EE certificates in your list
of trusted root authorities, since they should not be certifying
anything anyway.


That said, if you *do* want to add trusted root CAs to a debian-derived
system that aren't already shipped in the ca-certificates package, you
probably don't want to tamper with the contents of
/usr/share/ca-certificates directly.  That part of the filesystem is
controlled by the ca-certificates package.

Instead, for any CA that you want to add to a system as the admin, you
only need to drop a world-readable PEM-encoded file containing the CA's
certificate into /usr/share/ca-certificates/, and then re-run
"update-ca-certificates" as the superuser.  This will create links
properly under /etc/ssl/certs, and will include them in
/etc/ssl/ca-certificates.crt.

This last file is what is used as the default x.509 ca authority list on
recent versions of gnutls-cli on debian, and could be specified as
--x509cafile if you want to mimic that behavior when running an earlier
version.

> I verified that all permission were correct. Our webserver which is
> doing these connections uses Ubuntu 12.04 Server which uses gnutls
> 3.0.11 if that is of any use to you.

Thanks!  This bit of critical information should always be up front in
any problem report so that folks trying to solve it know what they're
dealing with!

Please let me know if you have any extra questions.

Regards,

	--dkg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1030 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20120920/76aa402c/attachment.pgp>