Welcome to my first post of 2018! And managing certificates is still a pain! What’s new?
I’ve been very busy since my last post, I became a Sophos certified Security Architect (Woo!), and because they’re so great they gave me some licenses to set up a virtual XG Firewall in my lab.
One of the cool things it does is SSL Inspection, whilst this isn’t a new thing, it is easier to configure than a FirePower module on a Cisco 5506-X. It’s a lot quicker to setup as well (I’ll just leave that there).
So – we all know how this works, you break the certificate chain between the browser and the server and you insert your intermediary, i this case the XG. The XG then forms an encrypted tunnel between itself and the remote server, and then between itself and the client. This last stage is the tricky one as the XG signs the certificate between itself and the client, you will get security warnings and some SSL websites (especially ones that use certificate pinning) will fail to load entirely.
The solution is simple – just install the root certificate from the XG and push that to all your machines through group policy.
I don’t like this solution. I don’t want to push another root CA key to all my clients. I already have a CA my clients trust. Importantly – my mobile clients already trust it.
Managing mobile device certificates without MDM is not great fun, and some MDM vendors don’t allow you to do this at all (Meraki make this very easy, if not immediately obvious). If you have already put your CA root key on those devices, it makes a lot more sense to have any certificate you issue to those clients, be trusted by the certificate they already have.
This is achieved by installing a subordinate CA certificate on the XG. Sophos have a great knowledge base article about it here. It has screen shots and everything, but it depends on using the web interface to the CA, and because I don’t have IIS installed on that server (and have no intention of doing).
You’ll need the following command to generate the certificate from the command line:
certreq -submit -attrib "CertificateTemplate:SubCA" FILENAME.csr
The KB article also asks you to convert the out put of the above command using OpenSSL, however I found the command would not run and I got this response:
C:\OpenSSL\out>openssl.exe x509 -inform DER -in ip-out.cer -out ip-out.pem2 unable to load certificate 9444:error:0D0680A8:asn1 encoding routines:ASN1_CHECK_TLEN:wrong tag:./crypto/asn1/tasn_dec.c:1294: 9444:error:0D07803A:asn1 encoding routines:ASN1_ITEM_EX_D2I:nested asn1 error:./crypto/asn1/tasn_dec.c:380:Type=X509
When repeating the command and trying to troubleshoot I omitted the -inform DER part of the command and it executed correctly, so simply the command to convert the certificate is
openssl.exe x509 -in filename.cer -out filename.pem
Once you’ve done this, upload the certificate to the XG firewall and follow the rest of the KB article to change the Web CA Settings to use this new certificate authority and your internal pages will now show as trusted through their existing domain root CA key.
You probably now want to generate a certificate for the XG itself so that the management and user portals also lose their security warnings. The process is nearly exactly the same as before except this time you use the following command to generate an SSL certificate for the device itself:
certreq -submit -attrib "CertificateTemplate:webserver" FILENAME.csr
Then you want to perform the same openSSL operation on this file, then upload the files back to the certificates section of the management interface of the XG.
A nice, tidy solution for just a little bit more time. Until your certificates expire, then a little bit more time… make sure you review your organisation’s maximum certificate duration.