While inspecting my CA-approved cert, I noticed the following oddities:

Extensions/CRL Distribution Points:

  Not Critical
  URI: http://crl2.alphassl.com/gs/gsalphasha2g2.crl

Extensions/Authority Information Access:

Not Critical
CA Issuers: URI: http://secure2.alphassl.com/cacert/gsalphasha2g2r1.crt
OCSP: URI: http://ocsp2.globalsign.com/gsalphasha2g2

Shouldn't the OCSP information be published via HTTPS (i.e., protected with TLS), to protect against MITM? Is that field just noise that shouldn't be used by a client?

I know that Is publishing CRLs over HTTP a potential vulnerability? explains that CRLs are always signed, so it is not a vulnerability to publish CRLs over HTTP. What about OCSP?

(Somewhat related to Does any technology prevent a CA unilaterally revoking a certificate?)

  • 3
    The "chicken and egg" problem Tom mentioned in his comment on Steffen's answer is that using HTTPS to check for CRL/OCSP responses when wiring up HTTPS connections would create an infinite loop of HTTPS connections which in turn have to check for CRL/OCSP responses.
    – Xander
    Mar 21, 2016 at 15:27

2 Answers 2


The CRL's and also the OCSP responses are signed by the CA. This means any kind of manipulation will already be detected even if the CRL or OCSP response is transferred using an insecure transport. Thus the protection against tampering which is offered by https is not needed.

  • After further digging, I believe RFC2459 is the current reference for this - hopefully all client libraries check that the signature is from the correct CA for the CRL.
    – Phil Lello
    Mar 21, 2016 at 13:52
  • 11
    And, if they wish to use https for OCSP or CRL, they have a chicken-egg problem
    – Tom
    Mar 21, 2016 at 14:07
  • "This means any kind of manipulation will already be detected even if the CRL or OCSP response is transferred using an insecure transport." - while it prevent from manipulation does it prevent against replay? I.e. is there any check that you don't get stale version of file which does not include a certificate owned by attacker? Mar 21, 2016 at 22:49
  • 3
    @MaciejPiechotka: replay is not a problem. In fact caching is recommended and replay of OCSP is done by a server when using OCSP stapling. But CRL and OCSP have timing information to detect if the response is stale and these timing information are part of the signed response. Mar 22, 2016 at 5:51
  • 2
    @MaciejPiechotka The security model must accept that for a period of time certificate issued by error will be treated as valid! It's an intrinsic part of "error": such certs have been considered valid by the provider itself at some point. The question is how much time is such error allowed to stay uncorrected.
    – curiousguy
    Dec 9, 2018 at 18:16

CRL / OCSP is (in my opinion) the weak link in the CA security model; the fact that they are signed by the CA prevents an attacker from making a revoked cert appear legitimate, but they can always DOS a legitimate cert by intercepting / blocking the CRL / OCSP response. Without a valid CRL / OCSP, the cert should fail to validate.

For public CAs, there's nothing you can do about this, but for private corporate PKIs you can host your CRLs on an authenticated network share inside a VPN (and similar tricks for OCSP) making it nearly impossible for the attacker to know which return packet to block, short of just blocking your entire VPN connection.

Not the answer you're looking for? Browse other questions tagged or ask your own question.