Various Certificate Types 

Any certificate you purchase from a trusted root certificate authority should conform to the X.509 standard described in the previous section. Nevertheless, certificate resellers often use ambiguous terminology to categorize the different types of certificates they provide. Marketing terms such as “turbo” or “extended-validation” mean little to those who aren't familiar with certificates, and in the end just convolute the purchasing decision. Therefore, let us take a moment to briefly cover the various types of certificates by their associated (non-standard) nicknames.

Standard Certificates

A certificate authority's primary role is essentially to vouch for your company's authenticity to non-trusting customers. While your customers may have never heard of your organization, they inherently trust a set of pre-installed root certificate authorities. If you can successfully influence one of those root CAs to trust your business, then all clients associated with that particular CA will in turn trust you as well. However, gaining the trust of a root CA is not always trivial.

A standard certificate may be viewed as a “mid-level” assurance certificate due to the average level of documentation an organization must must provide during the verification process. The process of issuing a standard certificate typically starts out with CA verifying your organizational structure from two or more public databases-- usually WHOIS and Dun and Bradstreet. From those two sources, the CA can ascertain both the technical contact for your domain name, as well as administrative contacts such as a chief financial officer or human resources director.

Once the CA locates your organization's official headquarters through a trusted third party, they will resume subsequent communications through that location. For example, the root CA may send a verification form to your organization's fax number which was listed by Dun and Bradstreet. The CA may additionally request further proof of organization by requesting a copy of your organization's Articles of Incorporation, or proof of 501(c)(3) status for non-profit organizations. Once all appropriate documentation has been verified, the CA will finally sign your organization's X.509 certificate, thereby declaring your corporate validity.

Domain-Validated Certificates

While many certificate authorities insist on the systematic steps involved in the issuance of a “standard” certificate, many potential certificate customers feel as though this degree of verification is unnecessarily stringent, and perhaps the overall process is just too complex to accommodate. While some CAs baulked at the idea of lowering their strict verification standards, other CAs viewed this as an opportunity to create a new “simplified” type of certificate which allows for verification to be achieved in far fewer steps.

Domain-validated certificates are marketed under several vendor-specific monikers. While GoDaddy refers to them as “Turbo” certificates, Thawte refers to the very same type of product as the “SSL123” certificate. Regardless of the name, the term “domain-validation” says it all-- if you can successfully validate your domain, the CA will issue you a signed certificate. The process begins with the CA performing a “WHOIS” lookup on your domain name. Once the individual with administrative and/or technical control over the domain is located, a simple verification email is sent to that individual. The verification process is completed once that individual clicks on a special activation hyper link embedded within the email message. Obviously, domain-validated certificates are issued far faster, and often at a much lower price than traditional “standard” certificates. The down side of course, is that if an attacker was to somehow gain access to the email box of your domain's designated contact, it would be trivial for the hacker to generate a certificate on your company's behalf.

You may be wondering if domain-validated certificates are too good to be true. The reality is that any certificate signed by a trusted root certificate authority will essentially provide the necessary authentication of your business. While a technically discerning web visitor may be able to pick apart your certificate and determine the exact level of assurance, the vast majority of your visitors will not. A domain-validated certificate will certainly provide the trusted SSL “padlock” icon within your clients' web browser windows, which should give them the assurance they need to do business with your site.

Extended-Verification Certificates

Thus far, we've covered the verification process of the low-assurance “domain-validated” certificate and the mid-level assurance “standard” certificate. Extended-verification certificates on the other hand boast the highest level of assurance by performing several steps above and beyond standard verification. The specifics of extended-verification vary somewhat among the various CAs. Nevertheless, the extended-verification process strives to verify the overall legitimacy of a business through the collection of additional documentation, and perhaps through the collection of external references. Extended-verification certificates are often expensive, and are typically offered exclusively to incorporated entities.

As described previously, any certificate signed by a trusted root certificate authority will ultimately yield the protected SSL “padlock” icon within web browser windows. As such, prospective certificate buyers may view the additional cost and administrative burden of extended-verification certificates unnecessary. However, some of the newer web browsers do in fact give end-users visual queues as to which sites use extended-verification certificates. If such functionality becomes commonplace, extended-verification certificates may be worth the extra effort.

Wildcard Certificates

While standard certificates are intended to protect a single hostname, wildcard certificates may be viewed as “blanket certificates” which essentially protect a pattern of hosts within a given domain. When purchasing a certificate, the certificate authority will ask for a “common name” which must match your primary domain name. For example, the “common name” field for Amazon books would simply be “www.amazon.com.” This effectively protects the server named “www” which lives within the “amazon.com” domain. Although this approach may suffice for most web sites, this method requires the creation of a new certificate for each unique hostname within your domain. In other words, you would need a distinct certificate for “www.yourdomain.com,” another for “email.yourdomain.com,” yet another for “shopping.yourdomain.com,” and so on. A convenient alternative to single-host certificates is the wildcard certificate. The wildcard certificate allows you to substitute any one field of the hostname with the special star (*) character, which fundamentally matches any string. Therefore, a common-name of “*.atomicfission.com” would match www.atomicfission.com, mail.atomicfission.com, and forums.atomicfission.com.

Note however, that you may substitute one, and only one, component of a hostname. For example, let's say your organization has two domains: one on the east coast (east.yourcompany.com) and the other on the west coast (west.yourcompany.com). If you wanted to deploy wildcard certificates, you would actually need to purchase a wildcard certificate for each subdomain-- one for the east coast office (*.east.yourcompany.com) and a second for the west coast office (*.west.yourcompany.com). If you were to purchase only one wildcard certificate (*.yourcompany.com), then perhaps deploy a new mail server on the east coast (email1.east.yourcompany.com), clients would receive certificate mis-match errors. This is due to the fact that your star character (*) is living within the the third label from the right. Since the server you want to protect (email1) is located within the fourth label from the right, the wildcard star character no longer matches that particular host living within the given domain name.

Aside from the special common-name field which should contain a special star character, the process of acquiring a wildcard certificate is identical to that of acquiring a standard certificate. Just note that the added convenience of a wildcard certificate does come with a higher price tag. As you are protecting more than one host within a given domain, expect to pay a bit more for this type of certificate.

Chained Certificates

A certificate-aware client application determines whether or not to trust your server's certificate by first consulting with its own local key store. If the client possess a corresponding public key from the certificate authority that signed your certificate, then the client should inherently trust the validity of your certificate. As an example, let's assume you purchased a certificate from Verisign. If a Firefox user then requests your certificate, Firefox will check its local key store to determine if it has a copy of Verisign's widely distributed public key. Since Verisign is a longstanding certificate provider with considerable tenure in this line of business, Firefox does indeed ship with the Versign public key by default. Therefore, there should be no issues with Firefox trusting your certificate in this scenario. This is obviously great news for Verisign customers, but what happens if you purchase a certificate from a newer, or perhaps lesser-known certificate authority?

Recall that certificates are published through a system known as the public key infrastructure. Fortunately, PKIs are hierarchical, which allows for “root” certificate authorities such as Verisign to give other lower-level “intermediate” certificate authorities the ability to sign certificates themselves. Binding an intermediate certificate authority to a root certificate authority is known as “certificate chaining.” The overall links of the chain create what is know as the “certification path.” The most important aspect of a certification path is that it must ultimately end with a root level certificate authority that is inherently trusted by clients. If PKI newcomers such as GoDaddy can acquire the trust of an existing and well-established root certificate authority, then GoDaddy and other resellers can in turn begin to sell certificates directly to customers. This creates competition amongst the various certificate vendors, which then of course equates to better prices for the consumer.

Chained certificates are often far less expensive than certificates offered directly by root certificate authorities. For the cost-conscious, this presents an attractive alternative to an otherwise expensive technology. Nevertheless, chained certificates must be chosen carefully. The intermediate certificate authority issuing your chained certificate must be trusted by a root certificate authority themselves. If the intermediate certificate authority isn't trusted (either directly or indirectly) by a root CA trusted by the client, then the certification path will fail.

Self-Signed Certificates

Self-signed certificates are used in conjunction with privately-owned, internally managed public key infrastructures. In addition to SSL-enabled intranet applications, X.509 certificates may also be used within applications such as secure SMTP or wireless (WiFi) authentication. Self-signed certificates work by first creating an internal root certificate authority. The public keys for this internal root CA must then be pushed to all clients within the organization. (This requires administrative access to the machines.) Once the internal root CA is trusted by all clients, application servers may then commence using certificates signed by the internal root CA. Ongoing key management is typically handled by an enterprise-class certificate management system such as Red Hat's Certificate System or Microsoft's Windows Server 2003 Certificate Services. The most important item to note with respect to self-signed certificates is that the internal root CA certificate must be forced onto client computers. As you cannot force the installation of internal CAs on remote / unmanaged client computers, using self-sign certificates on public web sites will certainly result in errors on the client side of the transmission.

Certificate Formats

While a single certificate encoding standard would be convenient, the reality is that there are several formats to choose from. If you plan on installing only a single certificate on a single server, you can probably get by with following your vendor's instructions. If you plan on managing multiple certificates across several different platforms, you may want to take a brief look at the various certificate formats as you'll certainly encounter them sooner or later.

PEM Format – Oddly enough, the PEM format originated from a standard which never really caught on-- “privacy enhanced mail.” PEM is text-based encoding format, which allows one to copy and paste certificates, as well as transfer certificates over text-based protocols such as e-mail, HTTP, FTP, and others. PEM is the default certificate format for many UNIX-based applications such as Apache and OpenSSL. PEM certificates may contain a single public key, a single private key, a single certificate, or any mixed combination thereof. Common file extensions include: *.key for private keys, *.crt for certificates, or simply *.pem. Two other types of certificate files commonly encoded in PEM format are certificate signing request (CSR) files, and certificate revocation list (CRL) files.

DER Format – The ASN.1 “distinguished encoding rules” format is a headerless, binary format. Like the PEM format, a DER-based file may contain any one key/certificate, or a combination of all three. DER-encoded files typically have .der or .cer extension. The DER format is commonly used in Java-based applications.

PKCS/PFX – Personal inFormation eXchange is a Microsoft-based protocol which is compatible with RSA's Public Key Cryptography Standard. Being a Microsoft-based protocol, it is most common in (you guessed it!) Microsoft products such as Windows and Internet Explorer. PFX files typically contain one or more encrypted keys, as well as basic X.509 certificate information. Common file extensions include *.pfx and *.p12.