Archived Forum Post

Index of archived forum posts

Question:

Cert ActiveX unable to get correct ValidTo date

Sep 01 '14 at 02:14

Hi,

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: 9.5.0.43
    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: 9.5.0.43
    UnlockPrefix: NONE
    Username: xxx
    Architecture: Little Endian; 32-bit
    Language: ActiveX
    VerboseLogging: 0
    (leaveContext)
ValidTo:
    DllDate: Aug  1 2014
    ChilkatVersion: 9.5.0.43
    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?

Regards,

Dan


Accepted Answer

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


Answer

Dan,

Thanks. Here's a new build with the fix:

32-bit: http://www.chilkatsoft.com/download/preRelease/ChilkatAx-9.5.0-win32.zip
64-bit: http://www.chilkatsoft.com/download/preRelease/ChilkatAx-9.5.0-x64.zip

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).


Answer

Hi,

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.

Regards,

Dan


Answer

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.

Regards,

Dan


Answer

Hi,

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.

Regards,

Dan