Here’s the problem.
Below we see the OCSP response from the server:
$ openssl s_client -connect stephenrank.me.uk:443 -servername stephenrank.me.uk -tlsextdebug -status
TLS server extension "renegotiation info" (id=65281), len=1
0001 - <SPACES/NULS>
TLS server extension "session ticket" (id=35), len=0
TLS server extension "status request" (id=5), len=0
TLS server extension "EC point formats" (id=11), len=2
0000 - 01 .
0002 - <SPACES/NULS>
depth=2 O = Digital Signature Trust Co., CN = DST Root CA X3
depth=1 C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
depth=0 CN = stephenrank.me.uk
OCSP Response Data:
OCSP Response Status: successful (0x0)
Response Type: Basic OCSP Response
Version: 1 (0x0)
Responder Id: C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
Produced At: Mar 8 02:46:00 2018 GMT
Hash Algorithm: sha1
Issuer Name Hash: 7EE66AE7729AB3FCF8A220646C16A12D6071085D
Issuer Key Hash: A84A6A63047DDDBAE6D139B7A64565EFF3A8ECA1
Serial Number: 03589C4650F717DB6AF7369889584429A224
Cert Status: good
This Update: Mar 8 02:00:00 2018 GMT
Next Update: Mar 15 02:00:00 2018 GMT
That serial number matches this certificate: https://crt.sh/?id=323644657
However, the certificate actually being served by the server is a different, newer serial (https://crt.sh/?id=385404236):
So, Apache is stapling an OCSP response for an old certificate, while also using a newer certificate.
When Firefox sees that the stapled OCSP response is for a different certificate to the actual certificate, it decides to bail out.
The solution, I believe, is to force Apache to drop its OCSP cache and fetch new responses. You need to ask your web host to do this (or wait it out, should be fine after an hour I think?)
This is either a terrible, terrible bug in Apache or a terrible, terrible bug in the Let’s Encrypt OCSP responder. I’m honestly not sure which one it’s more likely to be.