In cryptography, X.509 is an ITU-T standard for public key infrastructure
(PKI). X.509 specifies, among other things, standard formats for public
key certificates and a certification path validation algorithm.
X.509 was initially issued in 1988 and was begun in association with
the X.500 standard and assumed a strict hierarchical system of certificate
authorities (CAs) for issuing the certificates. This contrasts with web
of trust models, like PGP, where anyone (not just special CAs) may sign,
and thus attest to the validity of others' key certificates. Version 3
of X.509 includes the flexibility to support other topologies like bridges
and meshes. It can be used in a peer-to-peer, OpenPGP-like web of trust,
but is rarely used that way as of 2004. The X.500 system has never been
fully implemented, and the IETF's public-key infrastructure working group
has adapted the standard to the more flexible organization of the Internet.
In fact, the term X.509 certificate usually refers to the IETF's PKI Certificate
and CRL Profile of the X.509 v3 certificate standard, as specified in
RFC 3280, commonly referred to as PKIX.
Certificates
In the X.509 system, a CA issues a certificate binding a public key to
a particular Distinguished Name in the X.500 tradition, or to an Alternative
Name such as an e-mail address or a DNS-entry.
An organisation's trusted root certificates can be distributed to all
employees so that they can use the company PKI system. Browsers such as
Internet Explorer, Netscape/Mozilla and Opera come with root certificates
pre-installed, so SSL certificates from larger vendors who have paid for
the privilege of being pre-installed will work instantly; in essence the
browser's owners determine which CAs are trusted third parties. Whilst
these root certificates can be removed or disabled, users rarely do so.
X.509 also includes standards for certificate revocation list (CRL) implementations,
an often neglected aspect of PKI systems. The IETF-approved way of checking
a certificate's validity is the Online Certificate Status Protocol (OCSP).
Structure of a certificate
The structure of a X.509 v3 digital certificate is as follows:
Certificate Version Serial Number Algorithm ID Issuer Validity Not Before
Not After Subject Subject Public Key Info Public Key Algorithm Subject
Public Key Issuer Unique Identifier (Optional) Subject Unique Identifier
(Optional) Extensions (Optional) ... Certificate Signature Algorithm Certificate
Signature Issuer and subject unique identifiers were introduced in Version
2, Extensions in Version 3.
Certificate file extensions
Common file extensions for X.509-certificates are:
.CER - CER encoded certificate, sometimes sequence of certificates
.DER - DER encoded certificate
.PEM - Base64 encoded certificate, enclosed between "-----BEGIN
CERTIFICATE-----" and "-----END CERTIFICATE-----"
.P7B - See .p7c
.P7C - PKCS#7 SignedData structure without data, just certificate(s)
or CRL(s)
.PFX - See p12
.P12 - PKCS#12, may contain certificate(s) (public) and private keys
(password protected)
PKCS #7
is a standard for signing or encrypting (they call
it "enveloping") data. Since the certificate is needed to
verify signed data, it is possible to include them in the SignedData
structure. A .P7C-file is just a degenerated SignedData structure,
without any data to sign.
Used by Adobe Acrobat PDF's upto version 5.0
PKCS #12
evolved from the PFX (Personal inFormation eXchange) standard and
is used to exchange public and private objects in a single file. This
is the type of certificate commonly used for digitally signing PDF
files.
Used by Adobe Acrobat PDF's starting with version 6.0
A .PEM-file may contain certificate(s) or private key(s), enclosed between
the appropriate BEGIN/END-lines.
Sample X.509 certificates
As an example of an X.509 certificate, here's a decode (generated with
openssl) of one of www.freesoft.org's old certificates; the actual certificate
is about 1KB in size. It was issued (signed) by Thawte (since acquired
by Verisign), as stated in its Issuer field. Its subject contains a lot
of personal information, but the most important part is the common name
(CN) of www.freesoft.org - this is the part that must match the host being
authenticated. Next comes an RSA public key (modulus and public exponent),
followed by the signature, computed by taking an MD5 hash of the first
part of the certificate and encrypting it with Thawte's RSA private key.
To validate this certificate, we need another certificate, one that matches
the Issuer (Thawte Server CA) in the first certificate. Then we take the
RSA public key from the second (CA) certificate, use it to decode the
signature on the first certificate to obtain an MD5 hash, which must match
an actual MD5 hash computed over the rest of the certificate.
Here's the CA cert:
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 1 (0x1)
Signature Algorithm: md5WithRSAEncryption
Issuer: C=ZA, ST=Western Cape, L=Cape Town, O=Thawte Consulting cc,
OU=Certification Services Division,
CN=Thawte Server CA/Email=server-certs@thawte.com
Validity
Not Before: Aug 1 00:00:00 1996 GMT
Not After : Dec 31 23:59:59 2020 GMT
Subject: C=ZA, ST=Western Cape, L=Cape Town, O=Thawte Consulting cc,
OU=Certification Services Division,
CN=Thawte Server CA/Email=server-certs@thawte.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (1024 bit)
Modulus (1024 bit):
00:d3:a4:50:6e:c8:ff:56:6b:e6:cf:5d:b6:ea:0c:
68:75:47:a2:aa:c2:da:84:25:fc:a8:f4:47:51:da:
85:b5:20:74:94:86:1e:0f:75:c9:e9:08:61:f5:06:
6d:30:6e:15:19:02:e9:52:c0:62:db:4d:99:9e:e2:
6a:0c:44:38:cd:fe:be:e3:64:09:70:c5:fe:b1:6b:
29:b6:2f:49:c8:3b:d4:27:04:25:10:97:2f:e7:90:
6d:c0:28:42:99:d7:4c:43:de:c3:f5:21:6d:54:9f:
5d:c3:58:e1:c0:e4:d9:5b:b0:b8:dc:b4:7b:df:36:
3a:c2:b5:66:22:12:d6:87:0d
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Basic Constraints: critical
CA:TRUE
Signature Algorithm: md5WithRSAEncryption
07:fa:4c:69:5c:fb:95:cc:46:ee:85:83:4d:21:30:8e:ca:d9:
a8:6f:49:1a:e6:da:51:e3:60:70:6c:84:61:11:a1:1a:c8:48:
3e:59:43:7d:4f:95:3d:a1:8b:b7:0b:62:98:7a:75:8a:dd:88:
4e:4e:9e:40:db:a8:cc:32:74:b9:6f:0d:c6:e3:b3:44:0b:d9:
8a:6f:9a:29:9b:99:18:28:3b:d1:e3:40:28:9a:5a:3c:d5:b5:
e7:20:1b:8b:ca:a4:ab:8d:e9:51:d9:e2:4c:2c:59:a9:da:b9:
b2:75:1b:f6:42:f2:ef:c7:f2:18:f9:89:bc:a3:ff:8a:23:2e:
70:47
This is an example of a self-signed certificate; note that the issuer
and subject are the same. There's no way to verify this certificate except
by checking it against itself; we've reached the top of the certificate
chain. So how does this certificate become trusted? Simple - it's manually
configured. Thawte is one of the root certificate authorities recognized
by both Microsoft and Netscape. This certificate comes with the web browser
(you can probably find it listed as "Thawte Server CA" in the
security settings); it's trusted by default. As a long-lived (note the
expiration date), globally trusted certificate that can sign pretty much
anything (note the lack of any constraints), its matching private key
has to be one of the most closely guarded in the world.
Security
In 2005, Lenstra, Wang and de Weger published "two X.509 certificates
that contain identical signatures and that differ only in the public keys",
achieved using a collision attack on the MD5 hash function.
Certificate authority
Main article: Certificate authority A certificate authority or certification
authority (CA) is an entity which issues digital certificates for use
by other parties. It is an example of a trusted third party. CA's are
characteristic of many public key infrastructure (PKI) schemes.
There are many commercial CAs that charge for their services. Institutions
and governments may have their own CAs, and there are free CAs.
References
ITU-T Recommendation X.509 (1997 E): Information Technology - Open
Systems Interconnection - The Directory: Authentication Framework, June
1997.
Housley, R., W. Ford, W. Polk and D. Solo, "Internet X.509 Public
Key Infrastructure: Certificate and CRL Profile", RFC 2459, January
1999.
Housley, R., W. Ford, W. Polk and D. Solo, "Internet X.509 Public
Key Infrastructure: Certificate and CRL Profile", RFC 3280, April
2002.
Arjen Lenstra, Xiaoyun Wang and Benne de Weger, On the possibility
of constructing meaningful hash collisions for public keys, full version,
with an appendix on colliding X.509 certificates, 2005
See also
Digital Certificate
Digital Signature
Public Key
Public Key Infrastructure (PKI)
Certificate Authority
Pretty Good Privacy (PGP)
Certificate Policy
Online Certificate Status Protocol (OCSP)
Certificate Revocation List (CRL)
Protocols and Standards supporting
X.509 certificates
Transport Layer Security (SSL/TLS)
Secure Multipurpose Internet Mail Extensions (S/MIME)
IPSec
SSH
Smartcard
HTTPS
EAP
LDAPv3
Trusted Computing Group (TNC TPM NGSCB)
CableLabs (North American Cable Industry Technology Forum)
