Mitigation of RSA 1024-bit Certificate on Domain Controllers

Question

Mitigation of RSA 1024-bit Certificate on Domain Controllers

Yogesh Bhatia 21

Hi,

We have four Domain Controllers, and during the recent penetration test we identified the vulnerability “SSL Certificate Chain Contains RSA Keys Less Than 2048 bits” on TCP ports 636 (LDAPS) and 3269 (Global Catalog over SSL) across all DCs.

Upon verification, we observed that the default Domain Controller certificate on each DC was issued using RSA 1024-bit keys, based on the Domain Controller certificate template.

I would like guidance on the safe and recommended approach to mitigate this vulnerability. While I have reviewed the mitigation steps referenced in the Microsoft article below, I would like to better understand:

What are the steps I have to follow to fix this?
The impact on production during and after certificate replacement
Any future impact on certificate auto-enrollment, particularly after modifying the certificate template
The rollback procedure, in case any issues are observed after implementing the changes

Reference: https://learn.microsoft.com/en-us/answers/questions/104861/domain-conroller-certificate-key-size

Your advice on best practices for remediation and risk mitigation would be greatly appreciate.

Answer accepted by question author

0 additional answers

Your answer

Answer 1

VPHAN 25,000 Independent Advisor

Hello Yogesh Bhatia,

Before proceeding with the optimal solution, I must ask for a bit more detail regarding your environment. Could you specify the Windows Server operating system versions running on your domain controllers and your Enterprise Certificate Authority? Additionally, do you have any legacy third-party applications that rely on certificate pinning for their LDAPS connections? Knowing this ensures we account for strict TLS negotiation requirements and avoid unexpected authentication failures across your domain.

Assuming you are running a supported Windows Server architecture, the most precise mitigation is to utilize the Microsoft Management Console to access your Enterprise CA and duplicate the Kerberos Authentication template. Within the properties of this new template, you must navigate to the Cryptography tab to verify the minimum key size is strictly set to 2048 bits using the Key Storage Provider. You must then navigate to the Superseded Templates tab and explicitly add the legacy Domain Controller and Domain Controller Authentication templates. On the Security tab, ensure that both the Domain Controllers and Enterprise Read-Only Domain Controllers groups are granted Read and Autoenroll permissions. Once configured, you can issue this new template on the CA.

Regarding production impact, while modern Schannel implementations attempt to dynamically bind the newest valid certificate within the Local Machine Personal store, persistent LDAP connection pools from certain applications may cache the previous Schannel context. To ensure absolute compliance and prevent binding anomalies during the transition, you should schedule a brief maintenance window to restart the Active Directory Domain Services (NTDS) service on each domain controller after the new certificate is auto-enrolled. Your auto-enrollment infrastructure requires no modification; the Group Policy background refresh will detect the supersedence directive, request the new 2048-bit certificate, and automatically archive the legacy 1024-bit certificate.

If you must execute a rollback, don't manually delete certificates first, which breaks the active binding. Instead, remove the newly created Kerberos Authentication template from the CA issuance container, republish the legacy Domain Controller template, and execute certutil -pulse from an elevated command prompt on the domain controllers to pull the legacy certificate. Only after verifying the 1024-bit certificate is fully enrolled and present in the certlm.msc console should you manually archive or delete the 2048-bit certificate from the local machine store and restart the NTDS service to revert the Schannel binding.

Hope you found something useful in the answer. If it helped you get more insight into the issue, please consider accepting it. Thank you and have a nice day!

VP

Yogesh Bhatia 21 Reputation points

2026-02-19T12:16:35.3933333+00:00
Hi @VPHAN , Thank you for the explanation.

Environment Details:

Active Directory and Certificate Services OS version: Windows Server 2019

Client operating systems: Windows Server 2016 / 2019 / 2022

There are no legacy or third-party applications relying on LDAPS or certificate pinning in this environment.

Queries:

For mitigation, is it recommended to duplicate the Kerberos Authentication certificate template, or can the Domain Controller Authentication template be used to issue the new certificate with a minimum RSA key size of 2048 bits?

After issuing the new template and successful auto-enrollment on the Domain Controllers, should the existing RSA 1024-bit certificate in the Local Computer → Personal store be:

automatically archived/retired by auto-enrollment, or

manually deleted after verification?

Since the penetration test reports “The X.509 certificate chain used by this service contains certificates with RSA keys shorter than 2048 bits”, will the legacy RSA 1024-bit certificate be:

automatically removed from the active certificate chain once the new certificate is bound, or

