google / x509test

X.509 certificate test suite

X.509 Test

This project helps with the testing of X.509 PKIX (RFC5280) implementations, by providing test certificates and automation.

The original idea for this project was to work through the text of RFC5280 and create an invalid test certificate corresponding to each MUST or SHOULD clause in the RFC. These invalid certificates are then signed by a fake CA, and can be fed to various TLS implementations to see whether they are accepted.

Prerequisites

This project relies on the following tools being present in the PATH:

• the ascii2der and der2ascii tools from the der-ascii open source project
• the openssl binary.

Operation

The project is built from the top-level Makefile, where the master check target will:

• Create a private key (ca/fake-ca.private.pem) for the fake CA, and build a corresponding CA certificate (in ca/fake-ca.cert).
• Build a complete certificate for each test case (in tbs/*.tbs), signed by the fake CA (in certs/ or certs2/).
• Run each certificate through various different TLS implementations, saving the output (in results/$TOOL/*.out).
• Emit a summary of verification failures.

Project Layout

The project is organized as follows.

• The tbs/ directory holds the test certificates, in the form of ASCII files suitable for feeding to the ascii2der tool. These certificates are in the form of the TBSCertificate ASN.1 type, and they pull in shared common fragments (from the tbs/fragment/ subdirectory) using a #include extension to the ASCII format.
• The tbs2/ directory holds pairs of certificates where the leaf certificate (*.leaf.tbs) is signed by an intermediate CA certificate (*.ca.tbs).
• The scripts/ directory holds scripts that allow the certificates to be fed to the different TLS implementations and their results checked.
• The cfg/ directory holds additional configuration files, e.g. for controlling OpenSSL's certificate generation process.
• The third_party/ietf/ holds local copies of the relevant specifications and RFCs.

Disclaimer

This is not an official Google product.

x509test's Issues

Invalid domain name test in Subject Alternative Name

Hi David,

first off, thanks for the great work with this, it has been invaluable for me. I'm currently writing a validator to detect all kinds of issues with certificates and your test corpus has been a goldmine.

In my implementation I have an issue with xf-ext-altname-invalid-domain.pem -- it might very well be that my understanding is wrong. I still open this up as a ticket because if it turns out to be bogus there'll be public documentation and others might find it before asking :-)

The certificate contains a CN of "*.google.com" and a Subject Alternative Name of "DNS:*.123google.com". The SN/GN indicates:

SN = "RFC5280 s4.2.1.6 'The name MUST be in the preferred name syntax, as specified by Section 3.5 of [RFC1034] and as modified by Section 2.1 of [RFC1123]'"
GN = Subject Alternative Name with invalid domain

The issue here does not seem to be the mismatch between CN/SAN because if a SAN is present it always has precedence (to the best of my knowledge). Therefore the only issue I can see would be the wildcard domainname "*.123google.com". However, I don't see what's wrong with it. Leading digits for labels are okay (e.g., "www.321meins.de" leads to eBay), so maybe I'm missing something super obvious?

Would be very much appreciated if you could point me in the right direction.
Again, thank you so much for x509test.
Cheers,
Joe

BMPString uses invalid UTF16 encoding

Hi David,

hope you are well. I have been coding some more and checking against your great x509test toolkit. I believe I've found an issue in xf-ext-cert-policies-bmp-unotice. In particular, you define the explicitText BMPString as:

  BMPString { "User notice" }  # explicitText

Clearly, this violates the RFC because the type is a BMPString. However, a BMPString is UTF-16, but "User notice" is 11 characters wide. I.e., a proper BMPString parser doesn't even validate the encoded string, but chokes already on the encoding of the string itself. The testcase does pose an invalid certificate, but it does not test not what it should actually test.

It can be easily fixed by either of:

1. Change "User notice" to "User noticex" (or any other valid UTF-16 string)
2. Change BMPString to VisibleString

Thanks & HTH,
All the best,
Joe

Generate real private/public key pair for leaf certifcates

As discussed it would be useful if the generated certificates contained real private/public key pairs for the corresponding leaf certificates.

Recent OpenSSL versions refuse to convert invalid DER files

For example, the file tbs/xf-def-invalid-nonminimal-int.tbs includes an ASN.1 INTEGER that has been incorrectly DER-encoded (because it has leading padding). This fragment can no longer be converted into a full invalid certificate because the build tools try to use OpenSSL as part of the conversion.