Every Certificate Authority (CA) worth its weight provides a management solution for the certificates that it issues. Many of these are quite good and provide a great deal of beneficial functionality. It goes without saying that this type of focused information represents a significant operational boon to organizations. But is it enough? Most organizations use more than one public CA as well as one or more internal CAs. So juggling interfaces is the first problem that comes to my mind. But are there other factors that I was missing?
Certainly, machine identity protection adds a level of security above and beyond standard certificate management. But as I thought more about this, I began to wonder if machine identity protection would offer additional operational benefits—especially if it was integrated directly with leading CAs. So, I asked my go-to Venafi architect, Bill Madell. I hope his responses were as enlightening to you as they were to me.
What’s the biggest reason to integrate machine identity protection with your CA?
There are a lot of reasons. But I’d say that the top one is to gain a single pane of glass, which will give you consistent visibility across CAs. Every CA has its own interface and chances are that you've dual-sourced your public CAs. But it goes beyond that as well. Most large enterprises will generally have at least one other CA technology, and that would be their internal PKIs. Those could range from your straightforward Microsoft PKIs to other types of open source or commercial off-the-shelf CA software. And every CA will have its own logic and way that you can actually talk to it. By plumbing multiple CAs into an integrated platform for machine identity protection, you only have to worry about one interface to get a certificate from any integrated CA.
Does integrating with CAs limit you in any way?
No. Actually, integrating with CAs gives you more flexibility—especially if you ever need to switch CAs. The switch may be motivated by something like an emergency situation, such as when a CA has been put out of business or distrusted by Trust Store Providers. Or you might simply find a better overall commercial package from another CA. In either case, you don’t want to have to go through a potentially painstaking process to re-enroll everything manually through another CA's interface. With an integrated platform, you just simply change policy. Once you're plumbed into the new CA, you can either bulk rotate all of your certificates over to the new CA right then and there, or as they naturally expire, they will be renewed against the new CA.
How does integrating with CAs impact the process for requesting certificates?
I would say that integrations radically simplify certificate requests. Because when you implement consistent policies, you can lock down some standard data fields (e.g. key length, Distinguished Name attributes, etc.) via policy and remove much of the data input often required of end users. With self-service, the certificate requester is only required to provide minimal information as most of the data will be predefined by policy. The user only needs to enter specific information, such as subject alternative name/s. So, the process becomes more efficient—and less error-prone—by removing unnecessary choices. I realize that may sound almost counter-intuitive, but removing choices does actually simplify things for everyone by eliminating mistakes.
Why should you standardize policies for certificate requests?
When you enforce certificate policies, you eliminate non-conformant request from being sent to CAs. The integrations allow PKI teams to double check new entries against policy. So, if a user enters a domain name which doesn't match a policy configuration, the integration won’t allow the user to continue until the errors are fixed. Centralized policy definition and enforcement ensures the correct key size is used and automated policy enforcement is always going to include the correct values in a certificate request. When this basic information is provided and locked, the user has no opportunity to change it because the policy is being enforced. They don't even have to see the locked policy values—which removes data clutter and therefore, user confusion, when they have to create a new certificate request.
How does the integration give you more control over workflows?
You can add an overlay for approvals workflow. Before a certificate can be issued, it may need an approval for a variety of reasons. Maybe the finance team needs to approve a certificate request because it's going to cost money. Maybe the operations or security teams just want to have a look at the certificate before it goes out to the CA. With an integrated solution, the approver receives notification that there is a certificate requiring review and approval. This provides approvers with a vehicle for reviewing the request (in order to approve expenditure on a certificate or identify any errors in requestor-provided data). But even better, you can eliminate many of the errors of the manual process if you use the integration to automate provisioning. Automation removes the element of human error as much as we possibly can. Even when there is potential for human error, an approval workflow overlay will allow for an extra set of eyes before it goes to the CA.
Using a single platform to protect your machine identities has several benefits. With the best platforms, you get a nice simple, easy to use interface which gives you a single pane of glass to see all of your certificates. Even if you are dealing with countless CA's, you’ll still only have one place to go and one interface to learn. You’ll get crypto agility that allows you to act quickly in the event of a CA error or distrust. You’ll be able to eliminate human error through policy enforcement. And applying an approval workflow allows you to double check certificate requests before they actually get sent off to whichever CA you've defined by policy.
Are you ready to integrate machine identity protection into your CAs?