Peer's certificate issuer is unknown while certificates have been added
Bert Van de Poel
bert at bhack.net
Fri Sep 21 14:13:30 CEST 2012
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.
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
> 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 '18.104.22.168: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 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) is called the "end entity" (EE) certificate,
> meaning that it is the certificate that belongs to the endpoint itself
> (your LDAP server).
>> - Certificate 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
> Certificate 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 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 belongs to another intermediate CA, and ...
>> - Certificate 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
> Based on the sha-1 fingerprint, Certificate here matches the file on
> my debian system:
> 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
> 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."
> 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
> 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
> 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
>> 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.
More information about the Gnutls-help