Most of us who have setup a web server have also had to secure said server. If you’re anything like me, SSL is something that is easily understood superficially, but you just know there’s a lot going on down in the depths of the topic which are just waiting to bite you when you’re not looking. If only there were some tool to tell you just what you’re missing. What’s that GlobalSign? You say you’ve made such a tool and it’s free? Well, thank you very much!
I’ve recently setup an internal instance of WordPress which needed to utilize JetPack with the requirement that all traffic be encrypted. Sounds simple enough, especially since I had a valid certificate from InCommon handy. When I finished installing and configuring WordPress with JetPack over SSL, I did a quick test in multiple browsers to make sure they were all able to accept and validate the certificate. Since everything checked out, I tried connecting JetPack…much failure here. But why? The error that I received didn’t really say:
Your website needs to be publicly accessible to use Jetpack: site_inaccessible Error Details: The Jetpack server was unable to communicate with your site https://example.com/blog [IXR -32300: transport error: http_request_failed SSL certificate problem: unable to get local issuer certificate]
I chased down that last part, “unable to get local issuer certificate” thinking that must be important. But, after searching around for a bit, I finally had to give in and contact JetPack support. A very helpful gentleman by the name of Jeremy responded and provided a few openssl commands that I could execute to prove to myself that there was something not quite right with my certificate or its installation on my server. But wait, why weren’t any of the browsers I tested with showing a problem?
The answer to that question came in the form of identifying the actual problem. JetPack communicates via cURL, and cURL is far more picky about trusting certs than browsers. In my case, the problem was that I had “installed” the intermediate certificate chain on the server, meaning I basically put it on the server’s filesystem in the location I expected my certs to be, but then failed to actually configure Apache to use it. Oops. cURL will simply refuse to trust a certificate if it isn’t given the entire certificate chain. Browsers, on the other hand, will gleefully figure out the chain for you and say nary a word that it did so. The way that I finally discovered this issue was via a fantastic web tool from GlobalSign, which can be found here: https://sslcheck.globalsign.com/en_US
In addition to helping me resolve the truly broken portions of my certificate installation, it also provided me with some very helpful tips and tricks to make things more secure and more efficient that I wouldn’t have otherwise thought of. Best of all, it couldn’t be easier to use. Just go to https://sslcheck.globalsign.com/en_US, provide the IP address or hostname of the server you want to check, give it about 1 minute and you’ll get a full report along with recommendations. It doesn’t take the mystery out of certificates for you, but it does keep you on the right path, no matter how versed you might be on the subject.
I asked Jeremy to add a link to that tool on JetPack’s Troubleshooting Tips page if he found the tool as useful as I did. Apparently he did.