At a certain size a dedicated root and self-signed certificate solution is the only thing that makes sense
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.
A quick refresher on Public Key Infrastructure
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.
TLS Machine Identity Management for Dummies
Enterprises and Public Key Infrastructure
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:
- Private CAs pay for themselves very quickly
- Self-signed certificates can have customized lifecycles
- No fear of third-party revocation
- ·ou aren’t dependent on another company for certificates
- You can automate issuance for Private CAs
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.
Use a third-party certificate management tool with your Self-Signed Certificates
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 third-party CA are superior to Microsoft CA for several reasons:
- They use Microsoft Active Directory as a backbone to automate deployment of certificates
- They come with scanning & reporting capabilities to track your network
- Trusted CAs have development teams that keep the platforms up to date with new integrations without having to dedicate in-house development resources
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.
Get a 30 Day Free Trial of TLS Protect Cloud, Automated Certificate Management.
Related blogs