I recently migrated from Server Essentials 2012 R2 to Server 2016 Standard with the Essentials role. Both of these machines run a self-signed Certification Authority (CA). The old machine has been demoted and decommissioned. On the new machine, I’ve occasionally been getting the following error about a missing certificate:
Log Name: System
Date: 8/17/2017 10:23:10 AM
Event ID: 19
This event indicates an attempt was made to use smartcard logon, but the KDC is unable to use the PKINIT protocol because it is missing a suitable certificate.
Microsoft published KB967623 about the same error on Server 2008. The following paragraph under More Information caught my eye:
This issue may also occur because of invalid domain controller certificates. Domain controller certificates may become invalid if you remove a CA that was installed in the domain. After you remove the CA, the domain controller still tries to contact the CA. To resolve this issue, remove all the invalid domain controller certificates.
When I checked the computer certificate store on the new machine, under Personal, I do in fact see a Domain Controller certificate issued to the new computer by the old server. Since the old computer’s CA is no longer around, that certificate could well be invalid.
(Incomplete) instructions for deleting and re-issuing a domain controller certificate can be found here:
Although not mentioned in their instructions, before starting, I exported the Domain Controller certificate to a file. The private key was marked as non-exportable, so I was not able to export that.
Lost Remote Desktop Connection
After deleting the certificate as suggested, I was unable to re-connect to the server using Remote Desktop (“Because of a protocol error, this session will be disconnected.”) This machine is running as a virtual machine under Hyper-V. I was able to connect to the console by starting from Hyper-V Manager on the host.
The next step in the article above is to re-issue the domain controller certificate by running the Request New Certificate wizard. Unfortunately, the wizard does not include an enrollment template for domain controllers. Instead, it invites me to create my own by providing an enrollment policy server URI. Huh?
I figured the server itself must be the enrollment policy sever, but I tried and failed to find a URI it would accept.
From the Essentials dashboard, I ran an Anywhere Access repair. It completed successfully but did not re-issue the Domain Controller certificate. Not surprising, since that is about external (“anywhere”) access.
I found a couple sites that suggested issuing a Domain Certificate from IIS. Tried, that, but it created a Web Server certificate, not a Domain Controller certificate. Again, not surprising.
At this point, I re-imported the “bad” certificate issued by the old machine. Even without the private key, I was once again able to connect via Remote Desktop. However I suspect that the missing private key will cause other problems. In fact, I soon got this error in the System event log:
The TLS server credential’s certificate does not have a private key information property attached to it. This most often occurs when a certificate is backed up incorrectly and then later restored. This message can also indicate a certificate enrollment failure.
Finally, because I’d seen it mentioned in a couple places, I tried this at the command line, which is supposed to “Pulse autoenrollment event or NGC task”:
certutil – pulse
That returned the message, “CertUtil: -pulse command completed successfully.” And it worked! After that, the Personal store showed two certificates with the Domain Controller certificate template. The new one shows that it is issued by the new server. As suggested in the original article cited above, I ran
certutil -dcinfo verify
It showed “2 KDC certificates” for my server.
Then I re-deleted the certificate issued by the old server. Now it shows “1 KDC certificate” for my server. There are still several CRYPT_E_NOT_FOUND errors but I think that is another issue. I can still connect via Remote Desktop.