Quantcast

strange behavior of self signed cert “VeriSign Class 3 Public Primary Certification Authority - G5”.

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

strange behavior of self signed cert “VeriSign Class 3 Public Primary Certification Authority - G5”.

Pingzhong Li
Hi,  recently when we bought certificate from Verisign, our cert has new root Certificate which is “VeriSign Class 3 Public Primary Certification Authority - G5”.  This cert is quite strange when I run it at the openssl s_cilent command line, it won't stop at G5, it will go to another cert "Class 3 Public Primary Certification Authority", Here is part of the command line output:

C:\OpenSSL-Win32\bin>openssl s_client -connect xxx.xxx.com:443 -CAfile
"<cert_path>\cert.pem"
Loading 'screen' into random state - done
CONNECTED(00000160)
depth=3 C = US, O = "VeriSign, Inc.", OU = Class 3 Public Primary Certification
Authority
verify return:1
depth=2 C = US, O = "VeriSign, Inc.", OU = VeriSign Trust Network, OU = "(c) 200
6 VeriSign, Inc. - For authorized use only", CN = VeriSign Class 3 Public Primar
y Certification Authority - G5
verify return:1
depth=1 C = US, O = "VeriSign, Inc.", OU = VeriSign Trust Network, OU = Terms of
use at https://www.verisign.com/rpa (c)10, CN = VeriSign Class 3 Secure Server
CA - G3
verify return:1
depth=0 C = US, ST = Pennsylvania, L = xxxx, O = xxxx, OU = xxxx, OU =
Terms of use at www.verisign.com/rpa (c)05, CN = xxx.xxx.com
verify return:1
---
Certificate chain
0 s:/C=US/ST=Pennsylvania/L=xxxx/O=xxxx/OU=xxxx/OU=Terms of use at www
.verisign.com/rpa (c)05/CN=xxx.xxx.com
   i:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https:/
/www.verisign.com/rpa (c)10/CN=VeriSign Class 3 Secure Server CA - G3
1 s:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https:/
/www.verisign.com/rpa (c)10/CN=VeriSign Class 3 Secure Server CA - G3
   i:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc.
- For authorized use only/CN=VeriSign Class 3 Public Primary Certification Auth
ority - G5
2 s:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc.
- For authorized use only/CN=VeriSign Class 3 Public Primary Certification Auth
ority - G5
   i:/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority

Note that it doesn't stop at “VeriSign Class 3 Public Primary Certification Authority - G5”. However firefox will stop at that cert. From the cert, its issuer is:
CN = VeriSign Class 3 Public Primary Certification Authority - G5
OU = (c) 2006 VeriSign, Inc. - For authorized use only
OU = VeriSign Trust Network
O = VeriSign, Inc.
C = US

which is itself.

Any idea? Did some search on internet and didn't find any useful information on this, however see this post: http://efreedom.com/Question/2-72580/OpenSSL-Certificate-Signature-Failure-Error which has the same verification chain as I saw here.

My second question is that for the root CA used here "Class 3 Public Primary Certification Authority", there are both expired and unexpired cert at CAfile (one is expired at 2004, one is good till 2028, we probably should not do that in the first place, however the software is already at customer, not easy to change this). The strange behavior I saw here is that openssl sometimes uses the expired cert, sometimes uses the unexpired cert which really get me confused.

At the above openssl s_client run, the verification is ok, however after I just removed 2 certs from the CAfile, now s_client starts complaining that root cert is expired:
C:\OpenSSL-Win32\bin>openssl s_client -connect xxx.xxx.com:443 -CAfile
"<cert_path>\cert.pem"
Loading 'screen' into random state - done
CONNECTED(00000160)
depth=3 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=Pennsylvania/L=xxxx/O=xxxx/OU=xxxx/OU=Terms of use at www
.verisign.com/rpa (c)05/CN=xxx.xxx.com
   i:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https:/
/www.verisign.com/rpa (c)10/CN=VeriSign Class 3 Secure Server CA - G3
1 s:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https:/
/www.verisign.com/rpa (c)10/CN=VeriSign Class 3 Secure Server CA - G3
   i:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc.
