By default, WinRM requires mutual authentication and strict cryptographic verification when operating over HTTPS. For a successful connection, the certificate used must explicitly allow Client Authentication within its Enhanced Key Usage (EKU) field. If this property is missing, or if it only contains "Server Authentication", Windows rejects the connection to prevent unauthorized access or man-in-the-middle attacks.

Step-by-Step Fixes

To resolve this issue, you must ensure that the certificate being used contains the Client Authentication EKU (Object Identifier: 1.3.6.1.5.5.7.3.2). Below are the two most common ways to fix this.

Method 1: Request a New Certificate with the Correct EKU (Recommended)

If you are using an internal Active Directory Certificate Services (AD CS) or another Certificate Authority (CA), you must issue a certificate that contains both Server and Client Authentication.

1. Open the Run dialog box by pressing Windows Key + R.
2. Type mmc and press Enter to open the Microsoft Management Console.
3. Click File in the top menu, then select Add/Remove Snap-in....
4. Select Certificates from the left list and click Add.
5. Choose Computer account, click Next, select Local computer, and click Finish. Click OK to close the snap-in window.
6. Expand Certificates (Local Computer) > Personal > Certificates.
7. Right-click on an empty space in the middle pane, select All Tasks, and click Request New Certificate....
8. Click Next through the wizard until you see your organization's certificate templates.
9. Select a template that includes both Server Authentication and Client Authentication (such as the default "Computer" template).
10. Click Enroll and then Finish.

Method 2: Configure the WinRM HTTPS Listener to Use the New Certificate

Once you have generated a valid certificate, you must configure WinRM to use it by linking its specific thumbprint to the WinRM service.

1. In the same mmc console from Method 1, double-click your newly enrolled certificate under Personal > Certificates.
2. Go to the Details tab, scroll down to the bottom, and click on Thumbprint.
3. Copy the hexadecimal string from the box (e.g., a1b2c3d4e5...). Delete any spaces between the letters and numbers so it forms a single continuous string.
4. Open the Windows Start menu, search for Command Prompt, right-click it, and select Run as administrator.
5. Delete the existing broken WinRM HTTPS listener by typing the following command and pressing Enter:

   winrm delete winrm/config/Listener?Address=*+Transport=HTTPS

6. Create the new listener utilizing your corrected certificate thumbprint by running this command (replace YOUR CERTIFICATE THUMBPRINT with the clean string you copied in step 3):

   winrm create winrm/config/Listener?Address=*+Transport=HTTPS @{Hostname="YOUR COMPUTER FQDN";CertificateThumbprint="YOUR CERTIFICATE THUMBPRINT"}

7. Restart the WinRM service to apply all modifications immediately by running:

   net stop winrm && net start winrm

Method 3: Temporarily Disable Client Certificate Validation (Workaround)

If you cannot immediately issue a new certificate and need to restore remote management urgency, you can configure the WinRM service to bypass the client certificate EKU validation requirement. Note: This lowers deployment security and should only be used as a temporary solution.

1. Open the Windows Start menu, search for PowerShell, right-click it, and select Run as administrator.
2. Run the following command to check your current client certificate validation settings:

   Get-ChildItem WSMan:\localhost\Service\Auth

3. Disable the requirement for valid client certificates by modifying the WSMan configuration:

   Set-Item WSMan:\localhost\Service\Auth\Certificate -Value \$false

4. If you are connecting from a client machine, you may also need to instruct your client to ignore validation failures during the transition period:

   Set-Item WSMan:\localhost\Client\Auth\Certificate -Value \$false

5. Restart the WinRM service using PowerShell to ensure changes take effect:

   Restart-Service winrm