SSL certificate performance

[innodivergence]

Howdy,

As I understand SSL: the performance of my certificate providers
infrastructure
will effect the performance of page loads on my site.

I have searched a bit, and have not found anything that looks like a
SSL certifi
cate provider performance bench mark page. There are cheap certificate
providers
, and expensive ones. Like anything else, I expect the price has
little to do wi
th how well they do their job.

Can anyone comment on the relative speed/performance/coverage of
various SSL cer
t providers, or refer me to an objective source that documents this?

Thanks!

[David E. Ross]

Post by innodivergence
Howdy,
As I understand SSL: the performance of my certificate providers
infrastructure
will effect the performance of page loads on my site.
I have searched a bit, and have not found anything that looks like a
SSL certifi
cate provider performance bench mark page. There are cheap certificate
providers
, and expensive ones. Like anything else, I expect the price has
little to do wi
th how well they do their job.
Can anyone comment on the relative speed/performance/coverage of
various SSL cer
t providers, or refer me to an objective source that documents this?
Thanks!

If you have a secure Web site -- which is what SSL certificates provide
-- this is an overview of how it works:

SSL certificates are public key/private key certificates similar in
concept to OpenPGP keys but different in format and use.

A certification authority (CA) is an organization (often for-profit)
that has undergone an investigation by browser developers (e.g.,
Microsoft for Internet Explorer, Mozilla for Firefox, Google for
Chrome). I am most familiar with Mozilla, which does a very vigorous
investigation that even includes a period of soliciting public comments
on the CA's documented policies and practices and also reviews audit
reports from independent auditors who examine those policies and
practices against the documents.

The CA creates an SSL certificate known as the root certificate. The
public part of the root is widely distributed, not only to browser
developers but also to Adobe, Oracle, and others. The public part of
the root certificate is embedded in the software applications that
perform SSL operations (e.g., browsers). The public part is
generally available to anyone through the CA's Web site. The private
part is usually maintained on a portable electronic medium that is
stored in a safe or vault when not used to sign other certificates.

The CA's private part of its root is used to sign other SSL
certificates. Usually these are termed "intermediate certificates".
Again, the public part of an intermediate certificate is widely
distributed while the private part is kept secured with the private part
of the root certificate.

When someone wants an SSL certificate for use in a secure Web site -- a
"site certificate" -- the private part of an intermediate certificate is
used to sign it. The owner of the site again keeps the private part of
the site certificate in a secure location. The public part of the site
certificate along with a copy of the public part of the intermediate
certificate are then loaded onto the Web server of the secure Web site
(NOT onto the CA's Web site).

When I visit a secure Web site, the public part of the site's
certificate and the public part of the intermediate certificate that
signed the site certificate are sent by the site's server to my
browser. My browser checks the signature on the site certificate to
verify it was made by the intermediate certificate and then checks the
signature on the intermediate certificate to verify it was made by the
root certificate. Thus, the authenticity of the secure Web site is
established. Thereafter, the site certificate at the server and the
root certificate on the browser are used to create disposable encryption
keys so that secure input can be sent from my computer to the Web server
and secure Web pages can be sent from the server to my computer. Note
that none of this browsing involves the CA's server; thus, the CA's
infrastructure has no impact on the performance of my browser or on the
delivery of a secure Web page to my browser.

There is one area where the CA's infrastructure might impact
performance. My browser has options to check whether the CA has
cancelled, revoked, or otherwise invalidated an intermediate or site
certificate used in the site I am trying to browse. This involves OCSP
(Online Certificate Status Protocol), which requires a query to a CA's
OCSP server. On occasion, a CA's OCSP server might be down or slow.

An alternative to OCSP are CRLs (certificate revocation lists). These
are lists of certificates revoked by a CA, a separate list for each CA.
You import a CRL from a CA's Web site; the URI of the CRL is found in
the root certificate. Then you must update each CRL periodically; this
should be done at least weekly and can be done daily. My browser
provides for automatic CRL updates after a CRL has been imported; this
too relies on querying CA servers.

Updating CRLs involves automatically downloading and importing entire
lists of all revoked certificates from all CAs that support CRLs. On
the other hand, OCSP involves checking only one site certificate at a
time -- the certificate for the specific secure site you are visiting --
but checking each site certificate sent to you each time it is sent.
The issue is whether to download large lists (CRLs) not more often than
daily or to query an OCSP server for only one site certificate at a time
as often as secure sites are visited. Either way, you are dependent on
the CA's infrastructure.

For secure browsing, you should use both CRLs and OCSP since some CAs
support CRLs but not OCSP and other CAs support OCSP but not CRLs -- and
some CAs support both. You do not have to use both for the same CA.
Failure to use either CRLs and OCSP means that you might think you are
doing secure browsing (e.g., inputting your user ID and password at your
bank) when the Web site you are visiting has been compromised.

I am quite sure that I have some errors in this explanation and that
others will reply with corrections. I am actually more familiar with
OpenPGP than with SSL certificates.