[gnutls-devel] A certificate is verified by Gnutls but rejected by OpenSSL/PolarSSL
Peter Williams
home_pw at msn.com
Thu Apr 2 20:03:43 CEST 2015
There are no test vectors (outside of dod/nsa or equiv). Unlike crypto alg test vectors.
Sent from my Windows Phone
________________________________
From: 陈雨亭<mailto:chenyt at cs.sjtu.edu.cn>
Sent: 4/2/2015 10:57 AM
To: Nikos Mavrogiannopoulos<mailto:nmav at gnutls.org>; Peter Williams<mailto:home_pw at msn.com>
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
Is it possible to find any test oracles? Given a certificate chain,
how can we decide that it is correct or incorrect?
From: Peter Williams
Sent: Thursday, April 02, 2015 10:31 AM
To: Yuting Chen ; Nikos Mavrogiannopoulos
Cc: GnuTLS development list
Subject: RE: [gnutls-devel] A certificate is verified by Gnutls but rejected by OpenSSL/PolarSSL
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
Sent: 4/2/2015 10:01 AM
To: Nikos Mavrogiannopoulos
Cc: GnuTLS development list
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/0d865b74/attachment-0001.html>
More information about the Gnutls-devel
mailing list