This server certificate supports OCSP must staple but OCSP response is not stapled
not sure why that client requested must-staple certificate? you will need to config OCSP stapling or get a new certificate withtout OCSP extension
firefox hard fails in this case, chromium-based browsers doesn't care about OCSP IIRC
it's not likely hosting can give proper must-staple, as nginx skips stapling in first connect, and apache does not preload stapling response
I asked host if OCSP stapling is something they need to enable to resolve this. Host said it isn't something they can change on a shared server and that the certificate (how it's configured I presume) is the issue.
you will need to config OCSP stapling or get a new certificate withtout OCSP extension
Based on my host's response, I presume I can't config OCSP stapling. How do I get a new certificate without OCSP extension?
looks like its the really-simple one snicked it in, you may need different client go get cert from:
I think you will like a php client : certsage? @griffin
in addition to that for some reason kate's client (really simple ssl for wordpress) I think it forces(or at least by default) request cert with OCSP must-staple, and her hosting provider doesn't support stapling so it's broken config she will need new certificate
Thanks, Griffin. I've used the katearbon.pem as instructed but Firefox is still displaying the same warning. Perhaps I need to wait a few minutes more for new certificate file to take effect.
Firefox caches all the intermediate certificate it saw. as firefox problem itself was server reply without OSCP staple when certificate have must-staple extension, you will need a new one:
that script will put that code.txt file on that folder: look into it using ftp(or whatever you use to put a new file there) and copy the text file's content.
I've made some progress. I found the CertSage directory (one directory above web root) and copied the contents of code.txt and pasted it into the code textbox. The form has processed.
I've installed certificate.crt and certificate.key. This appears to have resolved the issue with Firefox.
@griffin How did you generate the .pem file you provided me? I'd like to serve intermediate certificates with the new certificate.generated by CertSage.
Sorry, was away, but back. Yes, the code.txt changes each time the CertSage page is loaded as @orangepizza correctly mentioned before.
I created it manually by retrieving the certificates from Chain of Trust - Let's Encrypt. You won't need to manually do anything though. If you look inside the certificate.crt that CertSage generated, you'll see that both of the intermediate certificates are in that file already because CertSage downloads the correct full chain directly from Let's Encrypt every time you generate a certificate.
If you're giving the interface the certificate file containing the full chain and it's only using the first certificate (your leaf certificate), that's rather strange. Is there a "CA certificate" or "CA bundle" upload?
[...] both of the intermediate certificates are in that file already because CertSage downloads the correct full chain directly from Let's Encrypt every time you generate a certificate.
That's great. The SSL checker you linked to earlier says:
Chain Issues: The chain doesn't contain any intermediate certificates
Yes, because without the intermediates, many browsers may struggle to verify. Many modern ones (like Chrome/Chromium) will be OK with just the leaf though.
If you look inside the 