Re: certificate validation issues with openssl 1.0.0 and expired certificates in cafile

2012-09-25 Thread Klaus Darilion
Just for the records: my workaround was to check the expiration date 
while dumping the certificates into the file, and skipping the expired 
ones. Further, I dump the certificates once a day to avoid issues with 
certificates expired after doing the dump.


regards
Klaus

On 13.09.2012 17:09, Erik Tkal wrote:

I suppose that’s a workaround, but doesn’t address the root cause.
Windows can quite happily handle expired certificates still hanging out
in trusted stores; I see this all the time as root updates occur and
renewed certificates are installed.  It seems that a change in OpenSSL
broke the previous behaviour that allowed this as well, though we can’t
tell if it’s the s_client app or the OpenSSL cert store functionality
that changed this.



*Erik Tkal**
*Juniper OAC/UAC/Pulse Development

*From:*owner-openssl-us...@openssl.org
[mailto:owner-openssl-us...@openssl.org] *On Behalf Of *Charles Mills
*Sent:* Thursday, September 13, 2012 9:42 AM
*To:* openssl-users@openssl.org
*Subject:* RE: certificate validation issues with openssl 1.0.0 and
expired certificates in cafile

Would it make sense to delete the expired certificate from the Windows
store? Duplicate expired/non expired CA certificates sounds to me like a
problem waiting to happen.

/Charles/

*From:*owner-openssl-us...@openssl.org
mailto:owner-openssl-us...@openssl.org
[mailto:owner-openssl-us...@openssl.org] *On Behalf Of *Ashok C
*Sent:* Thursday, September 13, 2012 12:49 AM
*To:* openssl-users@openssl.org mailto:openssl-users@openssl.org
*Subject:* Re: certificate validation issues with openssl 1.0.0 and
expired certificates in cafile

Sending again as the previous email did not appear in list.
Is there some problem with the mailing list?

--
Ashok

On Wed, Sep 12, 2012 at 2:59 PM, Ashok C ash@gmail.com
mailto:ash@gmail.com wrote:

Hi,

I don't think this question was answered. Could you please reply?

--
Ashok

On Tue, Jul 31, 2012 at 11:13 PM, Klaus Darilion
klaus.mailingli...@pernau.at mailto:klaus.mailingli...@pernau.at wrote:

Hi!

I wrote a small program which dumps all root certificates from Windows
certificate store into a file. Then I use openssl to connect to Google
and validate its certificate:

openssl s_client -connect www.google.com:443 http://www.google.com:443
-CAfile dump.crt

When using openssl0.9.8k or openssl0.9.8x everything works as expected.

When using openssl1.0.0g or openssl 1.0.1c the certificate validation
fails with:
   Verify return code: 10 (certificate has expired)

CONNECTED(016C)
depth=2 C = US, O = VeriSign, Inc., OU = Class 3 Public Primary
Certification Authority
verify error:num=10:certificate has expired
notAfter=Jan  7 23:59:59 2004 GMT
verify return:0
---
Certificate chain
  0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=www.google.com
http://www.google.com
i:/C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA
  1 s:/C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA
i:/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification
Authority

When analyzing the cafile with the dumped certificates from Windows
certificate store, I found out that there are two certificates for
Verisign with identical subject, whereas one is expired, the other not.

X.509 Certificate Information:
 Version: 1
 Serial Number (hex): 00e49efdf33ae80ecfa5113e19a4240232
 Issuer: C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary
Certification Authority
 Validity:
 Not Before: Mon Jan 29 00:00:00 UTC 1996
 Not After: Wed Jan 07 23:59:59 UTC 2004
 Subject: C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary
Certification Authority
 Subject Public Key Algorithm: RSA

X.509 Certificate Information:
 Version: 1
 Serial Number (hex): 70bae41d10d92934b638ca7b03ccbabf
 Issuer: C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary
Certification Authority
 Validity:
 Not Before: Mon Jan 29 00:00:00 UTC 1996
 Not After: Tue Aug 01 23:59:59 UTC 2028
 Subject: C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary
Certification Authority
 Subject Public Key Algorithm: RSA


Thus, it seems that openssl 0.9.8 just ignores the expired certificate
and searches if there is another valid one whereas openssl 1.0.0 stop
with the first expired certificate.

Is the new behavior the intended behavior? Is it possible to have the
old behavior also in new openssl versions?

Thanks
Klaus

__
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
mailto:openssl-users@openssl.org
Automated List Manager majord...@openssl.org mailto:majord...@openssl.org


__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl

Re: OpenSSL support of Intel AES instruction set

2012-09-25 Thread Klaus Darilion



On 24.09.2012 23:56, Alex Chen wrote:

Sorry I did not use new mail command to start a new topic.  Let me start
over again.

I remember seeing somewhere that OpenSSL supports Intel AES instruction
set.  If so, which release is that and what flag is needed to enable it.
Does the 'no-asm' flag in 'Configure' disable the use of these instructions?


There were patches for certains releases which addes AES support as an 
engine. When AES support was added to openssl it was not implemented 
as engine, but natively.


See http://www.openssl.org/news/changelog.html and search for AES-NI

regards
klaus
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org


certificate validation issues with openssl 1.0.0 and expired certificates in cafile

2012-07-31 Thread Klaus Darilion

Hi!

I wrote a small program which dumps all root certificates from Windows 
certificate store into a file. Then I use openssl to connect to Google 
and validate its certificate:


openssl s_client -connect www.google.com:443 -CAfile dump.crt

When using openssl0.9.8k or openssl0.9.8x everything works as expected.

When using openssl1.0.0g or openssl 1.0.1c the certificate validation 
fails with:

  Verify return code: 10 (certificate has expired)

CONNECTED(016C)
depth=2 C = US, O = VeriSign, Inc., OU = Class 3 Public Primary 
Certification Authority

verify error:num=10:certificate has expired
notAfter=Jan  7 23:59:59 2004 GMT
verify return:0
---
Certificate chain
 0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=www.google.com
   i:/C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA
 1 s:/C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA
   i:/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification 
Authority


When analyzing the cafile with the dumped certificates from Windows 
certificate store, I found out that there are two certificates for 
Verisign with identical subject, whereas one is expired, the other not.


X.509 Certificate Information:
Version: 1
Serial Number (hex): 00e49efdf33ae80ecfa5113e19a4240232
Issuer: C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary 
Certification Authority

Validity:
Not Before: Mon Jan 29 00:00:00 UTC 1996
Not After: Wed Jan 07 23:59:59 UTC 2004
Subject: C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary 
Certification Authority

Subject Public Key Algorithm: RSA

X.509 Certificate Information:
Version: 1
Serial Number (hex): 70bae41d10d92934b638ca7b03ccbabf
Issuer: C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary 
Certification Authority

Validity:
Not Before: Mon Jan 29 00:00:00 UTC 1996
Not After: Tue Aug 01 23:59:59 UTC 2028
Subject: C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary 
Certification Authority

Subject Public Key Algorithm: RSA


Thus, it seems that openssl 0.9.8 just ignores the expired certificate 
and searches if there is another valid one whereas openssl 1.0.0 stop 
with the first expired certificate.


Is the new behavior the intended behavior? Is it possible to have the 
old behavior also in new openssl versions?


Thanks
Klaus

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org