Windows Remote Management (WinRM) serves as the primary communications backbone for remote administration, PowerShell remoting (Enter-PSSession, Invoke-Command), and server orchestration tools across enterprise networks. By default, running Enable-PSRemoting provisions an HTTP listener on TCP port 5985. While domain-joined Kerberos authentication encrypts traffic at the application layer over HTTP, non-domain workgroup workstations, cross-forest architectures, and strict compliance frameworks require complete transport-layer encryption using TLS via an HTTPS listener on TCP port 5986.
Configuring an encrypted WinRM HTTPS listener requires provisioning a valid digital certificate containing the machine’s Fully Qualified Domain Name (FQDN) or IP SAN (Subject Alternative Name), creating the WSMan HTTPS listener with the certificate’s thumbprint, configuring the Windows Defender Firewall, and verifying remote session connectivity via PowerShell.
Understanding WinRM HTTP vs HTTPS Listeners
WinRM exposes two primary endpoints:
- Port 5985 (HTTP): Uses plain HTTP transport. In Active Directory domain environments, authentication packets are cryptographically protected using Kerberos session keys. However, in workgroup environments, passwords require TrustedHosts configurations or basic authentication, which is insecure over plain HTTP.
- Port 5986 (HTTPS): Wraps the entire WS-Management protocol exchange inside TLS encryption. This allows secure certificate-based authentication and protects credential payloads regardless of domain trust relationships.
Generating a Dedicated TLS Certificate for WinRM
For an HTTPS listener to function, the local machine requires a certificate in its Computer personal certificate store. In enterprise domains, this certificate is typically issued by an Active Directory Certificate Services (AD CS) enterprise Certificate Authority. In standalone environments or lab testbeds, you can generate a high-security self-signed certificate using PowerShell.
Open an elevated PowerShell prompt on Windows 11 by right-clicking Start and selecting Terminal (Admin). Determine your computer’s full hostname:
$computerName = [System.Net.Dns]::GetHostByName($env:computerName).HostName
Generate a self-signed certificate configured specifically for Server Authentication:
$cert = New-SelfSignedCertificate -DnsName $computerName -CertStoreLocation "Cert:\LocalMachine\My" -Type SSLServerAuthentication -KeyExportPolicy Exportable -KeyLength 2048 -NotAfter (Get-Date).AddYears(3)
$certThumbprint = $cert.Thumbprint
Write-Output "Generated Certificate Thumbprint: $certThumbprint"
Creating the WSMan HTTPS Listener
Once the certificate resides in Cert:\LocalMachine\My, query existing listeners to inspect the current WSMan state:
Get-ChildItem -Path WSMan:\LocalHost\Listener
To provision the HTTPS listener, use the New-Item cmdlet targeting the WSMan provider path, passing the certificate thumbprint:
$selectorSet = @{
Address = "*"
Transport = "HTTPS"
}
$valueSet = @{
CertificateThumbprint = $certThumbprint
Port = 5986
}
New-Item -Path WSMan:\LocalHost\Listener -SelectorSet $selectorSet -ValueSet $valueSet -Force
Verify that the HTTPS listener is now registered and active on port 5986:
Get-ChildItem -Path WSMan:\LocalHost\Listener | Where-Object { $_.Keys -contains "Transport=HTTPS" } | Format-List *
Configuring Windows Defender Firewall for Port 5986
Although the listener is active within the WinRM daemon, incoming network packets on TCP port 5986 will be blocked unless an inbound firewall rule exists.
Create a dedicated inbound firewall rule for WinRM HTTPS:
New-NetFirewallRule -Name "WinRM-HTTPS-In-TCP" -DisplayName "Windows Remote Management (HTTPS-In)" -Description "Inbound rule for Windows Remote Management via WS-Management over HTTPS [TCP 5986]" -Group "Windows Remote Management" -Enabled True -Direction Inbound -Protocol TCP -LocalPort 5986 -Action Allow
Confirm that the rule is active and bound to the appropriate network profiles (Domain and Private):
Get-NetFirewallRule -Name "WinRM-HTTPS-In-TCP" | Select-Object DisplayName, Enabled, Direction, Action
Disabling the Legacy Cleartext HTTP Listener (Optional Hardening)
To enforce strict compliance and ensure that no unencrypted connections can be established on port 5985, administrators can remove the HTTP listener entirely:
Get-ChildItem -Path WSMan:\LocalHost\Listener | Where-Object { $_.Keys -contains "Transport=HTTP" } | Remove-Item -Recurse -Force
Verify that only the HTTPS transport remains active in WSMan:
Get-ChildItem -Path WSMan:\LocalHost\Listener
Testing Remote PowerShell Connection Over HTTPS
From an administrative management workstation, test connectivity to the hardened Windows 11 host. If you utilized a self-signed certificate, the client machine must either trust the root certificate in its Trusted Root Certification Authorities store or explicitly bypass certificate validation during testing.
To test the listener using the Test-WSMan cmdlet over SSL, run:
Test-WSMan -ComputerName $computerName -UseSSL
A successful test returns the product version, OS version, and WS-Management stack details:
wsmid : http://schemas.dmtf.org/wbem/wsman/identity/1/wsmanidentity.xsd
ProtocolVersion : http://schemas.dmtf.org/wbem/wsman/1/wsman.xsd
ProductVendor : Microsoft Corporation
ProductVersion : OS: 10.0.26100 SP: 0.0 Stack: 3.0
To establish an interactive PowerShell remoting session through the encrypted tunnel, execute:
Enter-PSSession -ComputerName $computerName -UseSSL -Credential (Get-Credential)
The prompt transitions to the remote hostname, confirming that all management commands, object pipelines, and session credentials are encrypted with TLS across the wire.