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

Bert Van de Poel bert at
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.

Thanks again,

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 ''...
> 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
> Processed 94 CA certificate(s).
> Resolving ''...
> 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 ''...
>> - 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,',
>> 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=,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=,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."
> 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 ''.
>> - 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/ 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

More information about the Gnutls-help mailing list