Chapter Contents

Digital Certificates

Your digital certificate is a critical element of your Elektron configuration. Every Elektron installation requires a digital certificate so that the server can identify itself to wireless clients. This chapter introduces the concepts of digital certificates, including how they are constructed and how they protect your wireless network.

Your Server’s Digital Identity

The primary purpose of a digital certificate is to cryptographically bind a public key to a name. In layman’s terms, a digital certificate is a secure way for one computer to tell another computer “here’s who I am, and here’s my key.” Certificates allow a neutral third party, called a certificate authority (CA), to vouch for the identity of a user or computer by using their own digital certificate to sign the user or computer’s certificate.

The format and usage of digital certificates is defined by ITU-T Recommendation X.509 and further refined in IETF RFC 2459. If you are interested in the technical details of digital certificates, consult these references. The following description should suffice to get your Elektron server up and running securely.

Distinguished Names

Because the purpose of a digital certificate is to bind a public key to a name, there must be a way to encode names so that they can uniquely identify any person or computer on the planet. To solve this problem, the “distinguished name” was created by the developers of the X.500 series of technology standards. Distinguished names create a hierarchical tree of named objects using one or more of the following fields:

• Country This is the two-character ISO country code for the country in which the person or computer identified by the digital certificate is located, for example “US” for the United States or “CA” for Canada.
• State or Province The non-abbreviated name of the state or province where the certificate holder is located.
• Locality The locality is the third and final of the geographic identifiers. As the name suggests, it is the city in which the certificate holder is located.
• Organization If the certificate holder is part of a business, this is the business’ name. For educational users, the name of the educational institution.
• Organizational Unit This field is intended to designate the certificate holder’s department within the organization. In practice, many certificate authorities use this as a free-form field in which to place informational data.
• Common Name This is the final field which uniquely identifies the certificate holder within the organization. For a computer application, such as your Elektron server, this field will contain the DNS name of the computer, such as “machine.example.com”. If the certificate identifies a person, this will contain the person’s name, such as “Alice Smith”.

This naming scheme creates a hierarchical structure wherein each subsequent element of the name zeros-in on the specific object identified by the name, as in the figure below.

The concept of distinguished names should be familiar to LDAP users, since LDAP uses them to identify objects in the LDAP directory. Both LDAP and X.509 digital certificates like those used in Elektron trace their lineage back to the X.500 standards.

Distinguished names in their natural form are binary data encoded using Abstract Syntax Notation (ASN.1). For human consumption, distinguished names can be formatted as strings. In this case, each field is listed as an attribute-value pair, with the attribute name abbreviated to one or two characters, for example, “C=US, ST=California, L=Berkeley, O=Periodik Labs, CN=example.periodiklabs.com”.

Contents of a Digital Certificate

At its simplest, a digital certificate is nothing more than a data file, much like a word processing or spreadsheet file. Typically, digital certificates range from a few hundred to a few thousand bytes in length. There are a number of different ways a digital certificate can be stored as a file on disk, such a in binary form (using Distinguished Encoding Rules, or DER), as a PKCS#12 file, or most commonly as a text file (sometimes called “PEM encoding”). Elektron uses text files to import and export certificates, in order to ensure the widest compatibility with other digital certificate applications.

Inside each digital certificate are a number of different data fields, some of which are required and others which are optional. The contents of the certificate vary based on the identity of the certificate holder, the certificate authority that issued the certificate, as well as the version of the certificate. Digital certificates are available in two different versions: version 1 and version 3 (there was a version 2 defined, but it never made it into widespread usage). Elektron supports both digital certificate versions, although most Elektron installations will use only version 3 as that is the version required by most wireless clients. Here are the data fields present in a digital certificate:

