SSL inspection (aka SSL/TLS decryption, SSL analysis, or deep packet inspection) is an increasingly hot topic among enterprise IT. I’m not here to argue whether you should or shouldn’t be doing this. Working for a CA, I struggle with this concept because I believe in the fundamentals of encryption, but more and more companies are implementing because encryption does not necessarily mean the content is safe. If you are investigating or implementing SSL inspection, you should consider ways to do so in a safer, well-managed way.

This is why I want to talk about an aspect of implementation that many people may not be aware of – in fact, I know many people are not aware of it because everyone is surprised when they hear it’s possible – using a custom private issuing CA to generate the decryption and re-encryption certificates.  

That’s right, instead of relying on self-signed CA certificates or the CA certificates provided by the SSL inspection appliances, you can leverage a dedicated issuing CA from a third party CA like GlobalSign. But before we get into that, let’s do a quick refresher on the topic in general. 

What Is SSL Inspection and Why Is It Used?

More and more public websites are moving to HTTPS, which means communications and data sent between the webserver and client (i.e. an end user browsing the internet) are encrypted (which is over 60% of all web traffic, according to SonicWall).

While this move to encryption everywhere can obviously be a very great thing – protecting credit card payments, login credentials, etc. – unfortunately, some bad guys have started hiding harmful or malicious code in this encrypted traffic. This means IT’s common defences, such as Intrusion Prevention Systems or Data Loss Prevention, are bypassed and the scary stuff is getting right to employee machines.  It’s also worth noting that this trend of hiding malware in encryption has increased 72% over the past year and is probably only going to continue to grow, thanks in part to the growth of free SSL providers, like Let’s Encrypt, that make it very easy to acquire low assurance, Domain Validated (DV) certificates. It is becoming increasingly hard to tell if a “secure” website is actually a “safe” website.

SSL inspection helps mitigate this threat by essentially sitting between end clients (i.e. your employees browsing the web) and webservers and filtering out the bad stuff. There are a number of inspection appliances on the market today, but the processes are basically the same. When HTTPS content is exchanged between a client and a webserver, all traffic passes through the inspection appliance where it’s decrypted and inspected for anything malicious.

Once inspection is complete, the appliance creates a new SSL session with the end client to decrypt and re-encrypt the content. This is the part I want to focus on – those new SSL sessions and the issuing CA that creates them.

How the Decryption/ Re-Encryption Process Works

In order for the SSL inspection appliance to decrypt and re-encrypt the content before it’s sent back to the end users, it must be able to issue SSL Certificates on the fly. This means it needs a CA certificate (sometimes also called an intermediate or issuing CA) installed on it.

Another key factor here is that in order for those on-the-fly SSL Certificates to be trusted in browsers (i.e. not trigger scary warning messages like the one seen below every time employees visit a site that’s been re-encrypted), the CA chain (or hierarchy) must be in the browser’s trust store. Since these certificates aren’t issued from publicly trusted CAs whose roots and intermediates are already embedded, you need to manually push the CA hierarchies out to all end clients. 

Warning message for self-signed or untrusted roots in Chrome (source: BadSSL.com)

For Windows machines, this process might not be that painful since you can leverage Active Directory and Group Policy features, but what if you have mobile devices, Macs, or Linux? Anything non-Windows is generally going to be more complicated.

You also have to consider if you already have other roots to maintain and manage as well, including any self–signed, Microsoft CA, or OpenSSL-based roots that you may have within your enterprise. These can quickly add up. How are you protecting the private keys? Or making sure none of them expire on you unexpectedly? How do ensure what root to use for each of your use-cases.

There's a Better Way – Use a Private, Dedicated Root From a Third Party CA

If trying to manage multiple roots or relying on self-signed certificates doesn’t appeal to you, you should know that those aren’t your only options. You can work with a third party CA instead (note: not all CAs support this; GlobalSign does). Now you may be wondering, “wait a minute, I thought you couldn’t use publicly trusted certificates for SSL inspection appliances?” You’re right – in this case, the certificates would be issued from a private issuing CA that chains up to a dedicated, private root CA created for your company that GlobalSign manages.

 

Example (simplified) architecture for dedicated customer roots

So how does this set up eliminate some of those headaches I mentioned earlier? Well for starters, it can minimize the number of roots you have to manage and push out. With this option, you can have just one private root for all your internal PKI needs with as many intermediate CAs as you need chaining up to it. For example, the diagram above shows a multi-tier hierarchy where one of the issuing CAs (or intermediate CAs, whatever you call them) is used for SSL inspection/decryption activities and the other issuing CA is for internal machines (laptops, servers, desktops, etc).

While the SSL appliance use case does require that specific issuing CA to be hosted by the customer (because it has to live on the appliance itself), the top-level root CA is hosted by GlobalSign. We handle securing and protecting the private key and stay on top of expiration for you. This also means you only have to push out that top-level root CA and all certificates issued from any subordinate CAs will be trusted as well.

Another benefit to this approach is if you needed to revoke the appliance’s issuing CA for any reason. We would just create a replacement issuing CA for you, which could tie back to your original private root and you could essentially start using immediately. You wouldn’t have to worry about pushing any roots out since it would also chain up to that already trusted root CA.

Let Us Handle Your Internal PKI Needs

The SSL inspection use case is the latest in a growing trend of more enterprises relying on internal or private PKI. Other common use cases include certificates for user or machine authentication, SSL for internal servers, and configurations that aren’t allowed in publicly trusted certificates per CA/Browser Forum requirements.

If you’re considering internal PKI for any of these applications or others, or if you’re currently managing your own PKI in-house, you should know that outsourcing to a third party CA is an option. Managing CAs and trust anchors, both public and private, is what we do – let us handle this for you.