Hi Chad, >If I run the nstrace with 'capsslkeys ENABLED' will this give me the output I'm looking for or is it unrealistic to assume Wireshark is going to give me any output that matches the script error? I don't believe nstrace set to capture SSL keys will give you the response you're looking for. The option 'capsslkeys ENABLED' will cause nstrace to record the pre-shared master key received during the handshake phase "Client Key Exchange, Change Cipher Spec, Encrypted," but that phase doesn't appear to have been reached yet. Since the client (the PowerShell script) stops immediately after the server exchange, it's likely that it didn't accept the server's response, and therefore, there isn't data on the wire for Wireshark to capture. As Marcelo commented, one of the most likely reasons that the client stopped was that it didn't accept a 512-bit key. However, in your situation, I would enable System.Net tracing to create a log of the network communication, including the TLS handshake process. I believe this will help faster than reviewing WireShark, which is unlikely to give the output you need.
Steven Wright's post in SSL/TLS Handshake deeper dive was marked as the answer