OCSP server suggests trying again later

Question

I am using Firefox to access my site secured with a free StartSSL certificate. I am sending an HSTS header (though now for testing I have it set to 15 seconds!) and I have enabled OCSP stapling.

Yesterday and this morning StartSSL's OCSP responder was down, and I was (not surprisingly) getting sec_error_ocsp_try_server_later whenever I tried to visit my site.

Now, however, StartSSL has fixed their OCSP responder as far as I can tell, and my site works fine on other local computers (running Windows) with Firefox, but still does not work on my personal computer (running Linux).

If anyone has any insight on this would be nice; I'm not even sure if the issue is in my Firefox, Linux, or some server setting wrong yet.

Oh, and I am using Apache web server on Linux to serve the site. And I might as well give you the link.

Solution 1

I got the same message when viewing the site on Firefox.

It seems that the problem occurs when checking the revocation status of the StartSSL Intermediate certificate that was used to sign your certificate. It looks like their OCSP responder at ocsp.startssl.com still isn’t correctly responding to requests.

I used the online SSL server test from Qualys SSL Labs to test your server. When checking the revocation status of StartCom Class 1 Primary Intermediate Server CA, it reports that

OCSP ERROR: Request failed with HTTP status: 500 [http://ocsp.startssl.com/ca]

I also used the OpenSSL s_client diagnostic tool to check your server’s response:

echo | openssl.exe s_client -connect www.grepper.net:443 -CAfile /usr/ssl/certs/ca-bundle.crt -status

The -status option

sends a certificate status request to the server (OCSP stapling). The server response (if any) is printed out.

In your case, the response was:

OCSP response:
======================================
OCSP Response Data:
    OCSP Response Status: trylater (0x3)

BTW, congratulations on scoring the A in the SSL Labs test. It’s a shame that you configured everything correctly but were let down by external factors outside your control. I had been considering converting some personal sites to use HTTPS (and HSTS) with certificates from StartSSL but I wasn’t aware until now that there was such a critical reliance on the CA’s OCSP responder(s).

Solution 2

I had this problem, too, but it was entirely dependent on the browser I used. I got the issue with Firefox only and only occasionally (when the StartSSL OCSP server for my server's StartSSL cert was down).

To fix it in Firefox, which enables you to navigate to your StartSSL site even when their OCSP server is down, navigate to "about:config" and set

security.ssl.enable_ocsp_must_staple

to false.

Comments

[Steffen Ullrich]

".. enabled OCSP pinning" - there is certificate/pubkey pinning and OCSP stapling, but no OCSP pinning

[BenjiWiebe]

@SteffenUllrich Sorry about that, I must have been getting tired. I meant OCSP stapling (and editing to fix).

[BenjiWiebe]

Actually I've been scoring an A+. :) Just now I reduced (drastically) the HSTS duration so if the OCSP responder came up temporarily, people could access the site and then be able to access it non-https.

[BenjiWiebe]

As for StartSSL I've only been having intermittent problems in the last 3 weeks and total outage for less than 48 hours yet (this is the first time of it being down for more than 5 minutes that I know of). Also, if it isn't just my browser's fault, why did Firefox on Windows (with OCSP stapling enabled) allow me to visit the site with https??

[BenjiWiebe]

Well, whaddya know. It looks like the OCSP responder just came back up! Hooray!

[Anthony Geoghegan]

After I last edited my answer, I discovered that OpenSSL also includes an ocsp utility which can be used to diagnose OCSP tasks. However, I’ve been really busy since then and didn’t have the opportunity to investigate any further. Glad to hear the issue has been resolved.

[Anthony Geoghegan]

@BenjiWiebe When I checked earlier today, I wasn't able to access the HTTPS site while using Firefox on Windows. I’m fairly certain that OCSP stapling was enabled (by default).

[Gerrit]

This setting shoud really be called: I WILL require all OCSP staple responses from the webserver to be positive signed responses, or I will BLOCK access to the site, but WAIT, I will grant you two exceptions: (a) I find there is already a valid OCSP response in my own local cache that is valid, or (b) There is no staple response at all in the TLS connection from the webserver, and incidentally, I don't consider the OCSP required setting to be important at all, thank you very much.

[Gerrit]

To clarify. If a webserver tries to indicate that it tried to return an OCSP staple, but was unable to because it couldn't receive an OCSP response itself, and didn't have one cached anymore, and returns a valid TryLater (rfc 2560) response, Firefox in its default settings slaps its user on the wrist by denying access to the website.