Limits of Microsoft Active Directory Certificate Services

Active Directory Certificate Services have existed (albeit under a different name) in their basic form since Windows NT 4.0. The architecture based on Active Directory used today was introduced with Windows 2000 Server. AD CS are very well integrated into the Windows ecosystem and continue to be very popular in enterprises and government agencies of all sizes worldwide.

People like to point out the many possibilities offered by Active Directory Certificate Services. Rarely, however, is reference made to what can be done with them. not is possible. In the meantime, the product has also reached its limits in many places.

What these are will be explained in more detail below in order to better decide whether the AD CS can be the right solution for planned projects.

General

The product is not open source, so (further) development takes place behind closed doors and is not transparent to the outside world. The product documentation is partly outdated, incomplete and distributed over many different media (including books, articles only available via archives, and individual blogs).

As of today (2022), there is no known active further development of the product by Microsoft anymore (in the recent Windows Server 2022 release, exactly nothing was changed at all in AD CS. Security updates are only incorporated half-heartedly). In some cases not even Bugs known for years Fixed.

As a result, many restrictions and necessary workarounds are necessary in the meantime, so future security is at least questionable.

There is currently also no replacement or follow-on product available or announced by Microsoft as a cloud service in Microsoft Azure.

Currently, there is also no known plan for dealing with the issue of post-quantum cryptography (composite/hybrid certificates) in conjunction with the AD CS, cryptoagility is limited due to the dependency on the crypto libraries in the Windows operating system. Modern algorithms like EdDSA (especially interesting for IoT use cases, others are already further along here) are not usable with AD CS.

Microsoft-affiliated author Roger A. Grimes writes in his book "Cryptography Apocalypse" that Microsoft has at least successfully tested the AD CS with (experimental) quantum resistant algorithms, so that these could be used (i.e., presumably, integrated into a new version of the product) as soon as it is required (and the standardization process is completed).

Certification Authority

Design

From the point of view of PKI technology, it is possible to run multiple certificate authorities on the same server without any problems. Manufacturers like Nexus or PrimeKey are already successfully demonstrating this, and the same applies to open source projects such as OpenSSL or OpenXPKI.

However, because of the binding to the Kerberos identity of the certificate authority server, Active Directory Certificate Services requires that a complete Windows Server instance be run for each logical certificate authority.

Likewise, at least one certificate authority is required per Active Directory forest (note that to address this problem, there is a Third-party solutions).

Subsequently, the same applies to various combinations of Hash methods (e.g. SHA-1 for legacy applications in parallel to a hierarchy using modern algorithms) and key types (RSA, ECC).

In large companies, it is common for Certification bodies are divided and restricted per intended use, and also that there are multiple Active Directory environments as well as certificate authority hierarchies, which inevitably leads to an unnecessarily large number of certificate authority servers, all of which need to be managed, hardened, updated, maintained, and ultimately paid for.

This is very annoying not only, but especially for offline certification authorities, since a separate server is needed for each of these as well, and these servers generate a particularly high relative workload due to the lack of central management, despite the low certificate volume.

But even the configuration of online certification authorities (where it makes sense) can only be done centrally with a lot of effort (for example with PowerShell Desired State Configuration (DSC). Although there are corresponding projectswhich, however, only partially represent the required functionality so far).

A generation change between multiple hierarchies is also subject to the same constraint and creates an unnecessarily large number of servers during the transition.

The operation of Windows servers should not really be the main occupation of PKI operators. The overhead generated by the outdated architecture (operating system, management components, antivirus, scripts) increases enormously very quickly and, in addition to a high system load, also generates corresponding costs and an avoidable negative ecological footprint.

The used "Key Storage Provider"The interface is not designed for use with network appliances. For example, if one uses a network hardware security module (HSM) and the connection to it is briefly interrupted, the certificate authority service is no longer able to use the certificate authority's private key, Certificate requests fail accordingly and revocation lists can no longer be issueduntil the certification authority service is restarted.

Separation of certification authority (CA) and registration authority (RA)

There is no clean separation of certification authority and registration authority:

The Requesting certificates via RPC/DCOM is only possible directly against the certification authority, so an online certification authority must be exposed to all clients on the network, which can pose an increased security risk.
The decision whether or not to issue a certificate is made directly at the certification authority, not at an upstream Registration Authority.
The Network Device Enrollment Service (NDES) is often referred to as a registration authority, but it does not meet the criteria for such an authority. It cannot sufficiently check and prefilter certificate requests. NDES is more of a protocol conversion than a true RA. Such certificate requests could, however, be processed via a self-developed Policy module like TameMyCerts are (predominantly) intercepted on the side of the certification authority.
The same applies to the Certification Authority Web Registration (CAWE).
The Certificate Enrollment Web Services (CEP and CES) also do not fulfill the criteria for a Registration Authority, since certificate requests are passed on unchecked and are only evaluated by the Certification Authority's policy module, i.e. directly by the Certification Authority, i.e. this is also more of a protocol conversion than a proper Registration Authority.

