How to fix faulty SSL listeners so that ConfigureRemotingForAnsible.ps1 can execute

Archives Ansible Developer
1

PSRemoting from the Ansible controller to a Windows host was working fine and then one day failed with:

…
WINRM CONNECTION ERROR: 500 WinRMTransport. [Errno 104] Connection reset by peer
…

After some investigation, I was able to determine that SSL had become broken on the Windows host.

I was able to resolve this by debugging the Ansible Windows prep script, removing the apparently faulty SSL Listener from the WSUS replica and re-running the prep script.

The prep script is supposed to create a self-signed certificate* to enable PSRemoting over SSL. However, it does not do that if it detects that an SSL listener is already configured for the server and in this case, the WSUS server was reporting that it had one. This was not consistent with what it told me when I viewed the WSUS servers SSL configuration through the IIS GUI, however. There, it was reporting this:

“The site does not have a secure binding (HTTPS) and cannot accept SSL connections”

After stepping through the script with the ISE debugger, I was able to view the listeners after it executes line 134 and from there, I could see the following:

WSManConfig: Microsoft.WSMan.Management\WSMan::localhost\Listener

Type Keys Name
---- ---- ----
Container {Transport=HTTPS, Address=} Listener_1305953032
Container {Transport=HTTP, Address=} Listener_1084132640

I guessed that something was faulty with the HTTPS listener: Listener_1305953032 and executed this command to remove it:

Remove-Item WSMan:\localhost\Listener\Listener_1305953032

Then, I re-ran the prep script and it successfully created a new self-signed certificate for the server. After that, I was able to securely PSRemote to the WSUS server from the Ansible Controller.

Does the community have a recommendation to prevent this from happening again?
Is a pull request in order?

  • Side note: Even though the Windows error message states that the certificate cannot be self-signed, this is apparently not true as the prep script has always created self-signed certs and we’ve been using them successfully
2

Hi David,
We have some known issues with the script and there will probably be a pull req in the near future. However, your issue souds like kind of an edge case. The prep script was never meant to be a “catch-all” solution, but a simple way of getting up and running quickly on a relatively pristine windows instance. We will however, probably be able to perform better testing and report if something seems odd when running the new version of the script. I’ll try and find time to do a PR sometime during the next week.

-Trond

3

Hey Trond,

Thanks for the reply. I’m definitely living on the edge these days. I’ve had to use Chris Church’s winrm_kerberos_support branch to get domain auth, extend ViaSat’s ansible-vsphere module to do rolling snapshots and just yesterday, I dredged-up the reverted win_copy commit just for this one project to automate installing Windows updates. I’m going to make this work no matter what it takes. :slight_smile:

I understand that the script cant do it all. It is really handy though, and there may be an opportunity to do a little validation on the certificate in addition to the SSL Listener. Apparently, it’s possible to have an SSL listener without a certificate. Of course, Windows wasn’t actually listening on the secured port so maybe there’s another opportunity there – check for an answer on the secured port of the local host.

Probably nothing new in my suggestions, I know. The main thing I wanted to do was try to contribute a little to the community by sharing my experience and how I fixed it.

I will keep an eye out for updates to the script.

-David

4

PR #10539 has been added. David, thanks for your testing!