Today, I have run again to the common problem with the PKI autoenrollment technology which automatically renews certificates which are based on certificate templates. It was in combination with Remote Desktop Services (RDP) and their domain based, automatically issued internal certificate.
In a customer environment, they use their own intenal CA (based on AD CS) and issue RDP server certificates automatically to all RDP servers. In fact, they issue the certificates to all machines as most machine can be accessed remotely over RDP either by their own employees or some administrators staff.
They use the Remote Desktop Authentication EKU certificates (OID 220.127.116.11.4.1.318.104.22.168). The Remote Desktop Configuration service (SessionEnv) running on all the RDP servers (in fact, most of them are workstations) automatically enrolls for the the certificate if none is available. That works correctly. But it does not use the autoenrollment technology actually. It just requests the certificate "automatically". I say "automatically" because it does not need the Autoenroll permission on the certificate template. It makes do with the Enroll permission only, just like you were enrolling for a certificate manually. So rather to call it semi-automatically, because it does not require user action, but it also does not require the autoenrollment process.
Note - it is just the same behavior that you can observe with EFS.
And here comes the problem. They have autoenrollment technology enabled as well. And it also renews the certificates itself. What is worse, it does the renewal at some point prior the certificate expiration - typically at its 80% time of expiration. What the worst thing here is, is that the autoenrollment process also archives the existing, although still valid, certificate.
And it confuses the Remote Desktop Configuration service (SessionEnv) completelly. If it sees a yet valid certificate, although it is already archived, it ignores the archive bit on the certificate and tries to use it. But, because the certificate is archived, it cannot be used by the SChannel SSP and the TLS/SSL connection fails with the following errors:
Remote Desktop Connection - the connection cannot proceed because
authentication is not enabled and the remote computer requires that
authentication be enabled to connect.
The identity of the remote computer cannot be verified. This problem
can occur if the remote computer is running a version of Windows that
is earlier than Windows Vista, or if the remote computer is not
configured to support server authentication.
Event Id: 36870
Event level: Error
A fatal error occurred when attempting to access the SSL server credential
private key. The error code returned from the cryptographic module
is 0x8009030d. The internal error state is 10001.
Even if you yourself want to see the archived certificates on the server, you must enable it in the Certificates MMC console, in its View - Options - Archived certificates. Normally, you do not see archived certificates in the console by default. So no magic the SessionEnv service (or rather to say the SChannel SSP which performs the TLS actually) does not work correctly with such a confused setup.
How to solve it? You must either delete the archived certificates and restart the Remote Desktop Configuration service (SessionEnv), or you must replace the server certificate with the Remote Desktop Session Host Configuration console or with PowerShell.