Active Directory Domain Controller Certificates Installation Guide

Overview

This article deals with Domain Controllers, rather than member servers. Thus, Active Directory or AD Lightweight Services are assumed to be available on nodes being referenced herein. I’ve also intentionally limit the scope of technical instructions to exclude member servers, web servers, application nodes, and client computer objects. This is a hint that there would be a follow-up documentation to cover non-core infrastructure machines.

Most companies should favor the ‘Enterprise’ type of AD Certification Authority over the Standalone CA option for AD-joined servers. The fundamental difference would be that Standalone does not require Active Directory, which would nullify some useful features such as Domain Controller auto-enroll, etc. Moreover, the common legacy security recommendation is to install Authoritative Root CA on a non-domain joined server (Standalone CA) > Subordinate Root CA on a domain-joined server (Enterprise CA) > Turn off the Authoritative Root CA thereafter. Nowadays, most companies opt to simplify the architecture by installing the Authoritative Root CA as the Enterprise type; moreover, that RootCA often is also a DC since issuing certs databases are stored in AD, keeping read/write logging closer to the source. I often deploy CA’s using the latter design. My other recommendation is to install Root CA with a 20-year validity period and Sub-CA’s with a 10-year lifespans as extending root validity periods would clutter the certs database and AD entries. Then, custom templates would be created to automatically generate certs that are suitable for the enterprise. Here’s a quick overview of my normal setup for domains more than 20 domain controllers:

1. RootCA
   • Pick one domain controller that is in the most restrictive zone to act as the RootCA
   • RootCA certificate for itself will have a validity period of 20 years or more
   • Certificate Templates to only include a custom template named ‘Subordinate Certification Authority 10 Years’ (not the default of 5-year validity) so that this RootCA only responds to SubordinateRootCA machines and allow SubCA to be mostly independent.
2. SubordinateRootCA
   
   • Will point to the RootCA upon instantiation
   • Will have these custom templates:
     • Domain Controller 5 Years (replace ‘Domain Controller’ and ‘Domain Controller Authentication’ templates)
     • Kerberos Authentication 5 Years
     • Directory Email Replication 5 Years
   • All other templates will retain their default settings
3. Group Policies
   • Web servers that support Intranet applications will apply the ‘Web Server’ cert template
   • Domain Controllers will autoenroll (auto-renew). This is the function of the Active Directory cert auto-targeting per templates. No special GPs are required for propagation.
   • By Default, all domain-joined Windows machines will add the SubordinateRootCA and RootCA public certs into ‘Trusted Root Certification Authorities’ and ‘Intermediate Certification Authorities’ cert stores.

Domains with less than 20 DCs may not require SubordinateRootCA’s. A single RootCA can serve the purpose of responding to cert requests from all machines. Therefore, the layout of the SubordinateRootCA role above could apply to the RootCA role for small forests.

The following sections could either be consumed in ad-hoc per keyword fashion or via a linear execution. Certain due diligence is required. Thus, the author will only recommend applying these instructions in a ‘lab’ environment. Misuse of this advisory constitutes a waiver of rights in raising possible litigation due to unintended effects of technical applications.

How To Check for Existing LDAPS Certs:

Verify that the cert has these 2 application policies: Client Authentication & Server Authentication

[dc06]: PS C:\Users\kimconnect\Documents> certutil -verifystore MY
MY "Personal"
================ Certificate 0 ================
Serial Number: SOMESERRIALNUMBER
Issuer: CN=kimconnect-INTRANETCA01-CA, DC=kimconnect, DC=com
NotBefore: 11/18/1920 5:53 PM
NotAfter: 11/18/1921 5:53 PM
Subject: CN=dc06.intranet.kimconnect.com
Certificate Template Name (Certificate Type): DomainController
Non-root Certificate
Template: DomainController, Domain Controller
Cert Hash(sha1): 
Key Container = 
Simple container name: le-DomainController-
Provider = Microsoft RSA SChannel Cryptographic Provider
Private key is NOT exportable
Encryption test passed
Verified Issuance Policies: None
Verified Application Policies:
1.3.6.1.5.5.7.3.2 Client Authentication
1.3.6.1.5.5.7.3.1 Server Authentication
Certificate is valid

Example of an invalid cert:

