The Nightmare of Validating Certificate Requests

This post has been republished via RSS; it originally appeared at: Microsoft Tech Community - Latest Blogs - .

Certificate templates and Registration Authorities

In short, certificate templates in Active Directory define which information an acceptable certificate request must include, how the request and the subject and/or Subject Alternative Names (SANs) are verified, and which accounts are allowed to request a certificate.

 

ITU-T X.509 recommendations define the role of a Registration Authority (RA) to complete the task of "identification and authentication of the subject of a public-key certificate to be issued by that certification authority".

 

ADCS preferably delegates the RA tasks to Active Directory but also provides an interface for so-called "custom Policy Modules", which allow to introduce an individual ruleset for certificate request verification, like block- or whitelists of subjects, comparison of subjects with DNS etc. Custom Policy Modules are available from third-party vendors, published on GitHub and of course you can create your own. Finally, you can verify subject and SANs in certificate requests manually.

 

Whatever you decide for, you MUST ensure that subject and SANs of every certificate request are verified properly before being issued.

 

Wondering what the excitement is about?

Find an example of a combination of settings which allows domain dominance as soon as a single computer gets compromised in your forest below (assuming that a custom Policy Module is not in place):

 

Subject Name - Supply in the request

Issuance Requirements – None
Certificate templates with the "Supply in the request" radio button enabled are typically called "offline templates", because subject and SAN(s) cannot be verified against Active Directory  
DagmarHeidecker_0-1676715733375.png

 

DagmarHeidecker_1-1676715775943.png

 

Permissions to Enroll this type of certificate CA Certificate published to NTAuth Store in Active Directory
DagmarHeidecker_0-1676715968924.png

 

DagmarHeidecker_1-1676716019608.png

Note: The screenshot above was taken on a computer with the ADCS RSAT tools installed:

Press Start > Run > type pkiview.msc

With Enterprise PKI highlighted > select Action from the top menu and choose Manage AD Containers…

With the above configuration of a certificate template and the CA published to the NTAuth Store in Active Directory, an attacker could simply request and enroll a certificate with a Domain Admin's or some VIP's User Principal Name as a SAN and immediately use the certificate to logon to Active Directory in the security context of this account.

 

The NTAuth store is an object in the Services partition of AD. CA certificates which are trustworthy for AD authentication are published to the NTAuth object and from there replicated to the Enterprise certificate store on all members of the AD Forest.

 

Smart card authentication or Windows Hello for Business (Key Trust or Certificate Trust) only work with the issuing CA certificate published to NTAuth.

 

Improving your manual verification experience

During Compromise Recovery, we typically don't have time to evaluate and acquire custom Certificate Policy modules from third-party vendors. As a quick and cheap alternative we enforce manual verification of pending certificate requests. Customers complained - with good reason – ADCS do not provide a handy tool to complete this task. As described above, it is crucial to precisely verify subject and SANs of certificate request submitted for an offline template. Find more details about certificate template security settings at https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/dn786426(v=ws.11)#securing-certificate-templates.

 

This problem is now solved because my colleague Andreas Luy published a beautiful little tool on GitHub: GitHub - Bulgwei/CertMangement: Little Front End for ADCS to submit/retrieve/Issue and deny certificates/requests

 

Some notes on the tool:

  • It is natively written in PowerShell. So, it could be easily enhanced or modified to fit to the necessities needed.
  • It only uses functionalities which are available on every modern Windows™ OS (CERTUTIL/CERTREQ).
  • The tool supports separation of the following CA-specific roles: “CA Administrators” and “Certificate Managers”.
  • To use all features, you need "Manage CA" and "Issue and Manage Certificates" permissions – please note that this is NOT recommended, instead you should always split permissions.
  • The tool can be used to remotely connect to an Active Directory integrated CA (CA must not be restricted to deny remote administration) or locally on the CA computer.
  • It allows you to submit existing certificate requests (including ones which do not yet include certificate template information. This type of certificate request is typically created by some non-Windows operating systems or appliances). Please keep in mind that the account running the tool must have "Enroll" permission on the selected certificate template.

DagmarHeidecker_0-1676716596264.png

  • When it comes to handling of certificate requests, the tool has several options:
  • Display all issued certificates submitted by the account running the tool during a defined number of days and retrieve the certificate in DER and base64 format.
  • Display all issued certificates submitted by ANY account during a defined number of days and retrieve the certificate in DER and base64 format.

And finally, the "killer feature": The one-stop option to fully review certificate requests and finally issue or deny it:

One-stop verification of subject and SAN(s) of pending certificate requests:

DagmarHeidecker_0-1676812037146.pngDagmarHeidecker_0-1676812171432.png

 

We hope you enjoy the tool, and it makes your process of submitting and verifying certificate requests easier! 

 

 

 

Leave a Reply

Your email address will not be published. Required fields are marked *

*

This site uses Akismet to reduce spam. Learn how your comment data is processed.