I'm looking at the Chilkat Cert ActiveX object for use as a way to validate properties on X509 self-signed certificates, and have hit a roadblock when checking the ValidTo property. I have created a VB.Net project using the X509Certificate2 object and have been able to verify that the expiry date is correct in the certificate, as well as CAPICOM 2.1, however I have a requirement to be able to validate certificate data from a legacy VB6 application on Windows 7 for which the .Net framework is not an option and CAPICOM, while it appears to work, is not supported.
The certificates are sha256 signed (I have also tested sha1 versions and see the same issue), and have a ValidTo date that is exactly 100 years from the ValidFrom date. The certificate data is a base64 encoded DER format string. Taking a single certificate, I have run it through the following code:
Dim oCert As New Chilkat_v9_5_0.ChilkatCert success = oCert.LoadFromBase64(sCertData) With oCert Debug.Print "ValidFrom: " & .ValidFrom Debug.Print "ValidTo: " & .ValidTo End With
and the result is:
ValidFrom: 07/08/2014 13:22:19 ValidTo: 07/08/2014 13:22:19
Here is the debug log output for this:
LoadFromBase64: DllDate: Aug 1 2014 ChilkatVersion: 126.96.36.199 UnlockPrefix: NONE Username: xxx Architecture: Little Endian; 32-bit Language: ActiveX VerboseLogging: 0 createFromBinary: Found -----BEGIN CERTIFICATE----- certCreateFromDer: loadX509DerAlt: der_to_xml: (leaveContext) (leaveContext) (leaveContext) (leaveContext) Success. (leaveContext) ValidFrom: DllDate: Aug 1 2014 ChilkatVersion: 188.8.131.52 UnlockPrefix: NONE Username: xxx Architecture: Little Endian; 32-bit Language: ActiveX VerboseLogging: 0 (leaveContext) ValidTo: DllDate: Aug 1 2014 ChilkatVersion: 184.108.40.206 UnlockPrefix: NONE Username: xxx Architecture: Little Endian; 32-bit Language: ActiveX VerboseLogging: 0 Did not find UTC date/time... Checking for generalized date/time format... Found generalized date/time. (leaveContext)
which suggests that a "generalized date/time" value for ValidTo was found which looks correct, which is consistent a date far in the future as the X509 RFCs state that UTC dates cannot be used for dates after 2049. Also the value of the .Expired property is zero, which suggests that internally the Cert object has verified that the ValidTo date is in the future.
Here is the CAPICOM code:
Dim oCAPI As New CAPICOM.Certificate oCAPI.Import (Base64Decode(sCertData)) With oCAPI Debug.Print "ValidFrom: " & .ValidFromDate Debug.Print "ValidTo: " & .ValidToDate End With
which results in:
ValidFrom: 07/08/2014 13:22:19 ValidTo: 07/08/2114 13:22:19
Unfortunately I cannot provide a sample certificate to be tested as the nature of these is commercially confidential. I have saved the base64 decoded binary data to a file name cert.crt and when opened in Windows the certificate data displayed shows the correct expiry date. I have also used OpenSSL 1.0.1 to output a text display of the certificate data and again the ValidTo date is correctly shown.
Is there an issue in the Cert class that makes it unable to deal with 100 years difference as an expiry date on a certificate? A quick search suggests that there were bugs in older OpenSSL versions due to using operating system APIs to determine dates and failing with dates past 2049, could Chilkat Cert be doing a similar thing?
Dan, thank you for reporting the problem. I am investigating. I reproduced the problem already and should be able to fix it. I'll post a pre-release download link when the fix is ready. Also, each time a problem is identified, the test is added to Chilkat's internal QA suite so that it is re-verified prior to each version release. Chilkat's internal QA testing is always as a result of normal day-to-day operations..
Thanks. Here's a new build with the fix:
The problem was caused by an internal sanity-check for the date/time values. If the year was before 1960 or after the current date + 100 years, then it was considered invalid. This is now changed to 5000 years. Essentially, we don't want to allow for garbage date/time values if somehow the data was corrupt.
Note: The Chilkat Forum is not an official support line. If the problem is reported with good, precise information (such as with this one), and if the initial triage is to conclude a likely bug within Chilkat, then it will be addressed quickly. Otherwise, the post may be ignored and one should go through official support channels (via email and with non-expired support).
Thanks for the quick reply, that's got to be close to the quickest support response I've seen from any company. Glad to hear it wasn't me doing something wrong :)
I'm on holiday next week, so if there's a new release out when I get back I'll test it as soon as possible.
Hi, wow that was quick. I won't be able to test this for a week, but will do so as some as possible.
As to posting on the forum, I did so as I only downloaded the Chilkat ActiveX today to try it so don't have non-expired support. I was posting in the hope that another user may have had a similar issue and could suggest a workaround.
My new employer does have a developer licence for an older version of the controls but Cert is listed as free and i assume therefore unsupported. I will push for their support to be renewed if it has expired and to get the current controls implemented if possible.
Got back to work this morning and tested the updated Cert object, the ValidTo date is now showing correctly. Thanks for getting this corrected so quickly.