User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b5pre) Gecko/2008031504 Minefield/3.0b5pre Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b5pre) Gecko/2008031504 Minefield/3.0b5pre Yes, that's simply https://www:10000 in above URL... it gives: The certificate is not trusted because it is self signed. (Error code: sec_error_untrusted_issuer) [Add exception...] gives: [Confirm Security Exception] which is inactive. Reproducible: Always Steps to Reproduce: 1. connect to adjacent www machine 2. can't confirm security exception 3. Actual Results: no access Expected Results: access There are other reports on this issue; but I decided to keep this simple and avoid the political/usability discussions. I don't care if there are more "Confirm" steps; but no way forward forces me to use another browser... :(
More info... when getting into this situation on other hosts, I can get that site's certificate and proceed; but when connecting to webmin, there is no option to display the certificate making access impossible.
Confirming there is an NSS regression somewhere. I've got webmin on a NAT'd box runing on port 10000 using SSL (via SSLeay in perl. OpenSSL/0.9.7l on the box). In Safari 3/Firefox 2 I'm told about the self signed cert. In 2008032204 I get: Firefox can't establish a connection to the server at 192.168.xxx.xxx:10000. This clearly isn't right. It should prompt me about the cert, and require me to add an exception.
This is really starting to suck. My suspicion is that NSS doesn't like port 10000 for some reason, but I've yet to prove this.
There are two conflicting bug reports here - comment 0 says that the "bad cert" error page appears, but that when you try to add the security exception, the "confirm security exception" button is disabled (but doesn't mention clicking "Get Certificate", which is required). Comment 2 says that a "can't connect" error page is shown instead of a "bad cert" error page, which sounds like a different bug. Robert, can you file a new bug for your issue, so that we can keep track of these separately? Pierre: did you click "Get Certificate" before trying to "Confirm Security Exception"? If the button still doesn't work after that, you may be seeing bug 406954, which was fixed after beta 5.
Adding a few of the NSS maintainers.
It seems to be working well now... thanks.
Robert, would you be able to dump what happens on the network using WireShark ? ( http://www.wireshark.org/ ) Til now it's not clear if it's a problem with the port number or with the ssl handshake. A WireShark trace would clarify things.
- Comment 0 and comment 2 are reporting two separate issues. Robert, Failure to connect is a TCP issue, not an SSL issue. - I haven't seen any evidence of an NSS problem yet. An inactive "Add exception" button is not evidence of an NSS problem. NSS doesn't do UI. If you haven't yet gotten past the add-exception dialog, then this is probably just a certificate issue, and not an SSL issue. I wouldn't bother with any SSL traces until the cert itself has been vindicated. You could attach a copy of the cert to this bug. If and when it becomes appropriate to look at SSL traces, ssltap or ssldump output is *always* preferable to wireshark output. I'm inclined to say that ssltap/ssldump output is required, rather than wireshark output, if it comes to that.
Well, I suggested WireShark because *I*'d be able to help with a WireShark trace. And also because it would show what happens even if the problem had nothing to do with SSL, which seemed likely. I would easily prove if the problem was coming from a tcp drop instead. On a side note and AFAIC I was *very* *happy* recently to discover that WireShark enabled me to definitively dump ssldump in favor of a program that's *maintained*, *easy to use and install on all platforms*, compatible with recent tcpdump (the ones that recognize gbit-able ethernet cards), able to display *all* normalized aspects of SSL, this includes all security suits, all tls extensions (I used it recently for checking negotiation of the Maximum Fragment Length extension) and not just decode the inside encrypted traffic but interpret it. You could have your quirks for favoring ssltap, but except pure ignorance I can't find anything that justifies still using ssldump at this time.
Jean-Marc, If you're willing to help with wireshark traces, then you are of course free and welcome to do so. I would be VERY (pleasantly) surprised if wireshark can correctly interpret all the latest cipher suites and TLS extensions supported in NSS 3.12, and output them in as readable and usable fashion as ssltap, but if it does, then I don't object to others using it to produce that usable output. But I have no wish to do so. I know that ssltap produces very usable output, and it is my preferred format. It is maintained as part of NSS. I haven't used ssldump for some time (~ 1 year), but the last time I used it its output was satisfactory. Plus it had one advantage over ssltap, which is that it was able to decode several simultaneous SSL connections, while ssltap is only able to decode one connection at a time.
Considering I've yet to get ssldump or ssltap going, and apparently I'm the only one... I'm going to admit defeat and let this one live for a while. Perhaps at some point in the future I'll try and dig deeper. As long as it's isolated, it's quite frankly not worth the effort. Something must be odd on that box, and tripping things up.
(In reply to comment #10) I overreacted on that one. Just let's forget about it, and just say that wireshard recently has became an excellent product for ssl analysis (the only quirk is the edit/preference/Protocols/ssl/rsa key list/"ip adress,port,inner protocol,private key pem file path" format to decode ssl traffic that's really hidden and inconvenient) and you should thing about having a better look at it some day. (In reply to comment #11) > Considering I've yet to get ssldump or ssltap going I may seem insisting, but it should take you only minutes to install and get wireshark working, type tcp.port == 1000 for the filter, and you should see what happens. And it could happen it's convenient another day to have it installed to investigate network, http headers or xml soap problems.
Problem is actually dll hell from what looks like GTK (likely conflicting with either Pidgin or XChat's install).
Ok, so we can close the bug ?
If someone disagrees, reopen. Thanks to all.