[gnutls-devel] A certificate is verified by Gnutls but rejected by OpenSSL/PolarSSL

Peter Williams home_pw at msn.com
Thu Apr 2 19:31:50 CEST 2015


When we write the Verisign cps, we distinguished

Validating a root *(becos it is lusted in a mib, secured by non crypto means, in the days before gchq:s  tpm became embedded in laptops and export grade servers)

Validating a chain from said root to a leaf cert, which includes verifying a sequence signatures and asn1 encodings and control policies (eg chain length) against some cert profile or cps

Verifying a digital signature, distinct from validating it as part of chain processing.

The legal theory was clear. Dig sigs need to be verified using public keys (not certs). The security service of key distribution (cert chains, in this case) delivers leaf public keys to trust store (even ephemeral ones) from which they are accessed by the signature verification modules.

Fyi, ietf tls does not standardize any of the above. It's upto to each vendor, some of whose staff are typically easily compromised to deliver operationnally defective crypto or security services.

Check that the security service claimed by each lib is the same. No point comparing validation vs verification. No point comparing one vendors asn1 int encoding against another *recalling that public key length encoding choices represent  a crypto oracle)




Sent from my Windows Phone
________________________________
From: Yuting Chen<mailto:chenyt at cs.sjtu.edu.cn>
Sent: ‎4/‎2/‎2015 10:01 AM
To: Nikos Mavrogiannopoulos<mailto:nmav at gnutls.org>
Cc: GnuTLS development list<mailto:gnutls-devel at lists.gnutls.org>
Subject: Re: [gnutls-devel] A certificate is verified by Gnutls but rejected by OpenSSL/PolarSSL

Hi, Nikos, I'm not very sure whether the certificate should or should not
pass validation. It is a challenging problem to design tests for testing
SSL tools. I used openssl to create 4000 valid or invalid test certificates
(but I failed to design test oracles). It is interesting that the
certificate is the only that can be accepted by Gnutls, but rejected by
openssl and polarssl. The validation results are:
(1) Gnutls:
Subject: C=GB,ST=Greater Manchester,L=Salford,O=Comodo CA Limited,CN=Secure
Certificate Services
Issuer: C=US,ST=CA,O=Internet Widgits Pty Ltd,CN=Frankencert CA
Checked against: C=US,ST=CA,O=Internet Widgits Pty Ltd,CN=Frankencert CA
Output: Verified. The certificate is trusted.

Subject: C=US,O=VeriSign\, Inc.,OU=Class 4 Public Primary Certification
Authority - G2,OU=(c) 1998 VeriSign\, Inc. - For authorized use
only,OU=VeriSign Trust Network
Issuer: C=GB,ST=Greater Manchester,L=Salford,O=Comodo CA Limited,CN=Secure
Certificate Services
Checked against: C=GB,ST=Greater Manchester,L=Salford,O=Comodo CA
Limited,CN=Secure Certificate Services
Output: Verified. The certificate is trusted.

Chain verification output: Verified. The certificate is trusted.

(2) Openssl:
140637590406816:error:04091077:rsa routines:INT_RSA_VERIFY:wrong signature
length:rsa_sign.c:175:
140637590406816:error:0D0C5006:asn1 encoding routines:ASN1_item_verify:EVP
lib:a_verify.c:221:
ZZZZZZZZZZZZZComodo_Secure_Services_root.pem: C = US, O = "VeriSign, Inc.",
OU = Class 4 Public Primary Certification Authority - G2, OU = "(c) 1998
VeriSign, Inc. - For authorized use only", OU = VeriSign Trust Network
error 7 at 0 depth lookup:certificate signature failure

(3) PolarSSL:
  . Loading the CA root certificate ... ok (0 skipped)

  . Loading the certificate(s) ... ok
  . Peer certificate information    ...
      cert. version     : 1
      serial number     : 32:88:8E:9A:D2:F5:EB:13:47:F8:7F:C4:20:37:25:F8
      issuer name       : C=GB, ST=Greater Manchester, L=Salford, O=Comodo
CA Limited, CN=Secure Certificate Services
      subject name      : C=US, O=VeriSign, Inc., OU=Class 4 Public Primary
Certification Authority - G2, OU=(c) 1998 VeriSign, Inc. - For authorized
use only, OU=VeriSign Trust Network
      issued  on        : 1998-05-18 00:00:00
      expires on        : 2028-08-01 23:59:59
      signed using      : RSA with SHA1
      RSA key size      : 1024 bits

  . Peer certificate information    ...
      cert. version     : 3
      serial number     : 01
      issuer name       : C=US, ST=CA, O=Internet Widgits Pty Ltd,
CN=Frankencert CA
      subject name      : C=GB, ST=Greater Manchester, L=Salford, O=Comodo
CA Limited, CN=Secure Certificate Services
      issued  on        : 2004-01-01 00:00:00
      expires on        : 2016-07-06 23:59:59
      signed using      : RSA with SHA1
      RSA key size      : 1024 bits
      basic constraints : CA=true
      key usage         : Digital Signature, Key Encipherment

  . Verifying X.509 certificate...
Verify requested for (Depth 0):
cert. version     : 1
serial number     : 32:88:8E:9A:D2:F5:EB:13:47:F8:7F:C4:20:37:25:F8
issuer name       : C=GB, ST=Greater Manchester, L=Salford, O=Comodo CA
Limited, CN=Secure Certificate Services
subject name      : C=US, O=VeriSign, Inc., OU=Class 4 Public Primary
Certification Authority - G2, OU=(c) 1998 VeriSign, Inc. - For authorized
use only, OU=VeriSign Trust Network
issued  on        : 1998-05-18 00:00:00
expires on        : 2028-08-01 23:59:59
signed using      : RSA with SHA1
RSA key size      : 1024 bits
  ! self-signed or not signed by a trusted CA
 failed

On Thu, Apr 2, 2015 at 12:21 AM, Nikos Mavrogiannopoulos <nmav at gnutls.org>
wrote:

> On Wed, Apr 1, 2015 at 11:15 PM, Yuting Chen <chenyt at cs.sjtu.edu.cn>
> wrote:
> > I made a certificate and verified it using gnutls, openssl, and
> polarssl. It
> > can be verified by gnutls, but be rejected the other two due to
> certificate
> > signature failures. It is a special case because in many other cases in
> my
> > experiment, gnutls tends to "reject" certificates if openssl "rejects"
> them.
> > Can anyone help me find the reason (to ensure that gnutls has checked the
> > signature correctly)?
>
> Hello,
>  What is the issue in the certificate? Why it shouldn't be verified
> successfully?
>
> regards,
> Nikos
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20150402/2b6c85ca/attachment.html>
-------------- next part --------------
_______________________________________________
Gnutls-devel mailing list
Gnutls-devel at lists.gnutls.org
http://lists.gnupg.org/mailman/listinfo/gnutls-devel


More information about the Gnutls-devel mailing list