does it require manual cleanup to fully remediate the finding?
VPHAN 25,000 Reputation points Independent Advisor

2026-02-19T17:18:29.6033333+00:00

You must strictly use the Kerberos Authentication template rather than the Domain Controller Authentication template, as it is the most current Microsoft standard designed for modern KDC strict validation, smart card logon, and secure LDAPS bindings. When you duplicate this template, verify the Key Storage Provider is configured for an RSA key size of at least 2048 bits under the Cryptography tab, and explicitly add your existing legacy templates to the Superseded Templates tab to initiate the replacement lifecycle.

Regarding the disposition of the legacy 1024-bit certificates, the Windows auto-enrollment client is natively engineered to automatically archive any superseded certificates located within the Local Computer Personal store once the new Kerberos Authentication certificate is successfully enrolled. Archiving removes the certificate from active binding selection by the Schannel security support provider, but it retains the cryptographic material within the machine's registry. Because advanced penetration testing scanners often probe persistent LDAP connection pools or interrogate local stores exhaustively, relying solely on the auto-archive attribute frequently results in the vulnerability remaining flagged as a false positive during immediate rescans.

To ensure the vulnerable RSA 1024-bit chain is completely eradicated from the environment and the scanner reports a clean state, you must execute a manual cleanup phase to augment the auto-enrollment process. After utilizing certlm.msc to verify the 2048-bit Kerberos Authentication certificate is fully enrolled and valid, manually delete the legacy 1024-bit certificate from the Personal store on each domain controller. Following this deletion, you must restart the Active Directory Domain Services (NTDS) service or perform a full server reboot. This action forces the Domain Controller to destroy the existing Schannel context, rebuild the LDAPS listener, and exclusively bind the new 2048-bit certificate, definitively dropping any cached TLS sessions that might otherwise expose the legacy key chain to your security auditing tools.

VP
Yogesh Bhatia 21 Reputation points

2026-02-25T07:03:42.3933333+00:00

Hi @vphan

I followed the steps exactly as suggested; however, the certificate is still using the old RSA 1028 key. We have also restarted all the domain controllers, but the certificate has not updated automatically.

Could you please advise why the new certificate is not being issued or auto-renewed?
VPHAN 25,000 Reputation points Independent Advisor

2026-02-25T07:17:45.3366667+00:00

Hi Yogesh Bhatia,

Open the Certificate Templates Console , duplicate the Kerberos Authentication template, and navigate to the Cryptography tab to define a minimum key size of 2048 bits utilizing the Microsoft Software Key Storage Provider. Critically, navigate to the Superseded Templates tab and explicitly add the old Domain Controller and Domain Controller Authentication templates. Publish this new template on your Certificate Authority and ensure the Domain Controllers security group has Read, Enroll, and Autoenroll permissions assigned.

The reason your domain controllers did not automatically request a new certificate upon restart is that the Group Policy auto-enrollment engine only triggers a new request when an existing certificate enters its renewal period or when a definitively superseded template is published to Active Directory. Once you configure the supersession on the new template and the background Group Policy refreshes, the local Certificate Services Client will seamlessly execute the enrollment. During this process, the Active Directory Domain Services process natively monitors the Local Computer Personal store and dynamically binds the newly issued 2048-bit certificate for LDAPS on TCP ports 636 and 3269, ensuring zero downtime for your production environment without requiring a service restart.

Auto-enrollment is designed to automatically archive the superseded 1024-bit certificate, which logically removes it from the active Schannel TLS handshake chain. Active Directory NTDS immediately prefers the compliant 2048-bit key for securing the LDAP binding, remediating the vulnerability over the network. However, because many penetration testing scanners deeply inspect local machine store files rather than merely evaluating network handshakes, the presence of the archived legacy certificate may still trigger a false-positive vulnerability finding. To guarantee absolute compliance and completely clear the audit finding, you should manually delete the legacy 1024-bit certificate from the certlm.msc console under the Local Computer Personal store once the new certificate is verified.

Future certificate auto-enrollment will continue functioning autonomously based on the lifecycle parameters defined in your new Kerberos Authentication template. If you encounter any authentication anomalies requiring an emergency rollback, the procedure is highly controlled. You must unpublish the new Kerberos Authentication template from the Certificate Authority, delete the newly issued 2048-bit certificates from the Personal store of each domain controller, and force a manual enrollment targeting the legacy template using the certreq command line utility.

VP

Share via

Mitigation of RSA 1024-bit Certificate on Domain Controllers

0 additional answers

Your answer