SSL – How to Enable OCSP Stapling in Apache 2.4

The server is not configured properly — it does not send the required intermediate certificate. Note that there is only one certificate in the certificate chain:

---
Certificate chain
 0 s:/serialNumber=8z3ZNMMt8GMi9Qumrn0xficRkxAYJZQq/C=AU/ST=New South Wales/L=North Sydney/O=SERCO GROUP PTY LIMITED/CN=*.131500.com.au
   i:/C=US/O=GeoTrust, Inc./CN=GeoTrust SSL CA
---

There should be a second certificate after this with the subject s:/C=US/O=GeoTrust, Inc./CN=GeoTrust SSL CA.

In Apache intermediate certificates are configured using the SSLCertificateChainFile option.

As for why this site seems to work for you in Chrome, there are several possible explanations:

1. Different browsers may use separate certificate stores, and your Chrome may have the GeoTrust SSL CA certificate trusted directly (however, this is unlikely to be the case if the CA intended to use that certificate as intermediate).

2. Browsers often cache intermediate certificates in their certificate stores, therefore if you previously had visited another site which had the GeoTrust SSL CA intermediate certificate properly configured, you may then be able to access a site which uses the same intermediate certificate, but does not properly send it to clients, without security warnings, because the browser can get the required intermediate certificate from its cache and is able to verify the certificate chain.

3. The end entity certificate in question contains an HTTP URL which could be used to fetch the intermediate certificate:

       Authority Information Access: 
           OCSP - URI:http://gtssl-ocsp.geotrust.com
           CA Issuers - URI:http://gtssl-aia.geotrust.com/gtssl.crt
   

   (the CA Issuers link here points to the issuer certificate in the DER format). Some systems may be able to use such links to fetch the intermediate certificate even if it is not returned by the server. According to the Mozilla Bug 399324, Firefox (and other software based on Mozilla) is not currently able to follow such AIA links; however, Internet Explorer is able to use them.

If whynopadlock.com and ssltest.net complain about the certificate while ssllabs.com say that things are fine, check your virtual hosts configuration. SSLLabs.com supports SNI while whynopadlock.com, ssltest.net and older versions of IE do not.

When SNI is not supported by the client, no server name will be available to the webserver which will then fallback to the first matching virtualhost. Perhaps you have another virtualhost for testing purposes that takes precedence over your main website.

The solution is to change this order or use a dedicated IP address for this host.