Then, run another command that will print much more information about the server's certificate, and after the -V use the respective parameter from above, which didn't result in an error, but printed more information. At least one of the commands should print some diagnostic information. Tstclnt -D -p 443 -h $IP -R $ROOTS -V ssl2:ssl2 -C Tstclnt -D -p 443 -h $IP -R $ROOTS -V ssl3:ssl3 -C Open a text editor where you can paste text into.įor each of the tests you have executed, copy/paste the output that you see on the terminal, INCLUDING the respective command in front of the output, into your editor. I assume you connect to the regular https port, 443. Get the IP address and set it as a variable, so you can copy paste the following commands.Įxport IP=1.2.3.4 (use the IP of your cicso 5505) If that works, you can test connections to your 5505 box. Now, if you type the name of a NSS tool, it should print it's help output, e.g. OBJDIR=`cd nss/tests/common/ & make objdir_name`Įxport DYLD_LIBRARY_PATH=$PWD/dist/$OBJDIR/lib:$DYLD_LIBRARY_PATHĮxport ROOTS=$PWD/dist/$OBJDIR/lib/libnssckbi.dylib Now execute the following commands to prepare the environment to run the NSS tools that you just built:

Open a terminal and use 'cd' to go into that directory. It would help if you can compile NSS and run the diagnostic utilities on the command line.ĭownload and place it into that directory. If your device can be reached from the public internet, then it would be very helpful if you could enable me to connect to it myself, for purpose of diagnosing the server's beahviour.Ī debug version of firefox isn't easy to distribute and wouldn't give us the necessary information in a logfile. I really wish I was able to connect to your system myself. If this problem, Firefox hangs on that site, was first seen with Firefox 36, then we should investigate which SSL/TLS options have changed between Firefox 35 and Firefox 36. So it seems, the server is unable to understand the communication with Firefox, and falsely assumes that it needs to wait for additional data, and with both sides waiting, you see that it hangs and never loads. If the server were simply disconnecting, you'd a different error page. If Firefox 'hangs', it seems that Firefox is expecting the server to send more data, but it isn't. Once you had added the override, Firefox will pass beyond that step, and attempt to establish a connection to your server (which is the Cisco 5505 VPN hardware box you mentioned). This means, Firefox is able to initiate the connection to the server, and is able to complete the initial part of the handshake, in which the certificate is sent by the server (which is deemed untrusted, und thus you are asked to override). With Firefox 36, as you explained in the other bug, you are able to override, but then your connections are stuck, and Firefox doesn't show the web page.

Thus, the only way to differ is if the server presents a different certificate.

If you had connected with the same browser to the same host again, then the error would usually be the same (unless it had expired in the meantime). If anything changed on the next execution, the remembered override is ignored. The overrides in Firefox are bound to the combination of. Regarding the inability to override in the past: I wonder if your device generates a different certificate every time. The other unusual (different from the bugs I had seen) detail of your scenario is: In the past, you weren't able to add permanent overrides. However, as you say, adding an override doesn't help with Firefox 36, you're still not able to access the host. The bug in that scenario was: The error page shown for some sites displayed an error message, but didn't over to override.īased on your screenshots, you were given the option to override. In bug 1138332, people weren't even able to add an override. We must analyze what's happening for you.

Dick, your issue seems to be different in several ways.

Cisco asa 5505 software 8.4.6