WinRM certificate implementation in HTTPs is very strange

[1RedOne]

Steps to reproduce

• Use an internal CA to deploy a Cert template valid for WinRM
• Deploy the cert with an 8 hour validity period and renewal at 2 hours
• Deploy a script to auto-renew certs once every hour (b/c the default renewal period is 8 hours and ain't nobody got time for that)
• Enable WinRM w/ Https using winrm qc -transport:https
• Wait for cert to expire

Expected behavior

We would expect to see one of two things happen here:

Cert Auto Renews and UI correctly reports this

or

WinRM never notices that cert has been replaced and all remoting fails

Actual behavior

In actuality, it appears that WinRM somehow does note that the certificate has been renewed, because it continues to accept WinRM connections over HTTPS with no issues, even after the certificate referenced under WSman\Listener has expired.

However, everything in the UI reports outdated certificate information, for instance.

On the left, the current valid cert, on the right, what PowerShell reports

These inconsistencies are all over the place. WSman:\Service\CertificateThumbprint contains (in my case) the Thumbprint of the very first cert ever used with this machine, more than a week ago, also expired.

The built in winrm command also seems to report the same cert, which was present when winrm qc -transport:https was first conducted.

Looking under wsman:\Service, a Cert thumbprint from a previous test is visible

The strangest part of the whole thing is that even though WinRM References out of date and invalid certificate information all over, somehow only the correct and new cert is being presented when new Winrm connections come in (such as via Enter-PSSession -UseSsl.

Desired Change

The UI should correctly reflect the certificate thumbprint being used with WinRM, not refer to the original cert used to enable WinRM, as it does today.

Environment data

> 
Name                           Value                                                                                   
----                           -----                                                                                   
PSVersion                      5.0.10586.117                                                                           
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}                                                                 
BuildVersion                   10.0.10586.117                                                                          
CLRVersion                     4.0.30319.34011                                                                         
WSManStackVersion              3.0                                                                                     
PSRemotingProtocolVersion      2.3                                                                                     
SerializationVersion           1.1.0.1                                                                                 

[mirichmo]

Investigating

[1RedOne]

I wrote more about this on my blog! 👻👻👻

https://foxdeploy.com/2016/09/16/winrm-https-and-the-case-of-ghost-certificate/

[mirichmo]

This issue appears to be with WinRM and not PowerShell. I notified the WinRM team and they will continue the investigation.

TFS:8956786

[1RedOne]

For testing, I found that on a Server 2008r2 machine with WMF 2.0 that the same behavior exists. WSMan lists old cert but correctly presents new cert.

However in this configuration, the PsSession is dropped when the certificate changes.

[1RedOne]

@mirichmo , could you ask the WinRm team to update this issue with their results?

[manojampalam]

I'll get back on this EOD 10/4

[manojampalam]

I haven't tried out the repro steps yet, but going through internal details, I'm unable to understand how WinRM presents the "new and correct" cert after renewal. Automatic binding updates on cert renewal is currently not supported - so the SSL endpoint should either fail or continue to work with older cert.

@1RedOne can you confirm that after the certificate renews, following shows the new bindings (though WinRM reports the stale thumbprint):
netsh http show sslcert ipport=0.0.0.0:5986

[hakabo]

My tests show the older certificate thumbprint. (WinRM sessions over SSL confirmed still working using Enter-PSSession XX -UseSSL)

[manojampalam]

@hakabo, thanks. I assume the older certificate is still valid. http.sys caches the certificate, so that's the reason the connection is working even when the cert is deleted from store. I expect the SSL endpoint to stop working after the cert has expired or after a machine reboot.

Please let me know your observations.

[1RedOne]

Hi guys,

Just to confirm, I also see the expired certificate still listed when I run netsh as well.

Keep in mind that in my configuration, the cert will expire every eight hours, however, new HTTPS connections still work. My hypothesis is that the cert is correctly updated, and that WinRM does present the correct cert, but that for some reason the WinRM PS drive and netsh commands list outdated information.

Note the discrepency here, both commands list the first cert ever used with WInRM on this machine, however this info does not match what we see in the MMC.

[hakabo]

As its not explicitly been stated, the SSL connections continue to work after reboot.

Screenshot below taken after a reboot.

Enter-PSSession -UseSSL can still establish connections remotely.

[1RedOne]

I've tried capturing a trace using WireShark to help out, but

"Science Dog 'no clue what I'm doing'" .jpg

I've observed connections continuing to work no matter what, after reboot,
after restarting WinRM, etc. It seems that somehow WinRM correctly grabs
the right certificate and uses this for connections, even if the UI always
displays the original cert used to configure WinRM.

On Thu, Oct 13, 2016 at 6:13 AM, hakabo notifications@github.com wrote:

As its not explicitly been stated, the SSL connections continue to work
after reboot.

Screenshot below taken after a reboot.

[image: capture]
https://cloud.githubusercontent.com/assets/22237100/19345308/a8a70632-9135-11e6-9eb6-5b42e7f530b2.PNG

Enter-PSSession -UseSSL can still establish connections remotely.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#2282 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABMJiqcM2bhvYy7BixMa5jDagp9r_KHSks5qzgROgaJpZM4J-lsx
.