crl: invalid version test case

[woodruffw]

Reopens #439.

[woodruffw]

OpenSSL 1.1.1 appears to really struggle to produce well-formed error messages here:

Evaluating case: crl::crl-invalid-version
Warning: failed to parse CRL
Internal error: 0:error:0D0680A8:asn1 encoding routines:asn1_check_tlen:wrong tag:crypto/asn1/tasn_dec.c:1149:
0:error:0D06C03A:asn1 encoding routines:asn1_d2i_ex_primitive:nested asn1 error:crypto/asn1/tasn_dec.c:713:
0:error:0D08303A:asn1 encoding routines:asn1_template_noexp_d2i:nested asn1 error:crypto/asn1/tasn_dec.c:646:Field=signature, Type=X509_CRL
0:error:0906700D:PEM routines:PEM_ASN1_read_bio:ASN1 lib:crypto/pem/pem_oth.c:33:
o4=�`�"�RYT�Q*��
�e�9 c��        �

make: *** [run] Error 1

...so we probably need to stub out the error emission for that version.

[github-actions[bot]]

:shipit: No regressions found.

[github-actions[bot]]

New testcases

There are new testcases in this change.

openssl-3.3.3

Testcase	Expected Result	Actual Result	Context
crl::crl-invalid-version	SUCCESS	FAILURE	unable to get certificate CRL
crl::crl-update-generalizedtime-2025	SUCCESS	FAILURE	unable to get certificate CRL

openssl-3.5.0

Testcase	Expected Result	Actual Result	Context
crl::crl-invalid-version	SUCCESS	FAILURE	unable to get certificate CRL
crl::crl-update-generalizedtime-2025	SUCCESS	FAILURE	unable to get certificate CRL

openssl-3.0.16

Testcase	Expected Result	Actual Result	Context
crl::crl-invalid-version	SUCCESS	FAILURE	unable to get certificate CRL
crl::crl-update-generalizedtime-2025	SUCCESS	FAILURE	unable to get certificate CRL

gnutls-certtool-3.8.3

Testcase	Expected Result	Actual Result	Context
crl::crl-invalid-version	SUCCESS	SKIPPED	CRLs not supported yet
crl::crl-update-generalizedtime-2025	SUCCESS	SKIPPED	CRLs not supported yet

rustls-webpki

Testcase	Expected Result	Actual Result	Context
crl::crl-invalid-version	SUCCESS	SKIPPED	CRLs are not supported by this API
crl::crl-update-generalizedtime-2025	SUCCESS	SKIPPED	CRLs are not supported by this API

openssl-3.4.1

Testcase	Expected Result	Actual Result	Context
crl::crl-invalid-version	SUCCESS	FAILURE	unable to get certificate CRL
crl::crl-update-generalizedtime-2025	SUCCESS	FAILURE	unable to get certificate CRL

openssl-3.2.4

Testcase	Expected Result	Actual Result	Context
crl::crl-invalid-version	SUCCESS	FAILURE	unable to get certificate CRL
crl::crl-update-generalizedtime-2025	SUCCESS	FAILURE	unable to get certificate CRL

gocryptox509-go1.24.3

Testcase	Expected Result	Actual Result	Context
crl::crl-invalid-version	SUCCESS	SKIPPED	CRLs not supported
crl::crl-update-generalizedtime-2025	SUCCESS	SKIPPED	CRLs not supported

openssl-1.1

Testcase	Expected Result	Actual Result	Context
crl::crl-invalid-version	SUCCESS	FAILURE	unable to get certificate CRL
crl::crl-update-generalizedtime-2025	SUCCESS	FAILURE	unable to get certificate CRL

pyca-cryptography-45.0.2

Testcase	Expected Result	Actual Result	Context
crl::crl-invalid-version	SUCCESS	SKIPPED	testcase skipped (explicit unsupported feature)
crl::crl-update-generalizedtime-2025	SUCCESS	SKIPPED	testcase skipped (explicit unsupported feature)

rust-webpki

Testcase	Expected Result	Actual Result	Context
crl::crl-invalid-version	SUCCESS	SKIPPED	CRLs are not supported by this API
crl::crl-update-generalizedtime-2025	SUCCESS	SKIPPED	CRLs are not supported by this API

certvalidator-0.11.1

Testcase	Expected Result	Actual Result	Context
crl::crl-invalid-version	SUCCESS	SKIPPED	testcase skipped (explicit unsupported feature)
crl::crl-update-generalizedtime-2025	SUCCESS	SKIPPED	testcase skipped (explicit unsupported feature)

[alex]

This appears to generate data in a completely different way than we do in our existing test cases. Is there a reason to do things differently? Should we port all the existing cert generation to this style?

[woodruffw]

Is there a reason to do things differently?

@tnytown can correct me but I believe this approach was the easiest way to hack some invalid states into CRLs. Looking at it more however, I think we can do a bit of cleanup here -- rather than implicitly pulling der-ascii I think we could dump the der-ascii "stencils" here and manually check in the modifications.

(I think that'll reduce the need for extra support code here + shorten the diff a good bit.)

Should we port all the existing cert generation to this style?

IMO no -- this is a pretty niche case where our existing APIs/generation techniques (like the handful of OpenSSL CLI scripts) don't work super well, whereas they work fine (and are more readable/maintainable) more generally.

[tnytown]

@tnytown can correct me but I believe this approach was the easiest way to hack some invalid states into CRLs.

Yep, that's correct—I didn't want to rely on the ability of other tooling to encode invalid CRLs (cryptography rightfully doesn't allow us to customize the CRL's version field or select between UTCTime and GeneralizedTime for the lastUpdate / nextUpdate fields).

Looking at it more however, I think we can do a bit of cleanup here -- rather than implicitly pulling der-ascii I think we could dump the der-ascii "stencils" here and manually check in the modifications.

(I think that'll reduce the need for extra support code here + shorten the diff a good bit.)

Agree on saving the intermediate stencils for introspection, but either way I think we'll need a tool that signs over the CRL. AFAIK openssl doesn't have the capability to generate a signed CRL from a DER TBSCertList and CA.

[cpu]

I was looking at adapting some of the test cases from rustls/webpki to x509-limbo, but it looks like most of our interesting testcases are just bare DER that we cooked up with der-ascii. There's a few generated with pyca/cryptography, but at first glance they're maybe less helpful in a general suite.

I'll keep an eye on the outcome of this branch to decide the best way to adapt the DER testcases based on how these der2ascii examples land.