Crypto Basics

A Digital Certificate is an electronic credential for the Internet. It is similar to a driver’s license, employee ID card, or business license. Sometimes known as a Digital ID it may be issued either internally or externally by a trusted third party to establish the identity of the ID holder. The system that issues the Digital ID is known as a Certification Authority (CA). Commercial certificate authorities are often called CSPs – certificate service providers. Digital certificates are digitally signed by the issuing CA to prove their authenticity and detect any tampering. As the digital certificate is itself protected it can be transferred between users by any means (e.g. emails or online directories). Digital Certificates rely on public key cryptography. In such systems every entity has two special keys - a public key and a private key. These function as processing pairs to provide signature and encryption functionality. Public keys are widely distributed to users in the form of digital certificates, while private keys are kept safe and should only be used by their owner. Any data signed with a private key can be successfully verified only with the matching public key. Another way to look at this is that data that is successfully verified using the public key (usually sent with the digital signature) can only have been digitally signed using the corresponding private key - thus authenticating the data and showing that is mathematically infeasible for the data to have been tampered with.

The need for a Digital Certificate

Take the case of Alice sending a message to Bob. Bob has no way of checking whether the public key he receives belongs to Alice. Until Bob knows this reliably then he could be sent spoof or fraudulent messages pretending to be from Alice. The purpose of a certificate is to reliably and undeniably link a public key with its owner’s identity. When a CA signs a public key and issues a certificate, it verifies that the owner is not claiming a false identity. This is one area where the CAs vary – some just check that your specified email address works and others require stronger measures including face to face registration, presentation of paper credentials, signed, witnessed agreements, the use of hardware protection for the private key, etc. Just as when a government issues you a passport it is officially vouching for the fact that you are who you say you are, when a CA issues you a Digital ID, it is putting its name behind the statement that you are the rightful owner of your public/private key pair. The CA digitally signs the certificate using its own private key to protect its authenticity. A certificate is valid only for the period of time specified within it. The certificate contains information about its start and expiration dates. A CA can generally revoke (cancel) any certificate it has issued and maintains a list of revoked certificates. The reason for this may be that the details within the certificate have changed e.g. name changes or role changes, or as a result of they key being lost or compromised. This list of revoked IDs, called a Certificate Revocation List (CRL), is published by the CA so that anyone (or those allowed to) can check if the certificate has been identified as being revoked. Note: Microsoft pre-bundles its Operating System with many trusted Certification Authority certificates. In order to view them open Internet Explorer >> Tools >> Internet Option>> Content and click Certificate button. Other browsers also come pre-bundled with well-known CAs. It is a decision of the relying party who receives a digital certificate to determine which CAs he or she wishes to trust as issuer of certificates.

Contents of a Certificate

The contents of certificates supported by Microsoft and many other software companies are organized according to the X.509 v3 certificate specification, which has been recommended by the International Telecommunications Union (ITU), an international standards body, since 1988. Users don't usually need to be concerned about the exact contents of a certificate. However, system administrators working with certificates may need some familiarity with the information provided here.

Distinguished Names

An X.509 v3 certificate binds a distinguished name (DN) of the owner to their public key. A DN is a series of name-value pairs, such as uid=joe, that uniquely identify an entity that is, the certificate subject. For example, this might be a typical DN for an employee of Acme Limited uid=joe,e=joe@acme.com,cn=joe,o=Acme Limited,c=GB The abbreviations before each equal sign in this example have these meanings:

• uid: user ID
• e: email address
• cn: the user's common name
• o: organization
• c: country

DNs may include a variety of other name-value pairs. They are used to identify both certificate subjects and entries in directories that support the Lightweight Directory Access Protocol (LDAP). Note digital certificates may be issued to individuals, roles, organisations or IT devices. Many internet protocols like SSL, S/MIME, IPSEC etc. rely on digital certificates.

Typical Certificate

Every X.509 certificate consists of two sections: The data section includes the following information:

