Certificates
Q: What is a certificate ?
A: A document attesting to the truth of certain stated facts.
Q: What is a digital certificate ?
A: An electronic document which confirms someone's identity.
Other names you can find for digital certificates are:
- Public key certificates
- Identity certificates
- Electronic certificates
- ...
The first alternative name listed above is especially interesting, since it uncovers how the identity represented by the certificate can be confirmed - by using a public key. More precisely beside the information representing the identity (e.g. name, address, etc.) the certificate stores a signature that can be then validated by using the public key counterpart of the private key by which the signature was made.
X.509 is a standard covering whole bunch of security related issues, among which is the structure of the digital certificate (X.509 v3):
- 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
Subject is the person or the entity (e.g. company, web server, etc.) to be identified by the certificate. The certificate also includes the public key of the identified subject, which then can be used for validating subject's signatures and encrypting the messages sent to the subject (e.g. SSL).
Obviously you need a way to ensure that the entity which identifies itself by the certificate is really the one certified by this certificate. This is where the issuer comes in. Much as the university stands behind a university degree certificate, the entity represented by the issuer field stands behind the digital certificate, i.e. it is the entity that verified the subject's data and have issued the certificate.
It is crucial when confirming the identity of some certified entity, not to check the subject's data only, but also to confirm that this data have been confirmed and the certificate have been issued by a trusted issuer.
The validation dates include the period for which this certificate us issued to the subject, that is the period for which the issuer guarantees for the certified identity.
Finally the certificate signature guarantees that the certificate has not been modified since the issuer signed the certificate.
A more popular name for the issuer is certificate authority, or CA. The later is mostly used when discussing about the entity that issued the certificate, while the term issuer is used mostly to refer to the appropriate filed in the certificate.
Example (taken from Wikipedia):
This is an example of a decoded X.509 certificate for www.freesoft.org, generated with OpenSSL -- the actual certificate is about 1KB in size. It was issued by Thawte (since acquired by VeriSign), as stated in the Issuer field. Its subject contains many personal details, but the most important part is usually the common name (CN), as this is the part that must match the host being authenticated. Also included is an RSA public key (modulus and public exponent), followed by the signature, computed by taking a MD5 hash of the first part of the certificate and signing it (applying the encryption operation) using Thawte's RSA private key.
Certificate:
Data:
Version: 1 (0x0)
Serial Number: 7829 (0x1e95)
Signature Algorithm: md5WithRSAEncryption
Issuer: C=ZA, ST=Western Cape, L=Cape Town, O=Thawte Consulting cc,
OU=Certification Services Division,
CN=Thawte Server CA/emailAddress=server-certs@thawte.com
Validity
Not Before: Jul 9 16:04:02 1998 GMT
Not After : Jul 9 16:04:02 1999 GMT
Subject: C=US, ST=Maryland, L=Pasadena, O=Brent Baccala,
OU=FreeSoft, CN=www.freesoft.org/emailAddress=baccala@freesoft.org
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (1024 bit)
Modulus (1024 bit):
00:b4:31:98:0a:c4:bc:62:c1:88:aa:dc:b0:c8:bb:
33:35:19:d5:0c:64:b9:3d:41:b2:96:fc:f3:31:e1:
66:36:d0:8e:56:12:44:ba:75:eb:e8:1c:9c:5b:66:
70:33:52:14:c9:ec:4f:91:51:70:39:de:53:85:17:
16:94:6e:ee:f4:d5:6f:d5:ca:b3:47:5e:1b:0c:7b:
c5:cc:2b:6b:c1:90:c3:16:31:0d:bf:7a:c7:47:77:
8f:a0:21:c7:4c:d0:16:65:00:c1:0f:d7:b8:80:e3:
d2:75:6b:c1:ea:9e:5c:5c:ea:7d:c1:a1:10:bc:b8:
e8:35:1c:9e:27:52:7e:41:8f
Exponent: 65537 (0x10001)
Signature Algorithm: md5WithRSAEncryption
93:5f:8f:5f:c5:af:bf:0a:ab:a5:6d:fb:24:5f:b6:59:5d:9d:
92:2e:4a:1b:8b:ac:7d:99:17:5d:cd:19:f6:ad:ef:63:2f:92:
ab:2f:4b:cf:0a:13:90:ee:2c:0e:43:03:be:f6:ea:8e:9c:67:
d0:a2:40:03:f7:ef:6a:15:09:79:a9:46:ed:b7:16:1b:41:72:
0d:19:aa:ad:dd:9a:df:ab:97:50:65:f5:5e:85:a6:ef:19:d1:
5a:de:9d:ea:63:cd:cb:cc:6d:5d:01:85:b5:6d:c8:f3:d9:f7:
8f:0e:fc:ba:1f:34:e9:96:6e:6c:cf:f2:ef:9b:bf:de:b5:22:
68:9f
To validate this certificate, one needs a second certificate that matches the Issuer (Thawte Server CA) of the first certificate. First, one verifies that the second certificate is of a CA kind; that is, that it can be used to issue other certificates. This is done by inspecting a value of the CA attribute in the X509v3 extension section. Then the RSA public key from the CA certificate is used to decode the signature on the first certificate to obtain a MD5 hash, which must match an actual MD5 hash computed over the rest of the certificate. An example CA certificate follows:
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/emailAddress=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/emailAddress=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, or root certificate, as the issuer and subject are the same. There's no way to verify this certificate except by checking it against itself; instead, these top-level certificates are manually stored by web browsers. Thawte is one of the root certificate authorities recognized by both Microsoft and Netscape. This certificate comes with the web browser and is trusted by default. As a long-lived, globally trusted certificate that can sign anything (as there are no constraints in the X509v3 Basic Constraints section), its matching private key has to be closely guarded.
If the certificate includes all of the certificates leading back to the root certificate we would say that the certificate includes the complete certificate chain.
If the certificate includes all of the certificates leading back to the root certificate we would say that the certificate includes the complete certificate chain.
Keystores
From Wikipedia:
"A keystore is a repository of security certificates ..."
Although keystore is mostly used to refer to the Java key repository, I will use the term as a general name for a bigger spectrum of file formats which allow secure storing of keys and certificates. Other popular name that you might find is keychain, which is mostly used when speaking about Apple's systems like Mac OS X and iOS.
PKCS12 is one of the most popular keystore standards, and if yours keystore is not coming from the Java world, it is most likely to be a PKCS12. Usually the .p12 file extension is used for this type of files.
JKS is the other most popular keystore standard. The 'J' in the name stands for Java, so if you are using the JDK you would be most likely working with this type of files. It is said to be a better structured and simpler format than the PKCS12, but it is closely bonded to the Java's keytool. If you are looking for a more general and language independent format then PKCS12 is what you should use.
Other formats that I am not particularly familiar with are:
- JCEKS
- PKCS11
- CMSKS
- IBMi5OSKeyStore
- JCERACFKS
- JCECCAKS
Certificate file formats and other mambo-jumbo you might need to deal with
Abstract Syntax Notation One, or ASN.1, is a standard notation for describing data structures . You can think of ASN.1 as the language (independent of the alphabet) used to describe data structures. Here is an example of a ASN.1 description for the RSA public key embedded in a X.509 PublicKeyInfo structure:
Distinguished Encoding Rules, or DER, is a message transfer syntax and is one of the most popular formats for writing certificate data. You can think of the DER as the alphabet used to write the data. Here is one RSA public key (embedded in PublicKeyInfo structure) written in DER:
Note that the example above is formated and commented for readability, otherwise it is plain array of bytes (30 81 9f 30 0d ... 01 00 01)
XML Encoding Rules, or XER, is a set of XML based rules for writing data described with ASN.1. The above key written in XER would look something like this:
BER and PER are two other encoding formats that I will omit from this post.
The last format we will describe here is PEM. The Privacy Enhanced Mail standard began as a proposal for securing emails using public keys. Although the standard was never widely deployed, the file format for sharing the public key become very popular and is one of the most common formats you will find your certificates in.
The PEM formated certificate is basically a Base64 encoded DER certificate, enclosed between "-----BEGIN CERTIFICATE-----" and "-----END CERTIFICATE-----" tags.
PublicKeyInfo ::= SEQUENCE {
algorithm AlgorithmIdentifier,
PublicKey BIT STRING
}
AlgorithmIdentifier ::= SEQUENCE {
algorithm ALGORITHM.id,
parameters ALGORITHM.type OPTIONAL
}RSAPublicKey ::= SEQUENCE {
modulus INTEGER,
publicExponent INTEGER
}Distinguished Encoding Rules, or DER, is a message transfer syntax and is one of the most popular formats for writing certificate data. You can think of the DER as the alphabet used to write the data. Here is one RSA public key (embedded in PublicKeyInfo structure) written in DER:
XML Encoding Rules, or XER, is a set of XML based rules for writing data described with ASN.1. The above key written in XER would look something like this:
<PublicKeyInfo>
<AlgorithmIdentifier>
<algorithm>1.2..840.113549.1.1.1</algorithm>
<parameters></parameters>
</AlgorithmIdentifier>
<PublicKey>
<modus>8f e2 41 ... dc 90 65</modus>
<publicExponent>10 00 01</publicExponent>
</PublicKey>
</PublicKeyInfo>BER and PER are two other encoding formats that I will omit from this post.
The last format we will describe here is PEM. The Privacy Enhanced Mail standard began as a proposal for securing emails using public keys. Although the standard was never widely deployed, the file format for sharing the public key become very popular and is one of the most common formats you will find your certificates in.
The PEM formated certificate is basically a Base64 encoded DER certificate, enclosed between "-----BEGIN CERTIFICATE-----" and "-----END CERTIFICATE-----" tags.