================ Certificate 0 ================
Serial Number: SOMESERRIALNUMBER
Issuer: CN=test, DC=intranet, DC=kimconnect, DC=com
NotBefore: 10/6/2019 6:34 AM
NotAfter: 10/6/2020 6:34 AM
Subject: CN=test.intranet.kimconnect.com
Certificate Template Name (Certificate Type): DomainController
Non-root Certificate
Template: DomainController, Domain Controller
Cert Hash(sha1): somehash
Key Container = somekey
Simple container name: ou-DomainController-somehash
Provider = Microsoft RSA SChannel Cryptographic Provider
Private key is NOT exportable
Encryption test passed
Revocation check skipped -- server offline
Certificate is valid

How to Quickly Identify AD DS Cert Authorities of This Domain

Before doing anything, run this quick Domain Controller Cert Audit script to investigate the existing infrastructure prior to making modifications.

Command Line:

certutil -config - -ping

GUI:

Option A)

Run pkiview.msc > view the enterprise certs and their statuses

Option B)

certsrv.msc > connect to localhost (if current host is a CA) or a known certification authority server

Example of a broken CA in a domain:

---------------------------
Microsoft Active Directory Certificate Services
---------------------------
Cannot manage Active Directory Certificate Services.

The system cannot find the file specified. 0x80070002 (WIN32: 2 ERROR_FILE_NOT_FOUND)
---------------------------
OK 
---------------------------

A Sample Error When Calling Cert Manager When Role Was Missing

---------------------------
Microsoft Active Directory Certificate Services
---------------------------
Cannot manage Active Directory Certificate Services.
---------------------------
The specified service does not exist as an installed service. 0x424 (WIN32: 1060 ERROR_SERVICE_DOES_NOT_EXIST)

Workaround to the error above (assuming that a different CA server is online):
Run certsrv.msc > right-click Certification Authority > Retarget Certification Authority > Another Computer > Browse > Select the Cert Authority > OK

Since Active Directory should have a CA to enable certain services such as LDAPS, one must consider on these options prior to proceeding to the next section:

• CA Types:
  • StandaloneRootCA
  • StandaloneSubordinateCA
  • EnterpriseRootCA
  • EnterpriseSubordinateCA
• Cryptographic Providers:
  • Provider Names: “RSA#Microsoft Software Key Storage Provider”
  • Hash Algorithm Name: SHA256, SHA384, SHA512, SHA1, MD5, MD4, MD2
  • Key Lengths: 512, 1024, 2048, 4096

How to Install a Root CA:

# Install the ADCS Cert Role
Install-WindowsFeature Adcs-Cert-Authority -IncludeManagementTools

# Include the EnterpriseRootCa Role
$years=20
$hash='SHA256'
$keyLength=2048
Install-AdcsCertificationAuthority -CAType EnterpriseRootCa -CryptoProviderName "RSA#Microsoft Software Key Storage Provider" -KeyLength $keyLength -HashAlgorithmName $hash -ValidityPeriod Years -ValidityPeriodUnits $years

Example of expected output:

Confirm
Are you sure you want to perform this action?
Performing the operation "Install-AdcsCertificationAuthority" on target "CA01.intranet.kimconnect.com".
[Y] Yes [A] Yes to All [N] No [L] No to All [S] Suspend [?] Help (default is "Y"): y

ErrorId ErrorString
------- -----------
0

# Verify presence of key container
ls C:\ProgramData\Microsoft\Crypto\Keys\

# Verify Certs
certutil -verifystore MY

# Run Cert Manager to continue with configuration
certsrv.msc

How to Install Enterprise Subordinate CA

# Install the ADCS Cert Role
Install-WindowsFeature Adcs-Cert-Authority -IncludeManagementTools

# Include the Enterprise Subordinate Ca Role
$rootCaServer='LAX-DC01.kimconnect.com' # change these variables to fit your environment
$certAuthName='kimconnect-LAX-DC01-CA'
Install-AdcsCertificationAuthority -CAType EnterpriseSubordinateCa -ParentCA "$rootCaServer\$certAuthName"

# Run Cert Manager to continue with configuration
certsrv.msc

Some possible errors to indicate certain common problems

# This exception tells us that CA Role is already present on this server

Install-AdcsCertificationAuthority : The Certification Authority is already installed. If you are trying to reinstall
the role service, you must first uninstall it.
At line:1 char:1
+ Install-AdcsCertificationAuthority -CAType EnterpriseSubordinateCa -ParentCA "$r ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidOperation: (:) [Install-AdcsCertificationAuthority], CertificationAuthoritySetupE
xception
+ FullyQualifiedErrorId : CASetupObjectInitialize,Microsoft.CertificateServices.Deployment.Commands.CA.InstallADCS
CertificationAuthority

