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

[Bert Van de Poel]

Thank you DKG,

I already thought adding all those certificates was a bit strange. 
Indeed adding the --x509cafile did the trick. Afterwards we just added 
the TLS_CACERT information to ldap.conf and everything worked like a charm.
We have removed all incorrect information from the system again as we 
take security rather serious.

Your suggestions really saved our project.
ULYSSIS is thankful beyond description.

Thanks again,
Bert.
ULYSSIS

Op 20-09-12 23:55, Daniel Kahn Gillmor schreef:
> 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
>