I previously wrote a poston enabling Powershell Remoting over HTTPS. This has led to be carrying out a little more investigation on the security and certification considerations. For example, when creating the HTTPS listener the thumbprint is specified, but what happens when the certificate is renewed and the thumbprint changes?
As a quick recap, we were using
1 |
winrm create winrm/config/Listener?Address=*+Transport=HTTPS @{Hostname="$FQDN ";CertificateThumbprint="$thumbprint "} |
to create the HTTPS listener. The $thumbprint is obtained from the Server Authentication certificate that must be in place with the subject that equals the FQDN of the machine.
You can view the configuration of the listener by running the following
1 |
winrm enumerate winrm/config/listener |
or
1 |
winrm get winrm/config |
In a enterprise environment certificates are probably set automatically renew and when this happens the thumbprint of the certificate changes. However, the listener still functions and clients are still able to establish a connection using
1 |
Enter-PSSession -ComputerName fqdn -UseSSL |
If the certificate is deleted from the machine, the listener still continues to function and clients can connect over HTTPS, even after the machines are rebooted (the deleted certificate will be renewed and reappear at the appropriate time.) The behavior observed is that only when the certificate expires does the client really get refused a connection.
So why have a certificate and HTTPS listener in the first place? Its not necessary for encrypted communication, because whether HTTP or HTTPS is used the traffic is set to be encrypted by default (note it is possible to allow unencrypted traffic by changing the configuration). In a domain environment Kerberos handles the initial authentication and so that is secure too.
If connecting off domain, NTLM is used and that won’t guarantee the authenticity of the target machine. Here is where certificates and HTTPS listener come into their own. By specifying a HTTPS listener we can force the client machine to connect using the fqdn, we’ll know we are connecting to the server we think we are and the traffic will be encrypted.
Given that Remoting is enabled by default in Server 2012 and in a domain environment you’ll be using Kerberos and traffic is encrypted by default, there doesn’t seem to be much of a need to go to the trouble of distributing Server Authentication certificates and setting up HTTPS listeners.
Addition 16/09/16: Over at FoxDeploy a similar investigation was carried out which found results that agreed with mine. This has resulted in Stephen opening a github issue.