InfoCenter Home >
5: Securing applications -- special topics >
5.5: Certificate-based authentication >
5.5.3: Introduction to digital certificates

5.5.3: Introduction to digital certificates

A digital certificate is equivalent to an electronic ID card. It serves two purposes:

  • To establish the identity of the owner of the certificate
  • To distribute the owner's public key
Certificates provide a way of authenticating users, referred to as authentication by trusted third parties. Instead of requiring each participant in an application to authenticate every user, third-party authentication relies on the use of certificates, electronic ID cards.

Certificates are issued by trusted parties, called certificate authorities (CAs). These authorities can be commercial ventures or they can be local entities, depending on the requirements of your application. Regardless, the CA is trusted to adequately authenticate users before issuing certificates to them. Also, when a CA issues certificates, it digitally signs them. When a user presents a certificate, the recipient of the certificate validates it by using the digital signature. If the digital signature validates the certificate, the certificate is known to be intact and authentic. Participants in an application need only to validate certificates; they do not need to authenticate users themselves. The fact that a user can present a valid certificate proves that the CA has authenticated the user. The descriptor trusted third-party indicates that the system relies on the trustworthiness of the CAs.

Contents of a digital certificate

A certificate contains several pieces of information, including information about the owner of the certificate and the issuing CA. Specifically, a certificate includes:

  • The distinguished name (DN) of the owner. A DN is a unique identifier, a fully qualified name including not only the common name (CN) of the owner, but the owner's organization and other distinguishing information.
  • The public key of the owner.
  • The date on which the certificate was issued.
  • The date on which the certificate expires.
  • The distinguished name of the issuing CA.
  • The digital signature of the issuing CA. (The message-digest function is run over all the preceding fields.)
The core idea of a certificate is that a CA takes the owner's public key, signs the public key with the its own private key, and returns this to the owner as a certificate. When the owner distributes the certificate to another party, it signs the certificate with its private key. The receiver can extract the certificate (containing the CA's signature) with the owner's public key. By using the CA's public key and the CA's signature on the extracted certificate, the receiver can validate the CA's signature. If it is valid, the public key used to extract the certificate is known to be good. The owner's signature is then validated, and if the validation succeeds, the owner has successfully authenticated to the receiver.

The additional information in a certificate allows an application to decide if it should honor the certificate. With the expiration date, the application can determine if the certificate is still valid. With the name of the issuing CA, the application can check that the CA is considered trustworthy by the site.

A process that uses certificates must be able to provide its personal certificate, the one containing its public key, and the certificate of the CA that signed its certificate, called a signing certificate. In cases where chains of trust are established, several signing certificates may be involved.

Requesting certificates

To get a certificate, you must send a certificate request to the CA. The certificate request includes the following:

  • The distinguished name of the owner (the user for whom the certificate is being requested).
  • The public key of the owner.
  • The digital signature of the owner.
The message-digest function is run over all these fields.

The CA verifies the signature with the public key in the request to ensure that the request is intact and authentic. The CA then authenticates the owner. Exactly what the authentication consists of depends on a prior agreement between the CA and the requesting organization. If the owner in the request is successfully authenticated, the CA issues a certificate for that owner.

Using certificates: Chains of trust and self-signed certificates

To verify the digital signature on a certificate, you must have the public key of the issuing CA. Since public keys are distributed in certificates, you must have a certificate for the issuing CA. That certificate will be signed by the issuer. One CA can certify other CAs, so there can be a chain of CAs issuing certificates for other CAs, all of whose public keys you need. Eventually, though, you reach a starting point. The starting point is a root CA that issues itself a self-signed certificate. In order to validate a user's certificate, you need certificates for all intervening participants, back to the root CA. Then you have the public keys you need to validate each certificate, including the user's.

A self-signed certificate contains the public key of the issuer and is signed with the private key. The digital signature is validated like any other, and if the certificate is valid, the public key it contains can be used to check the validity of other certificates issued by the CA. However, anyone can generate a self-signed certificate. In fact, you will probably generate self-signed certificates for testing purposes before installing production certificates. The fact that a self-signed certificate contains a valid public key does not mean that the issuer is really a trusted certificate authority. In order to ensure that self-signed certificates are generated by trusted CAs, such certificates must be distributed by secure means (hand-delivered on floppy disks, downloaded from secure sites, and so forth).

Applications that use certificates store those certificates in key, or keyring, files. This file typically contains the necessary personal certificates, its signing certificates, and its private key. The private key is used by the application to create digital signatures. Servers will always have personal certificates in their key files. A client requires a personal certificate only if the client must authenticate to the server, that is, when mutual authentication is enabled.

To allow a client to authenticate to a server, a server's keyring file contains the server's private key and certificate and the certificates of its CA. A client's keyring must contain the certificates of the CAs of each server to which the client must authenticate.

If mutual authentication is needed, the client's keyring must contain the client's private key and certificate and the certificates of any CAs. The server's keyring needs a copy of the certificate of the client's CA as well.

Go to previous article: Digital signatures Go to next article: Requesting certificates

 

 
Go to previous article: Digital signatures Go to next article: Requesting certificates