A valid certificate cannot guarantee that I'm not being MITM'd right now, as either the private key or CA may have been compromised. For this reason, I have to contact a CA through CRL/OCSP to check if it's been revoked. Best case, I can have a CA's signed confirmation stapled to a response from the server.

But if the CA has to be contacted anyway, why even bother with certificates? Why not just have the server staple me a signed response from the CA that says "This is Server's PubKey, signed CA 5 seconds ago", which I can trust since I have the CA's PubKey in my store.

The CA's message is far more important to me than the certificate. The certificate is only somewhat useful in the case that I'm offline, or the CA's entire infrastructure is offline, and I just have to hope that the certificate hasn't been compromised.

What's strange is that the literature I read on this subject seems to invert the significance of the certificates vs CRL/OCSP information.

Am I missing something here?

  • 3
    Interesting question [+1]. There have been attempts to even go a step further than what you describe, and eliminate CA's altogether - using a network of peers to verify that all peers see the same public key for a server. So, your browser would just contact a few peers to verify that they all see the same public key for the server as you - and if so, it is unlikely that you are being MITM'd. See en.wikipedia.org/wiki/Convergence_(SSL) for some interesting reading on this subject.
    – mti2935
    Commented Jun 11, 2023 at 16:44
  • 4
    @mti2935 The method you describe about the peers could take two paths: 1) Check the certificate with random servers worldwide and see if they reach consensus, 2) Use the "Notaries", as Convergence (SSL) describes. The Convergence basically is the same as having multiple CAs sign the same public key (using the same CSR) and sending all the certificates to the client. In both paths, you would have to trust the peers, somehow; which, automatically, makes them similar to CAs. Just as a CA is compromised, so could the peers. The proposal didn't really take off and for good reason -it doesn't confer Commented Jun 12, 2023 at 0:05
  • 7
    significant advantages. The current method of using CAs with Certificate Transparency, is quite effective to keep CAs in check. In any case, I believe that DANE is the most viable alternative to CAs+CT. We already have to trust DNS and, if someone can hijack the DNS resolution, they probably have the means to do it when contacting the peers/"Notaries" and give a false response as to the authenticity; which means that Commented Jun 12, 2023 at 0:10
  • 4
    we STILL have to trust in some hardcoded signing keys to avoid DNS hijacking. It makes sense to enforce DNSSEC everywhere and use it for TLS, too. Disclaimer: These comments were written "casually" and off the top of my head; it is possible that I have missed something or that I haven't considered all cases. Commented Jun 12, 2023 at 0:10
  • 3
    @ARGYROUMINAS Interesting comments. WRT 'you would have to trust the peers, somehow; which, automatically, makes them similar to CAs' - True, but we can easily revoke our trust of a peer without serious repercussions, whereas we cannot easily revoke our trust in a major CA, without it breaking lots of other sites. The problem with DNSSEC/DANE is that then we have to trust the registrar (e,g. GoDaddy), the TLD (e.g. Verisign, for .com), and the root (e.g. ICANN). Anyone of these entities could hijack the DNS for the domain, and DNS records that appear to be perfectly authentic via DNSSEC.
    – mti2935
    Commented Jun 12, 2023 at 0:27

4 Answers 4


The signed CA response you envision is a certificate. Maybe not a classical X.509 certificate that we currently use, and maybe much more short-lived, but conceptually, it serves the exact same purpose as a certificate where a CA binds a public key to the identity of a particular server.

So instead of questioning the purpose of certificates, this seems to be more about increasing the frequency of validity checks. Sure, this could be done. But it would require CAs to significantly beef up their infrastructure, and it's questionable how much this would actually improve security. You assume that private keys get compromised all the time, and at the same time you assume that website owners somehow notice this immediately and inform their CA. In reality, certificate revocations are rare compared to the total number of certificates, either because website owners are pretty good at protecting their private keys, or because they don't notice when their key has been compromised. Even when they do notice, the time between the compromise and the actual notification of the CA can be pretty long. Putting seconds-level checks on top of this slow-moving process just isn't very helpful and could even create a false sense of security. The current model of relatively short-lived certificates, optionally coupled with OCSP, seems more appropriate.


Think of the certificate as an official signed statement confirming that the public key belongs to a particular host. The CRL/OCSP systems are there so that you can confirm that the official signed statement is still valid and that is still applies.

