Information Security Stack Exchange is a question and answer site for information security professionals. It only takes a minute to sign up.
Sign up to join this community
Imagine a situation where a rogue CA creates a certificate for your site. Since the user's browser trusts the CA, it will accept the certificate without any fuss. However, the site's real certificate doesn't expire for another year, and there's no CRL entry for it.
Why do we allow the browser to accept such a situation? Surely it would make more sense to enforce that the first certificate, and only that certificate, is accepted until it expires or it is explicitly revoked.
The first problem I can see is how do you find the first certificate? If you've visited the site before, then I suppose you could, but for anyone that doesn't keep certificates around from all the sites they have visited, we'd need some infrastructure to be able to look up all certificates that resolve for a particular CN.
Additionally, such a system might add another point of failure as such a service could be attacked (or the revocation list itself could be attacked) resulting in a failure to be able to authenticate a certificate.
I'm also not sure that it is a huge security threat. As I understand it, the revocation list is around primarily to prevent a leaked certificate from being used on a rogue site, not to prevent a rogue certificate from being used anywhere. And in fact, with such a system, it might be possible for the rogue certificate to knock out the trust of the original real certificate which could be even more damaging.
Yes, the problem of rogue registrars is a hard problem to solve and if you have a local store of the cert on file, then it is may be worth displaying a warning if it is replaced before expiration, but I'm not sure that we want revocation being used for more than loss of control of the private key or invalid initial issuance (which really is another form of loss of control of the private key).
There are several normal situations which would entail the existence of several simultaneously valid certificates for a given SSL server:
The server has several front-ends, each having its own private key and certificate, though all certificates contain the server name. Having a per-system private key is a good idea because it avoids moving private keys around, and moving private keys is rarely a good idea.
The private key was lost, but not compromised or stolen; e.g. the machine was destroyed in a fire. A new certificate should be issued for the new server key, but there is no point in revoking the old certificate (see below).
A server certificate will soon expire; a new one is issued. There shall be some overlap during which both certificates are valid, so that the transition can be enacted without any downtime.
Conceptually, the X.509 model is one of positive assertions of local properties. An X.509 certificate says "this key is owned by that entity". There is nothing in X.509 which says "that entity has only x active certificates"; this is not part of the properties that X.509 tries to maintain, and it would actually be impossible to enforce, because nothing would prevent me from building my own CA and issuing certificates for other people. I mean, if I find a certificate issued by some CA, then I can extract the certificate contents and put that in a new certificates which I can sign. I thus can arbitrarily make thousands of new certificates for any server I wish -- and that's not even "wrong" because I am not writing any fake assertion in any of these certificates.
Correspondingly, CRL are not designed to be a way to publish information about any list of "active certificates". A certificate is revoked not because it will no longer be used by the owner, but because verifiers must no longer accept it, which is a very different thing. You do not revoke a certificate when the private key is destroyed; you revoke it when you suspect that the private key is in the wrong hands.
That X.509 might not be the exact right model for HTTPS servers on the global Web is a valid point. That's the gist of Convergence: replacing the X.509 model (positive assertions trickling from trusted authorities) with another model where servers have some contextual state and, in particular, don't switch certificates every five minutes. With X.509, a given SSL server could perfectly have one million valid certificates at the same time, and use a randomly chosen one for each connection; X.509 validation is totally up to it. But "normal HTTPS servers don't do that" and Convergence tries to milk extra security out of that idea of "normal servers".
I propose a counter-scenario:
What if I am unhappy with my current CA, CA-1, and I move to CA-2 and have them issue a new certificate for my site. If I am no longer a customer of CA-1 and they decline to add my original certificate to the CRL then browsers in your scenario would reject my new (and valid) certificate.
Additionally there may be cases where you use certificates on multiple servers or load balancers. Your mechanism would require you to update all of those devices simultaneously (along with the CRL).
What you're proposing is to add very rudimentary anomaly detection into the browsers that would make good decisions in 96% of cases but not always.
The CRL is for certificates that we know (or strongly suspect) have been compromised, not for any certificate that we're done with but still believe is secure. The real issue in your scenario is that there's a rogue CA, not that the browsers accept two different certificates for the same domain at the same time. The browsers should stop trusting the bad CA.
