So, suppose your Azure WCF endpoint is at address 10.20.30.40, and you have a PFX certificate at C:\certs\myssl.pfx with password of “FooBar”. This is not covered in the Citrix article but is in the WireShark wiki. Password – if you are using a PFX certificate, this is a fifth parameter that is the password to unlock the PFX file.Key file name – this is the location on disk where you have the key file.Protocol – for a WCF endpoint this should always be http.For a WCF endpoint this is probably always going to be 443. Port – this is the port the encrypted traffic is coming across on.IP address – this is the IP address of the server that is sending you SSL encrypted content that you want to decrypt. So to combine that Citrix article and the info on the WireShark wiki, here is a quick run down on those values: Citrix actually has a pretty good article on how to configure WireShark to use SSL ( ), but the instructions are way to cryptic when it comes to what values you should be using for the “RSA keys list” property in the SSL protocol settings (if you’re not sure what that is, just follow the Citrix support article above). If you read the latest WireShark SSL wiki ( ) though it turns out that’s not actually true. A lot of the documentation around WireShark suggests that you need to convert your PFX of your SSL certificate (the format that you get when you export your certificate and include the private key) into a PEM format. Since the WCF service is one that I wrote it’s easy enough to get that. WireShark appears to have had support for SSL for a couple years now it just requires that you provide the private key used with the SSL certificate that is encrypting your conversation. I’ve personally always used NetMon but had some difficulties getting the SSL expert to work so decided to give WireShark a try. I looked at using both NetMon 3.4, which has an Expert add in now for SSL that you can get from, and WireShark. One of the difficulties in troubleshooting it is that case is that the traffic travels over SSL so it can be fairly difficult to troubleshoot. The CASI Kit that I’ve posted about other times on this blog ( ) is a good example whose main purpose in life is providing plumbing to connect data center clouds together. One of the interesting challenges when trying to troubleshoot remotely connected systems is figuring out what they’re saying to each other.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |