Computing [Home Page]

Why Use a Commercial Server Certificate Authority?

(Security Infrastructure Project, 12 June 2003)


A common question about server certificates is why do we need a commercial Certificate Authority (CA)?   With OpenSSL self-signed certificates, Windows Server CA, etc. we can generate our own certificates.

The answer is that it is less expensive to use a commercial CA in all but the smallest deployments and special cases, and the quality of the result is higher with a commercial CA.


The benefits of using a commercial certificate authority (CA) are essentially economies of scale:

  1. The CA negotiates with browser vendors to get their root certificates built-in to the browsers.
  2. The CA can afford cryptographic experts and key-generating hardware, etc.
  3. The CA certifies that a requestor is authorized to get a certificate for the requested Common Name (CN), and that the data in the certificate is valid.

Keep in mind that the server certificate serves two functions:

  1. The certificate verifies that your browser is talking to the server specified in the URL,
  2. The certificate establishes the basis for negotiation of a private connection.

While a self-signed certificate will get you a private connection, a private connection to an unknown server has dubious merit.

Built-in browser CA root certificates

Web browsers come with built-in CA root certificates for all of the major certificate authorities.  This has two strong advantages: it saves both the server administrator and their customer a lot of time and trouble, and it discourages the very bad practice of getting customers used to clicking Accept for bogus certificates.

In very small deployments, each customer can download and install a self-generated root certificate, or accept and store a copy of the server's self-signed certificate.  However at a scale of 100 customers or larger, the time for each customer to do this, plus the time of both the customer and the administrator to resolve problems begins to escalate.  At the size of university-wide deployment, the time and cost are unbearable!  While the time and effort cost for the server administrator may seem onerous, for a large deployment it is relatively trivial.

People are very sensitive to trouble and irritation.  It would take very little to train them to click OK or Accept to every security warning (or worse yet, click Don't Warn Me Anymore).  Any practice, such as accepting self-signed certificates, that  adds to this negative training needs to be avoided.

Cryptographic expertise and hardware

Real cryptographic expertise and hardware are rare and expensive.  Self-generated certificates rely on the expertise of the server administrator and the provider of the software.  While the open source providers may have solid software, the basis of good secret keys is a good random number source.  Software has problems trying to generate good random numbers.  Small misjudgments or misconfigurations by the server administrator may compromise the randomness of the secret key.  Also,  you did read the all source code to check for Trojans and bugs, didn't you?

Verification of Authority and Certificate Data

For a self-generated certificate, who has verified the authority of the signer or the data in the certificate?  This cuts to the core of the first purpose of server certificates, to securely identify the server.  Web spoofing is a reality.

Also see Server Certificates and SSL (Overview of SSL and server certificates)

Page modified: 06 Nov 2011 13:27:34 -0800

[Back to Top   [Home Page]