# This error indicates that there's a typo error, or the source server doesn't have the CA Root role installed

Install-AdcsCertificationAuthority : CCertSrvSetup::SetParentCAInformation: The parameter is incorrect. 0x80070057
(WIN32: 87 ERROR_INVALID_PARAMETER)
At line:1 char:1
+ Install-AdcsCertificationAuthority -CAType EnterpriseSubordinateCa -ParentCA "$r ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (:) [Install-AdcsCertificationAuthority], ArgumentException
+ FullyQualifiedErrorId : System.ArgumentException,Microsoft.CertificateServices.Deployment.Commands.CA.InstallADC
SCertificationAuthority

How to Uninstall CA Role

PS C:\Windows\system32> Uninstall-AdcsCertificationAuthority -Force

ErrorId ErrorString
------- -----------
0

How to Set Domain Controllers for Auto-enroll

On the Certificate Authority (CA) Server:
Start > run > certsrv.msc > right-click Certificate Templates > Manage > Double click the Domain Controller Authentication template > Select the Security TAB > select Domain Controllers > make sure that ‘Enroll’ and ‘Autoenroll’ are checked > OK

On Each Domain Controller (DC):
Run > certlm.msc > Expand the Certificates – Local Computer > Personal > Certificates > remove any expired certs > Reboot or just wait awhile for autogen

When ready, run certlm.msc > verify that the DC has automatically requested a new cert

How to Change Validity Period for Certs Being Issued

A) Configure CA Server to Increase Validity Period Units

By default, the maximum validity period of a CA is 2-year, regardless on whether the template would specify a longer period. Therefore, it is necessary to configure the CA server to allow it to grant a maximum of 10-year certificates, if its templates would specify such periods. That is, the CA will always follow the logic of setting the lesser of:

1. The validityPeriodUnits & ValidityPeriod registry entries
2. The remaining lifetime of an existing CA certificate as compared to its template
3. The validity period requested in the cert request by the requester
4. The validity period defined in the certificate template

Use PowerShell running as Administrator to edit the registry key:

$ValidityPeriodUnits=10
$caName=($env:USERDOMAIN).tolower()+"-$env:computername-CA"
$registryPath="REGISTRY::HKLM\System\CurrentControlSet\Services\CertSvc\Configuration\$caName"
Set-ItemProperty -Path $registryPath -Name ValidityPeriodUnits -Value $ValidityPeriodUnits -Type DWord
get-itemproperty -Path $registryPath -Name ValidityPeriodUnits
Restart-Service -Name CertSvc # Restart ADCS

B) Creating a New Cert Template

Certain templates would allow editing of its validity period without having to clone their originals. Here are the steps to edit such easy templates as ‘Kerberos Authentication’:

Run certsrv.msc > right-click Certificate Templates > Manage > double-click “Kerberos Authentication” > General Tab > change ‘Validity Period’ to 5 years > Security Tab > ensure that ‘Domain Controllers’ and ‘Enterprise Domain Controllers’ have the ‘Autoenroll’ option enabled > OK

Certain other templates, such as the ‘Domain Controller’, will not allow editing its time periods of expiration; hence, it would then become necessary to to create a new template basing on an existing one as illustrated below. This is an example of creating a custom template by cloning an existing one to succeed the original.

Run certsrv.msc > right-click Certificate Templates (or just run certtmpl.msc) > Manage > Select “Domain Controllers” > Duplicate Template

Change Template Display Name to ‘Domain Controller 5 Years’ > set Validity period = 5 years

Click on Security tab > select Domain Controllers > Autoenroll >

Select the Subject Name tab > toggle the drop-down menu to change Subject Name Format from ‘None’ to ‘DNS Name’

Click Extensions tab > highlight Application Policies > Edit

Edit Application Policies Extension window appears > Add > select ‘Smart Card Logon’ > OK > OK > select ‘Suspended Templates’ tab > Add > highlight both ‘Domain Controller’ and ‘Domain Controller Authentication’ > Apply > OK to create the new template

Close the Certificate Templates Console to return to the certsrv [Certification Authority] window > right-click on the CA node > All Tasks > Stop Service > repeat to Start Service (to effectively restart the certsvc service, allowing a reload and rediscovering of newly created templates) – alternatively, just run this command: Restart-Service CertSvc

