Thanks to DigiCert for their contributions co-authoring this post.

Interoperability for technology solutions is a top priority—standards used in these solutions become irrelevant when products operate in a silo. Thus, shifting to a new protocol in any solution takes careful consideration and collaboration by multiple parties in order to achieve a seamless operation.

One such protocol is Enrollment over Secure Transport (EST). EST provides secure digital certificate provisioning. Some of our products already support EST for digital certificates (e.g., Cisco IOS and IOS-XE), but EST endpoints don’t just operate by themselves. EST involves a certificate consumer and a certificate provider, usually called a Certificate Authority (CA). We needed to ensure that our EST solutions are compatible with third parties such as CAs, authentication servers, and endpoints.

To achieve that, Cisco collaborated with DigiCert to make sure Cisco’s EST implementations are interoperable with their CA. Today we want to share with you some lessons we learned from our testing.

Why EST?

EST is a standard (RFC7030) designed to improve the provisioning and management of digital certificates. At Cisco, we believe EST will be the chosen protocol for certificate management in industries that need more flexible and secure certificate registration. We have blogged about this before and have written about how EST compares with SCEP and other certificate management protocols, and why the industry has started to shift to EST.

About the Testing

The Cisco and DigiCert collaboration started in 2015. DigiCert provides the CA functionality (issuance and certificate lifecycle management) while our solutions are direct certificate consumers, clients themselves, or enable other clients to provision certificates from the CA.

Our goal for testing was to get the Cisco EST functionality that is embedded in our products to interoperate with the DigiCert EST server.

In the process we discovered some bugs that prevented our code from completing the supported EST transactions securely, but we fixed the issues. The following are some things we learned along the way:

• Clear language in standards specifications is imperative. Implementers commonly interpret RFC text incorrectly, which can lead to interop issues.
• Workflows defined by different use cases can lead to slightly different implementations. For example, the EST protocol defines certificate and basic HTTP client authentication. Depending on the use case, both authentication mechanisms might not be necessary. Thus, two different implementations could support different client authentication which leads to interop issues.
• EST clients and servers do not always have the same requirements. For example, it’s important for the certificate providers to have the functionality to distinguish between certificate profiles of the client requesting the certificate, which is not a requirement at the client side. We found that path segments were needed at the CA EST server to map clients to different certificate profiles which also needs to be supported by the client.
• Library dependencies could introduce issues. For example, we found that manually parsing HTTP headers on one side and using common HTTP libraries on the other revealed improper header processing in the manual parsing code which prevented the EST exchanges from completion.

Interoperability Success

The EST operations we tested initially were /cacerts, /simpleenroll and /simplereenroll. After concluding our first phase of testing, we have confirmed that:

• Cisco IOS and IOS-XE products require feature enhancements to successfully interop with the Digicert CA. Cisco products that offer Registration Authority (RA) functionality can successfully allow Cisco IOS an IOS-XE products to communicate with Digicert CA using EST.
• Cisco products leveraging the Cisco EST libraries (similar to libEST) can successfully communicate with Digicert CA using EST.
• libEST fully interoperates with Digicert CA.

Authentication and certificate management are needed to establish device identity, which is increasingly important in a connected world. Interoperability between the DigiCert CA and Cisco products is needed to establish this identity through EST. We look forward to further collaboration with DigiCert and the rest of the industry to achieve a more secure and flexible PKI for the future.

Note: We would especially like to thank Rick Roos for the fruitful collaboration and other members of the DigiCert team for discussions that led to the improvement of our code and the protocol implementation.