Online Certificate Status Protocol (OSCP) is a RFC 6960 standard, it is a method to determine the revocation status of a digital certificate. Normally, we need to know about Online Certificate Status Protocol (OSCP) for SSL/TLS certificate installation on any Web Server Software, for example – Nginx. It is alternative means than the use of Certificate Revocation Lists (CRL). The Online Certificate Status Protocol (OSCP) messages are encoded in ASN.1 and usually are transmitted on the HTTP protocol. The nature of OCSP requests and responses makes the OCSP servers are known as OCSP responders. This much theoretical knowledge, described in this article is required, at minimum to work with Online Certificate Status Protocol (OSCP) Stapling.
Online Certificate Status Protocol (OSCP) : Basics
The features expected of a OCSP server and the format of both the request and the response are defined. Both data structures are represented according to the ASN.1 syntax. An OCSP request is basically composed of the protocol version IDs and certificates need to be validated. This identifier is formed by the serial number, the hash of the Distinguished Name (DN) of the issuer of the certificate and the public key hash of it. In a petition may request to consult the status of various certificates, even from different CA. Signing the petition is optional and depends on what you decide to be OCSP Validation Authority.
An answer can return a signed OCSP response, which would mean that the certificate referred to in the petition is “good”, “revoked” or “unknown”. These responses will be used for each of the certificates that have been requested the query. You can also get an error code, in which case the answer would not be signed. Unfortunately, the draft of the first version of OCSP (OCSP v.1) is ambiguous in the sense of “unknown”. It could mean that the subject contained in the certificate is unknown, or that what is unknown is the revocation status of the certificate. The OCSP request format supports additional extensions. This allows more extensive adaptation and a PKI scheme specific configuration.
---
OCSP-based revocation is not an effective technique to mitigate against the compromise of a HTTPS server’s private key. An attacker who has compromised a server’s private key typically needs to be in a Man-in-the-middle position on the network to abuse that private key and impersonate a server.
Online Certificate Status Protocol (OSCP) and OCSP stapling
OCSP stapling is same as the TLS Certificate Status Request extension, an alternative approach to the Online Certificate Status Protocol (OCSP) for checking the revocation status of digital certificates. It allows the webmaster of a certificate to bear the resource cost involved in providing OCSP responses, instead of the issuing certificate authority (CA). In a typical stapling scenario on real website, the certificate holder (webmaster) queries the OCSP server at regular intervals (via settings of the web server), obtaining a signed time-stamped OCSP response. When the domain’s visitors attempt to connect to the site, this response is included (this is why said stapled) with the TLS/SSL Handshake via the Certificate Status Request extension response.
It can appear that, allowing the webmaster to control verification responses would allow a fraudulent website to issue a false verification for a revoked certificate, however, the stapled response is signed by the certificate authority, not the certificate holder (website operator or webmaster), so the stapled responses can not be forged without the certificate authority (CA)’s signing key.
As a result, clients continue to have verifiable assurance from the certificate authority that the certificate is presently valid (or was quite recently), but no longer need to individually contact the OCSP server. This means that the need of the resource burden is now placed back on the certificate holder. It also means that the client software no longer needs to disclose users’ browsing habits to any third party, thereby ensuring robust security.
Online Certificate Status Protocol Stapling on Nginx
Minimum need is Nginx 1.3.8 on Ubuntu LTS releases (14.04) for OCSP stapling. Running this command from SSH :
1 | OLDIFS=$IFS; IFS=':' certificates=$(openssl s_client -connect google.com:443 -showcerts -tlsextdebug -tls1 2>&1 </dev/null | sed -n '/-----BEGIN/,/-----END/ {/-----BEGIN/ s/^/:/; p}'); for certificate in ${certificates#:}; do echo $certificate | openssl x509 -noout -ocsp_uri; done; IFS=$OLDIFS |
shows up two or more URLs, these are the resolver URIs. In our case the response were :
1 2 | http://clients1.google.com/ocsp http://g.symcd.com |
The reverse IP of http://clients1.google.com/ocsp does not work. Second one returns :
1 | 23.5.251.27 |
Other domains hosted on this IP are :
1 2 3 4 5 6 7 8 9 10 11 12 | evsecure-ocsp.verisign.com evssl-ocsp.geotrust.com g.symcd.com gb.symcd.com gtglobal-ocsp.geotrust.com gtssl2-ocsp.geotrust.com gw.symcd.com ocsp.verisign.com sb.symcd.com sd.symcd.com se.symcd.com sf.symcd.com |
g.symcd.com matches with 23.5.251.27. You must already have A+ grade on SSL Labs Test (excludes too much writing on this article). That means, you have this :
1 | ssl_trusted_certificate /etc/ssl/certs/domain.chain.extension; |
on your nginx server. Now you need these lines on SSL server block :
1 2 3 4 | ssl_stapling on; ssl_stapling_verify on; resolver IP.IP.IP.IP valid=300s; resolver_timeout 10s; |
IP.IP.IP.IP is what your certificate will resolve at. After setting the resolver (which people usually copy-paste wrongly and never checks the error log), you can test from SSH :
1 | openssl s_client -connect thecustomizewindows.com:443 -tls1 -tlsextdebug -status |
Here is nginx docs on resolver :
1 | http://nginx.org/en/docs/http/ngx_http_core_module.html#resolver |
Instead of so much big output, we can use cut and grep to pipe the command :
1 | openssl s_client -connect example.org:443 -tls1 -tlsextdebug -status | grep "Verify" |
If you get :
1 | Verify return code: 20 (unable to get local issuer certificate) |
Then try this :
1 | openssl s_client -connect www.thecustomizewindows.com:443 -CApath /etc/nginx/ssl/www.thecustomizewindows.com |
/etc/nginx/ssl/www.thecustomizewindows.com is the path to the certs. www.thecustomizewindows.com is my domain name. It should return the no error code.
So, final stuffs are :
1 2 3 4 5 6 7 8 9 10 | ssl_stapling on; ssl_stapling_verify on; resolver IP.IP.IP.IP valid=300s; resolver_timeout 10s; ssl_stapling_file file; # file should be in the DER format ssl_stapling_responder url; # like # ssl_stapling_responder http://g.symcd.com; ssl_stapling_verify on; |
Your resolver of your own server, usually described in /etc/hosts file. Open the file :
1 | nano /etc/hosts |
You’ll see, usually 127.0.1.1 is assigned against the domain name. If you run this :
1 | cd /var/log/nginx && ls |
Usually, the file :
1 | nano error.log |
Will show the errors related to OSCP Stapling. You need to ping the port from SSH :
1 | curl -I 127.0.1.1:443 |
