Microsoft PKI, aka Active Directory Certificate Services (ADCS), has been a reliable tool for decades. But it’s time to say goodbye.
For several years after it was initially released in the early 2000s, ADCS was the “safe choice” (or, in some cases, the only choice) for organizations looking to implement PKI. Today, however, it’s become one of the most significant vulnerabilities in the infrastructure of the organizations that use it.
Why exactly is it so risky? Let’s dive into the top five security risks and limitations of Microsoft ADCS, along with different options for moving forward.
Top 5 barriers of Microsoft ADCS supporting modern businesses’ IT needs
Unfortunately, in today’s environment, Microsoft ADCS carries potential security risks that can make your PKI feel more like a liability than a core component of your security infrastructure. With that in mind, here are the top five risks and limitations every team using ADCS should know:
1) ADCS has a knack for misconfiguration
ADCS is not inherently insecure, but it is deceptively easy to misconfigure. Over the past few years, security researchers have found several exploits and vulnerabilities due to these widespread misconfigurations, to the point where it was actually listed as one of the top 10 cybersecurity misconfigurations in 2023 by the NSA and CISA.
Some of the most common misconfigurations include:
- Excessive permissions
- Misconfigured certificate templates
- Insecure access control settings
- Vulnerabilities in Windows OS, NDES, etc.
To be clear, even outside of ADCS, misconfiguration is possible with PKI as you issue new certificates. That said, the way ADCS is often set up and used typically opens the door for more opportunities for misconfiguration. This is largely because it’s very hard to find documentation on ADCS, so well-intentioned admins trying to find guidance to avoid some of these challenges are often unable to do so.
For example, there are various ways within ADCS to accidentally allow people to request certificates with whatever content they want – which can lead to a privilege escalation attack, among other risks. For example, this means individuals can get a certificate that authenticates them as someone else. Similarly, looking at Microsoft NDES, there are third-party products that ask you to turn off the challenge passwords on your NDES endpoint, which effectively means that anybody who knows where that endpoint is can request certificates with whatever information they want, including identifiers for other people in the company, like your CFO, your CEO, or one of your lead admins. These are just two examples of many that allow for unvetted or under-vetted content in certificates.
2) ADCS isn’t ready to leave the nest
According to the 2023 State of Cloud survey by HashiCorp, 76% of companies have or plan to implement a multi-cloud strategy. Against this backdrop, Keyfactor and the Ponemon Institute found that flexible deployment is the most important feature for today’s organizations when evaluating PKI solutions.
But the problem is that more than half of organizations say their existing PKI just isn’t capable of supporting the new applications they need as they migrate to the cloud. For many organizations, this existing PKI is ADCS, which doesn’t work well in these cloud environments.
Specifically, because ADCS runs on Active Directory, that connection creates key challenges when trying to operate in a cloud environment. These challenges include:
- Difficulty supporting containerization and automation
- No options for active-active high availability (only active-passive with Microsoft Cluster servers)
- Inability to open to DCOM/RDP ports and other network requirements since cloud communications require a much wider variety of ports than on-premise
3) ADCS doesn’t speak modern IT
PKI supports anywhere from 10-20 different applications across the business on average in modern environments. This includes everything from IIS and Linux machines to load balancers and cloud workloads. And when put against these modern use cases, ADCS starts to show its age and present serious challenges.
Modern use cases where ADCS presents the biggest problems include working with:
- Multi-cloud, multi-OS environments
- Non-Windows devices
- Modern protocols like ACME, EST, and CMPv2
- REST API
This is concerning, as things like EST and ACME are extremely widely used in today’s web-based environments. REST APIs are also very common, and although Microsoft introduced some web-based APIs starting in Server 2012, they don’t cover everything organizations need and are more cumbersome in cross-platform scenarios. In general, the inability to put something behind a web-based load balancer to handle certificate requests, which offers a more modern approach to calling cloud-based services and functions, is one of the bigger hindrances to using ADCS in a multi-cloud or hybrid-cloud environment. In turn, this is where a lot of PKI sprawl originates because if your current PKI can’t support key use cases, teams will go out and find something else that can do it.
4) ADCS can get complex (and costly)
ADCS can get very complex and costly at scale, mainly because Microsoft CA isn’t multi-tenant. Once you reach a certain scale, you need multiple servers and databases, in some cases as many as 70 or 80 servers supporting the PKI.
That’s because ADCS limits you to one CA per machine, which means if you need to install more CAs – either to handle scale or for different use cases, network segments, trust boundaries, or anything else – you need at least one other virtual machine, which is another Windows Server license and another system that you have to back up, patch, and update. That’s a limitation that really doesn’t exist in most other options for certificate services, which offer a lot of ways to spin up additional CAs that aren’t quite as costly from an IT footprint perspective.
All of this leads to another challenge as teams start maintaining a lot of workarounds to make ADCS work, but the cost of supporting those workarounds and maintaining them over time becomes higher as the rest of the ecosystem evolves out of compatibility with ADCS. Plus, it becomes something of an enterprise homebrew that is known by a very small handful of IT people. And as people leave, the knowledge about these workarounds degrades to a point where it becomes a potential risk to keep them running.
5) ADCS hasn’t changed much
The bottom line is that ADCS simply hasn’t changed much over the years. In fact, it hasn’t really seen any major updates since Server 2012. That means as new standards and use cases emerge, ADCS users are left unsupported and forced to find workarounds or switch to other options.
ADCS has never been a strategic piece of software for Microsoft; rather, it’s been a means to an end to solve certain use cases, like on-premise deployments, issuing certificates to things like SCCM or SCOM, and supporting Wi-Fi and VPN authentication. And it still solves those use cases very well. But since it’s not strategic for Microsoft, it has never gotten updates in the same way Office, Windows OS, and Azure have.
Microsoft does currently have a cloud-based certificate issuance capability coming as part of Intune, but at the moment, that’s strictly for issuing certificates to Intune, so it’s not a replacement for ADCS. And as Microsoft continues to invest in Azure, we’re less likely to see investments in all things on-premise, like ADCS.
The one exception here could be for post-quantum algorithms because the entire industry will need to support post-quantum once standards from NIST are solidified. Currently, however, ADCS does not support some of the newer protocols and certificate formats like Matter, SSH, and V2X.
Where do we go from here?
ADCS was a great fit for traditional, on-premise use cases, but in our modern, multi-cloud world, it presents serious limitations. So, what does the path forward look like for organizations using ADCS? There are several options:
- Status quo: One way to fill the gaps of ADCS is to pair it with other solutions for specific use cases (such as PKI built into developer tools or cloud services like AWS Private CA and Google Cloud CA Service). But having so many different issuers can also create complexity, as you wind up with fragmented tools that don’t offer consistent visibility or control.
- Augment: You can augment your ADCS alongside those other PKI solutions with certificate management, which offers a standardized interface and central place to gain visibility and control across all your different issuers.
- Modernize: Taking it one step further, you can simplify and consolidate onto a modern PKI alternative. A modern solution (like Keyfactor’s EJBCA) can support the diversity of current environments, including use cases, platforms, and cloud services found in enterprises today. These important capabilities allow for a smooth migration to a multi-cloud environment and support more modern protocols. If you’re ready to learn more about modernizing, contact Keyfactor here.
- Migrate: Finally, you can offload the infrastructure and maintenance of PKI by migrating to a SaaS-based or managed PKI service. This approach isn’t for everyone, but it can be a good fit for teams who don’t have the resources or bandwidth to run PKI in-house anymore.
Overall, regardless of which approach teams take, we’re seeing a huge movement to PKI in the cloud. Making this shift successfully requires teams to take a more modern approach to PKI, and fortunately, many options exist.
Ready to take charge of your PKI? Our team is ready to help your PKI enter the modern age. Let’s connect.
