At The SSL Store we deal with customers of all sizes, but the group that requires the most specialized SSL/TLS solutions is definitely Enterprise-level business. When you’re securing end points at the Enterprise level, you’re playing a completely different ballgame than SMBs and smaller companies. That’s owed to the fact that there is substantially more surface to cover when securing enterprise environments.
Today we’re going to talk about dedicated roots, self-signed certificates, managing your Public Key Infrastructure and what considerations you need to make as an Enterprise business looking to encrypt thousands of end points.
Let’s start out with a little background.
Public Key Infrastructure, or PKI, is the backbone of the SSL/TLS ecosystem. Understanding how it works will be instructional once we get into self-signing. Let’s start at the trusted root and work our way out.
A root certificate is a standard X.509 certificate that is considered trusted. There are multiple trusted root programs run by the likes of Google, Mozilla and Apple (to name a few). Each one of these stores contains a group of trusted root certificates. Any SSL certificate that is signed with one of those trusted root’s private key will now be trusted by any browser or device using a trust store that includes said root.
In the SSL/TLS ecosystem, Root Certificate Authorities, that is, CAs with trusted roots, issue Intermediate roots to sub-CAs and for their own issuance needs. This helps insulate the root should anything ever happen that would require a revocation. The way it works is that the root’s private key signs the intermediate, then the intermediate’s private key either signs another intermediate root or an end-user SSL certificate (sometimes called a leaf certificate).
As long as the signatures can be traced back to the root, the end-user certificates will be trusted.
Now, let’s package up that concept and apply it to an Enterprise Environment.
Once companies reach a certain size, paying individually (or even in bulk) for commercial SSL certificates is cost-prohibitive (or at the very least, wasteful). That’s why it’s in most Enterprise business’s best interest to work with a CA to set up a custom PKI solution (sometimes called setting up a dedicated root or a Private CA).
With a Private CA, a trusted Certificate Authority works with your company to create its own dedicated root. The root is added to your organizational trust store manually, so that within your own environment it will achieve trusted status. Once this is in place, the CA will generally spin up a few intermediate roots for you to issue off of.
Just as we described before, you simply use the private key from your company’s intermediate root to sign each certificate and as long as the dedicated root that signed the intermediate resides in your organization’s trust store all of those certificates will be trusted.
Now, it’s worth noting that the context we’re discussing here is your enterprise environment—not public facing networks and IPs. Enterprises should still use business authentication SSL certificates to secure those owing to the necessity for public trust in those contexts. But with regard to intranets and company networks, Self-Signed certificates have myriad advantages:
Self-signed certificates give you a more granular level of control over encrypting your enterprise environment. But with that extra control come some new problems. Read about some potential problems you may face with self-signed certificates on a Venafi post on Hashed Out, the SSL Store blog.
The first inclination when discussing self-signed certificates and private CAs is to go with the Microsoft Certificate Authority, which is ubiquitous given Microsoft’s market share. This can be a good decision if you have the time, resources and organizational experience to build out your own certificate management apparatus. But obviously it’s not a turn-key solution.
And this is critical. The biggest challenge most Enterprises face is not setting up their own CA or issuing their own certificates—it’s managing all that. You need to have full visibility, regular reporting, you need to be able to track certificates so that you can make decisions on revoking them or re-issuing for certain end points. Microsoft’s CA doesn’t offer support for any of that. That’s why it’s so important for your organization decide on a certificate management solution at the same time it makes a determination on setting up its own CA. Read about some common PKI management mistakes.
Managed PKI platforms from a 3rdparty CA are superior to Microsoft CA for several reasons:
When done correctly, self-signing SSL certificates can simplify and streamline an otherwise tedious process for enterprise companies. But most businesses can’t do it on their own. You need someone in your corner to help sort through minutiae. Whether that’s a CA, an SSL service or a third-party vendor, the stakes are too high to go it alone.
Learn more about machine identity protection. Explore now.