In this guide, you will learn how to use Enter-PSSession and Invoke-Command to securely manage remote Windows machines with PowerShell over HTTPS using a self-signed SSL certificate that we create with PowerShell.

Many PowerShell blogs like to mention that WinRM encrypts data and is therefore secure even if you only work with HTTP (which is the default configuration) and not with HTTPS. Indeed, Microsoft’s documentation for Invoke-Command confirms that WS-Management encrypts all transmitted PowerShell data. (An older version of WinRM on Windows Server 2003 R2 doesn’t encrypt.) Unfortunately, if not configured properly, PowerShell Remoting is insecure and it some cases you need to change the default configuration.

Allowing unencrypted PowerShell Remoting ^

First, it is possible to allow unencrypted WS-Management communication. This command configures the WinRM service to allow unencrypted traffic (you need an elevated console as for most things we do in this post):

winrm set winrm/config/service '@{AllowUnencrypted="true"}'

Allowing unencrypted WSMan traffic on the server

Allowing unencrypted WSMan traffic on the server

And this one does the same on the client side:

winrm set winrm/config/client '@{AllowUnencrypted="true"}'

Even though WS-Management encrypts all traffic by default, it is possible that someone (unknowingly) transmits unencrypted data because the default configuration has been changed. I guess this is why this Microsoft article about WinRM warns that “under no circumstances should unencrypted HTTP requests be sent through proxy servers.”

Allowing unencrypted WSMan traffic on the client

Allowing unencrypted WSMan traffic on the client

To check how your machines are configured, you can run this command:

winrm get winrm/config

Check WinRM configuration

Checking WinRM configuration

You can also view the configuration in PowerShell:

dir WSMan:\localhost\Service | ? Name -eq AllowUnencrypted
dir WSMan:\localhost\Client | ? Name -eq AllowUnencrypted

Why HTTPS with Invoke-Command and Enter-PSSession ^

The second and, in my view, bigger problem is that, if you are working with machines that are not in an Active Directory domain, you don’t have any trust relationship with the remote computers. You are then dealing only with symmetric encryption, so man-in-the-middle attacks are theoretically possible because the key has to be transferred first.