SSL Certificate Subtleties

Question

I have been reading up on the technical basics of how SSL works (which was surprisingly hard to find inside the ocean of laymen/non-technical articles/tutorial/videos out there). I have 3 small questions that in and of themselves felt too small to clutter SO with but as a whole I think provide some insight into how SSL works and address issues that don't seem to be well-documented:

1. Why (not when or how!) do SSL certificates expire? These are just public/private key pairs operating on a cipher/algorithm like AES. I assume there's a financial/business incentive behind the scenes here?!?

2. How many SSL certificates does an organization need? And before you say "that depends on your organization", I guess at the core of this question is: what driving factors make a company say, oh, I guess we're going to need another cert, or 10 more certs, etc. In other words: why is 1 cert often not sufficient for an organization??

3. Why does a company ask a CA for a root certificate and then get child certificates off of that root? What benefits does this "Certificate Tree" provide? (As opposed to just getting separate certs.)?

Thanks in advance!

Answer 1

1) Why do SSL certificates expire?

When a certificate expires, you're basically saying that this public/private keypair has been abandoned. Technically, you can still use this certificate to encrypt data, but the expiration date is there to mitigate revocations among other things. Additionally, however, in the X.509 spec there are specific reasons outlined for expiration:

4.1.2.5 Validity

The certificate validity period is the time interval during which the
CA warrants that it will maintain information about the status of the
certificate.

CAs publish revocation status information about a certificate and that means they need to keep track of them. When a certificate expires, the CA has done their part for the term of the certificate and stops tracking information for that certificate. You are essentially paying the CA to say with authority that this certificate is valid.

There are other reasons for expiration too. If I was still using a certificate signed in 2002 (which would be possible), the level of encryption probably wouldn't be up to standards used today. By setting an endpoint for the certificate, you are also setting a date on which you need to upgrade.

Now, of course, I don't think you can deny one of the biggest motivators behind the expiration is money [citation needed], but there are at least some technical and reasonable ideas behind it.

2) How many SSL certificates does an organization need / what driving factors help them decide?

It does depend on your organization. A traditional SSL certificate is matched to a domain name. However, anything can be signed with a key pair (developer certificates, etc.). So, for SSL, it'll depend on the number of domains you want to protect. For a traditional cert, www.domain.com and example.domain.com are completely different entities. There are other types of certs that can purchased, like wildcard certs, etc. that will depend on the needs of your business. Seriously, you can get incredibly complex or incredibly simple. Here's a rundown on some of the basic and different types for protecting a website: SSL Certificate Types

3) What benefits does [having a] "Certificate Tree" provide, as opposed to just getting separate certs?

You are basically saying that you trust this CA to generate certificates. That's why browsers have to have the root CA installed to accept a certificate. They are saying, "I trust this authority has only signed certificates for valid and trusted sources."

In practice, it ends up not being the case as a lot of CAs don't rigorously check who they are giving certificates to before issuance. Not always, but it does mitigate some of the danger. The problem is when the CA root certificate private key is compromised because then anyone can fake a legitimate certificate.

Hopefully this answers some of your questions.