Securing PKI: Technical Controls for Securing PKI
Applies To: Windows Server 2003 with SP2, Windows Server 2008 R2, Windows Server 2012 R2, Windows Server 2012
While a large percentage of the work required to operate a successful PKI is in the creation of the correct policies, standards and procedures, the work required to implement a secure design should not be discounted. This section introduces a number of technical recommendations for implementing a secure design. Implementing strong technical controls will introduce barriers that will make successful exploitation very difficult or cost prohibitive. Many of the recommendations are specific to AD CS-based online PKI deployments, although the concepts are universally applicable. Not all recommendations apply to all environments. Each recommendation is provided in the appendixTechnical Controls for Securing PKI along with the recommended impact level to which it applies.
Securing the CA Operating System
The following are recommendations for securing the CA operating system.
Creating a Baseline Configuration for all CAs and RAs
Critical systems such as CAs should be locked down from the moment they are introduced onto the network. Several freely available tools exist (discussed below) that either ship with Microsoft Windows® or can be downloaded to assist in creating a baseline and then deploying it via Group Policy Objects (GPO) to all domain-joined certification authorities.
Microsoft Security Compliance Manager
Microsoft Security Compliance Manager (SCM) provides comprehensive security baseline recommendations for Microsoft operating systems and server roles. Use SCM to create a detailed baseline that can be deployed and enforced on all domain-joined CAs via GPO.
Microsoft Security Configuration Wizard
Microsoft Security Configuration Wizard (SCW) is a guide for the process of creating, editing, applying, or rolling back a security policy. In conjunction with SCM, use it to create a baseline configuration that can be applied across other similar servers via GPO. SCW is included with Microsoft Windows Server®. For more information on SCW, refer to the links below:
Microsoft Windows Server 2008®: Security Configuration Wizard
Microsoft Windows Server 2008 R2® and Microsoft Windows Server 2012®: Security Configuration Wizard
Online CA Hardening Recommendations
Below are several recommendations to consider when creating a secure baseline for an online CA. This list is not complete, and the recommendations provided should be extensively tested before deploying in a production environment.
Disable CD-ROM Autoplay
Rename administrator and guest accounts
Disable local administrator and guest accounts
Use a distinct password for the local administrator account that is not used on other systems
Enable the Microsoft Windows® Firewall with Advanced Security and configure it to allow only required traffic. Refer to the Network Isolation section for more segregation recommendations.
Disable services that are not required for the CA to function. SCM contains service recommendations from Microsoft for the CA role.
Disable LM and NTLMv1 authentication protocols
Only install software that is necessary for the CA to perform its function
Disable Remote Desktop Services
Additional Roles on Certification Authorities
A common misconfiguration Microsoft sees during PKI assessments is an enterprise root or enterprise subordinate CA being run on the same system as a domain controller. Running a CA on the same system where other roles are hosted exposes the CA to a broader attack surface that introduces potential problems with performance and troubleshooting. Additionally, this may introduce issues when attempting to upgrade the environment in the future, as there may be requirements to run different components at different operating system levels. A CA system should run with only those roles and features installed that are required for its operation. Another common role installed on a CA is Internet Information Services (IIS) to support the CA web enrollment pages. Do not install the web enrollment pages or IIS as part of a standard CA install unless there is a known business requirement.
Alternate Administrative Accounts
Administrators managing the day-to-day operations of the PKI should not use the same accounts used on personal productivity workstations to check email and browse the Internet. Instead, they should use dedicated alternate accounts with the required permissions necessary to manage the PKI.
Updating Online Certification Authorities
Although it may seem counterintuitive, consider updating CAs and other critical infrastructure components separately from the general Microsoft Windows® infrastructure. If an organization leverages enterprise configuration management software for all computers in the infrastructure, compromise of the systems management software can be used to compromise or destroy all infrastructure components managed by that software. By separating updates and systems management for online certificate authorities from the general system population, the amount of software installed on CAs is reduced, and their management more tightly controlled.
Internet Access from Certification Authorities
Launching web browsers on CAs should be prohibited not only by policy but by technical controls, and CAs should not be permitted to access the Internet except to validate CRLs. Although detailed configuration instructions are outside the scope of this document, there are a number of controls to implement in order to restrict the misuse or misconfiguration and subsequent compromise of CAs.
Local Administrators Group Membership
In many organizations the baseline system configuration includes a large number of groups or user accounts included in the local administrators group of the system. With highly secure systems such as CAs, the number of accounts that are members of the local administrators group should be kept to a minimum. In an AD CS deployment, if an attacker gains access to an account with administrative access to the CA, there is a high likelihood they will be able to create certificates that will allow them to gain privileged access to the Active Directory®. For online CAs, consider limiting administrative access to only dedicated accounts used for management of the PKI, and enforce the members of the local administrators group via GPO. Enterprise Admins and Domain Admins can be removed from the local administrators group.
Accounts that are of particular interest to attackers are accounts with wide and/or deep access across an environment. Often these are accounts that perform an important function, such as security scanning, update management, backup, inventory, etc. and require administrative rights to operate. Where possible, remove these accounts from CAs and consider how the function could be performed without requiring administrative rights on the CA. Additionally, eliminate or limit the number of system/service accounts that are permanent members of the local administrators group. Actions that are performed on a CA should be traceable back to the person that performed the action.
Application Whitelisting
Use AppLocker or a third-party application whitelisting tool to configure services and applications that are permitted to run on CAs. These permitted applications and services should be comprised of only what is required for the computer to host AD CS plus any system security software such as antivirus software. Whitelisting permitted applications on CAs adds an additional layer of security so that even if an unauthorized application is installed, the application cannot run.
A CA is an excellent candidate for AppLocker because the list of software required to run on a CA should be minimal and relatively static. Testing is vital to an AppLocker deployment. Prior to deployment, test a list of rules in a test environment and then migrate the rules to a production server and run using Audit only enforcement to profile the CA. Once the rule set is established, enforce the rules. For more information on deploying AppLocker, refer to the AppLocker Overview.
Securing Remote Management Tasks
For highly secure CAs, it is very common for remote access to management tasks be very limited or disallowed by policy. Remote management should only originate from authorized users and systems. This can be accomplished through a combination of user rights settings and Microsoft Windows® Firewall with Advanced Security settings. A recommendation to consider when creating a remote access design is to use secure administrative hosts or jump hosts, as described in the Best Practices for Securing Active Directory whitepaper. While the whitepaper discusses in detail the approaches for securing domain controllers, the same strategies can be applied to other highly sensitive systems such as CAs.
Microsoft Windows Server 2012 R2® and Microsoft Windows 8.1® introduce a new featurein mstsc.exe called “Restricted Admin Mode”. If mstsc.exe is started with the /restrictedAdmin parameter, the credentials used to authenticate will not be sent to the remote computer, which limits the ability of attackers to steal and reuse credentials. In addition to restricting access via Remote Desktop Protocol (RDP), control access to the CA through other channels as well. If you use physical hardware to host the CA, there is a high likelihood that the hardware contains a Remote Management Board (RMB) that can be used to access the system. Account for access via the RMB and any other channels (Microsoft Windows PowerShell® Remoting, DCOM, SMB, etc.) when designing a firewall policy. In high security deployments, consider disabling RMBs.
After defining the acceptable methods of access, implement the controls using GPOs to apply them consistently. Consider using a dedicated Organizational Unit (OU) in Active Directory® to manage the application of GPOs to PKI systems. Many of the recommendations provided throughout this whitepaper can be applied through the use of GPOs.
Multi-factor Authentication for Certification Authority Access
A recommendation for implementing a secure design is the implementation of multifactor authentication such as smart cards for online CA access. Smart cards implement hardware-enforced protection of private keys in a public-private key pair, preventing a user’s private key from being accessed or used unless the user presents the proper PIN, passcode, or biometric identifier to the smart card. Even if a user’s PIN or passcode is intercepted by a keystroke logger on a compromised computer, the card must also be physically present for an attacker to reuse the PIN or passcode.
For cases in which long and complex passwords have proven difficult to implement because of user resistance, smart cards provide a mechanism by which users may implement relatively simple PINs or passcodes without the credentials being susceptible to brute force or rainbow table attacks. Smart card PINs are not stored in Active Directory® or in local SAM databases, although credential hashes may still be stored in LSASS protected memory on computers on which smart cards have been used for authentication.
A common misconception when requiring smart cards for interactive access for a CA is that if there is a problem with the PKI used for the smart card certificates, the CA will be inaccessible to resolve the problem because it requires smart card logon. This is untrue because it is possible to continue to use the local administrator account in the case of an emergency. Even if the local administrator account is disabled, the system can still be booted to recovery mode to enable the account, or if GPOs can be edited, the account can be enabled via GPO to perform the tasks required.
Securing Offline Certification Authorities
For highly secure CAs that issue very few certificates, a strong preventive control is to keep the CA offline. The lack of network connectivity provides a boundary for potential attackers and exploits. The purpose for adding an additional security boundary and removing root and policy CAs from the network is that a compromise of a root CA has broader impact because it can be used to sign additional issuing CAs valid for any use cases and are inherently trusted. Additionally, root and policy CAs typically have very little use that would even require them to be powered on. However, keeping a CA offline introduces some new challenges, such as updating, maintenance and access.
Offline CAs are often one of the most undervalued assets of an organization. If an attacker gains control of an offline CA that subordinates to an enterprise CA in Active Directory®, this could lead to full compromise of the directory by taking advantage of the inherited trust relationship. If an attacker gains control of an offline CA that subordinates to a CA used to issue certificates for financial transactions, intellectual property, or critical communication between partner organizations, this could jeopardize the business partnership or lead to regulatory penalties. Consider the following recommendations when designing and managing offline certification authorities.
Protect CA Private Keys
The most important logical piece of data is the CA private key. Every time a CA performs a signing of a certificate or CRL, the CA private key is being used. If the CA private key were compromised, the attacker could perform operations as the CA, undermining any other security controls.
Offline CAs Should Be Truly Offline
for potential attackers and exploits. They are only accessible physically and never connect to a network. If the offline CA is installed on a physical server chassis, a network cable should never be plugged into the server. Ideally the server would be built without a network card, or the network card disconnected from the motherboard, disabled in the BIOS, or at minimum disabled logically in the operating system. Offline CAs can also be virtualized; refer to the Virtualizing Certification Authorities section for more information.
Regardless if the CA is physical or virtual, when an offline CA is not in use, the systems and dependent components should be shut down completely. This includes host computers for virtualized offline CAs and HSMs.
Managing Data Transfer
With an offline CA, typical data transfer techniques such as file shares are not available. However, data will still need to be transferred to and from the system periodically. It is essential to scan USB or other transfer media for malware and only use authorized devices for file transfer or updating the server. Consider using a dedicated USB, SD card, or other removable media to transfer data to and from the offline system.
Updating Offline Certification Authorities
With strong processes in place to control the data introduced to the system, monthly security updates could be considered optional. For offline CAs, consider updating the operating system with service packs and any updates that affect the logical operation of the CA. This includes CA software updates, and updates for changes to time zone boundaries or Daylight Savings adjustments. Additional updates may be necessary to ensure supportability in case of a functional problem or for compliance reasons. If an HSM is used, ensure that updates to the HSM software and hardware are applied as appropriate. HSM vendors will provide updates that address security issues as well as additional functionality.
Account Management
If you need built-in auditing capacity for tracking purposes, it may be necessary to create and assign separate local accounts for administration. However, if accessing the CA is protected with entry auditing and surveillance, extra accounts may not be necessary and the standard built-in administrator account can be used. In either case, it is recommended that any activity performed on an offline CA can be attributed back to the individual who performed the activity. If an HSM is not used, additional care is needed for administrative accounts.
Virtualizing Certification Authorities
Virtualization of online or offline CAs may make sense in some scenarios. Virtualizing an AD CS CA in a Microsoft virtual server environment is a supported configuration. Refer to the Microsoft Virtual Server support policy for more information.
This section provides guidance for securely implementing offline or online CAs using virtualization technology.
Offline Certification Authorities
Before virtualizing offline CAs (root, policy), consider the following recommendations:
Decouple the CA from the Host Hardware – Use removable media to store the virtual machine hard disk files, regardless of the host hardware. Doing so permits independence of any host hardware, preventing problems if the hardware fails or needs to be replaced. Use a removable USB attached hard drive to store the virtual machine hard disk files. Securely store the removable media. Access to the CA hard disk files is equivalent to access to the CA.
Use a Secure Host Machine – The host hardware used to create the virtual machine and bring it online for routine maintenance should be dedicated hardware used for this purpose. Physically secure this hardware in the same manner as a physical Root CA. Use server hardware, or laptop hardware. If you use server hardware, keep the hardware locked in a secure cage under the same controls as other offline CAs. If you use laptop hardware, keep the laptop locked in a safe, handled similarly to storage of backup data or other items discussed in the Artifact Protection and Chain of Custody section. If dedicated hardware is not a feasible option, consider building a clean computer not connected to the network when powering on an offline CA. In that case, build the computer, perform the needed activities, and then wipe the computer securely. In any case, do not attach the host hardware to the network. The CA should not have any portion of the infrastructure connected to the network, not even to use SAN attached storage. Remember, offline continues to mean offline. Periodically evaluate the condition of the hardware and replace it as needed.
Use an HSM – By using an HSM, even if a virtual disk image is compromised, the keys are not. By not using an HSM, the CA keys are compromised if the virtual machine disk image ever leaves your immediate control. If there is already a network HSM for the online CAs, it may be possible to utilize it for offline infrastructure as long as you never connect the CA to any routable network. Many network HSMs come with multiple network ports, so it is possible to connect the host computer to the HSM using a crossover cable. More details on utilizing HSMs is explained in the Securing PKI: Protecting CA Keys and Critical Artifacts section below.
Securely Build the Virtual Machine – When creating the virtual machine for the offline CA, use the same controls that are used for a physical offline CA. Do not build the Virtual Machine (VM) on another computer connected to the network and then migrate it to a more secure computer. At no time during the build or maintenance process should you expose an offline CA virtual machine to a network attached host. Follow the same secure processes used to build a physical offline CA, including multi person control and building in a secure environment.
Perform Regular Backups and Updates – When performing regular maintenance on the CA, you should make a backup of the virtual hard disk files. Make multiple copies, ensure that they work, and securely store them to offsite facilities. Store the backup copies with the same precautions and controls as the primary copy. As part of the backup, include the virtualization software needed to bring the CA online so that a support team has all the data needed to use the backup and recover the CA. Ensure that the virtualization formats used (e.g. VHD/VHDX, etc.) are kept up to date to reduce reliance on out-of-support software or configurations.
Verify the System Time – Prior to performing any operations with an offline CA image, verify that the system clock is correct. Inaccurate time will cause certificates and CRLs to potentially be invalid and cause service interruptions.
Disable Remote Management Capabilities on the Host – If the host computer has a Remote Management (RMB) board, ensure that it is disconnected from the network.
Online Certification Authorities
When considering using virtualization for online CAs, consider the following recommendations:
Control Administrative Access to the Host Operating System – Users and processes that have administrative access to the host operating system ultimately have access to the virtual machine hard disk files, which can result in the equivalent of physical access to the virtual CAs. If an administrator should not have access to a physical CA, they should not have access to the host operating system on which the virtualized CA is running. When determining access controls, consider all potential paths that might allow a user to gain access to the CA hard disk files and administrative access to the host OS. Consider also the access to virtual machine management consoles, access to snapshots, access to back end storage arrays, etc. In high security environments, consider disabling RMB access to the host hardware if multi- person control is a requirement.
Use Network Attached HSMs – By using an HSM, even if a disk image is compromised, the keys are not. By not using an HSM, the CA keys are compromised if the virtual machine disk image ever gets out of your control. When using network attached HSMs, consider deploying redundant HSM hardware, because the HSM now becomes a single point of failure affecting multiple CAs relying on its services.
Use CA Database Backups – Virtual machine snapshots can provide an instant recovery to a known good state. Snapshots will restore the CA database to the state it was in when the snapshot was taken, similar to a CA backup. If any certificates have been issued since, they will not be in the database. If certificates have been revoked, they will no longer show as revoked and would be removed from the CRL at the next publication. For virtualized CAs, continue to take regular CA database backups so if a snapshot is used, you also have a clean backup of the CA database in the case of corruption or unforeseen issues.
Delegating PKI Tasks
Managing an Active Directory®-based AD CS CA deployment requires account permissions for a number of common activities. Generally speaking, the activities can be broken down into two major categories:
Certification Authority Management
These are infrequent configuration tasks that you may only perform once or a few times over the life of a CA:
Installation of a new CA
Renewal of a CA certificate
Managing Active Directory® certificate containers (NTAuth, CAs, AIA, CDP, etc.)
Certificate Management
These are more frequent operational tasks that regularly occur over the life of a CA:
Creating and managing certificate templates (new templates, updated enrollment permissions, etc.)
Certificate lifecycle management (issuance, revocation, renewal)
Maintenance of the CA (software or security updates, backups, etc.)
Managing and verifying CRL and OCSP availability
By default, after installing a CA, ongoing operations require at least the occasional use of an account in the domain administrators or enterprise administrators groups. In some organizations it may be desirable to delegate the rights required to perform common PKI tasks to a separate group. It may also be desirable to delegate the rights required to perform infrequent operations to a separate team or set of accounts. If an organization operates a large number of CAs or the organizational structure is such that it makes sense to delegate these rights, refer to Securing PKI: Appendix C: Delegating Active Directory PKI Permissions for details on what permissions must be delegated.
Role Separation
An AD CS CA offers the option to enforce Common Criteria (CC) role separation, which is used to separate CA support into predefined CA roles. Each role is eligible to perform a specific subset of CA functionality. Users can be assigned to only one role, and if they are assigned to more than one role, they are unable to perform any CA-related activities. The table below describes the different roles available that are subject to role separation:
Roles and groups |
Security Permission |
Description |
|---|---|---|
CA administrator |
Manage CA |
Corresponds with CC Administrator role. Configure and maintain the CA. This is a CA role and includes the ability to assign all other CA roles and renew the CA certificate. These permissions are assigned by using the CA snap-in. |
Certificate manager |
Issue and Manage Certificates |
Corresponds with CC Officer role. Approve certificate enrollment and revocation requests. This is a CA role. This role is sometimes referred to as CA officer. These permissions are assigned by using the CA snap-in. |
Backup operator |
Back up file and directories Restore file and directories |
Corresponds with CC Operator role. Perform system backup and recovery. Backup is an operating system feature. |
Auditor |
Manage auditing and security log |
Corresponds with CC Auditor role. Configure, view, and maintain audit logs. Auditing is an operating system feature. Auditor is an operating system role. |
Role separation offers some benefits, but it also introduces some challenges that should be considered when evaluating its usefulness for your environment. Separating roles allows for a stronger separation of responsibilities for individuals or teams, and can provide a clear technical separation for systems that are subject to compliance requirements that require separation of duties. However, implementing role separation does require a sizable support staff. To ensure that there is adequate coverage for all critical roles, an organization would require multiple individuals for each role, which is often not possible.
Give careful consideration to the operational impact enabling role separation may have before enabling it in your environment. If you use role separation, ensure that its configuration is monitored for changes, as it can be easily disabled by someone with administrative rights on the CA. Refer to the Securing PKI: Monitoring Public Key Infrastructure section for more information. For more details on role separation refer to the following resources:
Implement Role-Based Administration
Defining PKI Management and Delegation
Protecting CA Backups
When performing a backup of a CA, there are three items necessary to fully recover:
CA certificate(s) and private key(s)
CA registry information
CA database backup
Several options exist for backing up a CA. If you are using an HSM, consult the HSM vendor documentation for details on what is required to back up and restore HSM protected keys. CA backup options include:
Perform a system state backup, which will include the CA database, registry settings, and CA key information (including the private key if you are not using an HSM)
Manually back up the CA using the CA snap-in. This does not include the CA registry or any files required to restore HSM protected keys
Use certutil.exe or Windows PowerShell® CA Backup and Restore Windows PowerShell cmdlets to create a regularly scheduled backup script that backs up the database, registry settings, and required private key files
A common issue Microsoft finds in many PKI assessments is that once a backup of a CA is taken, the same level of protection is not always provided to the backup that exists on the CA. If you are not utilizing an HSM and you are performing regular backups that include the private key, the private key and certificate are stored in a PKCS#12 (PFX) file. If an attacker is able to gain access to the PKCS#12 file, they have the opportunity to brute force the password on the file and gain access to the CA key. If the password can be cracked, the attacker has compromised your PKI and can create certificates of their choosing. The same applies when performing system state backups. If an attacker gains access to a system state backup, they can restore it and gain access to the private key(s). When designing a backup strategy for the CA, consider the following recommendations:
If an HSM is not used, perform a separate backup of the CA key and certificate to a PFX file and Artifact Protection and Chain of Custody where it can be retrieved in the event a restore is required. Store the backup in a tamper-evident bag and place it in a safe with limited access, where the access is monitored and audited. When performing regularly scheduled backups, do not include the CA key as part of the backup. Continue to take new backups as CA certificates are renewed or new keys are generated and set a strong passphrase on the PFX file. To initiate a backup that includes only the CA database and not the CA key, use certutil –backupdb rather than certutil –backup if initiating the backup from the command line or a script. Beginning with Windows Server 2012 R2®, a backup can be performed with the PowerShell cmdlet Backup-CARoleService. When used with the –DatabaseOnly argument, the CA certificate will not be included in the backup.
If an HSM is used, examine how you back up the files and HSM data required to use the keys. If you have multiple HSMs operating within the same security boundary it may be possible to obtain HSM files and use the CA keys on other computers. Consider backing up any HSM files separately and storing them securely to prevent any unauthorized use of the CA keys from other computers with initialized HSMs.
Consider backing up the CA to another secure location that interfaces with backup systems rather than having backup systems connect directly to the CA. Backup systems typically have the ability to connect to large numbers of systems in the enterprise, and a compromise of the backup system could then lead to a compromise of the PKI.
Note
In Microsoft Windows Server 2008® and Microsoft Windows Server 2008 R2®, private keys were not included in the system state backup. A hotfix was released that addressed this issue and private keys are included with the system state backup image if the hotfix is applied.
Network Isolation
CAs should only be accessible by the users and systems that require access to them. There are many deployment scenarios for a CA and many front end systems that may require access to a CA. Supporting some out-of-box scenarios such as auto enrollment of user or computer certificates requires broad access to the CA from most, if not all, domain joined client computers and users on the internal network. Other deployments, such as deploying with a RA such as Forefront Identity Manager Certificate Management, may only require the RA system to interact directly with the CA.
When developing the security design for PKI, consider the following recommendations:
Isolate certificate systems away from other systems on the network. If a system does not have a legitimate need to connect to a certificate system, do not allow the connection.
Implement security “zones” to isolate the certificate systems based on their criticality or relationship to each other
Only allow the required inbound and outbound connections that are identified as necessary for the CA and supporting systems to function
If you utilize network attached HSMs, restrict access to those devices to only the CAs or other systems that utilize them
Restrict management access to originate from a limited set of administrative hosts. Refer to the Securing the CA Operating System section for more information.
Securing Certificate Templates
Attackers will take the path of least resistance when attempting to compromise an environment. If a simple attack vector is available, attackers will use it rather than using exploits that are more difficult to execute or more difficult to detect. One method attackers use to compromise environments is to employ misconfigured certificate templates to get credentials that can then be used to access additional systems or sensitive data. The following are several recommendations to consider in order to secure certificate templates:
Remove Overly Broad Enroll or Autoenroll Permissions – Rather than determining the exact population of users that require a specific certificate type and explicitly granting them enrollment permissions, occasionally “Authenticated Users”, “Domain Users” or other broad groups are granted enroll or autoenroll permissions. This can lead to accounts that have no need for a certificate to be eligible to enroll. Avoid granting overly broad enrollment permissions for certificates. Instead, carefully consider which accounts need permissions, and explicitly deny enrollment rights for users or groups of users that should not be eligible for enrollment.
Remove Unused Templates from Certification Authorities – When a Certificate Template no longer has a business need, remove it from any certification authorities that issued it. By default, several templates are included as part of the installation of an enterprise CA. If those templates are not required, they should be removed. Alternatively, on Microsoft Windows Server 2008® and newer you should install the CA with no default templates by including LoadDefaultTemplates=0 in the [certsrv_server] section of the CAPolicy.inf file used during setup of the CA.
Additionally, some high value templates that are issued relatively infrequently do not need to be available on the CA all the time. Examples include Enrollment Agent, Key Recovery Agent, and EFS Data Recovery Agent. Consider removing these templates from issuing CAs except during active use, and monitor for attempts to add these templates to a CA. Refer to the Monitoring Changes to Certificate Templates section for more information.
Secure Templates that Allow You to Specify the Subject in the Request – Certificate templates provide for two main mechanisms for generating the subject name(s) in a certificate:
Supply in request – All subject information is provided by the requestor. If you use the default CA policy module, no additional checks are done to confirm the mapping of the subject information to a user account in Active Directory®. If a certificate template is configured to use “supply in request” without additional approvals, the following dialog box displays:
.jpeg)
Build from this Active Directory® information – The subject for the certificate is determined by the CA by performing an Active Directory® lookup of the user performing the request. The applicable attributes from the Active Directory® are used to populate the certificate.
When using “supply in request”, a user can request a certificate that would potentially allow them to authenticate as another user if no other security mechanisms are in place. When using “supply in request” templates, ensure that one or more of the following controls are in place to prevent misuse:
Implement additional signatures on requests – A common approach is to require at least one signature from a user or system with an enrollment agent certificate. Consider requiring the enrollment agent private key to be stored in an HSM.
Implement certificate manager approval – Certificate manager approval will set any incoming requests for the template into a pending state, where it must be approved by a person (or system) that holds the “issue and manage certificates” role on the CA before it is issued.
Implement monitoring of certificates issued by the template – Configure monitoring and alert if certificates are issued to VIP user accounts or other accounts that are deemed critical.
Controlling User Added Subject Alternative Names
An Active Directory® Certificate Services CA offers several methods to add subject alternative names (SANs) to a certificate:
Add from known AD object attributes – The CA can add alternative names from a defined subset of attributes when you choose to add the subject information from Active Directory®. The CA performs this addition, and the data is not specified by the user. Manipulation would require an attacker to be able to manipulate the values of attributes for a user in Active Directory®.
Add as an extension in the certificate request – If the template is configured for “supply in request”, the extensions requested will be honored by the CA if supported. The alternative names are provided by the requestor.
Add as an attribute that accompanies the certificate request – Requires the CA to allow user-specified alternative names via the EDITF_ATTRIBUTESUBJECTALTNAME2 flag. If this flag is set on the CA, any request (including when the subject is built from Active Directory®) can have user defined values in the subject alternative name.
Allowing users to define arbitrary alternative names poses risk to the PKI if it is not implemented with proper controls. Anytime you allow a user to define SANs, implement the following additional controls:
Requests that may contain user-defined alternative names should be set to “pending” when submitted and reviewed by a Certificate Manager prior to issuance
Do not allow a single person to have the ability to both add SANs and approve the request
It is strongly recommended not to enable the EDITF_ATTRIBUTESUBJECALTNAME2 flag on an enterprise CA. If this is enabled, alternative names are allowed for any Certificate Template issued, regardless of how the subject of the certificate is determined according to the Certificate Template. Using this feature, a malicious user could easily generate a certificate with an alternative name that would allow them to impersonate another user. For example, depending on the issuance requirements, it may be possible for a malicious user to request a new certificate valid for smart card logon and request a SAN which contains the UPN of a different user. Since smart card logon uses UPN mapping by default to map a certificate to a user account, the certificate could be used to log on interactively as a different user, which could be a domain administrator or other VIP account. If this flag is enabled, the CA should be limited to require Certificate Manager approval or limit enrollment permissions to only trusted accounts.
To see if EDITF_ATTRIBUTESUBJECALTNAME2 is enabled on the CA, run the following command:
certutil –getreg policy\EditFlags
If EDITF_ATTRIBUTESUBJECTALTNAME2 is included, it is turned on. To disable the setting, run the following command:
certutil –setreg policy\EditFlags –EDITF_ATTRIBUTESUBJECTALTNAME2
Then restart the CA service:
net stop certsvc && net start certsvc
For more information on subject alternative names, refer to How to Request a Certificate With a Custom Subject Alternative Name.
Conclusion
Implementing strong technical controls can mitigate many of the common attack vectors used to compromise an ADCS PKI installation. This section has detailed some of the common misconfigurations that can lead to compromise, including securing access to certificate templates, and template enrollment options that lead to the issuance of unauthorized credentials. Limiting access to PKI systems through network controls and treating PKI systems as high value assets that are not managed like common infrastructure helps mitigate the risk of the PKI being compromised through supporting systems and overly broad access. Strong key protection help mitigate the threat of a CA key being exported and used outside of authorized hardware by an insider threat or an attacker.
For a complete list of the recommendations for technical controls, along with the level of Determining the Level of Protection Required at which you should consider implementing them for, refer to Securing PKI: Appendix F: List of Recommendations by Impact Level.
See Also
Securing Public Key Infrastructure (PKI) Securing PKI: Introduction Securing PKI: Planning a CA Hierarchy Securing PKI: Physical Controls for Securing PKI Securing PKI: PKI Process Security Securing PKI: Planning Certificate Algorithms and Usages Securing PKI: Protecting CA Keys and Critical Artifacts Securing PKI: Monitoring Public Key Infrastructure Securing PKI: Compromise Response Securing PKI: Appendix A: Events to Monitor Securing PKI: Appendix B: Certification Authority Audit Filter Securing PKI: Appendix C: Delegating Active Directory PKI Permissions Securing PKI: Appendix D: Glossary of Terms Securing PKI: Appendix E: PKI Basics Securing PKI: Appendix F: List of Recommendations by Impact Level Security and Protection Secure Windows Server 2012 R2 and Windows Server 2012