Select Certificate Templates > highlight Domain Controller > delete > Confirm > right-click on Certificate Templates > New > Certificate Template to Issue

Select ‘Domain Controller 5 Years’ > OK

Right-click Certificate Templates > Refresh > verify that the new template is now added to the list

Repeat this process to create the ‘Directory Mail Replication’ template, if necessary.

Requesting Certificates

After the CA has been setup as desired, one could wait a few minutes for the new Templates to propagate in AD (run gpupdate /force to fast pace this process) so the new template will call all Domain Controllers to enroll automatically, all DCs will be issued a cert as soon as the default domain group policy (GP) gets applied – no new GPs are required.

To manually retrieve a certificate using this new template: run certlm.msc > Personal > right-click Certificates > All Tasks > Request New Certificate

Click Next > Next > select ‘Domain Controllers 5 Years’ > Enroll

Note: sometimes, a problem of Certificate Template Missing from “Certificate Template to Issue” would occur if the certificate template ‘Domain Controller 5 Years’ has not been added to the Certificate Templates list on the CA or SubCA server. Resolution would be to return to the CA and retrace the instructions in the previous section.

How To Manually Change Renewal Validity Period for Certificate Renewals or New Issuance

Part A: Configure Cert Services with a New Validity Period

# Method 1: Use CertUtil command
certutil -setreg CA\ValidityPeriod "Years"
certutil -setreg CA\ValidityPeriodUnits 10
net stop certsvc
net start certsvc

# Method 2: Create a policy file:

