So far, we have been ignoring the self-signed SSL certificates used in WinRM communication—obviously, this is less than ideal, and it is quite straightforward to get Ansible to validate SSL certificates if they are not self-signed.
The easiest way to do this if your Windows machines are members of a domain is to use Active Directory Certificate Services (ADCs)—however, most businesses will have their own certification process in place through ADCS, or another third-party service. It is assumed, in order to proceed with this section, that the Windows host in question has a certificate generated for remote management, and that the CA certificate is available in Base64 format.
Just as we did earlier on the Windows host, you will need to set up an HTTPS listener, but this time using the certificate signed by your CA. You can do so (if not already completed) using a command such as the following:
Import-Certificate -FilePath .certnew.cer -CertStoreLocation Cert:LocalMachineMy
Naturally, replace the FilePath certificate with the one that matches the location of your own certificate. If you need to, you can delete any previously created HTTPS WinRM listener with the following command:
winrm delete winrm/config/Listener?Address=*+Transport=HTTPS
Then, using the thumbprint from the imported certificate, create a new listener:
New-Item -Path WSMan:LocalhostListener -Transport HTTPS -Address * -CertificateThumbprint <thumbprint of certificate>
Now to the Ansible controller. The first thing to do is to import the CA certificate for the WinRM listener into the CA bundle for your OS. The method and location for this will vary between OSes, but, on CentOS 7, you can place the Base64-encoded CA certificate in /etc/pki/ca-trust/source/anchors/.
Once this has been done, run the following commands:
update-ca-trust enable
update-ca-trust extract
Finally, we need to tell Ansible where to find the certificate. By default, Ansible uses the Python Certifi module and will use the default path for this unless we tell it otherwise. This process updates the CA bundle, located in /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem, and luckily, we can tell Ansible where to find this in the inventory file. Note the two further changes to the inventory file as shown in the following code—first of all, we have now specified the full hostname for the Windows host rather than the IP address, as the inventory hostname must match the CN on the certificate for full validation to occur. Also, we have removed the ansible_winrm_server_cert_validation line, which means all SSL certificates are now implicitly validated:
[windows]
WIN-2NJFMR0MNBD.mastery.example.com
[windows:vars]
[email protected]
ansible_password="password"
ansible_port=5986
ansible_connection=winrm
ansible_winrm_ca_trust_path=/etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem
If we run our ping test again, we should now see SUCCESS:
Obviously, we could improve our certificate generation to remove the subjectAltName warning, but for now, this demonstrates Ansible connectivity to Windows, with Kerberos authentication to a domain account and full SSL validation. So far, in demonstrating this, we have only used the Ansible win_ping module to test connectivity. While Windows playbooks for Ansible could occupy a complete book on their own, let's wrap up the chapter with some simple example playbooks.