PowerShell Remoting Over HTTPS With a Self-Signed SSL Certificate

Mar 9
10:42

2016

Rossy Guide

Rossy Guide

  • Share this article on Facebook
  • Share this article on Twitter
  • Share this article on Linkedin

To setup PowerShell remoting to use HTTPS protocol you should deploy an SSL certificate to remote server.

mediaimage

PowerShell Remoting is a light-weighted,PowerShell Remoting Over HTTPS With a Self-Signed SSL Certificate Articles server-client application which allows you securely connect to a remote PowerShell host and run script interactively.

SSL Certificates are small data files that digitally bind a cryptographic key to an organization's details. When installed on a web server, it activates the padlock and the https protocol (over port 443) and allows secure connections from a web server to a browser.

Many PowerShell blogs like to mention that WinRM encrypts data and is therefore secure even if you only work with HTTP and not with HTTPS. Indeed, Microsoft’s documentation for Invoke-Command confirms that WS-Management encrypts all transmitted PowerShell data. Unfortunately, if not configured properly, PowerShell Remoting is insecure and it some cases you need to change the default configuration.

When authentication relies on digital certificates, internal or external certification authorities (CA) are a crucial component of the authentication process. The certificate installed on the remote computer must come from a trusted CA and bear the same name that you will use when making the connection. Even though IIS is not needed for this configuration to work, ensure that you install a web server certificate in the remote computer certificate store.

CA makes sense for public sites such as web sites, but for private inter-server communication someone could just disable CA verification on the client side.

There are two primary purposes of using SSL certificates with PowerShell remoting:

  • Encrypting traffic between client and server
  • Verifying server identity

When you remote by using HTTPS, the whole connection is encrypted by using the encryption keys of the target computer’s SSL certificate; that means you could use the Basic Authentication protocol and the password would still be protected. Using MakeCert.exe to generate a self-sign certificate is not recommended in a production environment.

For our demonstration, a certificate signed by an internal CA has been installed in a workgroup server named Server1.

  • To verify that the computer is in a workgroup and that a certificate is installed in the computer store. Enter:

Get-CimInstance –ClassName Win32_ComputerSystem

Get-ChildItem –Path Cert:LocalMachineMy

  • To set up the WinRM HTTPS listener, you need to write down or copy the certificate thumbprint from the previous output. Then run this code:

New-WSManInstance winrm/config/Listener `

-SelectorSet @{Address='*';Transport="HTTPS"} `

-ValueSet @{Hostname="Server1"; `

CertificateThumbprint="B78FAAAB0FFE4B91A566B2923330CCB0C0EBC09B"}

Let’s review the parameter used with New-WSManInstance:

Address = ‘*’ the service will listen on all available IP addresses.

Transport = HTTPS. The other option is HTTP.

Hostname = Must match the name of the host on the certificate.

CertificateThumbprint = This is the thumbprint exposed with the Get-ChildItem cmdlet.

  • Configure the firewall to allow HTTPS traffic on port 5986. Enter:

Netsh AdvFirewall firewall add rule name="WinRM (HTTPS)" `

protocol=TCP dir=in localport=5986 action=allow

  • Start a remoting session to test the HTTPS listener. Run:

Enter-PSSession –ComputerName Server1 –Credential Server1Administrator -UseSSL

After entering the password, the remote session prompt is displayed, confirming a successful HTTPS connection.