$caCertPolicy="$env:systemroot\CAPolicy.inf"
$policy=@"
[Version]
Signature='`$Windows NT`$'
`
[Certsrv_Server]
RenewalValidityPeriod=Years
RenewalValidityPeriodUnits=10
"@
set-content -Path $caCertPolicy -Value $policy
get-content $caCertPolicy
Restart-Service -Name CertSvc # Restart ADCS

Note: The spelling of the dword name variables must be correct. Otherwise, strange things may occur. Hence, it’s always a good idea to check the registry after invoking the cmdlets.

Checking certificate validity periods via GUI:

Run regedit > Navigate to HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\CertSvc\Configuration\$CAName > verify that Validity Period = Years and Validity Period Units =  20 > Close regedit > Run PowerShell as Administrator > Restart-Service -Name CertSvc

# Validation via CLI
PS C:\Windows\system32> certutil -getreg ca\ValidityPeriodUnits
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\intranet-kimconnectcom-ca\ValidityPeriodUnits:
ValidityPeriodUnits REG_DWORD = 10 (10)
CertUtil: -getreg command completed successfully.

Part B: Renew CA Cert

Prerequisite: the login user ID must be a member of the domain Enterprise Admins for this procedure

To extend the validity period for Root CA cert: run certsrv.msc > right-click the RootCA > All Tasks > Renew CA Certificate

Make sure that the toggle selection next to ‘No’ is selected > OK

To extend certs already issued: run certlm.msc > Personal > Certificates > right-click on a Cert that has used a template with validity period allowable that is equal to or greater than the registry value above (e.g. ‘Domain Controller 5 Years’ shown in the previous section) > All Tasks > Advanced Operations > Renew This Certificate with the Same Key > Next > Enroll > OK

How to Manually Request A Cert

GUI Option:

Run > certlm.msc > Expand the Certificates – Local Computer > Personal > right-click Certificates > All Tasks > Request New Certificate > Next > Next > Put a check mark to each of the Type of Certificate to be associated with Active Directory Enrollment Policy > select the drop-down arrows next to each Cert Type > Properties > select the Certification Authority tab > select or deselect Enterprise Root CA as desired > OK > Enroll > Observe that new Certs would populate the Personal Certificates folder

# Variation 1: requesting from a template
$requestFile="C:\$env:computername.req"
cmd /c "certreq.exe -attrib "CertificateTemplate:DomainController5Years" -submit $requestFile"

############################

# Variation 2: requesting from an inf file

# Content of C:\RequestConfig.inf
[NewRequest]
Subject = "CN=<FQDN of Root CA or SubRootCA>"
Exportable = TRUE
KeyLength = 2048
KeySpec = 1
KeyUsage = 0xf0
MachineKeySet = TRUE
[RequestAttributes]
CertificateTemplate='DomainController5Years'
[Extensions]
OID = 1.3.6.1.5.5.7.3.1
OID = 1.3.6.1.5.5.7.3.2

# Command
CertReq -New C:\RequestConfig.inf C:\CertRequest.req

############################

# Variation 3:
$requestFile="C:\$env:computername.req"
$newCert="C:\$env:computername.cer"
$newPfx="C:\$env:computername.pfx"
cmd /c "certreq –submit $requestFile $newCert $newPfx"

How to View / Delete Certificates Local Machine Cert Store

Note: when viewing contents certificate store via GUI, you’ll occasionally see what appear to be two copies of the same certificate in the store. This situation occurs mostly likely because that Cert has revision(s) that would cause the expiration dates to differ. Hence, it’s often safe to ignore those seeming anomalies.

These are the common Cert stores:
————
Root: ‘Trusted Root Certification Authority’
CA: ‘Intermediate Certification Authority’
Personal: ‘MY’

# View certs via PowerShell
$store='MY'
Get-ChildItem -Path "Cert:\LocalMachine\$store"

# View certs via GUI
$store='MY'
certutil -viewstore $store

# How to Remove a Certificate
$certStore='MY'
$certThumbprint='E41ECHICKEN4E288NUGGETS0153MCDONALDSEF4248B'
Remove-Item cert:\LocalMachine\$certStore\$certThumbprint

How to Accept or Renew a Cert

# Accepting cert:
$newCert="C:\$env:computername.cer"
certreq -accept $newCert

# Renewing a certificate:
$certSerialNumber="1a 2b 3c 4e 00 00 00 00 00 05"
certreq -enroll -machine -cert $certSerialNumber Renew

Copy the request file from the client onto the RootCA or SubCA server > certsrv.msc >
Right-click Root CA > All Tasks > submit new request > browse to location of request file > OK >
Open Pending Requests folder > right-click on the new request item > All Tasks > Issue

ld = ldap_sslinit("localhost", 636, 1);
Error 0 = ldap_set_option(hLdap, LDAP_OPT_PROTOCOL_VERSION, 3);
Error 0 = ldap_connect(hLdap, NULL);
Error 0 = ldap_get_option(hLdap,LDAP_OPT_SSL,(void*)&lv);
Host supports SSL, SSL cipher strength = 256 bits
Established connection to localhost.
Retrieving base DSA information...
Getting 1 entries:
Dn: (RootDSE)
configurationNamingContext: CN=Configuration,DC=corp,DC=kimconnect,DC=com;
currentTime: 10/7/2020 4:12:23 PM Pacific Daylight Time;
defaultNamingContext: DC=corp,DC=kimconnect,DC=com;
dnsHostName: DC05.corp.kimconnect.com;
domainControllerFunctionality: 6 = ( WIN2012R2 );
domainFunctionality: 3 = ( WIN2008 );
dsServiceName: CN=NTDS Settings,CN=DC05,CN=Servers,CN=720Olive,CN=Sites,CN=Configuration,DC=corp,DC=kimconnect,DC=com;
forestFunctionality: 3 = ( WIN2008 );

$ldapServer='ca01.intranet.kimconnect.com'
$ldapPort=636
openssl s_client -connect "$ldapServer`:$ldapPort"

PS C:\Windows\system32> openssl s_client -connect "$ldapServer`:$ldapPort"
CONNECTED(000001A8)
write:errno=10054
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 331 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---

PS C:\Windows\system32> openssl s_client -connect "$ldapServer`:$ldapPort"
CONNECTED(0000013C)
depth=0
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0
verify error:num=21:unable to verify the first certificate
verify return:1
---
Certificate chain
0 s:
i:DC = com, DC = intranet, CN = intranet-DC01-CA-1
---
Server certificate
-----BEGIN CERTIFICATE-----
SOMECODE+MOREHASH
### Truncated for brevity ###
-----END CERTIFICATE-----
subject=
issuer=DC = com, DC = intranet, CN = intranet-DC01-CA-1
---
No client certificate CA names sent
Client Certificate Types: RSA sign, DSA sign, ECDSA sign
Requested Signature Algorithms: RSA+SHA512:ECDSA+SHA512:RSA+SHA256:RSA+SHA384:RSA+SHA1:ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA1:DSA+SHA1
Shared Requested Signature Algorithms: RSA+SHA512:ECDSA+SHA512:RSA+SHA256:RSA+SHA384:RSA+SHA1:ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA1:DSA+SHA1
Peer signing digest: SHA1
Peer signature type: RSA
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 2082 bytes and written 521 bytes
Verification error: unable to verify the first certificate
---
New, TLSv1.2, Cipher is ECDHE-RSA-AES256-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES256-SHA384
Session-ID: SOMEHASH
Session-ID-ctx:
Master-Key: SOMEHASH
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1630360263
Timeout : 7200 (sec)
Verify return code: 21 (unable to verify the first certificate)
Extended master secret: yes
---

