InfoCenter Home > 5.5.3: Introduction to digital certificatesA digital certificate is equivalent to an electronic ID card. It serves two purposes:
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 certificateA certificate contains several pieces of information, including information about the owner of the certificate and the issuing CA. Specifically, a certificate includes:
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 certificatesTo get a certificate, you must send a certificate request to the CA. The certificate request includes the following:
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 certificatesTo 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. |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|