We're calling on all EU-based Mozillians with iOS or iPadOS devices to help us monitor Apple’s new browser choice screens. Join the effort to hold Big Tech to account!

Ko tenda hembiapoite sa’ivéta oñemba’apokuévo hese hembiapo porãve hag̃ua. Peteĩ jehaipyre nomoĩporãiramo ne apañuái ha eporanduséramo, roguerekohína ore nepytyvõ rekoha ikatútava ndeykeko @FirefoxSupport Twitter-pe ha avei /r/firefox Reddit-pe.

Eheka Pytyvõha

Emboyke pytyvõha apovai. Ndorojeruremo’ãi ehenói térã eñe’ẽmondóvo pumbyrýpe ha emoherakuãvo marandu nemba’etéva. Emombe’u tembiapo imarãkuaáva ko “Marandu iñañáva” rupive.

Kuaave

What does Firefox mean by "broken certificate" ?

  • 2 Mbohovái
  • 4 oguereko ko apañuãi
  • 2 Hecha
  • Mbohovái ipaháva adaviel

more options

I have a site that gives a security warning "unable to obtain identification status for the given site", and then won't let me grant an exception. But only on certain machines. In two Linux machines running 10.0.4 it fails, in another also with 10.0.4 it's OK. In fact, with most machines I tried it's OK, and I can grant an exception marked as "not stored".

I've traced the error message in the sourcecode but lost the trail at gBroken in exceptionDialog.js If I look at the certificate with OpenSSL, it parses OK as X509 version 1.

I have a site that gives a security warning "unable to obtain identification status for the given site", and then won't let me grant an exception. But only on certain machines. In two Linux machines running 10.0.4 it fails, in another also with 10.0.4 it's OK. In fact, with most machines I tried it's OK, and I can grant an exception marked as "not stored". I've traced the error message in the sourcecode but lost the trail at gBroken in exceptionDialog.js If I look at the certificate with OpenSSL, it parses OK as X509 version 1.

Ñemoĩporã poravopyre

I have narrowed it down somewhat. If I create a new profile, there is no problem. I was having trouble accessing any page on the server e.g. https://example.com/robots.txt, https://example.com/foobar I found an entry in the cache for https://example.com/ which is actually a 301 moved response, and which includes a long security-info: string in base-64. If I empty the cache, the problem disappears - I get the challenge, and can grant an exception. If I restore the profile and cache from a saved copy, the problem reappears. I'm not sure what the saved state in the cache represents because I'd been playing with the certificate on the server too and hadn't documented when I'd changed it.

If I go to https://example.com/robots.txt and use reload, or shift-reload (which as I recall would normally get a new copy regardless of cached copies), it does not help.

When the problem manifests itself, I cannot retrieve the certificate using Firefox. There is no intermediate certificate, it's a self-signed one.

I'd had this problem on 3 machines. On one, I cleared the cache without saving it first, which fixed the problem. A third, running SeaMonkey, I presume still has the problem, and I presume it can be fixed by clearing cache.

(later) The issue appears if an HTTPS redirect is cached, and then the (self-signed) server certificate is changed Clearing the entry from cache resolves the problem. I have filed https://bugzilla.mozilla.org/show_bug.cgi?id=767611

Emoñe’ẽ ko mbohavái ejeregua reheve 👍 0

Opaite Mbohovái (2)

more options

Does Firefox allow to retrieve and inspect the certificate?

Can you post a link to that site?


Try to rename the cert8.db file in the Firefox profile folder to cert8.db.old or delete the cert8.db file to remove intermediate certificates that Firefox has stored.

You can use this button to go to the Firefox profile folder:

  • Help > Troubleshooting Information > Profile Directory: Open Containing Folder
more options

Ñemoĩporã poravopyre

I have narrowed it down somewhat. If I create a new profile, there is no problem. I was having trouble accessing any page on the server e.g. https://example.com/robots.txt, https://example.com/foobar I found an entry in the cache for https://example.com/ which is actually a 301 moved response, and which includes a long security-info: string in base-64. If I empty the cache, the problem disappears - I get the challenge, and can grant an exception. If I restore the profile and cache from a saved copy, the problem reappears. I'm not sure what the saved state in the cache represents because I'd been playing with the certificate on the server too and hadn't documented when I'd changed it.

If I go to https://example.com/robots.txt and use reload, or shift-reload (which as I recall would normally get a new copy regardless of cached copies), it does not help.

When the problem manifests itself, I cannot retrieve the certificate using Firefox. There is no intermediate certificate, it's a self-signed one.

I'd had this problem on 3 machines. On one, I cleared the cache without saving it first, which fixed the problem. A third, running SeaMonkey, I presume still has the problem, and I presume it can be fixed by clearing cache.

(later) The issue appears if an HTTPS redirect is cached, and then the (self-signed) server certificate is changed Clearing the entry from cache resolves the problem. I have filed https://bugzilla.mozilla.org/show_bug.cgi?id=767611

Moambuepyre adaviel rupive