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

[陈雨亭]

Interesting! I have never heard about this. Thus it is possible that one tool (e.g., openssl) chains the certificates on their keyids, but gnutls may chain them on their names (or on the contrary), right? 

From: Peter Williams 
Sent: Thursday, April 02, 2015 7:28 PM
To: Yuting Chen ; Nikos Mavrogiannopoulos 
Cc: GnuTLS development list 
Subject: RE: [gnutls-devel] A certificate is verified by Gnutls but rejected by OpenSSL/PolarSSL

Some libs chain on the keyids, not the names. Depends on the generation of developer. If paid / indoctrinated in the pem phase, will be name based (since one used the directory to do what we would now call openid connect discovery of tryst points (based on naming domains)). If NSA paid /influenced, it uses keyids (which are just NSA kmids, revisited)

For disclosure, I was NSA paid / influenced, but thoroughly bought into the darpa design , now realized (20 years late) as azure active directory plus openud connect.


Sent from my Windows Phone

--------------------------------------------------------------------------------
From: Yuting Chen
Sent: ‎4/‎2/‎2015 6:49 PM
To: Nikos Mavrogiannopoulos
Cc: GnuTLS development list
Subject: Re: [gnutls-devel] A certificate is verified by Gnutls but rejected by OpenSSL/PolarSSL


Another very different example: when I verify file5.pem (the attached file) against fa_rootCA_key_cert.pem, gnutls cannot find the issuer of the cert in file5.pem, but openssl/polarssl can find the issuer and accept it. It is a little tricky to find the issuer by comparing the "issuer" field of one certificate with the "subject" field of the ca certificate. 

On Thu, Apr 2, 2015 at 2:07 PM, Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote:

  On Thu, 2015-04-02 at 10:00 -0700, Yuting Chen wrote:


  > (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

  In the file.pem you have 2 certificates (a chain), and the fa_rootCA is
  another one. If you try openssl on each two of them (i.e., split the
  file.pem) you'll get an OK. Are you sure that openssl verify can accept
  a chain?

  regards,
  Nikos




-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20150402/401f1ab1/attachment-0001.html>