In order for certificates to be useful, each party must be able to determine that the certificate they receive from the other party is genuine and that it has not been forged or tampered with. The PKI infrastructure provides this through the use of the Certificate Authority (CA). A CA is a trusted party that issues certificates on behalf of the parties that they represent. A certificate issued by a CA will contain the CA's "digital signature" to verify that the certificate is authentic. The party receiving the certificate can compare the CA signature to a copy that it maintains in its local certificate store to verify its authenticity.

Verisign, Entrust, and Thawte are all well-known CAs.  A certificate provided by a well-known CA will contain its root certificate, and possibly an intermediate certificate. The example below is a certificate that was signed by Verisign.  If the CA is trusted by an organization that is confident of its identity, its public root certificate and any intermediate certificates can be added to a trusted root keystore. Applications that use the keystore should accept any certificates that contain a valid signature from the trusted CA, with the exception of those certificates that the CA may distribute in a Certificate Revocation List (CRL). Third-Party certificates are most commonly used as server side SSL certificates, however they can be used for client certificates as well.

All modern web browsers come pre-loaded with the root certificates for the well-known CAs in their trusted certificate keystore. If you are building a custom solution that does not require a web browser, you can either clone the keystore that ships with any browser or manually import the certificates into your trusted keystore.

While the well-known CAs can be a reliable certificate source, they can also become expensive. Certificates from one of the well-known CAs must be purchased, typically on an annual basis. If you plan to generate many certificates then this method could become cost-prohibitive.

Figure 8.1. Example of Certificate Signed by Third Party CA

The PKI infrastructure allows any organization to create its own private CA for signing its own certificates. Certificates signed by a private CA will look similar to those signed by a well-known CA in that the root certificate within the chain will belong to the CA. Figure 8.2, “Example of Certificate Signed by Private CA” is an example of a certificate signed by a private CA.

Figure 8.2. Example of Certificate Signed by Private CA

The benefit of using a private CA is that the organization does not have to purchase its certificates. The drawback to using a private CA is that the CA’s root certificate will not come pre-loaded with any of the commercially shipped keystores. The owner of the CA will typically perform an out-of-band communication with its business partners to verify its identity. The CA owner will then provide each of its business partners with a copy of its public root certificate. The business partners can then import the root certificate into their local trusted certificate keystore. Any certificates signed by the CA can then be validated against the root certificate in their trusted keystore.  

While private CAs may not provide the industry-wide validation that well-known CAs offer, they can still offer a safe and reliable solution for using certificates.

The third method of generating a certificate is to use a self-signed certificate. A self-signed certificate is exactly what the name implies; a certificate signed only by the creator of the certificate. It cannot be traced back to a signing authority and, therefore, its authenticity cannot be verified. Figure 8.3, “Example of Self-Signed Certificate” and Figure 8.4, “Example of Self-Signed Certificate Imported” show an example of a self-signed certificate.

Figure 8.3. Example of Self-Signed Certificate

Figure 8.4. Example of Self-Signed Certificate Imported

Self-signed certificates are typically used for development purposes as they are easier to create than CA-issued certificates, however your business partners must load the public key for each of your self-signed certificates into their trusted keystore to prevent their applications from throwing errors or warnings. With CA-signed certificates, your business partners only need to load the root certificate for the CA into their keystore and all certificates generated by the CA will be validated.

When self-signed certificates are used as server SSL certificates it may present some issues for your business partners. If they are using an SSL appliance their network security group may not be comfortable installing a self-signed certificate into the appliance’s keystore. This could cause the appliance to reject the SSL sessions.

Self-signed certificates are commonly used for digital signatures or data encryption. Each party will generate a signing or encryption certificate and perform an out-of-band exchange of their public keys using a trusted method to ensure that the source of the certificate is known.