|
Forums -> Security Library Forum
Seemingly valid cert shows as expired |
|
|
by dan trubow [dan dot trubow at ontariosystems dot com] posted on 2004/01/13 |
|
I'm connecting to a website using a secure socket with CredentialVerification.Manual.
The cert check comes back with an expired certificate. But if I capture the cert chain and print out the certificates, the dates show the certificates are valid. Trace as follows:
ProcessCert: Putting 2 into cert store
CERTIFICATE[0]:
Effective Date: 7/13/2003 7:00:00 PM
Expiration Date: 7/13/2004 6:59:59 PM
Format: X509
Name: xml.fastdataweb.com
Issuing CA: www.verisign.com/CPS Incorp.by Ref. LIABILITY LTD.(c)97 VeriSign
Key Algorithm: 1.2.840.113549.1.1.4
Serial Number: B12ACCE30D5D434CB49F57D1CB87DD00
Key Alogrithm Parameters: 0500
Public Key: 30818902818100D[SNIP]DF250203010001
CERTIFICATE[1]:
Effective Date: 4/16/1997 7:00:00 PM
Expiration Date: 10/24/2011 6:59:59 PM
Format: X509
Name: VeriSign Trust Network
Issuing CA: Class 3 Public Primary Certification Authority
Key Algorithm: 1.2.840.113549.1.1.5
Serial Number: A46E22AEDDC5F858E3CC4238858A4B25
Key Alogrithm Parameters: 0500
Public Key: 30818902818100[SNIP]F0203010001
VerifyChain: now in action ...
VerifyChain: server =xml.fastdataweb.com
VerifyChain: authtype = Server
VerifyChain: flags=None
VerifyChain: Calling sspi provider
Last error = -2147024896 (using Marshal.GetHRForLastWin32Error())
Chain Index = 0
Element Index = 1
VerifyChain: Status: Expired
VerifyChain: Returning: -2146762495
VerifyChain: Cleaned up.
ANY IDEAS ON WHY THIS IS OCCURRING OR HOW TO FIX? If I use VerificationFlags.IgnoreTimeNotValid then of course it works fine. However, I must catch invalid certificates, and this certificate appears valid.
|
by Pieter Philippaerts [Pieter at mentalis dot org] posted on 2004/01/13 |
|
In order to validate a certificate chain, all certificates in the chain must be valid. So even though the leaf certificate is valid, the chain will be marked as expired if one of the intermediate certificates is expired.
In your case, it's the VeriSign root certificate that has expired. More details are available at http://verisign.com/support/vendors/exp-gsid-ssl.html |
by Dan Trubow posted on 2004/01/14 |
|
Thanks for the answer.
I also found this by printing the cert to a file, then installing it on my computer (right clicked on the .cer file and chose Install). Then viewed the cert from Internet Explorer. Here I saw it was actually an intermediate certificate that was expired, not the root.
It would be interesting to know, why I could only print out the root and the leaf (end) certificate, but not the intermediate certificate from the chain?
Also, in Security.SSL.HandshakeLayer.VerifyChain, the default for the case statement is true, but to me seems it should be false. Minor but important if you wish to provide secure links and security is an important issue. |
by Pieter Philippaerts [Pieter at mentalis dot org] posted on 2004/01/14 |
|
If you create a CertificateChain instance from your leaf certificate and then call the GetCertificates method, it should return all certificates in the chain, including the intermediate certificates.
As for the case statement, the code should never get to the 'default' statement. The cases above the default are an exhaustive list of the CredentialVerification enumeration. |
by dan trubow posted on 2004/02/06 |
|
Okay, there is one more piece to this.
I didn't realize the certificate chain is built using the certificate store on the client computer. The server sends out its leaf certificate, then chain is then constructed at the client using the client's certificate store. So the server wasn't at fault, the client was.
Now that I've installed a new Intermediate Authority certificate from Verisign, on the client, the Expiration test passes, but now I get UntrustedRoot. But in this case the root is Verisign, and it's as trusted as they come. |
|
|