There is no support for implementing true high availability (see the Certification Authority Database section). This means that the product is not actually "enterprise-ready".

Installation routine

The hard-coded default settings during installation or role configuration...

...require Enterprise Administrator permissions to install the certificate authority (see also the section on certificate templates here). In the case of the certification authority, the permission can be delegated, for NDES there is an unofficial workaround, but in the case of CEP/CES, there is no chance, so its use in security-conscious corporate environments may be limited or not possible at all.
...allow any installed certification authority to issue logon certificates for Active Directory by registering the certification authority certificate in the NTAuthCertificates object. Although this can be changed afterwards, it contradicts the Secure by Design, Secure by Default principle.
...bind the Standard certificate templates for exhibition immediately after installation, provided that during installation. not explicitly preventedso that there is a great risk of unwanted/unmanaged certificates being issued immediately after installlation (at this point, no configuration of, for example, CDP/AIA and no functional test has yet taken place).
...gives the Windows firewall in the default setting also for the Remote administration interfaces of the certification authority free, which unnecessarily increases the attack surface.

Active Directory Integration and Certificate Templates

Certificate templates are stored in Active Directory. In large environments, these often have to be created by manual request from another team, which prevents automation and slows down processes.

There is no official way to script, i.e. automate, the creation and editing of certificate templates. Even if there is unofficial ways, even from (former) Microsoft employees themselves Microsoft takes the position that this procedure has not been tested and therefore cannot receive product support.

No individual AIA/CDP addresses can be defined via certificate template settings. The configuration always applies globally to all certificates issued by a certification authority, although this could technically be broken down to the respective certificate types. If a distinction is required here, another certification authority must be established (see section "Design").

Certificate authorities that are not integrated into Active Directory ("standalone") have no possibility at all to define certificate profiles analogous to the certificate templates stored in Active Directory.

LDAP revocation lists can be maximum 10 MB in size (due to a limitation in Active Directory).

The administration of the certification authorities is bound to the Active Directory accounts of the respective forest. In large enterprise environments that have multiple Active Directory forests (if only because there is also a test and staging environment), PKI administrators are thus forced to use multiple user accounts for different environments (unless a trust relationship is established between the environments) and the certificate authorities cannot be managed centrally (i.e. across multiple Active Directory forest boundaries) (if - as is usually the case - a trust relationship is not established).

For authentication and Certificate Enrollment across a position of trust must be mutual.

Since certificate authority servers are members of Active Directory, they can also be compromised by it in a variety of ways (group policies, logins of unauthorized accounts with administrator privileges, compromised service accounts).

The same applies to revocation list publication and requesting the OCSP-Authentication certificates. These are authenticated with the Active Directory mechanisms, so that the (often Internet-connected) security-critical revocation lists/OCSP servers are usually located in the same Active Directory forest as the certificate authorities and are often administered with the same accounts. This increases the risk that a compromise of a blacklist/OCSP server will spread to the certification authorities.

In addition, for the OCSP responder (if one wants to use the automatic application and renewal of the OCSP password signature certificate), a separate (sensibly highly available) instance of the online responder must be implemented in each Active Directory forest.

The Requesting certificates via RPC/DCOM with and without AutoEnrollment breaks down the applicant's identification to his Kerberos identity (his Windows logon). Since this is usually only done by entering the user name and password, the identification of the applicant for a certificate by the certification authority is ultimately no stronger than that knowledge of a user name/password combination was verified.

Certification Authority Database

The number of issuable Subject Alternative Names is limited: Certificate extensions can be a maximum of 4 KB in total (due to limitation of the certification authority database).

The certification authority database can manage a maximum of 2,147,483,647 certificates (32-bit or 4-byte signed integer, database schema limitation). Effectively, however, the certification authority database becomes increasingly sluggish in queries with increasing size, so that it is hardly suitable (if at all) for more than a few million certificates.

With regard to data protection, it should be noted that there is also no automatic housekeeping for expired certificates (to meet the requirement for deletion of personal data when the purpose of collection ceases to apply). Such a project can only be implemented by script.

The Certification Authority database (Microsoft JET Blue Engine) is implemented monolithically per server, it cannot be consolidated across multiple certificate authorities and must be run directly on the respective certificate authority servers.

The Certification Authority database allows Database queries only with the provided proprietary interfaces and that too only to a limited extent, but these do not scale well with large amounts of data and require Workaroundsto be used in a meaningful way. Too many queries running simultaneously against the certification authority database can even block certificate and revocation list issuance.

It does not allow to search for empty fields (e.g. an empty Common Name). The only possibility here is to read out all records and search for such entries with Windows PowerShell, for example. However, as the size of the database increases, such exports become slower and more time-consuming, so that they can no longer be realized with on-board tools.

Undefined Relative Distiguished Names (RDNs)if allowed and used, are not indexed in the certification authority database.

It also does not store/index any identities contained in Subject Alternative Names, these are only identified by Reading of the certification authority database and programmatic evaluation of the raw certificate data thus obtained possible. The same applies for the new proprietary certificate extension added in May 2022which is supposed to increase security, but is passed undetected in offline certificate templates.

