Introduction
Below is a collection of X509 certificates I use for testing and verification. Certificates have various key types, sizes, and a variety of other options in- and outside of specs. It is not always clear what limits are imposed and how applications work (or fail) if they encounter strange und uncommon values. If possible, the matching certificate requests and keys are included for completeness.
If not mentioned otherwise, certificates have been signed using the local WebCert CA certificate. For simple cert generation functions, check the online WebCert application.
1. Example Certificates with varied key type and key size
Certificate keys have a upper and lower limit in OpenSSL. lately, the trend is to increase key size for added protection, making 2048 bit standard, and 4096 bit are not uncommon. The following exemplary certificate creation process has been used to generate the example certificates with variations in key size and type:
1.1 Example Certificates using RSA keys ranging from 512 to 32768 Bit
This certificate test set consists of basic certificates with matching keys, and certificate requests using the RSA encryption algorithm. For certificates with RSA keys, the smallest possible key size is 384 bit (not generated), the biggest successfully tested size is 16384 bit.
| Key Size | RSA Test Certificates | |||||
|---|---|---|---|---|---|---|
| Certificate | Cert Request | RSA Key Pair | ||||
| 512 Bit | 512 RSA cert DER Format 534 bytes |
512 RSA cert PEM Format 778 bytes |
512 RSA csr DER Format 264 bytes |
512 RSA csr PEM Format 428 bytes |
512 RSA key DER Format 319 bytes |
512 RSA key PEM Format 497 bytes |
| 1024 Bit | 1024 RSA cert DER Format 602 bytes |
1024 RSA cert PEM Format 871 bytes |
1024 RSA csr DER Format 397 bytes |
1024 RSA csr PEM Format 611 bytes |
1024 RSA key DER Format 607 bytes |
1024 RSA key PEM Format 887 bytes |
| 2048 Bit | 2048 RSA cert DER Format 734 bytes |
2048 RSA cert PEM Format 1050 bytes |
2048 RSA csr DER Format 659 bytes |
2048 RSA csr PEM Format 964 bytes |
2048 RSA key DER Format 1192 bytes |
2048 RSA key PEM Format 1679 bytes |
| 4096 Bit | 4096 RSA cert DER Format 990 bytes |
4096 RSA cert PEM Format 1395 bytes |
4096 RSA csr DER Format 1171 bytes |
4096 RSA csr PEM Format 1659 bytes |
4096 RSA key DER Format 2348 bytes |
4096 RSA key PEM Format 3243 bytes |
| 8192 Bit | 8192 RSA cert DER Format 1502 bytes |
8192 RSA cert PEM Format 2090 bytes |
8192 RSA csr DER Format 2195 bytes |
8192 RSA csr PEM Format 3044 bytes |
8192 RSA key DER Format 4653 bytes |
8192 RSA key PEM Format 6363 bytes |
| 16384 Bit | 16k RSA cert DER Format 2526 bytes |
16k RSA cert PEM Format 3475 bytes |
16k RSA csr DER Format 4243 bytes |
16k RSA csr PEM Format 5819 bytes |
16k RSA key DER Format 9259 bytes |
16k RSA key PEM Format 12603 bytes |
| 32768 Bit | 32k RSA cert DER Format 4574 bytes *1 |
32k RSA cert PEM Format 6250 bytes *1 |
32k RSA csr DER Format 8339 bytes |
32k RSA csr PEM Format 11364 bytes |
32k RSA key DER Format 18477 bytes |
32k RSA key PEM Format 25083 bytes *2 |
Root CA: DER Format (960 bytes) / PEM Format (1354 bytes).
*1 Starting with 32k keys, a default compilation of OpenSSL starts to fail verifying the signature, and is unable to sign the certificate request. The error message is 3073525912:error:04067069:rsa routines:RSA_EAY_PUBLIC_DECRYPT:modulus too large:rsa_eay.c:622: 3073525912:error:0D0C5006:asn1 encoding routines:ASN1_item_verify:EVP lib:a_verify.c:184a:
OpenSSL limits the RSA keysize per crypto/rsa/rsa.h:
# define OPENSSL_RSA_MAX_MODULUS_BITS 16384per assumption that ultra-large keys make no sense in real world conditions.
*2 Generating a 32k RSA keypair took slighty over five hours. (2014)
1.2 Example Certificates using DSA keys ranging from 512 to 16384 Bit
Similar to the certificate test set above, this set consists of basic certificates with matching keys, and certificate requests using the DSA encryption algorithm:
| Key Size | DSA Test Certificates | |||||
|---|---|---|---|---|---|---|
| Certificate | Cert Request | DSA Key Pair | ||||
| 512 Bit | 512 DSA cert DER Format 683 bytes |
512 DSA cert PEM Format 981 bytes |
512 DSA csr DER Format 392 bytes |
512 DSA csr PEM Format 603 bytes |
512 DSA key DER Format 250 bytes |
512 DSA key PEM Format 680 bytes |
| 1024 Bit | 1024 DSA cert DER Format 882 bytes |
1024 DSA cert PEM Format 1249 bytes |
1024 DSA csr DER Format 591 bytes |
1024 DSA csr PEM Format 871 bytes |
1024 DSA key DER Format 446 bytes |
1024 DSA key PEM Format 1123 bytes |
| 2048 Bit | 2048 DSA cert DER Format 1283 bytes |
2048 DSA cert PEM Format 1793 bytes |
2048 DSA csr DER Format 1016 bytes |
2048 DSA csr PEM Format 1448 bytes |
2048 DSA key DER Format 858 bytes |
2048 DSA key PEM Format 2044 bytes |
| 4096 Bit | 4096 DSA cert DER Format 2051 bytes |
4096 DSA cert PEM Format 2833 bytes |
4096 DSA csr DER Format 1784 bytes |
4096 DSA csr PEM Format 2488 bytes |
4096 DSA key DER Format 1626 bytes |
4096 DSA key PEM Format 3779 bytes |
| 8192 Bit | 8192 DSA cert DER Format 3563 bytes |
8192 DSA cert PEM Format 4881 bytes |
8192 DSA csr DER Format 3298 bytes |
8192 DSA csr PEM Format 4539 bytes |
8192 DSA key DER Format 3162 bytes |
8192 DSA key PEM Format 7196 bytes |
| 16348 Bit | 16k DSA cert DER Format 6647 bytes *1 |
16k DSA cert PEM Format 9057 bytes *1 |
16k DSA csr DER Format 6358 bytes |
16k DSA csr PEM Format 8683 bytes |
16k DSA key DER Format 6210 bytes |
16k DSA key PEM Format 8472 bytes |
Root CA: DER Format (960 bytes) / PEM Format (1354 bytes).
*1: In a default compilation, OpenSSL 1.0.0e (6 Sep 2011) cannot create certificates with a 16384 bit DSA key. The error message "dsa routines:DSA_do_verify:modulus too large" is thrown when OpenSSL tries to verify the signature on the request. OpenSSL limits the DSA keysize per crypto/dsa/dsa.h:
# define OPENSSL_DSA_MAX_MODULUS_BITS 10000
Starting at 8192 Bit key sizes, the key generation time curve starts to go up drastically. The table below has real-world example times for comparison.
| Key creation time | ||||||
|---|---|---|---|---|---|---|
| Key Type | 512 Bit | 1024 Bit | 2048 Bit | 4096 Bit | 8192 Bit | 16384 Bit | RSA | 0m0.017s | 0m0.068s | 0m0.563s | 0m5.938s | 0m38.656s | 13m3.483s |
| DSA | 0m0.067s | 0m0.624s | 02.794s | 1m2.543s | 4m22.650s | 78m44.624s |
1.3 Example Certificates using ECC keys, example 571 bit
In addition to RSA or DSA keys, certificates can work with Elliptic Curve Cryptography (ECC) keys. These keys are fairly cutting edge and rarely used yet. According to the strength rating in RFC 5480, one example certificate has been generated using one of the highest possible key sizes.
| Key Type | ECC Test Certificates | |||||
|---|---|---|---|---|---|---|
| Certificate | Cert Request | ECC Key Pair | ||||
| sect571r1 | 570 ECC cert DER Format 610 bytes |
570 ECC cert PEM Format 883 bytes |
570 ECC csr DER Format 424 bytes |
570 ECC csr PEM Format 647 bytes |
570 ECC key DER Format 241 bytes |
570 ECC key PEM Format 390 bytes |
1.4 Example Certificates with key sizes not aligned to boundaries (i.e. 999bit)
Finally, the key length does not necessarily match the typical hex-boundaries (512, 1024, 2048, etc), but can have any size in bits within the valid range. For example, here is a certificate with a "evil" key length of 999bit:
| Key Size | RSA Test Certificates | |||||
|---|---|---|---|---|---|---|
| Certificate | Cert Request | RSA Key Pair | ||||
| 999 Bit | 999 RSA cert DER Format 598 bytes |
999 RSA cert PEM Format 867 bytes |
999 RSA csr DER Format 389 bytes |
999 RSA csr PEM Format 599 bytes |
999 RSA key DER Format 591 bytes |
999 RSA key PEM Format 683 bytes |
1.5 Example PKCS12 Certificate Bundles
OpenSSL PKCS12 creation examples without signing cert (password: test)
2. Example Certificates with variations in validity: problematic start and end dates
Overflow of 32bit system time in start and end dates
The following example cert has its date created on a 32-bit system, demonstrating the upcoming "Year 2038" problem. The 32bit integer defined as the Unix base time is counting the seconds since January 1, 1970. This system-wide counter is to small, and going to overflow on a wide range of systems in operation today.
Download: PEM Format.
The overflow result is a certificate start time dating to 1901, while the expiration is set to 03:14:07 UTC on Tuesday, 19 January 2038.
Historic, implausible dates in X509 certificates
The following example cert has its dates set to match the birth and dead of Napoleon Bonaparte, Emperor of France. This example shows that certificates can carry implausible date values going back for centuries.
Download: PEM Format.
If used as a client certificate, it could potentially trouble apps.
Maximum Date Range in X509 certificates
The next certificate is the currently maximum achievable: It is valid from the year zero until the year 9999, spanning ten thousand years of history. It was valid when Jesus was approx. two years old, and will still be valid until we reach the Year 10,000 problem (deca-millennium bug), if our race makes it that far. This certificate will become important for time-travellers e-passports.
Download: 9999-years-rsa-cert.pem.
# openssl x509 -in source/PEM/certs/9999-years-rsa-cert.pem -noout -startdate -enddate notBefore=Jan 1 00:00:01 0 GMT notAfter=Dec 31 23:59:59 9999 GMT
Most current operating systems will be troubled when they see this cert, here is an example screenshot from Windows 7.
It is sensible to restrict certificate validity values to a small, plausible date range, i.e. between 1970 and the year 2100 (unless we need to worry about the 2038 problem mentioned above).
Java clearly has a problem correctly displaying the start date. Keytool imports the certificate into the keystore without a complaint, trying to convert GMT time into local time. Amazingly, the end date rolls over nicely to the year 10000:
C:\>"Program Files\Java\jdk1.7.0_09\jre\bin\keytool.exe" -import -trustcacerts -alias 9999-years -file 9999-years-rsa-cert.cer -keystore keystore.jks
Enter keystore password:
Owner: CN=www.frank4dd.com, EMAILADDRESS=public@frank4dd.com, OU=Support, O=Frank4DD, ST=Tokyo, C=JP
Issuer: EMAILADDRESS=support@frank4dd.com, CN=Frank4DD Web CA, OU=WebCert Support, O=Frank4DD, L=Chuo-ku, ST=Tokyo, C=JP
Serial number: e1e
Valid from: Sat Jan 03 09:00:01 JST 1 until: Sat Jan 01 08:59:59 JST 10000
Certificate fingerprints:
MD5: 00:3F:5B:4C:EC:0D:C0:3D:E5:D8:1F:8D:E1:5E:31:A8
SHA1: DB:17:BE:A4:42:88:20:03:C1:31:34:02:B2:49:47:62:0F:54:D5:E0
SHA256: 35:39:2E:95:3F:83:71:2A:D1:49:EB:EA:65:DD:BA:6A:AD:03:0B:3F:18:6C:E1:46:8C:A5:6C:F8:4C:69:BB:8C
Signature algorithm name: SHA1withRSA
Version: 3
Extensions:
...
3. Example Certificates with "challenging" subjects
Embedding HTML code in CN
This certificate, found here demonstrates embedding malicious HTML code in its subject. Here is a example screenshot of the unintented side effects this can have.
Download (local copy):
embedded-html-cert.pem (1253 Bytes)
embedded-html-key.pem (887 Bytes)
4. Example Certificates with "challenging" extensions
Large number of Subject Alternate Name extension entries
The left certificate is a real one. Google is rolling out a new, single certificate for all its domains.
There, they managed to squeeze 458 DNS entries (list) into the Subject Alternate Name extension. It doesn't seem to create any issues, Windows is faithfully displaying all entries and the web site validates. The algorithm which checks if the web site's DNS name matches the certificate will be taxed, but it should not be a problem.
Download: google_jp_458san.pem
(9800 Bytes).
The certificate can be seen live in action under https://www.google.jp. Attention: catch it before the HTTP 302 redirect kicks in and moves over to www.google.co.jp, which does not have this cool certificate.