Run pkiview.msc (or MMC > Add Snapin 'Enterprise PKI') > expand Enterprise PKI > right-click the CA Node > Manage CA >
certsrv.msc pops up with auto targeting toward the correct CA > right-click the CA node > All Tasks > Stop Service >
Wait at least a few days or weeks to ensure that stopping the subject CA would not have adverse impacts prior to considering decommissioning of that Node

---------------------------
Microsoft Active Directory Certificate Services
---------------------------
Cannot manage Active Directory Certificate Services.

The system cannot find the file specified. 0x80070002 (WIN32: 2 ERROR_FILE_NOT_FOUND)
---------------------------
OK 
---------------------------

PS C:\Users\backupadmin> certutil -shutdown
CertUtil: -shutdown command completed successfully.

PS C:\Users\backupadmin> certutil -key
Microsoft Strong Cryptographic Provider:
SMS
-b19f-479b-a51e-
RSA
AT_KEYEXCHANGE, AT_SIGNATURE

iis-web(1)
-b19f-479b-a51e-
RSA
AT_SIGNATURE

{-A006-4721-8578-}
-b19f-479b-a51e-
RSA
AT_SIGNATURE

iisConfigurationKey
-b19f-479b-a51e-
RSA
AT_KEYEXCHANGE

iis-web
-b19f-479b-a51e-
RSA
AT_SIGNATURE

iisWasKey
-b19f-479b-a51e-
RSA
AT_KEYEXCHANGE

MS IIS DCOM Server
-b19f-479b-a51e-
RSA
AT_KEYEXCHANGE, AT_SIGNATURE

Microsoft Internet Information Server
-b19f-479b-a51e-
RSA
AT_KEYEXCHANGE, AT_SIGNATURE

NetFrameworkConfigurationKey
-b19f-479b-a51e-
RSA
AT_KEYEXCHANGE

TSSecKeySet1
-b19f-479b-a51e-
RSA
AT_KEYEXCHANGE

{-C20B-40D3-B7C6-}
-b19f-479b-a51e-
RSA
AT_SIGNATURE

CertUtil: -key command completed successfully.

CertUtil: -delkey command completed successfully.
PS C:\Users\backupadmin> certutil -delkey "iis-web(1)"
ops-web(1)
CertUtil: -delkey command completed successfully.

PS C:\Users\backupadmin> certutil -delkey '{BD27DC3E-C20B-40D3-B7C6-F0D50C5332B1}'
{BD27DC3E-C20B-40D3-B7C6-F0D50C5332B1}
CertUtil: -delkey command completed successfully.

PS C:\Users\backupadmin> certutil -delkey 'Microsoft Internet Information Server'
Microsoft Internet Information Server
CertUtil: -delkey command completed successfully.

PS C:\Users\backupadmin> Uninstall-AdcsCertificationAuthority -Force

ErrorId ErrorString
------- -----------
0

Navigate to Services > Public Key Services > CDP > Right click the container object where Certificate Services is installed > Delete > Yes

Navigate to Services > Public Key Services > Certification Authorities > Right click the CA object > Delete > Yes

Navigate to Services > Public Key Services > Enrollment Services > right-click on the subject pKIEnrollment > Delete > Yes

Optional: Navigate to Services > Public Key Services > Certificate Templates > Delete any unnecessary templates

Alternatively, the preceding steps could be accessed through a different AD console: Run adsiedit.msc > CN=Configuration > CN=Services > CN=Public Key Services

Run this command as Administrator: certutil -dcinfo deleteBad

PS C:\Users\backupadmin> certutil -dcinfo deleteBad
0: DC01
1: DC02
2: DC03
3: DC04

*** Testing DC[0]: DC01
** Enterprise Root Certificates for DC DC01
Certificate 0:
Serial Number: 
### Truncated for brevity ###

2 KDC certificates for DC03

CertUtil: -DCInfo command completed successfully.