April 9, 2014 at 8:30 am #14404ParticipantPoints: 0Rank: Member
I've been following Don's DSC book, labbing up DSC and seeing what might work best in a production environment.
My test scenario includes pulling via HTTPS, in a non-domain setting, and using OpenSSL to generate the certs.
That combination of factors proved to be more difficult than anticipated, and this was just at a very early stage.
OpenSSL doesn't, by default, include any "enhanced key usage" like server authentication.
Here's my recipe for just getting WinRM talking (given above factors):
1. Installed OpenSSL 1.0.1g on laptop. That cleared up any HeartBleed vulnerabilities.
2. Hacked the openssl.cfg file and put
extendedKeyUsage = serverAuth
under the v3_ca header.
3. Generated the CA private key.
4. Generated the CA cert, self-signed it.
5. Generated the target node's private key.
6. Generated the target node's CSR.
7. Signed the target node's CSR with the CA's private key and cert, generating the target node's cert.
8. Exported the target node's cert as a pfx file.
9. Imported the pfx file into the target node's Personal cert store (machine side, of course).
10. Extracted the CA root cert from the pfx file into the Trusted Root cert store (again, machine side, of course).
11. Installed the CA root cert into my desktop's SSL Trusted Root store.
12. Tried to create the WinRM listener on HTTPS.
a. Got the epic red FAIL error that said that the cert didn't have the Server EKU. (Squeezed my eyes shut so tightly I blinded myself for minutes...)
b. Opened the Certificate applet, double-clicked on the cert, saw in the details tab THAT THERE WAS INDEED no "Enhanced Key USAGE"
c. In the cert details tab, clicked on the 'Edit Properties' button.
d. In the general tab of the Certificate Properties, changed the Certificate purposes from 'Enable all purposes…' to 'Enable only the following purposes' (Server
Authentication checkbox was checked, also), saved that.
e. Checked again at the details tab, and saw that there is now an entry for Enhanced Key Usage, and it's Server Authentication.
f. Tried to create the WinRM listener again, and IT WORKED.
13. Tried to establish a remote session with the target node with
Enter-pssession -computername BoxName -Credential Boxname\administrator -usessl
14. It worked.
Sure, I could have done this within a domain, but that's the beauty of using http/s, no?
And I could have stood up a MS Certificate Authority, but OpenSSL doesn't require a machine. And a non-self-signed cert is closer to a production environment, I think.
Hope this might help someone save some time.
April 10, 2014 at 2:48 am #14436KeymasterPoints: 1,811Rank: Community Hero
Thanks for the input!
The topic ‘DSC - WinRM HTTPS connection’ is closed to new replies.