* 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.
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.
Jordan Borean