In reality, most browsers DO NOT actually check CRLs or use OCSP to check validity because that would be too slow. OCSP stapling does exist, but, as of now, it hasn't really taken off.

One of the reasons to "bother" with certificates is because you need to know WHOM to contact to confirm that the certificate is still valid. Without the certificate, you wouldn't know whom to contact or who the CA is. Another reason is so that there is a signed proof by the CA confirming that they did some checks to confirm ownership, etc. The certificate can contain the name and additional info of the organization, etc. The certificate also contains Certificate Transparency proofs, which are there to show that the CA published the fact that they had issued the certificate to a public log, and this serves to make sure that CAs don't misissue certificates, among other things, it keeps CAs in check, etc.

OCSP and CRLs don't tell you that "this is the public key of the server", instead, they tell you that you can trust whatever public key and other info is included in the certificate.

In general, the host using a certificate is supposed to keep the private key safe and there is the assumption that they will keep it safe.

Another issue with OCSP when the client makes the request to the CA is that it does not preserve privacy. The CA knows which (IP address) visits which host (website, domain). Also, if every client makes OCSP requests, the servers of the CA would receive significant traffic and require infrastructure upgrades to handle it.

The best and most practical scenario would be for the certificate (with Certificate Transparency information) to be accompanied by an OCSP response. The server preemptively and frequently asks for an OCSP response to have on hand and gives sends it to the client, along with the certificate. The same OCSP response can be sent to many clients, as long as it is still temporally valid. Also, since the server makes the OCSP request, the privacy of the client is preserved. The loading time is not increased, in any significant degree, since the client doesn't have to contact the CA for an OCSP response (or search through a huge CRL) and the cryptographic verification of the server-supplied OCSP response is quick. This is called OCSP Stapling; unfortunately, it hasn't taken off as of now.

  • 1
    "need to know WHO to contact" - no, you "need to know WHOM to contact" Commented Jun 13, 2023 at 11:24
  • 5
    @rexkogitans My sincerest apologies for the grammatical mistake; it has been fixed. Nevertheless, most people, wrongly, always use "who"; hence, it has become somewhat acceptable. Commented Jun 13, 2023 at 14:57

"A valid certificate cannot guarantee that I'm not being MITM'd right now, since the certificate may have been compromised"

In practice, this is mostly a non issue, as for all practical purposes compromising the private key (the certificate itself is public) usually means (there was the Heartbleed exception) that an attacker gained administrator access on the machine. Once the attacker has done so he usually can do much more than just man in the middle people. Machines get compromised all the time, and clearly using compromised keys post compromission hasn't been as much as an issue than the outright data plundering, malware planting and other not so nice things that happens in such case.


I think it's important to look at the historical context here, because successful protocols are generally built on what came before, not designed from scratch.

Netscape first released SSL to the public in 1995; for authenticating the server, it made use of an already standardised system of certificates, X.509. The integration was very simple: the operator of a server pointed their configuration at a private key and a certificate signed by some trusted Certificate Authority, and that certificate would be sent with every SSL connection to be checked by the client.

In this system, certificate renewal was an entirely manual process, with certificates often being marked valid for multiple years. Servers had no facility for contacting a Certificate Authority; CRL and OCSP were ways for clients to contact the CA after receiving a certificate from the server. A shared hosting provider did not need to configure any CA-specific systems, they could just allow a user to upload two files (or three, for a separate intermediary chain).

When Let's Encrypt launched, nearly twenty years later, they issued certificates valid for only 90 days, explaining on their website that this was explicitly to encourage automation, and that they might consider even shorter validity in future. This requires server administrators to configure more complicated software to talk directly to the CA, with the trade-off that users no longer have to pay a commercial CA if they just need a basic certificate.

If this history had happened differently, it's possible that something like what you describe would have arisen: perhaps certificates could be issued with lifetimes on the order of hours or days, rather than months or years. There would still be a tradeoff - every renewal costs resources for both the CA and the server which needs the certificate, and the lifetime on the certificate serves a similar purpose to the lifetime of a response cache. There would also likely be a difference between a "full renewal" (re-confirming ownership of the certified name) and a "revocation check" (confirming that the private key was not listed as compromised). The main difference in the end is whether the server is making this distinction, or the client.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .