Configure WinRM over HTTPS with a Trusted Certificate

Admin

October 3, 2026

5 min read

Windows Remote Management (WinRM) supports PowerShell remoting over HTTP or HTTPS. With Kerberos or NTLM, WinRM protects messages over HTTP; HTTPS adds TLS transport. HTTPS does not replace authentication or prevent pass-the-hash attacks by itself. For domain systems, prefer Kerberos and a server certificate trusted by clients.

This walkthrough uses a certificate issued by your organization’s trusted certificate authority (CA). The certificate must be in the Local Computer\Personal store, include the server’s fully qualified domain name (FQDN) in its Subject Alternative Name, have the Server Authentication purpose, be valid, and include its private key. It does not configure mutual TLS or client-certificate authentication.

Port & Protocol Architecture

Setting	HTTP Listener	HTTPS Listener
Listener Port	TCP 5985 (HTTP)	TCP 5986 (HTTPS)
Authentication	Depends on configured policy	Kerberos for domain remoting
Encryption	Kerberos/NTLM can encrypt WinRM messages	TLS-protected HTTPS transport
Certificate	Not used for HTTP transport	Trusted server certificate matching the FQDN

Step 1: Check the Existing WinRM Configuration and Certificate

Record Listener State and Identify a Trusted Certificate

Prerequisites

Run these checks in an elevated PowerShell session on the server. Obtain or enroll a certificate from your organization’s CA if none is suitable. Do not use a self-signed certificate for a production listener or bypass certificate validation on clients.

$Fqdn = 'srv01.corp.internal'
winrm enumerate winrm/config/listener
Get-NetConnectionProfile | Select-Object InterfaceAlias, NetworkCategory
Get-ChildItem Cert:\LocalMachine\My |
  Where-Object { $_.HasPrivateKey -and $_.NotAfter -gt (Get-Date) } |
  Select-Object Subject, DnsNameList, EnhancedKeyUsageList, Thumbprint, NotAfter

❯ View Expected Console Output

Select the certificate whose DNS name matches srv01.corp.internal,
whose chain is trusted by clients, and whose Enhanced Key Usage includes
Server Authentication. Record its thumbprint for the next step.

Step 2: Create the HTTPS Listener and a Scoped Firewall Rule

Bind the Certificate to Port 5986

Listener Setup

Set $CertificateThumbprint to the verified certificate thumbprint. Confirm the management interface’s network profile and set $FirewallProfile to that profile. Start WinRM and create the HTTPS listener first; allow port 5986 only from the approved management subnet. Keep the existing HTTP listener in place until HTTPS has been tested successfully. If an HTTPS listener already exists, inspect and update it through your change process instead of creating a duplicate.

$CertificateThumbprint = '<verified-certificate-thumbprint>'
$ManagementSubnet = '10.10.100.0/24'
$FirewallProfile = 'Domain'

# Change the profile value if the management interface is not on Domain.
Set-Service -Name WinRM -StartupType Automatic
Start-Service -Name WinRM

New-WSManInstance -ResourceURI 'winrm/config/Listener' `
  -SelectorSet @{ Address = '*'; Transport = 'HTTPS' } `
  -ValueSet @{ Hostname = $Fqdn; CertificateThumbprint = $CertificateThumbprint }

New-NetFirewallRule `
  -Name 'WinRM-HTTPS-5986-Management' `
  -DisplayName 'WinRM HTTPS from Management Subnet' `
  -Direction Inbound -Action Allow -Protocol TCP -LocalPort 5986 `
  -RemoteAddress $ManagementSubnet -Profile $FirewallProfile

winrm enumerate winrm/config/listener

Step 3: Require Encrypted Transport and Disable Basic Authentication

Keep WinRM Authentication on Approved Windows Methods

Service Policy

Disable unencrypted WinRM messages and Basic authentication. For a domain member, connect by FQDN with Kerberos so the client authenticates the server and user through the domain. If Group Policy manages WinRM, make the change in the controlling policy instead of relying on local settings.

Set-Item -Path WSMan:\localhost\Service\AllowUnencrypted -Value $false
Set-Item -Path WSMan:\localhost\Service\Auth\Basic -Value $false

Get-Item WSMan:\localhost\Service\AllowUnencrypted
Get-Item WSMan:\localhost\Service\Auth\Basic

Step 4: Verify HTTPS from the Management Workstation

Validate the Certificate and Kerberos Remoting

Verification

Run the checks from an authorized domain management workstation. Use the same FQDN that appears on the certificate. Do not add -SkipCACheck or -SkipCNCheck; a validation failure means the trust chain or certificate name needs to be corrected.

$ComputerName = 'srv01.corp.internal'

Test-WSMan -ComputerName $ComputerName -UseSSL
Enter-PSSession -ComputerName $ComputerName -UseSSL `
  -Authentication Kerberos -Credential (Get-Credential)

Step 5: Retire the HTTP Listener Only After a Successful Test

Remove HTTP Only If Policy Requires It

Change Control

WinRM over HTTP can still use message encryption with Kerberos or NTLM, but some environments require HTTPS transport. If policy requires removing the HTTP listener, do so only after HTTPS remoting succeeds and you have a console or out-of-band recovery path. A domain GPO may recreate or manage the listener.

# Run on the server only after the HTTPS test succeeded and the change is approved.
winrm delete 'winrm/config/Listener?Address=*+Transport=HTTP'
winrm enumerate winrm/config/listener

PowerShell showing the WinRM HTTPS listener on port 5986 and a successful Test-WSMan connection over SSL

Figure 1: WinRM exposes the HTTPS listener on port 5986, and the remote WS-Man identity check succeeds over SSL.