help-gnutls
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Help-gnutls] Re: gnutls fails to verify server sertificate while openss


From: Simon Josefsson
Subject: [Help-gnutls] Re: gnutls fails to verify server sertificate while openssl works
Date: Fri, 03 Oct 2008 17:51:45 +0200
User-agent: Gnus/5.110011 (No Gnus v0.11) Emacs/22.2 (gnu/linux)

Peter Volkov <address@hidden> writes:

> address@hidden ~ $ /usr/bin/gnutls-cli -V --x509cafile 
> /usr/share/ca-certificates/mozilla/ValiCert_Class_2_VA.crt metasploit.com > 
> gnutls-cli.out

The certificate chain returned by that server appears to be:

cert[0]
 # Subject's DN: O=metasploit.com,OU=Domain Control Validated,CN=metasploit.com
 # Issuer's DN: C=US,ST=Arizona,L=Scottsdale,O=GoDaddy.com\, 
Inc.,OU=http://certificates.godaddy.com/repository,CN=Go Daddy Secure 
Certification Authority,serialNumber=07969287

cert[1]
 # Subject's DN: C=US,O=The Go Daddy Group\, Inc.,OU=Go Daddy Class 2 
Certification Authority
 # Issuer's DN: L=ValiCert Validation Network,O=ValiCert\, Inc.,OU=ValiCert 
Class 2 Policy Validation Authority,CN=http://www.valicert.com/,address@hidden

cert[2]
 # Subject's DN: C=US,ST=Arizona,L=Scottsdale,O=GoDaddy.com\, 
Inc.,OU=http://certificates.godaddy.com/repository,CN=Go Daddy Secure 
Certification Authority,serialNumber=07969287
 # Issuer's DN: C=US,O=The Go Daddy Group\, Inc.,OU=Go Daddy Class 2 
Certification Authority

As far as I can tell, that isn't a valid certificate chain.  The issuer
of the first, end-entity, certificate isn't the subject of the middle
certificate in the chain.  It seems as if the final two certificates in
the chain are swapped.

According to RFC 4346 (earlier TLS specifications contains similar
wording):

   certificate_list
      This is a sequence (chain) of X.509v3 certificates.  The sender's
      certificate must come first in the list.  Each following
      certificate must directly certify the one preceding it.  Because
                  ^^^^
      certificate validation requires that root keys be distributed
      independently, the self-signed certificate that specifies the root
      certificate authority may optionally be omitted from the chain,
      under the assumption that the remote end must already possess it
      in order to validate it in any case.

So I'd say this is a server configuration error.

/Simon




reply via email to

[Prev in Thread] Current Thread [Next in Thread]