So it took me a while to figure out why OCSP Stapling wasn’t working on the server I’m building with Adam. I figured I’d write down what I found here to sort of cover my problems. This is by no means a comprehensive list or solution, just what I found worked for me.
It seems that for OCSP to work properly you need to include it in the default server block.
For whatever reason this wasn’t working alone for me, so I also added ssl_stapling on; to the http block in /etc/nginx/nginx.conf
Now OCSP seems to be working correctly on my other subdomains, this appears to be due to a limitation with openssl tests not allowing SNI.
You can test your own OCSP Stapling status using the following command:
openssl s_client -connect your.site:443 -tls1 -tlsextdebug -status
It appears that on the first load it’s not necessarily cached, so try running the command twice back to back to confirm whether you see:
OCSP response: no response sent
OCSP Response Data: OCSP Response Status: successful (0x0) Response Type: Basic OCSP Response Version: 1 (0x0) Responder Id: 90AF6A3A945A0BD890EA125673DF43B43A28DAE7 Produced At: Oct 18 00:36:24 2014 GMT Responses: Certificate ID: Hash Algorithm: sha1 Issuer Name Hash: 7AE13EE8A0C42A2CB428CBE7A605461940E2A1E9 Issuer Key Hash: 90AF6A3A945A0BD890EA125673DF43B43A28DAE7 Serial Number: FD9BEFA92F8BEBCE721B67BED87783E3 Cert Status: good This Update: Oct 18 00:36:24 2014 GMT Next Update: Oct 22 00:36:24 2014 GMT
Best of luck to you in your journey for a better SSL server.
It seems like all the bad things always happen whenever we’re far away from our computers. In my case, I’m trying to purchase a server from a company that seems to sell them as quick as I get them, so knowing right away when they come in is important. Ideally I’d like my whatever device I’m using to let me know right away if something has been made available.
To solve my dilemma, I’ve written a short python script using the chump library to periodically reload the webpage to determine whether or not the server I want is available for purchase. Chump is a pretty awesome python wrapper for the Pushover API that lets you quickly and easily send push notifications to any of your devices, or all of them at once.
Unfortunately, Pushover has a license cost of $4.99, but given what it comes with it seemed like a no-brainer for me to pick this up. Today it’s a simple script to alert me when a server is available for purchase, tomorrow it’ll be server monitoring alerts via push notifications.
Once you’ve created a Pushover account, it’ll give you a user key that is used to uniquely identify you and send push notifications to you. To get started, you’ll want to create an application so you can receive an application key. In this example, we’re going to use USERKEY and APPKEY to denote the string values of your user key and application key.
Once you’ve gotten these two pieces of information and installed chump (pip install chump), you can begin your own notification script like so:
from chump import Application
myApp = Application(‘APPKEY’)
#check to see if we’re authenticated successfully
print “Application Successfully Authenticated!”
print “Application Failed to Authenticate!”
myUser = myApp.get_user(‘USERKEY’)
#check to see if the get_user returned successfully
print “User Successfully Authenticated!”
print “User Failed to Authenticate!”
#We’re not going to check user devices because we want to send to all
myAlert = myUser.sendMessage(“Testing Chump & Pushover!”)
print “Failed to send message! Aborting!”
And now we’ve sent a basic message via Pushover using chump. For more information on chump, check it out on readthedocs. I’m not going to get too far into the details of my automated system, but this should at least get you started sending push notifications to your devices.