The certification authority database does not allow advanced database queries as would be the case with a relational database system such as an SQL server.

The certification authority database does not allow storage or linking of meta-information (e.g. an e-mail address of the certificate holder or data required for a billing of the service) in case of manual Certificate Enrollment or generally the extension of the database schema.

The certification authority database does not allow database replication for true clustering (in the existing cluster implementation, only one cluster node can and may access the database files via the file system at a time, otherwise data corruption occurs very quickly, which is diametrically opposed to the intended high availability).

Certification Authority Service

Changes to the configuration of a certification authority require a restart of the service with a corresponding interruption of availability (see also topic Clustering).

Policy module

The supplied Windows Default Policy module does not allow the definition of rules for manual certificate requests. This very often results in errors during certificate issuance (forgotten attributes, syntax errors are not recognized, multiple CNs are possible, false issuances with security implications, etc...).

The functional scope of the certification authority's policy module is not directly extensible. After all, there are Code examples to develop your own policy modules.

With TameMyCerts a policy module is now available under an open source license that significantly extends the functionality of the Windows Default Policy Module while retaining the basic functionality provided by the original module.

Interfaces

As of today, Active Directory Certificate Services does not provide support for the following interfaces:

Enrollment over Secure Transport (EST)
Automatic Certificate Management Environment (ACME) (but there are 3rd party solutions from different Providers)
Certificate Management Protocol (CMP)
REST- or SOAP-based interfaces for the Certificate Enrollment are also in vain.

Thus, the only reasonably usable interface for certificate requesting in most cases is RPC/DCOM left - a proprietary interface designed over 20 years ago for on-premise infrastructures and nowhere near optimized for a cloud-native world. The interface is also limited to Active Directory authentication methods and forces certificate authorities into the Active Directory ecosystem.

The existing protocol conversion interfaces also suffer from quite a few limitations.

Network Device Registration Service (NDES)

The as Network Device Enrollment Service (NDES) known implementation of Simple Certificate Enrollment Protocol (SCEP) suffers from the following limitations:

It is not possible to define guidelines for the Certificate Enrollment (e.g. allowed certificate content) (however, it is an API for your own implementation of a policy module available, but for which no code samples or stubs are available from Microsoft).
For each combination of certificate authority, certificate template and (NDES) password policy, the installation of a standalone Windows server instance is necessary. In larger environments, the number of servers to be operated will therefore grow unnecessarily - just as with certification authorities. It is very irritating that Microsoft with Intune also subjects itself and its customers to this restriction.
NDES is generally not reasonably configurable for high availability because there is no replication mechanism for the issued one-time passwords.
NDES is still in the process of developing interfaces for the Registration Authority certificates used. Cryptographic Service Provider (CSP) world on the move, so for these, too, there will inevitably be no elliptic curves supported.
NDES unnecessarily requires that the installation be done with Enterprise Administrator privileges. In security-conscious enterprise environments, this permission is (rightly) not given out, accordingly the role cannot be used (or only via a Workaroundwhich, however, officially forfeits product support) can be used.
The Registration Authority certificates required for operation are provided in the Microsoft Product documentation not used at all.

Certificate Enrollment Web Services (CEP/CES)

Certificate Enrollment Web Services (CEP/CES) suffer from the following limitations:

You support due to a bug that has not been fixed to this day none Version 4 Certificate templates.
CES requires during installation hard-coded and accordingly non-delegable that the user is a member of "Enterprise Administrators", which is a no-go for security-conscious enterprise environments.

Certification Authority Web Enrollment (CAWE)

A usable web-based user self service is also not available. The Certificate Authority Web Enrollment (CAWE) suffers from the following limitations:

It is hopelessly outdated and has not been actively developed for almost 20 years.
It does not support Version 3 (or newer) Templates.
It does not support definition of certificate content policies (but can also be used with the TameMyCerts Policy Module be mitigated).
Installation directly on the certificate authority is not recommended for security reasons, installation on a separate server requires Kerberos delegation to be set up, which may increase the Kerberoasting hazard can increase drastically.

Validation Authority

The Online responder (OCSP) again accesses revocation lists and not the certification authority database directly. However, there are Workaroundswhich entail further maintenance effort.

It is not a support for Server-Based Certificate Validation Protocol (SCVP) present.

Certificate Management

Microsoft still sells the FIM/MIM Certificate Management product, but this is still at home in the Cryptographic Service Provider (CSP) world and, according to current knowledge, will no longer receive any new functions. The new adoption of FIM/MIM CM in 2021 is therefore a one-way street.

Conclusion

The good thing is that AD CS provides a relatively easy entry into the subject area of PKI, and most PKI software vendors make it possible to later move existing Microsoft certificate authorities into their solutions if the functionality provided is no longer sufficient.

In my view, however, the glory days of AD CS are numbered, so that a possible use of the product should be viewed critically with regard to its future viability - especially in larger environments.