[Note: We would especially like to thank the Entrust Datacard team for their contributions to this post and the fruitful collaboration. More info at Entrust Datacard’s Digital DNA blog series and Twitter handle (@entrustdatacard).]
Products and solutions do not operate in silos. In technology, interoperability is a top priority. Thus, making a transition to different communication protocols takes careful consideration and collaboration by multiple parties in order to achieve a seamless operation.
One relatively new protocol is Enrollment over Secure Transport (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.
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 need to ensure that our EST solutions are compatible with third parties such as CAs, authentication servers, and endpoints.
To achieve that, Cisco collaborated with Entrust Datacard to make sure Cisco’s EST implementations are interoperable with their CA. Today we want to share some lessons we learned from our testing. The Cisco and Entrust Datacard collaboration started in 2015. Entrust Datacard 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 Entrust Datacard EST server.
In the process we fixed a few issues and bugs that prevented our code from completing the supported EST transactions securely. The following are some things we learned along the way:
- Sometimes language used in standards can be interpreted differently by implementers. Clear, non-ambiguous language in standards specifications is imperative.
- Underlying library dependencies and design could affect the way new protocols are implemented and can introduce challenges in following the exact standard specification.
The EST operations we tested initially were /cacerts, /csrattrs, /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 Entrust Datacard CA. Cisco products that offer Registration Authority (RA) functionality can successfully allow Cisco IOS an IOS-XE products to communicate with the Entrust Datacard CA using EST.
- libEST fully interoperates with Entrust Datacard CA.
- Cisco EST libraries (similar to libEST) fully interoperate with Entrust Datacard CA.
We look forward to further collaboration with Entrust Datacard and the rest of the industry to achieve a more secure and flexible PKI for the future.