• Serial Number Every digital certificate includes a serial number to uniquely identify it. When used in combination with the issuer name and an outside source such as a certificate revocation list (CRL) or and online certificate status protocol (OCSP) responder, the serial number can help determine the certificate’s current status. You should consult your client software documentation for information on configuring certificate status checking. Most small businesses will not require certificate status checking.
• Issuer Name Certificates are digitally signed by a certificate authority. The issuer name field contains the distinguished name of the CA, allowing applications to recreate certificate chains in order to validate a given certificate. For a discussion of validating certificate chains, see below.
• Validity Period Digital certificates have a time window during which they are valid. The validity period includes two dates: a “not valid before” date and a “not valid after” date. If a digital certificate is presented for validation outside these two dates, it should be rejected.
• Subject Name The subject name contains a distinguished name that identifies the holder of the digital certificate. The format of distinguished names is described above.
• Extensions These appear only in version 3 certificates. Extensions allow the certificate creator to insert data into the certificate that does not fit into the other fields. There are a wide variety of extensions defined for use, including extensions describing what cryptographic purposes a certificate may be used for, whether a certificate may be used as a certificate authority, and alternative names for the certificate’s subject. You should note that some wireless clients, most notably the WPA client included with Microsoft Windows XP, require specific extensions to be present in the server’s digital certificate. In the case of the Windows XP clients, an Extended Key Usage extension designated “server authentication” must be present or Windows will reject the certificate. Elektron will correctly create certificates for use with Windows XP clients, but if you choose to generate your own certificates using another application or use a third-party Certificate Authority, you will need to ensure that the certificate includes the necessary extensions.
• Public Key Traditional cryptographic systems have used what is called “symmetric cryptography”, in which a single key (such as a password) is used to encrypt data, and the same key is used to decrypt the data. Public key cryptography introduces the concept of “asymmetric cryptography”, where a pair of keys is used: one to encrypt, another to decrypt. Any data encrypted with one key may only be decrypted with its paired key. No other key can be used to decrypt the data, including the key that was used to encrypt the data. Of the two keys in the key pair, one is known as the public key, which is distributed to other users. The other key is known as the private key, and is maintained securely by the key pair’s owner. Public key cryptography enables a number of solutions to problems that have plagued secure communications for centuries. One such problem is key distribution: in order to communicate securely with another person, you would first need to somehow securely transmit the key used to encrypt the data you are sending. If you are communicating with a number of different people, this can become unwieldy. Public key cryptography solves this problem by allowing you to freely distribute your public key with no need to keep it secret, since only you hold the private key, and any data encrypted using your public key can only be decrypted using your private key. Every digital certificate contains the certificate holder’s public key, which can be used to verify signatures generated by the certificate holder, as described below.
• Signature Another feature of public key cryptography is the ability to generate digital signatures. A digital signature performs much like a traditional signature, in that it identifies the sender of a piece of data, but with the added ability to prove that the signed piece of data has not been altered since it was signed. Every certificate contains a digital certificate generated by the certificate authority that created the certificate. This allows anybody who receives the digital certificate to verify that it is the true and correct certificate as generated by the certificate authority. It is the digital signature on a certificate that gives that certificate its trustworthiness. If a user trusts a given certificate authority, and the user receives a certificate signed by that certificate authority, the user can trust the certificate.

Creating Trust

A digital certificate by itself is of limited usefulness in terms of establishing the identity of the certificate’s owner. For instance, when a wireless client connects to your Elektron server, Elektron will send its digital certificate to the client. It is not enough for the client to merely look at the name on the certificate, it must verify the signature on the certificate and trace it back to a certificate authority that is trusted by the client.

Certificate Chains

In order to verify the trustworthiness of a certificate, a client must build a certificate chain to trace it back to a trusted source. Many wireless clients, including those built in to Windows and Mac OS X, come pre-configured with a database of certificate authorities that will be trusted automatically. Any server sending a certificate signed directly by one of these pre-configured certificate authorities will be considered trustworthy. Additionally, any certificate that can be chained back to one of these certificate authorities will be trusted.

Given a server’s certificate and a database of trusted certificate authorities, the client can construct the certificate chain by using the certificate’s subject and issuer name fields. Starting with the server certificate’s issuer name, the client searches its certificate database for a certificate with a matching subject name. If one is found, the public key from the issuer certificate is used to verify the signature on the subject’s certificate. If the signature verifies correctly, then the client continues to build the chain by looking for the issuer of the previous issuer’s certificate, until the chain is complete.

At the end of each chain is a self-signed root certificate. This is a digital certificate where the issuer and subject names are the same, and the public key in the certificate is able to verify the signature on the certificate. Self-signed root certificates are held by certificate authorities, and are used to solely sign other certificates.

In the example certificate chain shown above, the self-signed root certificate is held by the fictional Acme Certificate Authority. The second certificate in the chain was issued by the Acme Certificate Authority to Widgets Incorporated. In this example, the Widgets Incorporated certificate is acting as an intermediate certificate authority, which issued the final certificate in the chain, the widgets.example.com certificate.

