OCSP responder hangs?

Hi,
I’m currently looking at adding ocsp requests as part of my Windows GUI https://certifytheweb.com in order to faciliate a scan for revoked certs.

Currently if I try to query http://ocsp.int-x3.letsencrypt.org (for instance) the response hangs with no result (same for staging) but if I use another responder (e.g. http://ocsp.digicert.com) I get an instant Unauthorized oscp response (as expected).

Is oscp just super slow or does a certain path for the current ocsp responder just do nothing in it’s response (not http status code, or perhaps not closing the response stream?). There’s a possibility my request is malformed in some way but that probably shouldn’t result in no response (as I presume I’m starving the server of a socket while I wait for no response to come).

1 Like

Do you have a basic main program that reproduces it? Sounds interesting.

Let Encrypt OCSP has always seemed speedy for me.

1 Like

It’s basically the same as this: https://github.com/reisjr/BouncyCastleExamples/blob/master/OcspClient/OcspClient.cs

It uses the BouncyCastle OcspRequest/Response objects and generators then posts it to the ocsp endpoint and expects a response. I could maybe try doing a GET instead if that would make any difference.

1 Like

Wild guess…
But ocsp.int-x3.ketsencrypt.org has IPv6 and IPv4 IPs, while ocsp.digicert.com seems to only have an IPv4 IP. Do you think maybe your issue is with IPv6?

If I ping int-x3 I get cs9.wac.phicdn.net [117.18.237.29] (as IP v4) so I don’t think so?

Post looks like this in Fiddler, could be a header missing or extra?:

POST http://ocsp.int-x3.letsencrypt.org/ HTTP/1.1
Content-Type: application/ocsp-request
Accept: application/ocsp-response
Host: ocsp.int-x3.letsencrypt.org
Content-Length: 115
Expect: 100-continue
Connection: Keep-Alive

0q0o0O0M0K0	+ ~ j r      dl -`q] Jjc}ݺ  9  Ee      >   Ĵ    9sʢ00+ 0
 0

Try kill this request header.

You should be able to set the Expect request header to an empty string.

Hi @webprofusion

I see such hangs sometimes with "check your website".

Counting - oh, a little bit too much. Last sample - https://check-your-website.server-daten.de/?q=mail.domainkeren.web.id#certificates

NotTimeValid: A required certificate is not within its validity period when verifying against the current system clock or the timestamp in the signed file.
RevocationStatusUnknown: The revocation function was unable to check revocation for the certificate.
OfflineRevocation: The revocation function was unable to check revocation because the revocation server was offline.

That check is one hour old. ~~4000 checks of Letsencrypt certificates (but not all domains have LE-certificates).

So - yes, looks like the OCSP hangs sometimes. That's not an own written check, that's the integrated .NET-check.

3 Likes

I also don’t think the OCSP server is hanging. The client is misbehaving.

I tried running it under Mono … it appears to hang as you report:

root@df80dcde1fdf:~/BouncyCastleExamples/OcspClient# mono bin/Debug/OcspClient.exe
Querying 'http://ocsp.int-x3.letsencrypt.org'...

but when we look at packet sniffer … server did indeed respond with the HTTP 100 Continue … and then the client does nothing:

Modifying the HTTP method with:

request.ServicePoint.Expect100Continue = false;

results in the program no longer hanging - instead it is continuing to crash elsewhere (for unrelated reasons - I think the program expects the issuer certificate to be bundled in the OCSP response, but Let’s Encrypt doesn’t attach one to save bandwidth, so the program throws the bounds exception):

root@df80dcde1fdf:~/BouncyCastleExamples/OcspClient# mono bin/Debug/OcspClient.exe
Querying 'http://ocsp.int-x3.letsencrypt.org'...

Unhandled Exception:
System.IndexOutOfRangeException: Index was outside the bounds of the array.
  at ReisJr.BouncyCastle.Examples.OcspClient.ValidateResponse (Org.BouncyCastle.Ocsp.BasicOcspResp or, Org.BouncyCastle.X509.X509Certificate issuerCert) [0x00017] in <aac126ae196b4db7a0d3467188803f88>:0

Maybe finding some examples that aren’t from 2012 would be better.

6 Likes

I tried using the (.net) X509Chain build to check for revocation status initially but it just instantly came back saying something about the CRL being offline so I don’t know if it attempts an Oscp check.

2 Likes

Ha! Yep, you nailed it. I was just replying to say that this fixed it:

request.ServicePoint.Expect100Continue = false;

The other part I’m not worried about, as you say that code is old.

4 Likes

Thanks. First idea: That's the problem.

But rechecked my code. That's already used.

ServicePointManager.Expect100Continue = False

Do you use the Bouncy castle ocsp libraries for your check or do you have another method (.net framework)? There seems to be zero docs for BouncyCastle examples and some stuff on the java side dates back to 2005.

1 Like

It's own .NET-code. But I don't use an explicit OSCP-check, it's only

ServicePointManager.CheckCertificateRevocationList = True
ServicePointManager.Expect100Continue = False

Later follows an own

_hWebRequest.ServerCertificateValidationCallback = own Procedure

So the OSCP-check is invisible, may be the reason Expect100Continue = False doesn't work.

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.