Self signed certificates for NNTP servers need to be downloaded and stored as Security Exceptions. This fails because port 563 is blocked for getting certificates. To reproduce go to Add Security Exception dialog and try to get the certificate for reader.albasani.net:563. No request is send to the server. The result is an exception in the error console: | Attempted to connect to a site with a bad certificate in the add exception | dialog. This results in a (mostly harmless) exception being thrown. Logged | for information purposes only: [Exception... "Establishing a connection to | an unsafe or otherwise banned port was prohibited" | nsresult: "0x804b0013 (NS_ERROR_PORT_ACCESS_NOT_ALLOWED)" | location: "JS frame :: chrome://pippki/content/exceptionDialog.js :: | checkCert :: line 138" data: no] Try again for a random port like 555. Result is that several port unreachable" messages from the server shown up on the wire. And after two minutes a "0x80004005 (NS_ERROR_FAILURE)" is thrown in the error console for the same file as above. Now try with the hostname reader.albasani.net alone. The server is asked on port 443. The certificate will show up and can be stored permanently for port 443. Conclusion is that NSS asks for certs on bogus ports like 555. But it blocks cert requests on standard SSL ports like 563. This limitation should be removed.
If the server delivers the certificate for NNTPS on another port (443 for example) too a workaround is possible. In Add Security Exception set your.target.server:443 and click Get Certificate. If the cert is loaded, click View. Then in the Certificate Viewer switch to the Details tab and click Export and save the cert somewhere on disk. Close the Certificate Viewer. Cancel the Add Security Exception dialog. Click Import in the Certificate Manager and select the previously saved cert file from disk. Now you have an accepted certificate for the server not bound to a specific port. A problem remains if you need HTTPS and NNTPS from the same server with different certs.
With help from Kai it turns out that Mozillas Port Blocking  is the cause. Port 563 is generally blocked, but NNTP can use any port. So NNTP is successful when calling the data but NSS fails when calling the certificate on the same target port. Setting the pref network.security.ports.banned.override with "563" allows to download and confirm the needed certificate.  http://www-archive.mozilla.org/projects/netlib/PortBanning.html#exceptions
Port Blocking has a new home in MDN https://developer.mozilla.org/en-US/docs/Mozilla_Port_Blocking . It came with bug 83401. Later it was extended to IMAPS, POPS and NNTPS against some warning in bug 301762 comment 11.
My inclination here is to mark this bug as WONTFIX. Port blocking exists as a security countermeasure against abuse. As noted in this bug there are ways for users to override port blocking if absolutely necessary. The number of users who don't need this port open in Firefox is far larger than those that do thus making the security <> usability tradeoff biased towards the security side and for blocking. Just because you can use some other arbitrary port for this does not negate that protection. This bug is asking for a way to allow legitimate requests on the legitimate port. However, attempting to detect and check proper requests then allow them is a non-trivial problem. We're far more likely to make mistakes and allow requests that should not be made, not to mention adding code complexity for what is likely a small corner case of usage at this point.
I believe dougt had a hand in this original decision so I am going to cc him on this for input as well.
(In reply to Curtis Koenig [:curtisk] from comment #4) > The number of users who don't need this port open in Firefox Erm, this bug is about MailNews, where you need to access these ports …
https://developer.mozilla.org/en-US/docs/Mozilla_Port_Blocking says: "Each Protocol Handler can override the global blocked ports to allow it's own protocol to function." In this case, SM/TB blocks it's own request for certificate. This is rather stupid/a bug. It should be able to override as mentioned later. --- Ports enabled by protocol handlers in Mozilla: Protocol Handler Allowed Ports [...] NNTP any port [...] --- If another handler is necessary, well, then it should be added.
(In reply to Curtis Koenig [:curtisk] from comment #4) We agree that for Firefox no change is needed. Users get a big warning screen when trying to access a blocked port. But this part of Gecko is used by E-Mail and News programs too. And when those users try to secure their communication they get the misleading error message "No Information Available - Unable to obtain identification status for the given site". That is the main issue of this bug report. Options are: 0. WONTFIX Most users will fail and throw their Mozilla based product away. Some will Google and may find this bug. Very few will check the Error Console and can help them self after spending some hours. 1. Better error message The user interface should show the point of failure precisely like "The current preference settings block the port called. You can change this in about:config...". Even better would be a help text or an URL to a web based help. 2. Open ports for certs Some globally blocked ports are already opened by specific Protocol Handlers. So can NNTP, POP3, IMAP and SMTP connect to any port given to them. Perhaps the certificate GET call is done by an own protocol handler. If yes, this handler may be given access to standard SSL ports. The call is made near http://mxr.mozilla.org/comm-central/source/mozilla/security/manager/pki/resources/content/exceptionDialog.js#133 P.S.: I beg your pardon for not having been precise enough with the words chosen so that my intentions weren't easy to understand.
The point of these port blocks is that some protocol interactions are security holes. So, we restrict where each protocol can run. Specifically, port 563 is for NNTP over TLS. It isn't meant for *anything* else. So, we have two choices. To analysis the security impact of running http(s) against a server running NNTP over TLS, or just block it. Since we haven't done that assessment, it's blocked. I hope this is helpful.
Yeah, but the point of requesting a certificate is: to get it, not blocking the own request initiated by SM/TB itself. The user is left with a dialog not succeeding what it's supposed to do, that's awful. Your exemplification doesn't state where the security risk is at that point. It's not like the mozilla-application should listen on this port 24/7 and accept any incoming data any time. It should be possible to detect a proper answer to a self-initiated request within a limited time frame properly. (the certificate getter dialog works on certain other ports anyway not being considered as a risk, why should it fail on another?)
So, right now, Thunderbird is broken for setting up a new account requiring a self-signed certificate. I've been trying to fix another bug and just wasted 2 hours fighting this issue before I figured out what caused it. If gecko is not going to be changed, then we are going to have to figure out a different workaround for mailnews. ----- However, consider this use case. Say that I am a business that has it's own intranet running over https (port 443) on a server with a self-signed certificate. Now, on the same server, I have an anti-virus software that is configured via a web interface (https) on port 3456. Now, I can't use firefox to configure my anti-virus because it only allows me to use https 443. It seems like there should be the possibility of adding additonal ports in about:config to handle cases like this.
I missed comment 2 earlier. Perhaps the fix for mailnews is to add the various mail/news ports to the network.security.ports.banned.override preference?
I just ran into this problem, and I'm stubborn enough to search and search and search until I stumbled across this report. I understand how to adjust network.security.ports.banned.override in *Firefox*, but how the heck do I adjust it in *Thunderbird*? Meanwhile, I'm using webmail because I have *NO WAY* to make this work with the self-signed cert, and my IMAP server requires SSL or STARTTLS - I literally cannot connect insecurely.
Never mind, I found the config editor in Thunderbird. I agree that this is an incredibly stupid bug, 99.9% of TB users will give up and switch UA before fixing this. And I know a *LOT* of mail servers using self-signed certs now, it's not an insignificant problem.
I run a Ubuntu server behind a Juniper router firewall. Since January of this year I have been unable to connect to the Juniper router filewall to adjust the firewall settings because Firefox continues to show a "Untrusted Connection" message and the "Add Exception" button does not do anything. I followed some instructions I found under another forum post (also about this same "Add Exception" problem) to go to Preferences->Advanced->Certificates->View Certificates->Servers and did find an old exception for my address 192.168.1.1 in the list which showed it expired on Dec 31, 2014. I removed that exception and tried again, but am still stuck and cannot connect to my own Juniper firewall router. On the Certificate Manager page when I click "Add Exception" it asks me to enter the server and then click "Get Certificate" but that just shows me "No Information Available. Unable to obtain identification status for this site." If I just try to go to the https://192.168.1.1 address directly in the browser I end up at the "Add Exeception" button that does nothing when I click it. I have been waiting for several months for this serious bug to be fixed, but somehow Firefox is still broken despite numerous posts that I can see from others about this bug. Now I have to change some of the firewall rules on my Juniper router because an ISP has renumbered their networks and people can no loner get through the firewall to reach my server until I change the rules. This inability to add a Security Exception is a very serious bug. Why is there such a delay in fixing the problem?