2

I'm still trying to understand the functionality of a Certificate Authority, so if this obvious, I apologize.

I understand CRLs play a role when the CA wants to invalidate a certain SSL certificate. In every SSL certificate I checked, both OCSP and CRL URLs are served in plain HTTP. Is there any particular reason to distribute them over HTTP?

The chances of someone stealing a server private key and spoofing the clients connection to the CA's servers are quite slim, but I'm wondering if there is nay accessibility or technical reason behind that.

As always, thank you for your attention and time

AKS
  • 714
  • 5
  • 14
  • I'm extremely sorry @techraf for posting this duplicate. You are right that question s exactly what I had. Thank you. – AKS Jul 03 '16 at 01:05

1 Answers1

5

HTTPS (or any TLS clients really) need to know the certificate revokation status before being able to trust that TLS connection. If the HTTPS connection used to fetch the CRL itself can't be trusted, then what is the point? Not to mention, your original HTTPS connection triggers a CRL lookup, which in turn triggers another HTTPS connection for the CRL server, which in turn... you get the point, we end up with an infinite loop of resource-expensive, untrustable and thus pointless connections.

Fortunately CRLs are signed themselves so the transmission medium doesn't matter, it must on the contrary be as lightweight as possible, so that excludes HTTPS (or any other crypto protocol really).

André Borie
  • 12,736
  • 3
  • 40
  • 76