Closed Bug 1126034 Opened 9 years ago Closed 8 years ago

Can't add exception when 'sec_error_untrusted_issuer'

Categories

(Core :: Security: PSM, defect)

Product:
Core
Component:
Security: PSM
Version:
35 Branch
Platform:
x86
All
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: mozilla.org, Unassigned)

Details

Attachments

(4 files)

Screenshot comparing working self-signed certificate to failing certificate.
22.39 KB, image/png
Details
Working self-signed certificate
966 bytes, application/pkcs7-mime
Details
failing-cert.p7c
607 bytes, application/pkcs7-mime
Details
output of $openssl s_client -connect x.x.x.x:443 -showcerts
4.12 KB, text/plain
Details 
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:35.0) Gecko/20100101 Firefox/35.0
Build ID: 20150108202552

Steps to reproduce:

Went to an internal site that uses a self-signed certificate

An error occurred during a connection to xxx.example.edu. Peer's certificate issuer has been marked as not trusted by the user. (Error code: sec_error_untrusted_issuer)

There is no option to view the certificate.


Actual results:

I get the message below, and an [Add Exception] button. When I click the button, nothing opened. I've been having a similar problem with previous versions of Firefox


If you understand what's going on, you can tell Firefox to start trusting this site's identification. Even if you trust the site, this error could mean that someone is tampering with your connection.

Don't add an exception unless you know there's a good reason why this site doesn't use trusted identification.



Expected results:

I should have been able to create an exception.
QA Whiteboard: [DUPEME?]
Component: Untriaged → Security
Will, can you share what site this is happening on?
Flags: needinfo?(mozilla.org)
This is with an internal site with a self-signed cert. I don't think the hostname is accessible from off-site. I can send the cert itself via direct email if you'd like it, but prefer not to attach to the ticket.

I've seen the same behavior with expired certs, if memory serves.
Flags: needinfo?(mozilla.org)
Hello
I'm facing to the same problem on a custom internal CA that we use to generate internal serveur certificates. But my problems comes only after updating on FF36, 35.x worked for me.

If i add my internal CA to certificates manager in autorities i'm getting an error page on which we can't do anything (error is sec_error_bad_der), firefox is the only browser that give me a such error.

