������

In our fourth and final interview on building a scalable PKI, we ask Darin how we should automate certificate management. But first, let’s recap the series up to this point: We started by giving you a high-level overview of some of the critical PKI use cases. We then delved into the difference between public and private PKI. Next, we presented information to help you figure out whether your private PKI should use a hosted or internal CA. Now, we move on to considerations for automating certificate management to turn your PKI into an efficient machine. But, how do you do that? We start by asking Darin about tools that help organizations automate certificate management.

What tools do I need to automate certificate management?

DA: In past interviews, we talked about using certificates on your organization’s devices, so that when they connect to the Virtual Private Network (VPN), they must provide their username and password, plus a certificate. Your next question will probably be, “Are there any certificate management software solutions out there to automate this?”

However, if you already have enterprise device management software (which you likely do, depending on the number of devices you manage), I’d suggest finding a CA that will work with you to deliver certificates down to your devices by integrating with those software solutions you’re already using to manage your devices. A good example of this is our REST API integration with Venafi.
��

How do these integrations for automating certificate management work?

DA: One of the things you should find out is whether the CA you’ve chosen offers APIs for you to program against. When I say program against, I mean that you can use the RESTful API endpoints as part of the programming you’re doing on your side.

This could be full programming where you start from scratch to create scripts that are kicked off by a service. For example, devices might hit the server. The server then kicks off the script that hits the API endpoint, requests the cert, pulls the cert back down, and passes it to the device.

Another example is a software that’s already written for some of the certificate management, but you need to write a little piece that says, when the cert gets requested, send that cert request information off to this script, and that script ends up being sent to the API.

What are some examples of software that can integrate to automate certificate management?

DA: This model can be applied for a variety of software solutions, including Venafi, AirWatch, Casper, Tanium, and others. These solutions are already written to manage delivery of packages down to your laptops and other devices.

For example, Venafi allows you to install an agent on the server. Then, the Venafi server can speak with that agent to manage the SSL certificates. Venafi has worked to integrate with CAs, like ������, and even private CAs like Microsoft CA for certificate issuance.

For example, the Payment Card Industry (PCI) requirements govern how enterprises that deal with people’s credit card information must manage their services. Some of these requirements involve knowing what’s on the device. If you fall into this category, you likely already use tools like Venafi, Airwatch, or Casper.

Are there options other than API integrations for certificate management?

DA: Another option is Simple Certificate Enrollment Protocol (SCEP). This requires a SCEP agent on the device, and works in conjunction with enterprise device management software. The software sends a script down to the device, telling it to go get a cert and providing the configuration information to hit the SCEP service.

Then, the SCEP service takes it from there to get a cert on the device. The benefit of this is that any device that supports SCEP (Android, Microsoft Windows, Apple, Linux and other operating systems support SCEP agents) makes it quicker to go from proof of concept to production because it’s already an established protocol.

So, the benefit of SCEP is that the agent already knows how to request and retrieve certificates to the device. The agent will automatically put it into the operating system’s key store. Some enterprise device management systems have this capability, but this is a question you should ask your software provider. If your software has this capability, something like the ������ REST API could take the place of the SCEP agent.

As the successor to SCEP, Enrollment over Secure Transport (EST) is almost identical, except that EST supports Elliptic Curve Cryptography (ECC).

The fourth major option for automating certificate management is Microsoft Active Directory (AD) Auto-enrollment. This can be used for automating certificate delivery to the Microsoft Key Store on all Windows PCs and servers.

For servers, Internet Information Services (IIS) uses the Microsoft certificate store. Other Microsoft services, like Exchange Server, use the Microsoft certificate store. But, other web services can be installed on Windows that don’t use the Microsoft certificate store. If you’re running a Tomcat server, the cert would need to be extracted out of the Windows store to be used by the Tomcat service. It would need to be in a Java Key Store file instead.

In this scenario, it might make more sense to use a RESTful API for automatic spin up of those server types. Let’s say you have a big project where you’re going to have to spin up and spin down servers that are running a Tomcat web service, and each one needs a certificate. If you want to automate everything using scripts, you would be better off using a RESTful API.

So, how do I know which of these solutions is best for my network?

DA: Deciding whether to use an API, SCEP, EST or AD Auto-Enrollment depends in large part on the technology you’re dealing with. It can also depend on the key type. For example, SCEP works for certs that are the RSA key type, but if it’s Elliptic Curve, SCEP won’t work—EST will.

What it breaks down to is the technology you have in place. If you’ve already been using Microsoft AD, it might make the most sense to use AD Auto-Enrollment. If you have enterprise device management tools that support API integrations with a CA’s API, you can move certificate management into your existing workflow that way. No matter what mix of technology you’re working with, a RESTful API can be customized to fit your needs.

What if I’m a manufacturer of connected devices?

DA: For the Internet of Things (IoT), a RESTful API usually works best for automating certificate delivery to connected devices. These manufacturers are writing the software on the devices. They’re writing the cloud services software. They know how to talk to their devices. To add in certificates, it’s just a simple question of adding a simple piece on their cloud service that knows how to talk to the RESTful API.

So, you have four major options for automating certificate processes:

• RESTful API
• SCEP
• EST
• AD Auto-enrollment
  
  

Well, that wraps up our series on how to build a PKI that scales. How would you summarize the entire series?

DA: I’d summarize building a scalable PKI in six steps:

As a security engineer, your first step is to evaluate your own environment. This is something I’m always walking through with customers. There are always certain “must-dos”—You must protect your web services for data entry, you must protect your databases for access to knowledge, you must protect your network from external access, you must verify authenticity of messages being transferred on your network. These are high-level concepts, but as a security officer, if you define these concepts first, a bunch of issues fit under them.

Then, with your knowledge of PKI, you can use signing to identify the sender of a message, encrypt and decrypt messages, protect your network for access, and more.

Next, you’ll want to understand what devices will need certificates. From there it’s a question of how to get certs down to these devices, and whether your device management software can help you do this via API integrations.

These steps will give you greater confidence and a higher success rate as you seek buy-off from senior management. Good luck!

We’d like to thank Darin for his expertise and for taking the time to do this interview series on building a scalable PKI.

If you’d like to chat about your own PKI needs with Darin, or another ������ PKI architect, call 1.801.701.9690 or email enterprise@digicert.com.

Discover how PKI unlocks a connected world of possibilities; read our PKI eBook.

��