Public key infrastructure (PKI) is the bedrock of modern telecommunications. It is a foundational technology to uniquely identify clients and facilitate their secure transmission and storage of data between public and private networks. Some common examples where PKI is used might be accessing a web server where traffic is encrypted with TLS/SSL server authentication certificates, a managed device authenticating to an enterprise management platform such as Microsoft Intune, or a user using a digital signature on a document/email, or backend services (e.g., network appliances, web service APIs, etc.) to authenticate and exchange information securely.
Microsoft PKI is a collection of software solutions leveraging the industry-standard X.509 protocol that enables organizations to create, manage, and distribute digital certificates to their users, devices, and enterprise systems. In the same way that Microsoft Active Directory Domain Services (AD DS) and Microsoft Entra ID are successive enterprise-grade identity and access management (IAM) platforms built in their respective eras upon vendor-agnostic protocols such as LDAP/Kerberos (AD DS) and SAML/OAuth/OIDC (Entra ID), the suite of Microsoft PKI solutions have evolved over time to support the modern IT landscape as it has transitioned from supporting primarily on-premises Windows devices to increasingly cloud-first devices running different operating systems.
In this blog post we will focus on the current landscape of Microsoft’s PKI service offerings and what opportunities exist today for designing a robust PKI implementation. If you are interested in a deeper dive into the history and anatomy of PKI and digital certificates as a whole, we have a five-part blog series that expands on these concepts.
What are Windows PKI Servers?
Partner with Microsoft experts you can trust
If it’s time to take that first step toward leveling up your organization’s security, get in touch with Ravenswood to start the conversation.
Windows PKI servers are Windows Servers that are configured with one or more of the Active Directory Certificate Services (AD CS) role services that are bundled with Windows Server operating system, and more recently, may also refer to Windows servers that are deployed with supporting Microsoft PKI offerings such as the Certificate Connector for Microsoft Intune.
At a high-level, the purpose of a Windows PKI server deployment is to provide an organization with a centralized system for issuing and managing digital certificates to trusted identities (users or devices) to facilitate verifying identities and securing communications.
Although there are a variety of PKI solutions in the marketplace that will achieve this outcome, the primary benefits of deploying Windows PKI servers are:
- Native integration with AD (e.g., access control, certificate enrollment, etc.)
- Cost-effective (included with Windows Server licensing)
- Product maturity (ADCS was introduced originally in Windows 2000 Server)
- Customizability and extensibility for various use cases and assurance levels
In addition to the benefits that Windows PKI servers provide, they also have a number of limitations. A common grievance is that Windows PKI servers have been increasingly targeted in cybersecurity attacks due to a mixture of exploitable “out-of-the-box” default configurations when deploying ADCS—and due to their native integration with AD—the ability to leverage authentication certificates for impersonating other identities within the environment. This can have disastrous consequences, especially for organizations that are investing significantly less resources in security hardening and ongoing maintenance of their PKI than they have for other critical IAM infrastructure, such as their AD domain controllers.
The good news is that leveraging Windows PKI servers continues to be a viable option in the enterprise, and we’ll discuss some potential alternatives to rolling your own on-prem Windows PKI server implementation later in this blog post.
PKI Components in Windows
It’s important to touch on the various components that are integral to a Windows PKI implementation. I’ve categorized these into two main categories: fundamentals that you’ll need to know to get started, and more situational concepts that are helpful to know when supporting Windows PKI.
Fundamentals
Let’s start with the “need to know” fundamentals:
Certification Authority
The Certification Authority (CA) is the system that performs certificate issuance and management. From a Windows Server perspective, it is the primary role service within AD CS. By default, this server contains the CA certificate itself (used for signing new certificates and CRLs), the CA database, CA database logs, the CA management console, and (if applicable) processes certificate requests from clients via the built-in Windows RPC/DCOM API.
AD CS “Enterprise CAs”
When deploying AD CS, this is a specific CA deployment type option that integrates with AD DS for storing configuration information and enabling clients to discover and perform certificate enrollment via domain authentication. The CA must be domain-joined to the forest that it is being deployed in. This is sometimes referred to as “online CA” or “issuing CA” and is the most common configuration.
AD CS “Standalone CAs”
When deploying AD CS, this is a specific CA deployment type option that has no relationship with AD and does not require domain membership to be deployed. This is a common configuration when building a tiered PKI where you can build an “offline” Root CA that exists to issue certificates for “online/issuing” Subordinate CAs, and in the event of a compromise of a Subordinate CA, it is easier to redeploy the Subordinate CAs as the clients have established their trust based on the Root CA certificate. Tiered PKIs are based on a “certificate chain” that follows a hierarchal trust path. When referring to an “offline” Root CA – this ideally describes a Root CA that is fully air-gapped and has never touched the network, but some organizations may (albeit incorrectly) refer to their “offline” Root CA as simply being managed outside of the domain trust.
Certification Revocation Lists
The Certification Revocation List (CRL) is a list of revoked certificates digitally signed by the CA that should be accessible by all identities that rely on the PKI via a CRL distribution point (CDP). From a Windows Server perspective, the CDP is configured by default with an LDAP URL when a domain-integrated “Enterprise CA” is initially built and published in the forest. Since the LDAP URL is only accessible to domain-joined endpoints with network connectivity to the domain, ideally IT administrators should configure the CDP with an HTTP URL, which is the common practice for non-Microsoft CAs.
Certificate Signing Request
The Certificate Signing Request (CSR) is a request sent to the CA that is digitally signed by the private key generated by the requester. The CSR contains information about the desired attributes (e.g., common name, country, organization, DNS subject alternative names, etc.) that the requester wants on the issued public key from the CA. This can be a fully automated process (e.g., during certificate auto-enrollment from a Microsoft CA) or can be a manual process where a CSR is generated on a system and uploaded to the CA via alternative means.
AD CS Certificate Templates
These certificate templates are stored in AD, discoverable by CAs and clients, and establish the common enrollment conditions and attributes for certificate issuance. A certificate template can be published to one or more Enterprise CAs. An example of a certificate might be a “Workstation Authentication” certificate that is permissioned to all domain computers, automatically supplies the name of the requesting domain computer in the certificate, specifies the allowed key size and algorithm (e.g., RSA-2048 and SHA-256), and is published to “Tailspin Toy Co Internal Issuing CA1” but not published on “Tailspin Toy Co Internal Issuing CA2”.
AD CS Certificate Auto-Enrollment
This is a Windows mechanism for domain members to programmatically discover and enroll/renew certificates from Enterprise CAs and their respectively published certificate templates without requiring any user interaction. In the example above with the “Workstation Authentication” certificate template, domain computers configured to “Auto-enroll” would happen automatically once the domain computer has the appropriate network connectivity to the Enterprise CA.
Situational Concepts
Now let’s cover the “helpful to know” situational concepts:
Online Certificate Status Protocol
An Online Certificate Status Protocol (OCSP) responder is a web service that clients use for requesting real-time revocation status of an issued certificate. It was introduced later to address limitations with large CRL file sizes (OCSP is a fixed network size) and CRL caching that may delay clients from getting up-to-date revocation information. From a Windows Server perspective, it is a separate, optional role service called the “Online Responder” that is not configured by default when building a CA.
Registration Authority
The Registration Authority (RA) is an intermediary system between subscribers and a CA that performs identity verification and brokers the certificate issuance process. Examples of registration authorities may be Active Directory Federation Services (ADFS) configured to issue Windows Hello for Business (WHfB) certificates, Forefront Identity Management Certificate Management (FIM CM), Network Device Enrollment Service (NDES), or third-party smartcard management systems.
Enrollment Agent
The Enrollment Agent (EA) performs certificate enrollment on behalf of another user. EA certificates can be issued directly to individuals (e.g., CA manager) or can be issued to “registration authority” systems. EA certificates digitally sign the enrollment request to prove their trustworthiness to the CA.
Network Device Enrollment Service
The Network Device Enrollment Service (NDES) is an ADCS role service that leverages SCEP (Simple Certificate Enrollment Protocol) and acts a RA web service to allow certificate issuance for network devices that otherwise cannot authenticate via traditional AD domain authentication. Prior to the creation of the, it was required for issuing certificates to iOS/Android devices for EAP-TLS wireless authentication.
Certificate Authority Web Enrollment
The Certificate Authority Web Enrollment (CAWE)* is an ADCS role service that deploys an interactive web portal (https://hostname/certsrv) for performing certificate enrollment. An example may be a web developer going to CAWE web portal to submit a CSR and downloading the issued certificate to transfer back to an isolated dev/test device. CA Web Enrollment can be difficult to secure and is not recommended.
Certificate Enrollment Web Service
The Certificate Enrollment Web Service (CES) is an ADCS role service that deploys a web service for brokering certificate enrollment and renewal via HTTPS to clients outside of the forest trust that would not be able to use the standard AD-integrated RPC/DCOM enrollment functionality directly from an Enterprise CA. This is used in conjunction with CEP.
Certificate Enrollment Policy Web Service
The Certificate Enrollment Policy Web Service (CEP) is an ADCS role service that deploys a web service for brokering the discovery of available Enterprise CAs and their published certificate templates in an AD domain. This is used in conjunction with CES.
Key Archival
By default/design, Microsoft CAs don’t store the private key of an issued certificate. Key archival is an optional configuration that allows the recovery of private keys of issued certificates by “archiving” them in the CA database.
Key Recovery Agent
The Key Recovery Agent (KRA) is a prerequisite for enabling key archival on a Microsoft CA. KRA certificates are used in the encryption/decryption of the archived private key.
Public Key Services Container
The Public Key Services Container is a forest-wide repository in Microsoft Active Directory (located in CN=Public Key Services, CN=Services, CN=Configuration, DC=<ForestRoot>) that allows clients to discover ADCS configuration, such as Enterprise CAs and certificate templates. It is also why deploying certain ADCS role services requires the highest privileges in Active Directory (Enterprise Admin).
Software Key Protection
These are private keys that are stored and protected entirely by software, such as the Windows operating system. This is the most common (and default) configuration. Software keys are vulnerable to unwanted key extraction.
Hardware Key Protection
These are private keys that are stored and protected entirely by hardware, such as stored within a dedicated cryptographic module of a smartcard, workstation’s TPM, or proprietary hardware security module (HSM). In this configuration, the private key is never stored within software memory when it is being used and is not vulnerable to key extraction.
Cryptographic Storage Providers or Key Storage Providers
Cryptographic Storage Providers or Key Storage Providers (CSP/KSP) refer to software libraries that define and support cryptographic standards and algorithms via the underlying cryptographic APIs in the Microsoft operating system. CSP refers to Microsoft’s legacy CryptoAPI (CAPI) and KSP refers to Microsoft’s newer CryptoAPI: Next Gen (CNG/CAPI2). Windows comes with default CSP/KSPs; however, third-party vendors can create their own providers to support their custom software/hardware crypto solutions (e.g., Luna Cryptographic Services for Microsoft Windows, AWS CloudHSM Key Storage Provider, SafeNet Key Storage Provider, YubiHSM Key Storage Provider, etc.)
PKCS #12
PKCS #12 (.pfx/.p12) is an industry-standard format for storing X.509 certificates and private keys in a flat file, such as cert.pfx or cert.p12. These files are usually encrypted with a secondary unlock requirement (e.g., passphrase).
PEM
-----BEGIN CERTIFICATE-----. PKI Implementation Practices
Understandably, organizations frequently struggle with designing, building, managing, and securing their PKI implementations. It can be surprisingly complex to do correctly. The recommendations outlined in Microsoft’s 143-page document on securing PKI (https://aka.ms/securingpki) are so demanding that most organizations that currently have a Microsoft PKI deployment would be unlikely to satisfy even half of them. For example, here are some “high value” Microsoft recommendations that would require most organizations to entirely redesign and rebuild their PKI environment:
- Do not use a one-tier hierarchy
- Perform formal key ceremonies that follow a script and include a witness
- Use secure administrative hosts or jump hosts to perform remote management tasks
- Isolate certificate systems from other systems on the network
- Require PKI admins to use smart cards for all accounts that manage the PKI
- Use a Hardware Security Module in offline CAs
- When virtualizing online CAs, use network attached HSMs for key protection
- If using network HSMs for offline CAs, do not connect the HSM to a routable network
The unfortunate reality is that many organizations will accept the risk that their Microsoft PKI has inadequate security controls and lower assurance due to the sheer cost and complexity with satisfying best practices. This is one of the reasons why a “managed PKI” can make more sense if an organization needs a high assurance PKI implementation and can offload CA physical/technical security controls to a provider that specializes in CA management.
What to Use: Managed PKI vs. On-Premises PKI (AD CS)
An increasingly popular alternative to building your own on-prem Windows PKI (ADCS) is deploying a managed PKI. For example, Microsoft recently released their Microsoft Cloud PKI for Microsoft Intune. This is a fully cloud-based service that natively integrates with Microsoft Intune, doesn’t require any on-premises infrastructure, and handles all aspects of the certificate management lifecycle (e.g., issuance, renewal, revocation). Unlike building your own ADCS, a managed PKI (such as Microsoft Cloud PKI) will incorporate a significant number of “best practices” CA security controls that would otherwise be cost-prohibitive (and sometimes impossible for smaller organizations) to implement. For example, recreating some of the Microsoft Cloud PKI features would require IT administrators to:
- Build a two-tier PKI hierarchy (Root and Issuing CA)
- Implement hardware key protection (e.g., HSM) for the CAs
- Deploy CDP/AIA on HTTP web servers (e.g., IIS or other static file hosting service) and develop custom event triggering to republish CRL after every certificate revocation
- Deploy a connector service (NDES role service or Certificate Connector for Microsoft Intune) to support Intune devices to enroll via SCEP profiles
- Design and implement a custom dashboard for reporting issued/revoked certificates from ADCS.
Additionally, some RBAC capabilities within Entra ID / Microsoft Intune would not be possible to fully recreate with traditional on-premises ADCS deployment, such as requiring administrators to access the Intune admin center with phishing-resistant authentication from a compliant, managed device.
There are also a variety of well-known vendors that offer “managed PKI” implementations, such as DigiCert, Sectigo, Entrust, etc. Some of these vendors are well-known for their “globally trusted CA” certificate offerings, which is a common practice of purchasing certificates that should be trusted by all modern internet-capable devices without installing an organization’s individual CA certificate (e.g., publicly available websites or public software).
The upsides of leveraging a managed PKI are simplified deployment, management, and the ability to offload underlying complex security controls. The primary downside of using a managed PKI is that it can be expensive compared to the most basic on-premises ADCS deployment. Managed PKIs tend to be priced per user or per certificate. For example, Microsoft Cloud PKI is an add-on capability at an additional cost ($2/user/month) and is not bundled in the existing Enterprise Mobility + Security (EMS) licensing or Microsoft 365 E3/E5 licensing.
Conclusion
It’s important for organizations to make educated decisions about how to support PKI in the enterprise, especially as the IT landscape has evolved to an increasingly cloud-first approach and we have seen a rapid increase in cybersecurity threats for traditional Microsoft PKI implementations. We encourage our readers to evaluate the status quo of their existing PKI deployment and evaluate what opportunities may exist to improve it, and in some cases, consider the value proposition of transitioning to a managed PKI. If you have any questions or you’d like a second opinion on your PKI architecture, please contact us. We’re here to help.
