So I have been back in Sweden for about two weeks, working in an intense project with PKI (AD CS, Venafi, PointSharp NetID Portal, and Thales Luna HSMs) as well Active Directory and tiering.
In the frist post of the series
When your Enterprise PKI becomes one of your enemies (Part 1) – I explained the following in short:
- Issues and challenges with “Supply in the request” (SITR) – Certificate Templates
- How NTAuth works and what it means if a Certificate Authority is trusted in NTAuth
- That the new Strong Certificate Binding Enforcement is a response to CVE-2022-34691, CVE-2022-26931, CVE-2022-26923 and is NOT designed to resolve the challenges with “Supply in the request” (SITR) – Certificate Templates
- That templates that lack the – Client Authentication EKU (1.3.6.1.5.5.7.3.2) might be subject anyway for PKINIT and Schannel.
Let’s talk about possibilities to mitigate – the first ability is to design your PKI Hierarchy so that you have at least two CAs where one of them is trusted in NTAuth and the other isn’t.
Design 1 – Preferred works for most organizations
Issuing CA 1 (AD CS) – Installed as Enterprise CA trusted in NTAuth – Issues certificates used for authentication such as Smart Card/Yubikey PIV, 802.1x (Only important if you’re running NPS in particular) and any other certificate where the subject is built from the Active Directory user or computer. This CA should never have certificate templates published with “Supply in the request” (SITR).
Issuing CA 2 (AD CS) – Installed as Enterprise CA (The CA is going to be initially trusted in NTAuth as it’s installed as an Enterprise CA and has to be installed by an Enterprise Admin within the forest or by an account that is delegated to write to the NTAuth object anyway) –
Important! This CA has to be removed from NTAuth manually and repeatable have to be so every time the CA certificate is renewed.
Read more about NTAuthGuard by Carl Sörqvist further down as a automated solution for this task
This CA as it is installed as an Enterprise CA will still have the capability to publish certificates and enable auto-enrollment to clients/servers and is intended as a SSL-TLS CA and can safely publish certificate templates where the subject can be supplied aka “Supply in the request” (SITR)
However there is some more restrictions that should be performed on this CA – I would recommend to disable the following extensions so the CA never can include them in any certificates:
- DisableExtensionList +1.3.6.1.4.1.311.25.2 (SID) – The SID extension is not needed as this CA should never issue any certificates used for authentication and there for do not need to be compliant with the Strong Certificate Binding Enforcement requirements.
- DisableExtensionList +1.3.6.1.4.1.311.21.10 (App Policies) – This is a legacy proprietary extension that would allow the requester to supply a EKU within the request of choice on templates that are missing the ‘msPKI-Certificate-Application-Policy Attribute’ attribute – typically v1 templates as the built-in ‘WebServer’ template, but not limited to.
Note the ‘DisableExtensionList’ can be set using the certutil command line utility – for example:
certutil -setreg policy\DisableExtensionList +1.3.6.1.4.1.311.25.2
certutil -setreg policy\DisableExtensionList +1.3.6.1.4.1.311.21.10Secure – Supply in the request (SITR) templates additionally – As an extra safety precaution I recommend that SITR templates are configured with the ‘msPKI-Enrollment-Flag‘ attribute to contain the new bit/flag ‘0x00080000 – CT_FLAG_NO_SECURITY_EXTENSION’ to make sure that certificates generated by those templates never can include the SID extension regardless on which CA they are published on (as long as we’re speaking AD CS)
Design 1 and Tiering – Note that this design requires both “Issuing CA 1” and “Issuing CA 2” to be managed from T0, however to be clear they can both issue certificates to clients/servers in all tiers and you can even delegate certificate manager responsibilities to T1 on “Issuing CA 2” – what you can’t do however is allowing T1 to logon to interactively to “Issuing CA 2”.
Design 1 – Design Rational – Some will probably argument that why not just have one Enterprise CA and make sure that all the “Supply in the request” (SITR) templates are configured to have certificate manager approval required – sure this can work for small businesses, also remember that each request must be reviewed be for approved by a T0 administrator – they typically have other things to do.
The hygiene factor is hard if it’s not automated – reporting templates that have “Supply in the request” (SITR) enabled and lacking the certificate manager approval requirement or even remediate them – when performing security assessments at Epical we always se the left-overs of templates where someone just wanted to test something or was in a hurry and might intended to change the settings back to what they should be, this design minimize those mistakes as well and it’s fairly easy to script compliance checks when the CAs are split up-on the type of templates they should publish.
Have a sample script for that:
NTAuthGuard by Carl Sörqvist
So NTAuthGuard is a solution from Carl Sörqvist that will help us with the fact that in Design 1 as mentioned above both “Issuing CA 1” and “Issuing CA 2” are AD CS Enterprise CAs mening they will both publish and trust them self in NTAuth and has to be installed by an Enterprise Admin within the forest or by an account that is delegated to write to the NTAuth object anyway, “Issuing CA 2” needs to be removed manually and repeatable have to be so every time the CA certificate is renewed.
NTAuthGuard allows us to define a whitelist by CA certificate thumbprints that is allowed to be trusted in NTAuth – the script can log events if a CA certificate that is not whitelisted is being trusted in NTAuth or even take action and remove the none-whitelisted CA certificate from NTAuth.
Read more about the NTAuthGuard solution – how to set it up and get all the required content from Carl’s GitHub: PsCertTools/NTAuthGuard at main · CarlSorqvist/PsCertTools · GitHub
Design 2 – would basically be what is described to avoid if possible in the design rational of Design 1 above .
Next part will look into some really bad, vulnerable and complicated scenarios and how to mitigate those as well.