X.509 certificates are digital documents that represent a user, computer, service, or device. They are issued by a certification authority (CA), subordinate CA, or registration authority and contain the public key of the certificate subject. They do not contain the subject's private key which must be stored securely. Deserialize a certificate revocation list (CRL) from PEM encoded data. PEM requests are base64 decoded and have delimiters that look like -BEGIN X509 CRL-. In cryptography, X.509 is a standard defining the format of public key certificates. X.509 certificates are used in many Internet protocols, including TLS/SSL, which is the basis for HTTPS, the secure protocol for browsing the web.

Openssl x509 -in cert.der -out cert.pem You can also use similar commands to convert PEM files to these different types of files as well. Furthermore, there are additional parameters you can specify in your command — such as -inform and -outform — but the above. $ openssl req -x509 -sha256 -days 365 -newkey rsa:4096 -keyout private.pem -out public.pem. I keep my private key very safe. I send you my public key: public.pem file (sometimes the naming convention in examples is certificate.pem). I sign my text file (in this example it’s a string as the text parameter).

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.

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:

Pem

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 SizeRSA Test Certificates
CertificateCert RequestRSA Key Pair
512 Bit512 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 Bit1024 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 Bit2048 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 Bit4096 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 Bit8192 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 Bit16k 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 Bit32k 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
18877 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: per 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 SizeDSA Test Certificates
CertificateCert RequestDSA Key Pair
512 Bit512 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 Bit1024 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 Bit2048 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 Bit4096 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 Bit8192 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
3139 bytes
8192 DSA key
PEM Format
7196 bytes
16348 Bit16k 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:

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 Type512 Bit1024 Bit2048 Bit4096 Bit8192 Bit16384 Bit
RSA0m0.017s0m0.068s0m0.563s0m5.938s0m38.656s13m3.483s
DSA0m0.067s0m0.624s02.794s1m2.543s4m22.650s78m44.624s

1.3 Example Certificates using ECC keys, example 570 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 TypeECC Test Certificates
CertificateCert RequestECC Key Pair
sect571r1570 ECC cert
DER Format
3563 bytes
570 ECC cert
PEM Format
4881 bytes
570 ECC csr
DER Format
3298 bytes
570 ECC csr
PEM Format
4539 bytes
570 ECC key
DER Format
3139 bytes
570 ECC key
PEM Format
7196 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 SizeRSA Test Certificates
CertificateCert RequestRSA Key Pair
999 Bit999 RSA cert
DER Format
867 bytes
999 RSA cert
PEM Format
598 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.

Pem_read_bio_x509

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.

X509 Pem Encoded Certificate

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.

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:

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.

I was really confused about all those acronyms when I started digging into OpenSSL and RFCs. So here's a no bullshit quick intro to them.

Or Public-Key Crypto Standard number 7. It's just a guideline, set of rules, on how to send messages, sign messages, etc.. There are a bunch of PKCS that tells you exactly how to do stuff using crypto. PKCS#7 is the one who tells you how to sign and encrypt messages using certificates.If you ever see 'pkcs#7 padding', it just refers to the padding explained in pkcs#7.

In a lot of things in the world (I'm being very vague), we use certificates. For example each person can have a certificate, and each person's certificate can be signed by the government certificate. So if you want to verify that this person is really the person he pretends to be, you can check his certificate and check if the government signature on his certificate is valid.

TLS use x509 certificates to authenticate servers. If you go on https://www.facebook.com, you will first check their certificate, see who signed it, checked the signer's certificate, and on and on until you end up with a certificate you can trust. And then! And only then, you will encrypt your session.

So x509 certificates are just objects with the name of the server, the name of who signed his certificate, the signature, etc..

Example from wikipedia:

So, how should we write our certificate in a computer format? There are a billion ways of formating a document and if we don't agree on one then we will never be able to ask a computer to parse a x509 certificate.

That's what ASN.1 is for, it tells you exactly how you should write your object/certificate

ASN.1 defines the abstract syntax of information but does not restrict the way the information is encoded. Various ASN.1 encoding rules provide the transfer syntax (a concrete representation) of the data values whose abstract syntax is described in ASN.1.

Now to encode our ASN.1 object we can use a bunch of different encodings specified in ASN.1, the most common one being used in TLS is DER

Pem X509 Quick

DER is a TLV kind of encoding, meaning you first write the Tag (for example, 'serial number'), and then the Length of the following value, and then the Value (in our example, the serial number).

DER is also more than that:

DER is intended for situations when a unique encoding is needed, such as in cryptography, and ensures that a data structure that needs to be digitally signed produces a unique serialized representation.

Openssl X509 Dates

So there is only one way to write a DER document, you can't re-order the elements.

And a made up example for an ASN.1 object:

And its DER encoding:

Base64 is just a way of writing binary data in a string, so you can pass it to someone on facebook messenger for exemple

From the openssl Wiki:

And if you see any equal sign =, it's for padding.

So if the first 6 bits of your file is '01' in base 10, then you will write that as B in plaintext. See an example if you still have no idea about what I'm talking about.

Openssl X509 Example

A pem file is just two comments (that are very important) and the data in base64 in the middle. For example the pem file of an encrypted private key:

Openssl X509 Pem

And yes the number of - are important

FBs-40MA-B, FBs-60MA-B, Unlock Crack PLC Fatek FBs series Hotline: ( 84) 932.690.218 Email: unlockplc123gmail.com a ch: H Ni Xem thm chi tit ti Website. Fatek Plc Password Khng Nu. Nu bc s dng phn mm th bc c bn phn mm ph password khng nu bn th gi c th no. Fatek FBs series tt c cc Version OS 4.0 hay 4.6. Program Project Password, Program ID, Sub. Siemens: S7-200 Project Password Fatek: FBe, FBs Project Password Pro-face: GP Project Password (File type: prx &prn) FUJI-Hakko: U2,U3,V4,V5,V6,V7 Project Password FUJI-Hakko: CF Card Password Weintek: Crack Xob file Hiteck: V6 Project Password. Siemens: S7-200 Project Password Fatek: FBe, FBs Project Password Pro-face: GP Project Password (File format is Prx &Prn) FUJI-Hakko: U2,U3,V4,V5,V6,V7 Project Password FUJI-Hakko HMI: CF Card Password & Scan port Weintek HMI: Decompile to Xob file Hi-Tech HMI: V6 & V8 Project Password. Discover a way to Unlock PLC password in five Minutes. Plc