Without the CA, i'm getting the error page on sec_error_unknown_issuer, with the "add exception" button but i don't get any window when I click on.
(In reply to Julien from comment #3)
> Hello
> I'm facing to the same problem on a custom internal CA that we use to
> generate internal serveur certificates. But my problems comes only after
> updating on FF36, 35.x worked for me.
> 
> If i add my internal CA to certificates manager in autorities i'm getting an
> error page on which we can't do anything (error is sec_error_bad_der),
> firefox is the only browser that give me a such error.
> 
> Without the CA, i'm getting the error page on sec_error_unknown_issuer, with
> the "add exception" button but i don't get any window when I click on.

Also My old registrered exception aren't working anymore.

I'm on ubuntu 14.04.1
I'm having the same problem. Just upgraded to 36.0.1 automatically, and suddenly my old exceptions aren't working, and the "Add Exception ..." button does nothing. I consult on other peoples' firewalls for a living, so I use this feature almost daily, and it was working yesterday.

On closer inspection, it appears to be a problem with only certain IP addresses:

BAD: https://12.218.210.226/ (private Juniper firewall) - no popup when clicking Add Exception
GOOD: https://74.125.239.112/ (www.google.com's current IP address) - Add Exception works fine

On even closer inspection, this only seems to be happening for me when logging onto the public IP for Juniper SSG firewalls, such as the first link above. Other brands of firewalls, such as WatchGuard, are still working fine (Firefox remembers my exceptions for these).
One more observation - the IP addresses where Add Exception is not working are fine when added to other browsers.

And I'm using Windows 8.1.
I can confirm this problem.

I cannot add exceptions for self-signed certs (first noticed with Juniper Firewalls).

36.0.1 on Windows 7.
Component: Security → Security: PSM
OS: Mac OS X → All
Product: Firefox → Core
I can confirm this problem.  It has been broken since 36.0.1 on Mac OS X.  All of my old exceptions are now not working, and I cannot add new exceptions.  I use this function daily for connecting to the management interface of storage equipment via HTTPS.
For posterity, the error "sec_error_untrusted_issuer" hasn't been overridable for a while (if it ever was). Bug 1123671 fixed the UI inconsistency.
(In reply to David Keeler [:keeler] (use needinfo?) from comment #9)
> For posterity, the error "sec_error_untrusted_issuer" hasn't been
> overridable for a while (if it ever was). Bug 1123671 fixed the UI
> inconsistency.

I was able to access my company's intranet using Firefox 35. Upgrading to Firefox 36 removed that functionality and now reports a "sec_error_untrusted_issuer".

IMHO, no SSL certificate error should be exempt from overriding. There are legacy devices that cannot be upgraded, company internal servers with uncooperative IT departments, and so on. If people can't use Firefox to access those sites, people will stop using Firefox. As it stands now, I've installed Chrome just to be able to hit my company's internal websites, and given that I'm lazy, I wouldn't be surprised if I just start using Chrome for everything.
(In reply to jking from comment #10)
> (In reply to David Keeler [:keeler] (use needinfo?) from comment #9)
> > For posterity, the error "sec_error_untrusted_issuer" hasn't been
> > overridable for a while (if it ever was). Bug 1123671 fixed the UI
> > inconsistency.
> 
> I was able to access my company's intranet using Firefox 35. Upgrading to
> Firefox 36 removed that functionality and now reports a
> "sec_error_untrusted_issuer".
> 
> IMHO, no SSL certificate error should be exempt from overriding. There are
> legacy devices that cannot be upgraded, company internal servers with
> uncooperative IT departments, and so on. If people can't use Firefox to
> access those sites, people will stop using Firefox. As it stands now, I've
> installed Chrome just to be able to hit my company's internal websites, and
> given that I'm lazy, I wouldn't be surprised if I just start using Chrome
> for everything.

(That wasn't meant to sound catty, sorry. I realize it could be read that way.)
I can confirm too, as described Will in the first post and Drake in comment #5

Both Linux Ubuntu x86 14.04 and Windows 7 OS with Firefox 36.0.1 same issue.

Please fix this quick because i daily connect to Juniper Firewalls via https.
I get the point of trying to protect users from malicious attacks, but that's why Mozilla already has cert warnings. IMHO, there should be some option to let users accept certs, even from untrusted issuers, even if it requires enabling a 'don't blame Mozilla' flag in the preferences.

The UI bug is the bigger problem, obviously (confusing to be told to add an exception, but to be unable to)
Hope the following will wake up and jumpstart the fixing machine ...

Some dwarves in this forge found that Firefox 36.0.1 barfs on certs which X509v3 "Subject Alternative Name" extension is empty.
(In reply to Will from comment #13)
> I get the point of trying to protect users from malicious attacks, but
> that's why Mozilla already has cert warnings. IMHO, there should be some
> option to let users accept certs, even from untrusted issuers

To clarify the situation a bit, there's a difference between "untrusted issuer" and "unknown issuer". If the error is sec_error_unknown_issuer, it means that Firefox can't find a path to a trusted root certificate. Usually this means a server isn't sending all of the intermediate certificates it needs to or the certificate wasn't issued by an authority in our CA program. This is the "unknown issuer" case, and it is overridable.

However, if the error is sec_error_untrusted_issuer, it means that while attempting to build a path to a trusted root, Firefox has encountered a certificate that has been explicitly marked as distrusted by the user on all potential paths. There isn't any UI in Firefox itself to make this happen (see bug 585352), but it is possible to use certutil directly on a profile's certificate database to mark an intermediate as distrusted. Addons can also potentially do this. This is the "untrusted issuer" case (maybe it should be "distrusted issuer"). This error is not overridable because from Firefox's perspective, the user has said "I do not trust this issuer; do not accept certificates it issues".
(In reply to David Keeler [:keeler] (use needinfo?) from comment #15)
> (In reply to Will from comment #13)
> > I get the point of trying to protect users from malicious attacks, but
> > that's why Mozilla already has cert warnings. IMHO, there should be some
> > option to let users accept certs, even from untrusted issuers
> 
> To clarify the situation a bit, there's a difference between "untrusted
> issuer" and "unknown issuer". If the error is sec_error_unknown_issuer, it
> means that Firefox can't find a path to a trusted root certificate. Usually
> this means a server isn't sending all of the intermediate certificates it
> needs to or the certificate wasn't issued by an authority in our CA program.
> This is the "unknown issuer" case, and it is overridable.
> 
> However, if the error is sec_error_untrusted_issuer, it means that while
> attempting to build a path to a trusted root, Firefox has encountered a
> certificate that has been explicitly marked as distrusted by the user on all
> potential paths. There isn't any UI in Firefox itself to make this happen
> (see bug 585352), but it is possible to use certutil directly on a profile's
> certificate database to mark an intermediate as distrusted. Addons can also
> potentially do this. This is the "untrusted issuer" case (maybe it should be
> "distrusted issuer"). This error is not overridable because from Firefox's
> perspective, the user has said "I do not trust this issuer; do not accept
> certificates it issues".

Thank you for the clarification.

So we're currently getting "sec_error_unknown_issuer" for all of our Firefox users trying to hit our corporate intranet, and the "Add Exception" button does nothing. Are you aware of a manual override? Unfortunately, installing the certificate locally isn't an option.
(In reply to jking from comment #16)
> So we're currently getting "sec_error_unknown_issuer" for all of our Firefox
> users trying to hit our corporate intranet, and the "Add Exception" button
> does nothing. Are you aware of a manual override? Unfortunately, installing
> the certificate locally isn't an option.

Do you see the same error in Nightly? ( https://nightly.mozilla.org/ ) If not, then bug 1123671 probably fixed the UI issue. Unfortunately that would mean that there is something about the certificates in question that doesn't conform to the relevant standards. If the certificates were generated with TinyCA, I would bet that they have an empty subject alternative name extension, which isn't valid according to RFC 5280: "If the subjectAltName extension is present, the sequence MUST contain at least one entry.". It's looking like we'll have to change how we handle certificates like this, but in the meantime any certificates with that problem can be re-generated with valid extensions or with that extension omitted altogether.
(In reply to David Keeler [:keeler] (use needinfo?) from comment #17)
> (In reply to jking from comment #16)
> > So we're currently getting "sec_error_unknown_issuer" for all of our Firefox
> > users trying to hit our corporate intranet, and the "Add Exception" button
> > does nothing. Are you aware of a manual override? Unfortunately, installing
> > the certificate locally isn't an option.
> 
> Do you see the same error in Nightly? ( https://nightly.mozilla.org/ ) If
> not, then bug 1123671 probably fixed the UI issue. Unfortunately that would
> mean that there is something about the certificates in question that doesn't
> conform to the relevant standards. If the certificates were generated with
> TinyCA, I would bet that they have an empty subject alternative name
> extension, which isn't valid according to RFC 5280: "If the subjectAltName
> extension is present, the sequence MUST contain at least one entry.". It's
> looking like we'll have to change how we handle certificates like this, but
> in the meantime any certificates with that problem can be re-generated with
> valid extensions or with that extension omitted altogether.

Thanks David for your help. The latest nightly gives a "Secure Connection Failed" with error "sec_error_bad_der", and no option to override.
I obtain An error occurred during a connection to internal_url:443. security library: improperly formatted DER-encoded message. (Error code: sec_error_bad_der) with 2015-03-15 nightly.
Also, if I regenerate a cert with XCA the error is gone (along with the empty subjectAltName).
David --

I get what you're saying, but I don't recall marking any of these certificates as untrusted.
I remember you said offline that Firefox doesn't look at the OS X certificate store (which is confusing in and of itself, though I understand why that's the case), but I can't find any record in Firefox's builtin certificate manager of having *specifically* not listed any cert (including a parent) as trusted. I get this warning for various self-signed certs, or certs from a non-imported internal CA. Any easy way to check /which/ certificate Firefox is unhappy about and where I would have marked it as "untrusted"?
Additionally, there's no way that I can see to *view* the certificate that you're being told not to trust, which makes it difficult to check expiration date, cert chain, etc. Normally, there'd be a "view certificate" button.
I'm wondering if this behavior is the same, since this is also referring to NSS:
https://access.redhat.com/documentation/en-US/Red_Hat_Certificate_System/8.0/html/Admin_Guide/Managing_the_Certificate_Database.html#About_CA_Certificate_Chains

"If the certificates contain the SSL-CA bit in the Netscape Certificate Type certificate extension and do not already exist in the local certificate database, they are added as untrusted CAs"

If I'm reading this right, NSS treats unknown certificates with the CA bit set (which presumably includes self-signed certificates) as "untrusted", so wouldn't that mean they'd get this error, despite the user not having "explicitly marked [the cert] as distrusted"?
(In reply to David Keeler [:keeler] (use needinfo?) from comment #17)
> (In reply to jking from comment #16)
> > So we're currently getting "sec_error_unknown_issuer" for all of our Firefox
> > users trying to hit our corporate intranet, and the "Add Exception" button
> > does nothing. Are you aware of a manual override? Unfortunately, installing
> > the certificate locally isn't an option.
> 
> Do you see the same error in Nightly? ( https://nightly.mozilla.org/ ) If
> not, then bug 1123671 probably fixed the UI issue. Unfortunately that would
> mean that there is something about the certificates in question that doesn't
> conform to the relevant standards. If the certificates were generated with
> TinyCA, I would bet that they have an empty subject alternative name
> extension, which isn't valid according to RFC 5280: "If the subjectAltName
> extension is present, the sequence MUST contain at least one entry.". It's
> looking like we'll have to change how we handle certificates like this, but
> in the meantime any certificates with that problem can be re-generated with
> valid extensions or with that extension omitted altogether.

Confirmed problem occurs with certificates generated using TinyCA. The "X509v3 Subject Alternative Name:" is empty on my testing certificate.

I'm using Mozilla Firefox 36.0.1 on "Linux Mint 17.1 MATE 64-bit".
something important with this bug is that if you import the CA certificate, then firefox shows a more detailed explanation of the error:

Secure Connection Failed

An error occurred during a connection to some.domain.name. security library: improperly formatted DER-encoded message. (Error code: sec_error_bad_der)

    The page you are trying to view cannot be shown because the authenticity of the received data could not be verified.
    Please contact the website owners to inform them of this problem.



(In reply to Alfredo Cambera from comment #24)
> (In reply to David Keeler [:keeler] (use needinfo?) from comment #17)
> > (In reply to jking from comment #16)
> > > So we're currently getting "sec_error_unknown_issuer" for all of our Firefox
> > > users trying to hit our corporate intranet, and the "Add Exception" button
> > > does nothing. Are you aware of a manual override? Unfortunately, installing
> > > the certificate locally isn't an option.
> > 
> > Do you see the same error in Nightly? ( https://nightly.mozilla.org/ ) If
> > not, then bug 1123671 probably fixed the UI issue. Unfortunately that would
> > mean that there is something about the certificates in question that doesn't
> > conform to the relevant standards. If the certificates were generated with
> > TinyCA, I would bet that they have an empty subject alternative name
> > extension, which isn't valid according to RFC 5280: "If the subjectAltName
> > extension is present, the sequence MUST contain at least one entry.". It's
> > looking like we'll have to change how we handle certificates like this, but
> > in the meantime any certificates with that problem can be re-generated with
> > valid extensions or with that extension omitted altogether.
> 
> Confirmed problem occurs with certificates generated using TinyCA. The
> "X509v3 Subject Alternative Name:" is empty on my testing certificate.
> 
> I'm using Mozilla Firefox 36.0.1 on "Linux Mint 17.1 MATE 64-bit".
Hello,

I just worked around this issue.

firefox: 36.0.4
windows 7
certificates generated on centos 6.6 (up-to-date) with openSSL v1.0.1e-fips

I had the CA self signed & servers certificates (manually) installed in Firefox and Firefox would deny validity of the certificates, AND would not respond to "add exception".

=============
What worked for me:


Removed (deleted) ALL related certificates..

... and "add exception" worked fine...

... manually added the corresponding self signed CA...

... all other server certificates (under the same self signed CA) worked (and without the need for "add exception", meaning it recognized the self signed CA as trusted).


=============

For the sake of curiosity, 

I removed again ALL related certificate, restarted Firefox, manually added the self signed CA, requested one of the servers, and "add exception" did not work.

then I removed the self signed CA again, requested the https page, "add exception" worked again.


=============

regards
Claude.
Oh, and one more detail,

about "verified server certificate" and "CA trust settings"...


When certificates (CA & servers) were added beforehand, editing "the CA certificate trust settings" would not reflect on the "child" certificates. Meaning that servers Certificates would not be considered verified (as seen in the view certificate details)

BUT, when:
1. none of the certificates are installed
2. request https server, and "add exception"
3. then, add self signed CA
4. then, edit "CA certificate trust settings"

then the server certificates shows as verified (when viewing the certificate) as set in the "CA certificate trust settings"

Hope that helps

C.
Not sure if this the right bug but when I access on Firefox 37 to this site https://app.siscad.cadivi.gob.ve/ and tried to add exception, nothing happens, It doesn't show the dialog box to add the security exception like previous version.
If I try to access to that same site in Firefox Nightly I get this error security library: improperly formatted DER-encoded message. (Error code: sec_error_bad_der)
I tried with a new profile and Firefox 36.0.4 and it is possible to add the security exception.
Also I tested with that same profile which has added permanently the security exception and in Firefox 37 appears the screen to add the security exception but again the 'add exception' button doesn't work out.

I'm concerned about this bug because https://app.siscad.cadivi.gob.ve/ is a goverment site really really important for Venezuela.
Looks like that certificate has the same problem as in bug 1148766:

X509v3 Subject Alternative Name: 
                othername:<unsupported>, IP Address:190.202.84.148, DNS:200.44.32.10, DNS:200.11.248.11, othername:<unsupported>, othername:<unsupported>, othername:<unsupported>

("200.44.32.10" is not a valid DNS name, so mozilla::pkix rejects this certificate when doing name checking)
Indeed, 37.0.1 broke a bunch of certs that were fine with 36.0.4 :/ i.e those self-generated by Oracle Grid Manager (Weblogic 12c). I need to figure out what is wrong with them.
I'm running FF 37.0.1 on Ubuntu 14.04 and I've been able to reproduce this issue while trying to access various hardware with self-signed certificates.

It looks like security.use_mozillapkix_verification also vanished from about:config.

The only workaround so far is to downgrade to FF 28.0 with "sudo apt-get install firefox=28.0+build2-0ubuntu2". Couldn't find any newer version on Ubuntu's repositories online.
Can you post the certificate chain the server is sending? (use wireshark for example, or openssl s_client -connect host:port -showcerts)
I'm having this same issue with Firefox 37.0.1 with wide variety of self-signed certs for Polycom Group Series videoconferencing systems.  These are all internal systems with the embedded HTTPS servers behind our corporate firewall.

I'd always been able to add exceptions for these in the past, but suddenly with FF37.0.1 all of my exceptions no longer work, and the behavior at the Add Exception page is as described above (click the button, nothing happens).  I've tried a variety of the fixes mentioned online, including trying a completely fresh profile to no effect.  The Cert error is: Peer's Certificate issuer is not recognized. (Error code: sec_error_unknown_issuer)

The Polycom systems in question are running the latest firmware from Polycom, and as I mentioned, it worked before.  I'm happy to assist with additional investigation on the conditions of these certs if someone gives me instructions.
(In reply to E. M. Ryan from comment #35)



My quick fix: backtrack to FF36.

here's the link: https://ftp.mozilla.org/pub/mozilla.org/firefox/releases/36.0/

That solved issues with my self-signed certificates, as well as with other issues.

Hope that helps.

Claude
Thanks, Claude.  I did test rolling back and that did fix it. I'm hoping to help get the problem actually solved, though, as I'd prefer (obviously) not to run an old outdated browser (like an animal).
(In reply to E. M. Ryan from comment #37)

Hey Ryan,

I share your view. Idealy.

Actually, I should have suggested v36.0.4 , from 21-Mar-2015 .... "previous" yes, "outdated"... I wouldn't go that far :)

https://ftp.mozilla.org/pub/mozilla.org/firefox/releases/36.0.4/

Considering that this ticket is open since january and still nobody's been assigned to it, and that FF is open source (community driven)... I'm really ok with using the "previous" working version. And hopefully, issues will be solved in the near future.

take care

Claude
I've done more testing. Some certificates (such as WatchGuard firewall self-signed certs) generate the same sec_error_unknown_issuer message, but always can be added without a problem. Other certs (such as Juniper SSG self-signed certs) never work.

Both certs lack the "Subject Alternative Name" extension.

There are a lot of other differences, though. The attached screenshot shows that the WatchGuard cert "Issuer" field contains a CN, OU, and O entry, whereas the Juniper contains 3 CN fields instead.

The Juniper only contains 1 extension, "Certificate Subject Alt Name", which is set as "Not Critical." The WatchGuard has several extensions (Certificate Key Usage, Certificate Basic Constraints, Object Identifier (2 5 29 16), Certificate Subject Key ID, and Certificate Authority Key Identifier).

I will attach each exported cert shortly so a debug person can compare the two.
Attached is a working certificate in PKCS#7 format.
Attached file failing-cert.p7c — 
Attached is a failing certificate in PKCS#7 format. Note that both certs can be imported and viewed in the Certificate Manager (in the Servers tab), but the failing cert's URL will still fail when the cert is manually imported.

Here are 2 sample URLs that illustrate the issue:

https://98.210.49.51:8080/ (WatchGuard - always works)
https://12.218.210.226/ (Juniper - always fails)
Drake, thanks for posting those. A couple of questions: does the Juniper certificate work with a new profile using a recent version of Nightly? ( https://nightly.mozilla.org/ ) Is the error you're seeing still "sec_error_untrusted_issuer"? (note: this describes a different situation than "sec_error_unknown_issuer")
Hi David,

Thanks for the feedback.

1. In the latest Nightly build (Windows 32-bit), I get a new, different error:

Secure Connection Failed
An error occurred during a connection to 12.218.210.226. Cannot communicate securely with peer: no common encryption algorithm(s). (Error code: ssl_error_no_cypher_overlap)
The page you are trying to view cannot be shown because the authenticity of the received data could not be verified.
Please contact the website owners to inform them of this problem.

The only options are "Try again" and "Report this error." There's no longer an "I Understand" link or an "Add exception" button.

Manually importing the Juniper certificate to the Firefox Certificate Manager doesn't help.

The Juniper I'm working with was installed 2 months ago and has the latest firmware (ScreenOS 6.3.0r18). The site works fine in IE and Chrome.

The WatchGuard site works exactly the same, including the same sec_error_unknown_issuer error, "I Understand" link and working "Add exception" button.

2. You're correct that the error message for me (and most of the posters here, I think) has been sec_error_unknown_issuer. The behavior is otherwise the same (trying to override the issue always fails).

Would you like me to break this out into a new bug?
(In reply to David Keeler [:keeler] (use needinfo?) from comment #34)
> Can you post the certificate chain the server is sending? (use wireshark for
> example, or openssl s_client -connect host:port -showcerts)

There it is...
Firefox versions:
* version 40.0a1 (nightly from 21.04.2015)
* version 37.xx

Problem:
https://ldap.anxia/  (Error code: sec_error_bad_der)
https://10.10.10.2/  (works)
https://test.anxia/  (works)

SSL Cert:

root@ldap:~# openssl x509 -text -in /etc/ssl/own/ldap.crt -noout

[...]
X509v3 extensions:
 X509v3 Basic Constraints:
  CA:FALSE
X509v3 Key Usage: critical
 Digital Signature, Non Repudiation, Key Encipherment
X509v3 Extended Key Usage:
 TLS Web Server Authentication, TLS Web Client Authentication
X509v3 Subject Alternative Name:
 DNS:test.anxia, DNS:anxia, DNS:*.anxia, DNS:net.anxia, DNS:*.net.anxia, DNS:*.dev.anxia, DNS:*.dev.anxia, DNS:doc.anxia, DNS:*.doc.anxia, DNS:adm.anxia, DNS:*.adm.anxia
[...]

All this certs are working on all browsers, only firefox 37+ can't use this cert with.
i can confirm this bug.

user@host:~$ openssl s_client -connect failed-server:4119 -showcerts
CONNECTED(00000003)
depth=1 CN = WatchGuard Server Root CA, O = WatchGuard
verify error:num=19:self signed certificate in certificate chain
verify return:0
---
Certificate chain
 0 s:/CN=WatchGuard Agent (c2bd2c8c-9d5b-11e4-9409-005056a0766b)/O=None
   i:/CN=WatchGuard Server Root CA/O=WatchGuard
-----BEGIN CERTIFICATE-----
[skipped]
-----END CERTIFICATE-----
 1 s:/CN=WatchGuard Server Root CA/O=WatchGuard
   i:/CN=WatchGuard Server Root CA/O=WatchGuard
-----BEGIN CERTIFICATE-----
[skipped]
-----END CERTIFICATE-----
---
Server certificate
subject=/CN=WatchGuard Agent (c2bd2c8c-9d5b-11e4-9409-005056a0766b)/O=None
issuer=/CN=WatchGuard Server Root CA/O=WatchGuard
---
No client certificate CA names sent
---
SSL handshake has read 2877 bytes and written 503 bytes
---
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1
    Cipher    : DHE-RSA-AES256-SHA
    Session-ID: 97EAD41DBC53C7D0D2C79334FACE1D61C43C1C8F74FD483D511D4B6AE471EB49
    Session-ID-ctx:
    Master-Key: 9607FAEF3DCD3C1CFA5A350889A6AE4D80B19B460F9AB625CB0CA4E22CF9740D2CED7DCC8F75A73E0BD6F7AD428658CD
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket:
    0000 - de 0c 3d 47 54 cd 18 91-e1 52 21 b0 e1 c4 5b 70   ..=GT....R!...[p
    0010 - 6c d0 cf 6a 37 2c 50 8e-b4 e7 f2 22 bd 89 df 4c   l..j7,P...."...L
    0020 - 2d 18 c3 d3 5e 70 8e 5a-fb 16 50 58 ac f6 d3 91   -...^p.Z..PX....
    0030 - 95 03 61 01 7f d8 d2 20-c7 52 f4 23 4b da b5 b0   ..a.... .R.#K...
    0040 - 06 e0 b8 0a 45 eb ed 98-bb 75 53 46 20 21 a8 0c   ....E....uSF !..
    0050 - 49 12 cb 60 c0 4b 9e aa-d2 17 bb 1f e0 d2 2c 2d   I..`.K........,-
    0060 - a5 84 7b f9 d8 99 74 8e-d6 be 04 0f c9 d7 20 e2   ..{...t....... .
    0070 - 0d 1d a6 93 f0 63 f9 6d-28 03 d6 f4 13 6c b4 b5   .....c.m(....l..
    0080 - 41 71 45 d9 43 c9 54 db-6a fb ab 9c 8f ef e2 cc   AqE.C.T.j.......
    0090 - 21 c5 99 84 a8 96 72 ed-e3 76 a2 b7 1c 24 ee 0c   !.....r..v...$..
    00a0 - d1 16 b7 6c 72 49 14 fd-68 9e 08 c0 f5 7a 7f 57   ...lrI..h....z.W
    00b0 - 82 ce 0d fc 2f 16 ff 3e-2e 72 60 22 69 84 28 87   ..../..>.r`"i.(.

    Start Time: 1429705184
    Timeout   : 300 (sec)
    Verify return code: 19 (self signed certificate in certificate chain)
---

user@host:~$ openssl s_client -connect working-server:443 -showcerts
CONNECTED(00000003)
depth=0 C = DE, ST = Saxony, L = city, O = company, OU = IT, CN = server.local, emailAddress = admin@local
verify error:num=18:self signed certificate
verify return:1
depth=0 C = DE, ST = Saxony, L = city, O = company, OU = IT, CN = server.local, emailAddress = admin.local
verify return:1
---
Certificate chain
 0 s:/C=DE/ST=Saxony/L=city/O=company/OU=IT/CN=server.local/emailAddress=admin@local
   i:/C=DE/ST=Saxony/L=city/O=company/OU=IT/CN=server.local/emailAddress=admin@local
-----BEGIN CERTIFICATE-----
[skipped]
-----END CERTIFICATE-----
---
Server certificate
subject=/C=DE/ST=Saxony/L=city/O=company/OU=IT/CN=server.local/emailAddress=admin@local
issuer=/C=DE/ST=Saxony/L=city/O=company/OU=IT/CN=server.local/emailAddress=admin@local
---
No client certificate CA names sent
---
SSL handshake has read 1744 bytes and written 431 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES256-GCM-SHA384
    Session-ID: A28A5A6AE50C577E20D6F3C47FC974DA5FE0FEABE9CE35AABD7BBFE52C26B9BE
    Session-ID-ctx:
    Master-Key: 2B7D2F2AC54EB774578D26E8172AFCDB19650A8B305AE61D647EE62BEE6D32298963F449A05729F61C6FCE9561040865
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket lifetime hint: 300 (seconds)
    TLS session ticket:
    0000 - 66 ba f8 bb 91 58 68 a6-a6 66 3b 62 39 d2 48 09   f....Xh..f;b9.H.
    0010 - 59 b5 54 0a 18 72 ba bd-b1 8b 30 fe 13 43 2e 18   Y.T..r....0..C..
    0020 - d3 01 ce af 82 64 97 44-eb 1a 4a 80 db 2b 11 83   .....d.D..J..+..
    0030 - e6 00 a4 a5 c9 40 89 f4-d8 a0 e8 6d d5 d3 04 4c   .....@.....m...L
    0040 - ce 6e f8 14 e8 27 cb 98-49 71 2f 3c 1a ca 19 db   .n...'..Iq/<....
    0050 - c7 3e 74 6c a2 92 40 4b-4d 40 03 f2 a7 c5 98 6f   .>tl..@KM@.....o
    0060 - c9 91 ee dd af 77 26 7b-75 dd 50 5e e5 00 75 2d   .....w&{u.P^..u-
    0070 - a9 69 ba 82 8e 64 b0 fb-e3 82 a1 c8 e3 5b 3e 2b   .i...d.......[>+
    0080 - 40 40 30 cb fb 29 b3 f1-c4 84 e0 e0 60 0f 56 cd   @@0..)......`.V.
    0090 - 3f 32 17 84 2b 33 e6 7c-a9 9a 48 4a d3 16 e0 ac   ?2..+3.|..HJ....
    00a0 - af 12 34 04 8d 86 05 48-61 29 61 b9 5d 48 60 ff   ..4....Ha)a.]H`.
    00b0 - a1 73 01 33 3a 9e 5d c0-46 61 40 d0 9e 2a 36 36   .s.3:.].Fa@..*66

    Start Time: 1429705283
    Timeout   : 300 (sec)
    Verify return code: 18 (self signed certificate)
---

see also my comments in bug #1151376 (may be duplicate)
imo duplicate candidates are: #1121601, #1153214, #1152931
Juniper has a case on this issue.

https://kb.juniper.net/InfoCenter/index?page=content&id=KB30330

Cause:

Beginning with version 32, Firefox no longer accepts certificates with 1024-bit RSA keys.  This has been deemed insecure, and the resolution is to re-configure the ScreenOS device to include a 2048-bit RSA key for the self-signed certificate.  If you have other devices that use 1024-bit RSA keys for default self-signed certificates, you will have to do the same procedure for those devices as well.
I am having the same problem that Will is, well its my whole dev team is having this problem rather. Firefox 36 worked just fine to get to our site, but after Firefox updated to 37 the "Add Exception" button stopped working. I tried to go to my profile file and deleting the cert8.db but nothing changed.
I can also confirm this problem.. Tried to set up apache jmeter for load testing.. didnt work out for https..

Here is how to reproduce the problem: https://jmeter.apache.org/usermanual/jmeter_proxy_step_by_step.pdf
I had the same problem a while ago, I had posted information here:
http://forums.mozillazine.org/viewtopic.php?f=38&t=911375

after numerous efforts I managed to fix it, 
but it came up again after the latest firefox update,
I installed esr version to work with for the while,
but please fix in the next update
See also bug 1042889
If anyone is still encountering the error "SEC_ERROR_UNTRUSTED_ISSUER", please re-open this bug with steps to reproduce. For other issues (particularly different error messages), please file a new bug.
Status: UNCONFIRMED → RESOLVED
Closed: 8 years ago
Resolution: --- → WORKSFORME
I still have the issue on one pc, while sharing the (roaming) profile with a different pc on which it works fine.
Issue is exclusively with sites using certs from an internal CA. Migrating the internal CA + the certs to SHA2 has not resolved the issue. No issues on FF 44. Since FF 45, only temporary exceptions can be made.
(In reply to Sander Goudswaard from comment #54)
> I still have the issue on one pc, while sharing the (roaming) profile with a
> different pc on which it works fine.
> Issue is exclusively with sites using certs from an internal CA. Migrating
> the internal CA + the certs to SHA2 has not resolved the issue. No issues on
> FF 44. Since FF 45, only temporary exceptions can be made.

It sounds like you're saying the issue you're having is that you can't make permanent certificate error overrides. If that is the case, please file a new bug with information we can use to debug the situation (e.g. what certificates you're using, etc.)
Flags: needinfo?(sander+bugzilla)
(In reply to David Keeler [:keeler] (use needinfo?) from comment #55)
> It sounds like you're saying the issue you're having is that you can't make
> permanent certificate error overrides. If that is the case, please file a
> new bug with information we can use to debug the situation (e.g. what
> certificates you're using, etc.)

I just opened Bug 1260994 for this issue, thank you for your assistance.
Flags: needinfo?(sander+bugzilla)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: