EJBCA, Microsoft and open source: How Azure brought everything together

It used to be uncommon to mention open source and Microsoft in one sentence. PrimeKey’s open source history is no exception, and used to distance us from Microsoft. Read on to learn about the transformation journey of EJBCA and Microsoft during the past two decades and find out how everything came together in the cloud.

How we learned to stop worrying and embrace Microsoft

PrimeKey has since its inception always been a FOSS shop at heart. With that comes some baggage, in particular in regard to our operating system of choice. Linux has always been the natural choice for a CA software suite written in Java, but following the Java ethos of “compile once, fail everywhere”, EJBCA has always been equally at home in Windows environments. Going back a decade or so, the main reason that most of our customers were Linux-based was due to Microsoft’s homegrown PKI support, which of course in most cases negated the need for a third-party PKI provider. Times change though, and we are eager to adapt.

Over the last decades, the world of PKI has changed dramatically, from being a fringe technology in the early 2000s to becoming a ubiquitous piece of infrastructure in today’s world. EJBCA as a product has steadily changed with it, embracing emerging markets such as IoT and V2X and growing to be able to handle throughput and volumes which would have been considered pure fantasy twenty years ago.

A couple of years age, two things became obvious. Firstly, Microsoft’s legacy CA solution (Microsoft Active Directory Certificate Services, ADCS) was no longer able to live up to the common requirements of today. Secondly, PKI in the Cloud (which I publicly ridiculed many times in the past) is today not only viable but an essential piece of the puzzle. In this area, Microsoft’s endeavors have been laudable; Azure has grown remarkably into a well-designed environment for supporting both full cloud and hybrid solutions. EJBCA is available as an Azure Marketplace app since 2018.

It was now time for the next big step. We had previously supported a third-party proxy that translated auto-enrollment requests into our own web service format, but our new goal was to not only respond to auto-enrollment requests but to actually provide a better home for them than Microsoft ADCS itself. The only way of doing this holistically was to make auto-enrollment support an integral part of EJBCA, just like ACME and EST, and thus eliminating the need for a proxy.

Implementing auto-enrollment in a multi-purpose PKI platform

Customers that were using Microsoft ADCS addressed us to handle mainly either of these two limitations: the limited maximum population size of the Microsoft CA, and the difficulty in supporting multiple forests from a single PKI server. Naturally the two problems were interlinked, with multi-forest support putting demands on population. As the demands on PKI infrastructure are increasing, we have been seeing a common theme among industries and markets to consolidate their PKIs.

Auto-enrollment is admittedly a rather neat protocol, and in many ways was ahead of its time. Controlling both client and server, Microsoft initially solved many of the issues that the ISRG set out to solve with ACME in terms of supporting short-lived certificates and automating enrollment and renewal. In fact, Microsoft managed to make PKI transparent in ways that few other ecosystems had done. That said, being isolated from other ecosystems lead to Microsoft’s PKI, like giant fauna on remote islands, evolving some unique quirks.

EJBCA as a perfect fit into the Microsoft architecture

Microsoft today supports two stacks, the legacy one built on DCOM and the (somewhat) newer one built on web services, implemented as the two protocols XCEP/WSTEP. As web services lie far closer to our own domain, the choice was clear from the outset to go straight to the more modern protocol. This turned out to be a wise choice, because as we explored the architecture, we realized how beautifully EJBCA could insert itself into this environment.

As mentioned above, Microsoft’s PKI functions under some different constraints than most other PKIs, first and foremost being in control of both client and server, and secondly, being in full control of authentication. Authentication is in fact handled entirely out of band as the user logs in to the Active Directory (AD) server and receives a Kerberos ticket in return. Upon enrolling for a certificate, the client calls through the XCEP protocol to receive a bespoke subset of Certificate Enrollment Policies (CEPs), which essentially acts as a laundry list of possible certificates that the currently authenticated user is entitled to have issued. Picking whichever CEPs to ratify, signature requests are then passed up in a predictable manner to the CA through the WSTEP protocol.

The beauty of this scheme is that the entire transaction, as well as subsequent renewals, happens entirely in the background and with no requirements or responsibilities from the end user besides logging in to their workstation.

Our PKI implementation – In true synergy with the Microsoft ecosystem

Our initial implementation made use of our inherent system for multitenancy, familiar from SCEP, CMP and other protocols, which directly fulfilled the requirement of multi-forest support. By being able to communicate directly with Active Directory, our implementation inserts itself and the primary enrollment endpoint for workstations, effectively replacing Microsoft Certificate Services. There were some minor hiccups along the way, primarily due to the insular evolution problem mentioned above, primarily in how Windows handles CRLs, but these were all discovered and solved.

Adding Azure to the game tears down traditional borders

We had already published EJBCA as an Azure Marketplace app. And as the SCEP support also included Microsoft Intune, devices could enroll for certificates from EJBCA, with authentication and validation of those requests coming from Azure itself. 

Now was the time to see how modern technologies could not only change the EJBCA deployment options but also to take EJBCA integration into Microsoft ecosystem to a new level.

Moving past the functionality described above, we started looking into how we could continue to synergize with Microsoft’s ecosystem. Thus, we were the first to implement their revocation API for Intune, which was the result of a close collaboration between teams at Microsoft and PrimeKey. Correspondingly, we implemented support for both Azure Key Vault (AKV) and Microsoft’s FIPS 140-3 certified Azure Managed HSM (MHSM) for key storage. We also made Azure OAuth a primary target for our own OAuth support, which in the coming release of EJBCA has been extended to allow EJBCA’s Roles to be fully managed from within Azure AD.

The future of Microsoft and EJBCA – There’s more to come

Looking into the future, we’re planning to integrate the MSCS Key Recovery Server with our own key archiving and recovery functionality, implement TPM key attestation to be able to assure that signed keys reside in secure memory spaces, and continue to evolve PKI hand in hand with Microsoft, with a focus on cloud and IoT.  This will continue with the release of EJBCA SaaS in Azure and deeper native EJBCA integration into Azure IoT.

All in all, here at PrimeKey by Keyfactor we couldn’t be more pleased with how we and Microsoft have over the years matured from being competitors to confederates, and we’re looking forward to continuing to make the world more secure, together. 

As of June 2021, PrimeKey is a part of Keyfactor.

Contact us