I manage a few small networks where there is a single server for the company. Last year, on one of those networks, I set up Server 2022 with a new domain from scratch. I did not install Certificate Services. It created a 20-year self-signed certificate for both Server Authentication and Client Authentication and has been happy with that ever since.On two other networks, I migrated domains from old Server 2012R2 or 2016 Essentials to Server 2022. The old Essentials machines included Certificate Services, which issued one-year certificates to my new Server 2022 machines. The old Essentials machines are now demoted and gone.
Now, the one-year certs are about to expire and the CAs are gone so cannot renew them.
Do I need certificates at all? Are they being used?
TL;DR – jump to the bottom to skip all the details.
Deleting the Expiring Certificate
After some conversation in this thread, I decided to try deleting the one-year certificate from my in-house server (a little nerve-wracking since the private key was non-exportable). The server and network still function, but I am getting some warnings and errors in the Event Log. Here’s what happened,
This event documents the time when I deleted the certificate:
Log Name: Microsoft-Windows-CertificateServicesClient-Lifecycle-System/Operational
Source: Microsoft-Windows-CertificateServicesClient-Lifecycle-System
Date: 9/25/2024 3:38:16 PM
Event ID: 1004
Task Category: None
Level: Information
Description: A certificate has been deleted. Please refer to the “Details” section for more information.
The server immediately noted that it won’t be able to provide LDAP over Secure Sockets Layer, even though I’m not using it as far as I know:
Log Name: Directory Service
Source: Microsoft-Windows-ActiveDirectory_DomainService
Date: 9/25/2024 3:38:16 PM
Event ID: 1220
Task Category: LDAP Interface
Level: Warning
Description: LDAP over Secure Sockets Layer (SSL) will be unavailable at this time because the server was unable to obtain a certificate.
It also warned about no suitable certificate, implying that the directory server needs one:
Log Name: System
Source: Schannel
Date: 9/25/2024 3:38:16 PM
Event ID: 36886
Task Category: None
Level: Warning
Description: No suitable default server credential exists on this system. This will prevent server applications that expect to make use of the system default credentials from accepting SSL connections. An example of such an application is the directory server. Applications that manage their own credentials, such as the internet information server, are not affected by this. The SSPI client process is lsass (PID: 760).
The next morning I got four of the following errors within two seconds. It doesn’t say which application failed to connect. The details point to Process ID 744, which is the Local Security Authority Process (lsass.exe), so that doesn’t tell us much. There are no Audit Failures in the Security event log at that time. I do see a client computer on the domain refreshing Group Policy at that time; the refresh was successful.
Log Name: System
Source: Schannel
Date: 9/26/2024 7:07:31 AM
Event ID: 36874
Level: Error
Description: An TLS 1.2 connection request was received from a remote client application, but none of the cipher suites supported by the client application are supported by the server. The TLS connection request has failed. The SSPI client process is SYSTEM (PID: 4).
I’ve had those Schannel errors ever 14-21 days even when the certificate was good, so that one could be a coincidence.
Creating a Self-Signed Certificate
It does sound like the server would be happier with a certificate. So how do I create a self-signed certificate? Using this helpful reference and the certificate on the “from-scratch-domain” server as a guide, here’s what I came up with (for use at an administrative PowerShell prompt):
To view all properties of the certificate(s) in the model server’s store:
Get-ChildItem Cert:\LocalMachine\My | select-object *
To create a new self-signed cert with a 20-year duration, I first tried this:
$cert = New-SelfSignedCertificate -Subject MCB-DC.mcbsys.local -NotAfter (Get-Date).AddYears(20)
$cert | Format-List -Property *
Note that the certificate is automatically created in the Personal store of the computer certificates. This was pretty close, but it lacked the Subject Alternative Name (SAN). It did include the correct Enhanced Key Usage:
Client Authentication (1.3.6.1.5.5.7.3.2)
Server Authentication (1.3.6.1.5.5.7.3.1)
However it only included two Key Usages:
Digital Signature, Key Encipherment (a0)
as opposed to the six included in the from-scrath server:
Digital Signature, Key Encipherment, Data Encipherment, Certificate Signing, Off-line CRL Signing, CRL Signing (b6)
So to remedy that, here’s the full command (after digging in to the New-SelfSignedCertificate documentation):
$cert = New-SelfSignedCertificate -DnsName 'MCB-DC.mcbsys.local' -NotAfter (Get-Date).AddYears(20) -KeyUsage DigitalSignature,KeyEncipherment,DataEncipherment,CertSign,CRLSign
$cert | Format-List -Property *
That does create a certificate that is pretty close to the one created automatically when I set up a new domain without Certificate Services. Interesting that the private key is exportable—apparently the model server’s certificate added “KeyExportPolicy = ‘NonExportable'” to the command.
Of somewhat greater concern is that it immediately raised a Directory Services > ActiveDirectory_DomainService event 1220: “LDAP over Secure Sockets Layer (SSL) will be unavailable at this time because the server was unable to obtain a certificate.” It also raised the System > Schannel 36886 warning: “No suitable default server credential exists on this system.”
Troubleshooting
I found a NetTools.com article on How to Troubleshoot AD LDAPS Connection Issues and downloaded their free software NetTools.exe. Then I found this Microsoft article that mentions the built-in ldp.exe tester (just be sure to connect to port 636 as SSL):
After much trial, error, and googling, I realized that this error held the clue:
Log Name: System
Source: Schannel
Date: 9/26/2024 6:44:26 PM
Event ID: 36882
Level: Error
Description:
The certificate received from the remote server was issued by an untrusted certificate authority. Because of this, none of the data contained in the certificate can be validated. The TLS connection request has failed. The attached data contains the server certificate. The SSPI client process is NetTools (PID: 9716).
All I had to do was to copy the new certificate from the Personal store to the Trusted Root Certification Authorities store. You can do this in Certificate Manager with a right-click and drag to the new store, then choose Copy. After that, I was able to connect with both NetTools and ldp.
According to this Microsoft article, “If an existing LDAPS certificate is replaced with another certificate, either through a renewal process or because the issuing CA has changed, the server must be restarted for Schannel to use the new certificate.” So it doesn’t hurt to reboot.
I went back to my “model” server, the one that I set up with a new domain and no Certificate Services, and discovered that ldp was not able to connect there either. So perhaps LDAPS hasn’t been working there and it just hasn’t complained much.
If the server gets confused about which certificate to use for LDAPS, you can copy the certificate directly to the NTDS personal store. This article has instructions on importing it there, and this article has instructions on using PowerShell to do the copy. This was part of my trial and error, but in the end was not needed on my server.
TL;DR
In summary, here are the steps I followed to migrate a standalone domain controller from an expiring CA certificate to a self-signed certificate. Use at your own risk!
1. Export the expiring cert from the domain controller’s computer certificates (to keep a copy of its attributes), then delete it. You may want to check the Intermediate Certification Authorities store and the Trusted Root Certification Authorities store, deleting old Server 201212R2/2016 CA server(s) there as well.
2. Create a new cert in from an administrative PowerShell prompt:
New-SelfSignedCertificate -DnsName 'MyDC.mydomain.local' -NotAfter (Get-Date).AddYears(20) -KeyUsage DigitalSignature,KeyEncipherment,DataEncipherment,CertSign,CRLSign
3. Open Manage Computer Certificates. Right-click to copy the new certificate from the Personal store to the Trusted Root Certification Authorities store. This may be optional but does enable an LDAPS connection (see the ldp.exe test above).
4. Reboot the server.