- For authorized use only/CN=VeriSign Class 3 Public Primary Certification Auth
ority - G5
2 s:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc.
- For authorized use only/CN=VeriSign Class 3 Public Primary Certification Auth
ority - G5
   i:/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority


Just wonder what sequence openssl is used to build up the certification verification chain. Is this an openssl bug? Do you see this problem before?

Really appreciated.

Thanks,
Pingzhong Li

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: strange behavior of self signed cert “VeriSign Class 3 Public Primary Certification Authority - G5”.

Pingzhong Li
This post was updated on .
Didn't see any reply, thought I will ask one simpler questions again.

If for one root Certificate, there are both expired and unexpired cert (same DN) at the CA file, which one will be used during certificate verification? From testing, if there are only those 2 certs at the CA file, the certificate at later of CA file will be used. However if there are quite a few certs at the CA file, this doesn't hold any more, it seems that the sequence at the CA file doesn't matter any more. Could any one shed some lights on this?  

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: strange behavior of self signed cert ???VeriSign Class 3 Public Primary Certification Authority - G5???.

Dr. Stephen Henson
On Wed, Dec 22, 2010, Pingzhong Li wrote:

>
> Didn't see any reply, thought I will ask one simpler questions again.
>
> If for one root Certificate, there are both expired and unexpired cert (same
> DN) at the CA file, which one will be used during certificate verification?
> >From testing, if there are only those 2 certs at the CA file, the
> certificate at later of CA file will be used. However if there are quite a
> few certs at the CA file, this doesn't hold any more, it seems that the
> sequence at the CA file doesn't matter any more. Could any one shed some
> lights on this?  
>

At present which certificate is used is a matter of luck: so you shouldn't
include expired certificates in the trusted store.

In future the algorithm used will be enhanced so it can handle this situation
properly and ignore expired certificates is an unexpired one exists.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: strange behavior of self signed cert ???VeriSign Class 3 Public Primary Certification Authority - G5???.

Pingzhong Li
Working with our network team, we finally found out the reason for the strange behavior of the "VeriSign Class 3 Public Primary Certification Authority - G5" cert, actually there are 2 G5 cert from Verisign, one is self signed, one is signed by "Class 3 Public Primary Certification Authority", so basically there are 2 verification chain for our server
1. our server --> VeriSign Class 3 Secure Server CA - G3 --> VeriSign Class 3 Public Primary Certification Authority - G5 --> Class 3 Public Primary Certification Authority
2. our server --> VeriSign Class 3 Secure Server CA - G3 --> VeriSign Class 3 Public Primary Certification Authority - G5

The intermediate certs deployed on our server are the following 2 certs stacked together:
VeriSign Class 3 Secure Server CA - G3
VeriSign Class 3 Public Primary Certification Authority - G5
so even we have the self signed "VeriSign Class 3 Public Primary Certification Authority - G5" at the trusted CA file, it won't be used. However at firefox, it won't use the intermediate G5 from server. That's the reason why we saw this different verification chain at firefox and our application.

Dr. Stephen Henson wrote
At present which certificate is used is a matter of luck: so you shouldn't
include expired certificates in the trusted store.

In future the algorithm used will be enhanced so it can handle this situation
properly and ignore expired certificates is an unexpired one exists.
Thanks for this information. This does clarify quite a bit on this.  We will remove the expired trusted CA from our CA file. This does solve the current verification problem with "VeriSign Class 3 Public Primary Certification Authority - G5" not matter if G5 is self signed or intermediate cert.  However there is still one thing which is puzzling us. The old cert verification chain at our server is:
 our server --> VeriSign Class 3 Secure Server CA --> Class 3 Public Primary Certification Authority
Note that its root CA "Class 3 Public Primary Certification Authority" is same as the root CA of the  "VeriSign Class 3 Public Primary Certification Authority - G5", so both expired cert and unexpired cert for that root CA is presented at our trust CA filesin last couple years, however we never run into cert expired problem. So not sure if this luck is related with depth of the verification (depth: 2 vs 3).



Loading...