5
X.509 Certificates
In this chapter we will describe how to set up Openswan to use X.509 Certificates. We will cover the concepts and properties of X.509, and study some examples of how to use the openssl command to generate, sign, and revoke X.509 Certificates. This chapter is focused on Linux; refer to later chapters for information on setting up X.509 on Microsoft Windows, Mac OS X, and other platforms.
In the previous chapter, we looked at how to set up a specific IPsec connection for a specific user or configuration. But of course setting up an IPsec connection for each individual user does not scale. We want to be able to set up just one tunnel endpoint on our VPN server, while easily handing out (and retracting!) different VPN credentials to our individual users. The most common way of doing this relies on X.509 Certificates.
X.509 Certificates Explained
A certificate is more than just an RSA key for authentication. Additionally, there is a unique serial number for easy referencing and an identity, which can be a person, computer, or group. The certificate binds the identity to the RSA key. Certificates also contain a time period for which this binding is considered valid. They can even contain information on where to verify the certificate. Finally, a purpose or group limitation can be included in the certificate.
A certificate is given out by an issuer. To prevent forgery, the entire certificate is protected by a cryptographic signature. Certificates enable us to:
•Hand out digitally signed identities for hosts and users
•Set a duration for the validity of the credentials (begin and end time)
•Revoke an identity
•Create a hierarchical structure for decision making (such as access restrictions)
•Manage large numbers of identities
•Delegate the management of these identities hierarchically
•Set up trust relationships between two parties who have never met
X.509 Certificates
You can think of a certificate as a passport. Both are issued by a known and trusted party, they are resistant to forgery due to various protection measures, they are bound to a single person and are useless for anyone else, and they both have limited lifespans. Those who value a passport do so on the trust they put in the issuer of the passport, in much the same way as for certificates.
X.509 Objects
X.509 is a standard for writing these kinds of relationships. X.509 is based on designs that are older than the IP protocol itself, being created in the era of leased lines and the X.25 protocol. Those familiar with LDAP, NDIS, or SSL certificates will find all this very familiar, as those standards also go back to the days of X.25. These standards use a hierarchical system of categorizing objects, sometimes referred to as trees and forests.
What we see is that the topmost node, the Root, is the same for everyone. In our example we have two organizations A and B, each having two departments A and B, and so forth. It is important to realize that in order to refer to one specific object, you need to do so in terms of the hierarchical relation, that is in terms of the object's parent, the parent's parent, and so forth.
For example, User A from Department B is not necessarily the same object as User A from Department A. These descriptions are called Relative Distinguished Named (RDNs). A full description of an object fully from top to bottom is a Distinguished Name (DN). A DN is written as a list of RDNs separated by commas (,) or slashes (/).
The following table lists the X.509 RDNs supported by Openswan:
Relative Distinguished Name |
Meaning |
|
|
DC |
Domain Component |
C |
Country |
ST |
State or province |
|
|
110
Chapter 5
Relative Distinguished Name |
Meaning |
|
|
L |
Locality or town |
O |
Organization |
OU |
Organizational Unit |
CN |
Common Name |
ND |
Name Distinguisher, used with CN |
N |
Name |
G |
Given name |
S |
Surname |
I |
Initials |
T |
Personal Title |
E, Email, or emailAddress |
Email address |
SN or serialNumber |
Serial Number |
D |
Description |
UID |
User ID |
ID |
X.500 Unique Identifier |
TCGID [Siemens] |
Trust Center Global ID |
|
|
The most commonly used RDNs are C, ST, L, O, OU, CN, and E (or one of its alternatives). An example DN is:
C=Ca, ST=Ontario, L=Toronto, O=Xelerance, OU=Support Staff, CN=Naomi Rae,
E=support@xelerance.com
Due to the various different implementations of X.509 and character sets and representations, you should avoid using any international characters or any character that commonly changes location between keyboards.
We recommend use of only alphanumeric characters, spaces, and the minus character in Distinguished Names. A commonly chosen OU= value is 'R&D', which fails to work when trying to use Openswan with certain Windows IPsec clients.
111
X.509 Certificates
X.509 Packing
X.509 Certificates are written in a specific machine-parsable way called Abstract Syntax Notation One (ASN.1). This is then wrapped in a specific format such as the Public-Key Cryptography Standards (PKCS) of which there are various versions.
Because people wanted to be able to use more than just ASCII characters (and because some old network connections were not even 8-bit clean and could not even safely transport ASCII), these ASN.1 notations are packed in either the binary DER format, or in the base-64 PEM format. The DER format is used in OpenLDAP, but the PEM format is commonly used for SSL/HTTPS certificates for websites. Openswan detects the type of packing used, so you can use both formats interchangeably, though it is recommended to stick to PEM encoding. We will use PEM in all our examples.
Types of Certificates
Certificates with different purposes are also named differently. To make things more confusing, some vendors give these certificates or certificate containers different names. The most commonly known X.509 Certificates are those used in web servers and web browsers. Web servers obtain signed X.509 Certificates from a commonly known and trusted source. In practice this means from companies like Verisign / Thawte, but it could easily be your own Certificates R Us-generated certificate. Another example is the non-profit organization, CAcert.org. Browser manufacturers, such as Microsoft, Apple, or the Mozilla Foundation, supply their software with certificates for these organizations already built in, and the software will trust certificates signed by those authorities, also called Certificate Authorities (CAs).
Certificate Type |
Description |
|
|
Certificate Authority (CA) |
The start of a trust chain. The CA is the only certificate that signs itself. |
(Trusted) Root certificate |
Another name for a CA certificate. |
Intermediate Certificate Authorities |
A CA that is not signed by itself but by another (parent) CA. |
CSR Certificate |
Certificate Signing Request. This is a certificate generated by a person, |
|
with an embedded request to sign. This request is then given to a CA to |
|
be signed. |
Host (Local Computer) certificate |
Certificate issued for a machine (usually signed by a CA). |
User (Personal) certificate |
Certificate issued for a person (usually signed by a CA). |
Private Key |
Private key file belonging to a public key of a .pem file. Can be pass- |
|
phrase protected. |
PKCS#12 (.pl file) |
Certificate plus private key issued and signed by a CA. Normally pass- |
|
phrase protected. |
PKCS#15 |
Certificate standard for Cryptographic Tokens (for instance, USB crypto |
|
tokens). Usually PIN protected. Sometimes multilevel PINs differentiate |
|
user and admin access. |
CRL |
Certificate Revocation List, a list of revoked serial numbers of issued certificates. |
|
|
112 |
|