* Generate SHA256 signed certificates
Vulnerability scanners are increasingly reporting SHA-1 signed certificates as a vulnerability on servers. Before this change, -ForceNewSSLCert generates a signature algorithm that openssl shows as sha1WthRSAEncryption for WinRM port 5986. After, this forces certificates to be signed with SHA256, which openssl shows sha256WithRSAEncryption.
Some example SHA-1 deprecations include:
- https://docs.microsoft.com/en-us/security-updates/SecurityAdvisories/2017/4010323
- https://blog.mozilla.org/security/2014/09/23/phasing-out-certificates-with-sha-1-based-signature-algorithms/
Also note that RDP 3389 on Windows 2016 also defaults to a SHA256 certificate.
The specifics were merged from a script mod I found at https://gallery.technet.microsoft.com/scriptcenter/PowerShell-script-to-7a0321b7 intended for Exchange. It also includes a mod to add an alternate DNS listing so the cert contains CN=HOSTNAME plus now also an alternative of the FQDN.
I tested this change on Windows 2008R2, 2012R2, and 2016 Datacenter.
* Keep WinRM cert key length at 4096.
* Remove WinRM cert exportpolicy setting.
The new Windows documentation references the top of this file for a list and explanation of options, however `-EnableCredSSP` was missing from this list.
* Add missing support for -CertValidityDays
For some reason the -CertValidityDays option was not being used in the certificates we created.
This fixes#10439
* Possible fix
* We cannot use New-SelfSignedCertificate on 2012R2 and earlier
As suggested by @jhawkesworth
Instead of asking the user to type something prior to running the script, why not allow -Verbose on the command line directly.
Also log important events to EventLog, so that it can be traced e.g. when running via RunOnce mechanism.
The documentation is updated as well.
- Remove shebangs from:
- ini files
- unit tests
- module_utils
- plugins
- module_docs_fragments
- non-executable Makefiles
- Change non-modules from '/usr/bin/python' to '/usr/bin/env python'.
- Change '/bin/env' to '/usr/bin/env'.
Also removed main functions from unit tests (since they no longer
have a shebang) and fixed a python 3 compatibility issue with
update_bundled.py so it does not need to specify a python 2 shebang.
A script was added to check for unexpected shebangs in files.
This script is run during CI on Shippable.
Having used this script several times today, I came to notice the $SubjectName variable, being passed in via the CLI, is essentially ignored when generating the SSL certificates, rendering it useless. I believe it's a good idea to have it in place, so I've updated the script to reflect this.
I also cleaned up some random new lines throughout the file, and expanded on a comment.
It might be worth going a step further and commenting the file fully, as most people reviewing this file won't be familiar with PowerShell (like I wasn't unitl a few days ago). It could be helpful.
The current script fails on machines which have network interfaces designated
as connected to "Public" networks (choices for network designation being
Private, Domain, Public). This commit changes the script to NOT prevent winrm
initialization when device is connected to a "Public" network.
Replace .iteritems() with six.iteritems() everywhere except in
module_utils (because there's no 'six' on the remote host). And except
in lib/ansible/galaxy/data/metadata_template.j2, because I'm not sure
six is available there.
$powershell path is set to "C:\powershell" at line 27. This is fine, but on line 82 $powershellpath is called as ".$powershellpath\$filename". Because the path at line 27 is absolute, a period preceding the $powershellpath is not required at 82. It actually causes an error:
Start-Process : This command cannot be executed due to the error: Unknown error (0x80041002).
At C:\users\Nathan Sosnovske\Documents\ps2to3.ps1:81 char:14
Start-Process <<<< -FilePath ".$powershellpath\$filename" -ArgumentList /quiet
CategoryInfo : InvalidOperation: (:) [Start-Process], InvalidOperationException
FullyQualifiedErrorId : InvalidOperationException,Microsoft.PowerShell.Commands.StartProcessCommand
Removing the period on line 82 before $powershellpath fixes this error.
Abhijeet Kasurde