A wireless client connecting to the widgets.example.com server would need to have either the Widgets Incorporated or the Acme Certificate Authority in its database of trusted certificate authorities. If either of these were present in the trusted database, then the widgets.example.com certificate would itself be trusted. In effect, the client is saying, “the widgets.example.com certificate is signed by the Widgets Incorporated certificate authority, and I trust Widgets Incorporated, therefore I can trust widgets.example.com”.

Certificate Signatures

The digital signature on a certificate is the key to verifying the certificate’s trustworthiness. When a certificate authority signs a certificate, the authority is signaling that the certificate holder’s identity has been verified and that the certificate holder can be trusted to conduct secure transactions using the certificate.

Because individual users are unlikely to have the time or inclination to accurately verify the identity of a certificate holder, users must rely on certificate authorities to perform that task. Users can then keep a limited number of certificate authorities that they trust to make identity decisions on their behalf, and when receiving a certificate signed by one of these authorities, the certificate can be trusted.

There are a wide variety of certificate authorities for users to choose from. Commercial authorities, such as Verisign and GeoTrust are commonly used by web site operators to secure e-commerce sites. For proprietary networks, such as your small business wireless network, a good solution is to act as your own certificate authority. This can be both less expensive (commercial certificate authorities charge hundreds of dollars for a certificate), and less hassle (commercial certificate authorities typically require that you renew your certificate every year).

If you use the Elektron Setup Assistant to configure your Elektron server, a variety of options are available for choosing a certificate authority. The default (and recommended) option is to create a new certificate chain while acting as your own certificate authority. After running the Elektron Setup Assistant, you will have a certificate that can be distributed to wireless clients for inclusion in their databases of trusted certificate authorities.

Additional Certificate Validation

While validating the signatures on a digital certificate chain is a key part of validating the authenticity and reliability of a certificate, it is not the only step that must be performed. Any application accepting digital certificates must also perform checks on these features:

• Validity Period The application must determine that the certificate falls within the dates specified as the certificates validity period.
• Name Checking The subject name in the certificate must match the name expected by the client application. This can prevent an otherwise valid certificate chain from being used in an invalid context. For instance, if you were to purchase a book from Amazon.com’s secure web checkout, you would want to ensure that the name on the digital certificate used to secure the site is “www.amazon.com”.
• Extensions The application must check extensions present in the certificate to ensure that the certificate is being used in a manner consistent with what the certificate authority has authorized. The following are the most common checks performed on certificate extensions:

• The certificate is allowed to perform the basic operation it is being called on to perform, such as validating a digital signature or exchanging cryptographic keys (key usage checking).
• The application using the certificate is appropriate for the certificate. As mentioned above, Windows XP wireless clients require that the correct extension be present here in order to verify the certificate (extended key usage checking).
• Any intermediate certificate authorities in the certificate chain must be allowed to act as certificate authorities (basic constraints checking).

• Revocation Status It is possible for a certificate to be revoked (that is, cancelled for usage) by a certificate authority prior to the end of its normal validity period. This can happen if the certificate holder’s private key is compromised, the certificate holder’s identity changed (for instance, their certificate identifies them as an employee of a certain company, and they leave the employ of that company), or under other circumstances. Since a certificate by itself only specifies a certificate’s status at the time a certificate is issued, additional status checking at the time the certificate is actually presented is sometimes used. This usually comes in the form of a certificate revocation list (CRL). However, due to the complexity of keeping certificate status lists up to date, many organizations do not perform this checking.

Once these checks have been successfully performed, the client can accept the server’s certificate and the wireless login process can proceed.

Public Key Infrastructure

Public Key Infrastructure (PKI) is the name given to the organizational deployment of digital certificates. At its simplest, a PKI may consist of only a single certificate chain, such as one generated by the Elektron Setup Assistant for your small business. As its most complex, a PKI may be a multi-tiered hierarchy consisting of millions of certificates, such as the PKI maintained by the United States federal government for its employees.

If you choose to purchase a digital certificate from an external certificate authority for use with Elektron, you will be participating in that certificates authority’s PKI.

If you are deploying Elektron as part of a larger PKI, you can use the Elektron Setup Assistant or the Elektron Settings application to generate a certificate request that can be submitted to your certificate authority for fulfillment.