July 25, 2017 at 11:52 am #75773
Everything related to SSL and certificates have really been a pain so far with DSC, and yesterday added a new layer on top of it. After installing the latest Cumulative update, communication broke btw the nodes and the pullserver in the test environment(it was working fine before the update). I even rebuilt the pullserver from scratch to no help, and now I can't even make the node register with the pullserver anymore. The error message is the generic
Could not establish trust relationship for the SSL/TLS secure channel
My question is: How do you debug SSL related stuff? I'm used to debugging regular things using wireshark, but everything related to ssl is (obviously 😛 )encrypted, so wireshark doesn't help in that area. And the logs in windows about ssl are less than helpful. Any tips?
I should add that even though it's a test env, the certificates used by IIS and the pullserver are from our internal CA and are trusted, so that shouldn't be the issue.
July 25, 2017 at 12:11 pm #75781
As happens oftentimes, 5 mins after I ask, I find the problem!
Answer: When we configure the nodes LCM, we use a DNS alias in the url ServerURL = 'https://pullserver:8080/PSDSCPullServer.svc' and use the DNS to point "pullserver" to the correct server. But in test, we forgot to put "pullserver" as an alternate name in the certificate, but it never bothered DSC so far.
Well, it seems something in the update changed that and the certificate, which was previously trusted, was not anymore because the alias was not in the Alternate name properties. I changed the LCM config to call the server name directly in the url and it worked again. Gonna have to reissue those certificates with alternate names, not a biggie, but SSL diag is really not fun though, lost an entire day yesterday. So the question on how to best debug SSL still stand 🙂
July 25, 2017 at 1:09 pm #75794
As a note, none of that is really DSC per se. It's all Windows and IIS doing the SSL bits underneath. So that's what changed.
And you can troubleshoot SSL with Wireshark; it let's you import the private keys so it can decrypt comms.
July 25, 2017 at 4:04 pm #75830
Thanks for the cue. I read about how to import the private key in wireshark and it helped me debug and solve another problem with a script that was using invoke-webrequest to query the report server over https. Problem that also arose after doing the update.
You must be logged in to reply to this topic.