• The version number of the X.509 standard supported by the certificate.
• The certificate's serial number. Every certificate issued by a CA has a serial number that is unique among the certificates issued by that CA.
• Information about the user's public key, including the algorithm used and a representation of the key itself.
• The DN of the CA that issued the certificate.
• The period during which the certificate is valid (for example, between 1:00 p.m. on January 15, 2008 and 1:00 p.m. January 14, 2010)
• The DN of the certificate subject (for example, in a client SSL certificate this would be the user's DN), also called the subject name.
• Optional certificate extensions, which may provide additional data used by the client or server. For example, the certificate type extension indicates the type of certificate--that is, whether it is a client SSL certificate, a server SSL certificate, a certificate for signing email, and so on. Certificate extensions can also be used for a variety of other purposes.

The signature section includes the following information:

• The cryptographic algorithm, or cipher, used by the issuing CA to create its own digital signature.
• The CA's digital signature, obtained by hashing all of the data in the certificate together and encrypting it with the CA's private key.

Here are the data and signature sections of a certificate in human-readable format: Certificate: Data: Version: v3 (0x2) Serial Number: 3 (0x3) Signature Algorithm: PKCS #1 MD5 With RSA Encryption Issuer: OU=Ace Certificate Authority, O=Ace Industry, C=US Validity: Not Before: Fri Oct 17 18:36:25 2003 Not After: Sun Oct 17 18:36:25 2004 Subject: CN=Joe, OU=Finance, O=Tech Industry, C=US Subject Public Key Info: Algorithm: PKCS #1 RSA Encryption Public Key: Modulus: 00:ca:fa:79:98:8f:19:f8:d7:de:e4:49:80:48:e6:2a:2a:86:ed:27:40:4d:86:b3:05:c0:01:bb:50:15:c 9:de:dc:85:19:22:43:7d:45:6d:71:4e:17:3d:f0:36:4b:5b:7f:a8:51:a3:a1:00:98:ce:7f:47:50:2c:93 :36:7c:01:6e:cb:89:06:41:72:b5:e9:73:49:38:76:ef:b6:8f:ac:49:bb:63:0f:9b:ff:16:2a:e3:0e:9d:3 b:af:ce:9a:3e:48:65:de:96:61:d5:0a:11:2a:a2:80:b0:7d:d8:99:cb:0c:99:34:c9:ab:25:06:a8:31:a d:8c:4b:aa:54:91:f4:15 Public Exponent: 65537 (0x10001) Extensions: Identifier: Certificate Type Critical: no Certified Usage: SSL Client Identifier: Authority Key Identifier Critical: no Key Identifier: f2:f2:06:59:90:18:47:51:f5:89:33:5a:31:7a:e6:5c:fb:36: 26:c9 Signature: Algorithm: PKCS #1 MD5 With RSA Encryption Signature: 6d:23:af:f3:d3:b6:7a:df:90:df:cd:7e:18:6c:01:69:8e:54:65:fc:06: 30:43:34:d1:63:1f:06:7d:c3:40:a8:2a:82:c1:a4:83:2a:fb:2e:8f:fb: f0:6d:ff:75:a3:78:f7:52:47:46:62:97:1d:d9:c6:11:0a:02:a2:e0:cc: 2a:75:6c:8b:b6:9b:87:00:7d:7c:84:76:79:ba:f8:b4:d2:62:58:c3:c5: b6:c1:43:ac:63:44:42:fd:af:c8:0f:2f:38:85:6d:d6:59:e8:41:42:a5: 4a:e5:26:38:ff:32:78:a1:38:f1:ed:dc:0d:31:d1:b0:6d:67:e9:46:a8: dd:c4 Here is the same certificate displayed in the 64-byte-encoded form interpreted by software: -----BEGIN CERTIFICATE----- MIICKzCCAZSgAwIBAgIBAzANBgkqhkiG9w0BAQQFADA3MQswCQYDVQQGEwJVUzERM A8GA1UEChMITmV0c2NhcGUxFTATBgNVBAsTDFN1cHJpeWEncyBDQTAeFw05NzEwMT gwMTM2MjVaFw05OTEwMTgwMTM2MjVaMEgxCzAJBgNVBAYTAlVTMREwDwYDVQKEw hOZXRzY2FwZTENMAsGA1UECxMEUHViczEXMBUGA1UEAxMOU3Vwcml5YSBTaGV0dH kwgZ8wDQYJKoZIhvcNAQEFBQADgY0AMIGJAoGBAMr6eZiPGfjX3uRJgEjmKiqG7SdATYa zBcABu1AVyd7chRkiQ31FbXFOGD3wNktbf6hRo6EAmM5/R1AskzZ8AW7LiQZBcrXpc0k4du +2Q6xJu2MPm/8WKuMOnTuvzpo+SGXelmHVChEqooCwfdiZywyZNMmrJgaoMa2MS6pUkf QVAgMBAAGjNjA0MBEGCWCGSAGG+EIBAQQEAwIAgDAfBgNVHSMEGDAWgBTy8gZZk BhHUfWJM1oxeuZc+zYmyTANBgkqhkiG9w0BAQQFAAOBgQBtI6/z07Z635DfzX4XbAFpjlRl/ AYwQzTSYx8GfcNAqCqCwaSDKvsuj/vwbf91o3j3UkdGYpcd2cYRCgKi4MwqdWyLtpuHAH1 8hHZ5uvi00mJYw8W2wUOsY0RC/a/IDy84hW3WWehBUqVK5SY4/zJ4oTjx7dwNMdGwbWf pRqjd1A== -----END CERTIFICATE-----

CA Hierarchies

In large organizations, it may be appropriate to delegate the responsibility for issuing certificates to several different certificate authorities. For example, the number of certificates required may be too large for a single CA to maintain; different organizational units may have different policy requirements; or it may be important for a CA to be physically located in the same geographic area as the people to whom it is issuing certificates. It's possible to delegate certificate-issuing responsibilities to subordinate CAs. The X.509 standard includes a hierarchical model for setting up a hierarchy of CAs such as the example shown below: