In today’s Ask the Admin, I’ll show you how to configure a Windows Remote Management (WinRM) HTTPS listener using a self-signed certificate.
Windows Remote Management (WinRM) is Microsoft’s implementation of WS-Management, a SOAP-based protocol that can traverse firewalls and is used to manage infrastructure devices and operating systems from different vendors. WinRM is the protocol behind PowerShell Remoting, which allows cmdlets and scripts to securely run on remote devices, with the results being sent back to the originating PowerShell console.
Windows Server is configured out-of-the-box with an HTTP WinRM listener. Before data is sent to a remote device, it is serialized and encrypted. Secure Sockets Layer (SSL) isn’t required to ensure that data is encrypted across the wire.
In an Active Directory environment, Kerberos provides assurance that the remote device is trusted. But in a workgroup, either you have to add remote devices to the TrustedHosts list or you should configure an HTTPS WinRM listener and install certificates to establish trust between the local and remote devices. Adding a remote device to the local TrustedHosts list is OK in a lab, but in a production environment, TrustedHosts doesn’t provide a high level of assurance that remote devices can be trusted.
The following instructions assume that PowerShell Remoting is enabled on the device where the HTTPS WinRM listener will be configured. If not, run the Enable-PSRemoting cmdlet in an elevated PowerShell console before continuing. PowerShell Remoting is enabled by default in Windows Server 2012 and later.
Before we start configuring an HTTPS WinRM listener, let’s take a look at the existing listeners configured in Windows Server 2012 R2. Open a PowerShell console with local administrator privileges, and run the command below:
In the output, you should be able to see the default HTTP listener, assuming the server configuration hasn't been modified from the default settings.
Create a self-signed certificateIf you don't have a Public Key Infrastructure (PKI) in place, a self-signed certificate will be required to set up an HTTPS listener. Fortunately, that's easy to do in PowerShell using the New-SelfSignedCertificate cmdlet:
In the above code, you should replace contosodc1 with the common name of the server on which you are creating the WinRM listener. The certificate must be exported to a file so that it can be installed on devices that will connect to the listener. Note that the export directory must exist before running the command below.
Create an HTTPS WinRM listener and inbound Windows Firewall ruleNow that the certificate is installed and exported to a file, configure an HTTPS WinRM listener on all IP addresses using the command below:
You can run the Get-Item cmdlet again as shown below to check the new listener was created successfully:
An inbound Windows Firewall rule will also be needed for the new listener, to allow devices to connect:
Import the self-signed certificateThe certificate will need to be imported to the Trusted Root Certification Authorities (Computer Account) store on all devices, which will connect to the new WinRM listener. Copy the exported certificate file and run the command below on each device that will connect to the listener. You must run the Import-Certificate cmdlet from a PowerShell console with local administrator privileges.
Establish a PowerShell remoting session using SSLNow that the certificate has been installed on devices that will connect to the listener, you should be able to connect using PowerShell remoting with the Enter-PSSession cmdlet. You'll need to replace contosodc1 with the name of the device, where the HTTPS WinRM listener is configured. The –ConfigurationName parameter is optional and can be omitted if you want to connect to the default PowerShell session configuration: