The value data would be the SHA1 hash of the self-signed certificate that was created, something like: Now, the hacker in you might think to look to the Registry for a solution, and you would indeed find the value SSLCertificateSHA1Hash in the hive. These certificates would be perfectly valid if we could just select them, and clients could be configured to trust them by installing the issuing authority's certificate. This can be frustrating because if you are like me, you have already got an Enterprise Root Certificate Authority in your domain and it is enrolling both users and computers with corresponding certificates.
This is the cert it uses, and you cannot change it via a Session Host Configuration app since one is not provided. In order for the workstation to secure RDP, it creates this self-signed certificate in the remote desktop certificate store. Manually configuring this on each client would be a huge administrative burden. You cannot simply trust the issuing certificate authority on the client because there is not one. If you have disabled connections with authorization failures, as you should, then you could find yourself in a pickle since you would have to export each individual self-signed certificate to whatever client is going to connect. This is all well and good, except for when you try to connect to it from a client that does not trust it.
Timothy “Thor” Mullen, in Thor's Microsoft Security Bible, 2011 Workstation Host ConsiderationsĪnother configuration issue with certificates that you need to be aware of if you want users to be able to connect up to their own desktops is that the workstation implementation of Remote Desktop (as in Windows 7 or Vista) uses a self-signed personal certificate to secure the RDP connection.
0 kommentar(er)
