X509.has_expired() returns wrong value on OS X / OpenSSL 1.0.2

[mrjefftang]

I'm putting this here to track down some weird behavior I'm seeing when I was testing the verify-chain branch.

pyOpenSSL: 0.14
cryptography: 0.7.2

Test fails on: OpenSSL: 1.0.2 22 Jan 2015 (Homebrew OpenSSL)
Test passes on: OpenSSL: 0.9.8zc 15 Oct 2014 (OS X 10.10.2 OpenSSL)

from OpenSSL.crypto import load_certificate
from OpenSSL.crypto import FILETYPE_PEM
from OpenSSL.test.test_crypto import root_cert_pem

cert = load_certificate(FILETYPE_PEM, root_cert_pem)
assert cert.has_expired() == False

[mrjefftang]

It looks like the return value of the call to ASN1_UTCTIME_cmp_time_t returns -2 which is an error condition.

The function changed in this commit: openssl/openssl@46a6cec

According to the OpenSSL changelog, it was added after 1.0.1k and landed in the 1.0.2 release.

[mrjefftang]

This is no longer an issue with OpenSSL 1.0.2a (the bug occurred in 1.0.2).

[hynek]

So it seems as if there’s still some problem here.

On 1.0.2d, ASN1_UTCTIME_cmp_time_t returns -2 in our test_root_has_not_expired.

I’ve glanced over OpenSSL and googled it but couldn’t find anything helpful related to it.

The certificated used in the test FWIW expires in 2017…

[hynek]

Seems like there’s no less than three reasons why ASN1_UTCTIME_cmp_time_t could return -2: https://github.com/openssl/openssl/blob/0d0099ea3b1825fe51bce11e076292e408b55feb/crypto/asn1/a_utctm.c#L245-L252

[hynek]

To be clear, this seems to be a bug from us because we use the function wrong? Could it be related to #311?

[reaperhulk]

gm_time_adj (which is used in this test) properly does UTCTIME vs GENERALIZEDTIME so that's not the issue here (although the unconditional use of UTCTIME is incorrect). I'm looking into this a bit more.