FF presents SSL Error: SEC_ERROR_INADEQUATE_KEY_USAGE
Categories
(Firefox :: Security, defect)
Tracking
()
People
(Reporter: support, Unassigned)
Details
Attachments
(8 files)
User Agent: Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:69.0) Gecko/20100101 Firefox/69.0
Steps to reproduce:
open https://fritz.box , a AVM DSL-Router commonly used in Germany.
Version: FF 69.0.1 x86_64 Fedora 29
Actual results:
The german error msg for "SEC_ERROR_INADEQUATE_KEY_USAGE" appears:
Fehler: Gesicherte Verbindung fehlgeschlagen
Beim Verbinden mit fritz.box trat ein Fehler auf. Eine Verwendung des Zertifikatschlüssels ist für den versuchten Arbeitsschritt unpassend. Fehlercode: SEC_ERROR_INADEQUATE_KEY_USAGE
Die Website kann nicht angezeigt werden, da die Authentizität der erhaltenen Daten nicht verifiziert werden konnte.
Kontaktieren Sie bitte den Inhaber der Website, um ihn über dieses Problem zu informieren.
I debuged the problem with openssl, as Firefox rejects to offer any useful informations. The Cert offered by the router as one major flaw, but it's from 2017, which means, that firefox has accepted it for nearly 2 years without any complaint:
$ openssl x509 < x.cert -text -purpose
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
de:09:4a:4f:a8:22:62:da
Signature Algorithm: sha256WithRSAEncryption
Issuer: CN = benderirc.de
Validity
Not Before: Dec 24 15:25:01 2017 GMT
Not After : Jan 15 15:25:01 2038 GMT
Subject: CN = benderirc.de
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public-Key: (2048 bit)
Modulus:
00:d7:6c:4e:30:d2:1f:5c:1f:d7:98:b5:cd:55:60:
a1:41:30:e2:5b:df:6b:16:03:ec:3c:03:d2:73:fb:
20:2a:8d:37:87:72:7d:52:0d:56:51:9a:e4:69:7b:
b3:b4:5c:1d:d2:87:ab:fd:e9:95:ba:5e:14:58:cf:
87:3d:01:f3:c9:3e:24:94:4f:16:11:2b:9d:00:3e:
51:8c:d0:6a:d4:58:42:cf:73:40:c8:75:74:5d:17:
3d:88:8f:04:10:6e:f4:d8:55:93:ea:10:42:25:f7:
96:cb:eb:6b:9f:28:05:df:ad:b1:b8:0f:23:38:4c:
74:c9:c4:d1:dd:bb:47:ee:d6:c9:67:f9:87:4f:07:
c4:be:37:b0:25:27:e2:e6:6c:d5:d9:81:5c:5c:7a:
51:42:bf:89:08:b1:e9:e7:0e:2d:bc:54:e7:a3:76:
a9:44:ca:fa:6b:e7:ee:b9:55:b0:91:84:ae:5b:35:
34:0e:1c:be:cd:dc:c2:2f:44:2c:93:d1:8d:81:ee:
07:20:f5:c3:1b:fa:2a:4b:7d:23:4f:f5:da:a9:da:
ea:65:a2:b5:9a:bc:a8:36:02:32:96:30:b2:a3:e9:
0a:32:21:92:6f:b8:d1:96:7a:65:6a:a2:62:2f:fe:
51:69:54:45:7d:ef:72:52:d5:94:22:d2:a1:bb:56:
19:d3
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Subject Key Identifier:
2A:A3:5E:AD:2A:57:BD:97:22:8A:CE:F0:5B:D6:9C:77:C7:0E:03:A4
X509v3 Authority Key Identifier:
keyid:2A:A3:5E:AD:2A:57:BD:97:22:8A:CE:F0:5B:D6:9C:77:C7:0E:03:A4
DirName:/CN=benderirc.de
serial:DE:09:4A:4F:A8:22:62:DA
X509v3 Basic Constraints:
CA:TRUE
X509v3 Subject Alternative Name: critical
DNS:benderirc.de, DNS:fritz.box, DNS:www.fritz.box, DNS:myfritz.box, DNS:www.myfritz.box, DNS:fritz.nas, DNS:www.fritz.nas
Signature Algorithm: sha256WithRSAEncryption
91:0d:1b:dc:b7:c6:5e:c5:46:1b:8c:2d:be:b4:a2:90:83:bb:
3d:4e:db:92:2c:39:0f:07:0b:44:6b:9d:4e:64:d6:17:4f:91:
98:18:71:de:5b:93:7a:1a:63:cb:ce:24:ee:2c:6c:88:e6:ad:
3e:55:89:08:27:27:df:d9:fc:88:d0:8a:c0:ca:34:65:1a:3c:
d6:63:bc:65:47:cb:a0:e9:c9:47:87:0d:b4:28:76:75:a3:df:
34:e2:12:02:74:c3:ef:ff:f4:fe:b3:55:95:e2:6e:02:8b:ee:
0d:f7:14:93:84:f8:a5:9e:ed:f2:21:2b:e9:07:a7:b6:33:c0:
1d:16:89:12:eb:ac:31:77:8b:db:be:54:e2:df:0f:fe:a3:2a:
d5:09:66:13:f4:bc:96:8e:78:56:00:1b:17:73:19:7e:20:f0:
32:c6:cc:05:13:e2:2b:78:ab:ef:d7:91:4d:05:25:b4:95:17:
0b:63:ec:c0:45:b0:2d:42:b7:93:59:4c:98:56:b7:a2:d7:75:
4a:e2:60:25:d0:26:5a:9e:fc:b1:8b:8a:17:58:4a:50:77:84:
84:a2:11:be:30:9b:0a:fe:57:f9:3f:75:af:a7:2c:51:fa:5a:
08:83:9e:3d:0c:58:96:a0:a2:77:7d:08:c6:d9:0a:06:c5:76:
2a:2d:b5:08
Certificate purposes:
SSL client : Yes
SSL client CA : Yes
SSL server : Yes
SSL server CA : Yes
Netscape SSL server : Yes
Netscape SSL server CA : Yes
S/MIME signing : Yes
S/MIME signing CA : Yes
S/MIME encryption : Yes
S/MIME encryption CA : Yes
CRL signing : Yes
CRL signing CA : Yes
Any Purpose : Yes
Any Purpose CA : Yes
OCSP helper : Yes
OCSP helper CA : Yes
Time Stamp signing : No
Time Stamp signing CA : Yes
Bug #1 :
it says "benderirc.de" as CN, which is one of my domains, not connected to the box in anyway. It routes normaly, so no idea why the box makes a cert with that domain as CN and alternatename.
Firefox can connect to benderirc.de without any mistakes.
That firefox blocks this site, got noticed a few weeks ago. I waited for an os upgrade of the dsl box, it came, i updated, nothing changed. To fix this bug, was obviosly not part of the os update.
Expected results:
a) a hint, what exactly triggered the error would be extrem helpful.
b) as nothing is wrong with that cert, that should trigger "INADEQUATE_KEY_USAGE" that i see, i would request to continue accepting this cert.
|
||
Comment 1•5 years ago
|
||
Can you attach a packet trace of the TLS handshake with the router? Thanks!
|
|
||
Comment 4•5 years ago
|
||
Thanks! Do you see the same behavior with Firefox 70? (released today) Or Firefox ESR 68.2.0?
No change with FF 70. Problem NOT solved.
I observed the same problem on FF 69 and 70 (Win64), with the same kind of device (FritzBox). I am remotely connecting to the device using a dynamic DNS name on a non-standard port. If I use a clean Firefox profile, I can connect without issues, once I confirm that I want to accept the self-signed certificate of the device. Now, I host a public-facing web site on the same hostname, on the standard SSL port (443), using a valid Let's Encrypt certificate. Once I connect to that site (which works fine), if I try connecting back to the FritzBox with the same hostname (but different port), I have the SEC_ERROR_INADEQUATE_KEY_USAGE error. At this point, even trying to connect with a different hostname pointing to the same IP address, or with the IP directly, triggers the same error, probably because of the presence of the hostname in the certificate presented by the FritzBox.
If that is the problems cause, the entire problem of the wrong hostname in a fritzbox could be avoided by making use of the Invention of the year 1998 ... "SNI" aka. setup proper vhosts for the apache or whatever webserver, and present valid vhost bound certs.
I'm so curious about AVM answere to this proposal :D
@Mozilladevs: A statement, that the second name in that cert is the cause of all this, is needed to bring AVM to a fix.
|
|
||
Comment 9•5 years ago
|
||
Ale, do you have the enterprise roots feature enabled? (see the preference security.enterprise_roots.enabled in about:config)
Also, can you attach the file cert9.db from your profile directory to this bug?
Thanks!
|
||
Comment 10•5 years ago
|
||
I'm using the default settings, security.enterprise_roots.enabled is false. The cert9.db is attached.
Testing further, it looks that it is not just enough to visit the address with the "real" valid certificate to trigger the problem for the self-signed one on the non-standard port.
This seems to always trigger the problem:
- open Firefox
- visit the web site having the valid Let's Encrypt cert with https://hostname/
- visit the FritzBox login page (which uses a certificate that contains, among others, the host name of the web site mentioned above) using https://hostname:port/ -- this gives SEC_ERROR_INADEQUATE_KEY_USAGE
On the other hand:
- open Firefox
- visit the FritzBox login page using https://hostname:port/ and accept the self-signed cert
- visit the web site with https://hostname/
- reload the FritzBox login page
In this case, the FritzBox login page still loads fine, most of the time. Sometimes, at this point, after waiting a few seconds/minutes without doing anything, reloading doesn't work anymore and triggers the issue. I didn't have time yet to figure out whether this only happens with IPv6 enabled or not.
I did tests with both IPv6 enabled and using a SOCKS5 proxy that only has IPv4 to see if the issue is related to IPv6, but for now I have no evidence of any relationship. I tested this because the hostname I'm using has both AAAA and A records, the web server on port 443 is listening on both, but the FritzBox only on the IPv4 address.
|
||
Comment 11•5 years ago
|
||
I encountered this same issue with self-signed certificate chain generated in the Yunohost project with the default installation.
https://github.com/YunoHost/issues/issues/1479
|
||
Comment 12•5 years ago
|
||
The priority flag is not set for this bug.
:wleung, could you have a look please?
For more information, please visit auto_nag documentation.
|
|
||
Comment 13•5 years ago
|
||
(In reply to support from comment #0)
it says "benderirc.de" as CN, which is one of my domains, not connected to the box in anyway. It routes normaly, so no idea why the box makes a cert with that domain as CN and alternatename.
This is basically what's causing the issue. When you visit benderirc.de, Firefox caches that certificate, which has a subject name of CN=benderirc.de. For some reason, the certificate on your FritzBox has an issuer (and subject) name of CN=benderirc.de, which means that when Firefox tries to find an issuer for it, the cached benderirc.de certificate is seen as a potential issuer. However, since it doesn't have the right key usage, searching that path fails. Since there are no other potential issuers, that's the error that gets reported to the front-end.
Do you have a way of regenerating that certificate so it doesn't have that name?
|
Reporter | |
Comment 14•5 years ago
|
||
The cert of the DSL box with the wrongly aquired domainname is out of my control. The cert gets autogenerated everytime the box thinks it's needed.
I'm pretty sure, the box picked the name up, because a subdomain of this domainname is used to connect home via ssh. But as ssh does not need such certs nor does the box be the endpoint of the connection, it just did wrong.
That the box did something wrong, was clear in the beginning. The Question is, why did FF change the test for it, as the creation of the cert was years ago.
To get it fixed, I need a statement of the DEV team, that the sole problem is the acquirement and usage of a domainname, that has a different and valid certificate, by the box. With it I can go to AVM and push for a solution.
|
|
Reporter | |
Comment 15•5 years ago
|
||
BTW.. the presented error messages of firefox are mostly useless, in special in this case. Why is it not possible to exactly tell the one infront of the display, what triggered the message? If FF detected 2 Certs with the same domainname and both shall be valid, which suggests a fraud attempt, than tell it to us.
"Hello User, Firefox has found two colliding certs. Please refer to page ... and here is a short overview of the offending certs:
CN:
ADN:
Timewindow:
Issuer:
Checksum:
CN:
ADN:
Timewindow:
Issuer:
Checksum:
"
That way, things will be much easier for any first level supporter worldwide. The uninformed user does not understand a word, but that is true in both cases anyway ;)
|
||
Comment 16•5 years ago
|
||
So I have the same issue (also using yunohost as in this comment https://bugzilla.mozilla.org/show_bug.cgi?id=1590217#c11)
Following from https://bugzilla.mozilla.org/show_bug.cgi?id=1590217#c13 and to precise things a bit, the problem appears when:
- for some reason, the CN key changes (in my case, by recreating the dev vm).
- the CN is not the same as the domain (maybe Firefox goes to a different path by considering it is a self-signed certificate when both are the same, and doesn't check the key any more in this case). After recreating my vm, I created two domain : ynh.local and ynh2.local. In my case, the CN is ynh.local. the webpage ynh.local still displays in firefox (because I have accepted the self-signed certificate) but ynh2.local now displays this error.
Can someone that the code is really doing that?
If I'm right, then I guess we should either be able to clear this CN key cache (or the certificate cache?) somehow, or to be able to bypass this specific error. The error could say "The CN key has changed, do you want to proceed anyway?".
I think we should pass this as CONFIRMED
|
|
||
Comment 17•5 years ago
|
||
What is the issuer distinguished name of the ynh.local certificate?
|
|
||
Comment 18•5 years ago
|
||
I don't know how to get that info, but here is the top of certtool -i. In my case, my main domain is yolo.test (the one that works all the time), and the domains that don't work are yolo2.test and test.yolo.test.
root@yolo:/home/vagrant# certtool -i < /etc/yunohost/certs/yolo.test/crt.pem
X.509 Certificate Information:
Version: 3
Serial Number (hex): 00c80bb5c8e9b2de4cf00c18cbefa55e4466e139
Issuer: CN=yolo.test
Validity:
Not Before: Tue Nov 05 14:27:11 UTC 2019
Not After: Fri Nov 02 14:27:11 UTC 2029
Subject: CN=yolo.test
Subject Public Key Algorithm: RSA
...
and
root@yolo:/home/vagrant# certtool -i < /etc/yunohost/certs/yolo.test/ca.pem
X.509 Certificate Information:
Version: 3
Serial Number (hex): 00ca65b1255b62354c
Issuer: CN=yolo.test
Validity:
Not Before: Tue Nov 05 14:27:09 UTC 2019
Not After: Fri Nov 02 14:27:09 UTC 2029
Subject: CN=yolo.test
Subject Public Key Algorithm: RSA
...
is that what you wanted Dana?
|
|
||
Comment 19•5 years ago
|
||
Do all of those domains use the same server certificate?
|
|
||
Updated•5 years ago
|
|
|
||
Comment 20•5 years ago
|
||
By server certificate you mean the certificate authority ? If so, yes, the ca.pem is the same for both domain, though the cr.pem and key.pem differ.
|
|
||
Comment 21•5 years ago
|
||
The server certificate is the certificate the server uses when you connect to it. The certificate authority is the certificate that signed the server certificate. If the server certificate is self-signed (which it sounds like it might be?) then there wouldn't actually be two separate certificates. It sounds like the issue with yunohost may be due to the framework generating multiple unrelated certificates that all have the same issuer/subject distinguished names. The algorithm Firefox uses to verify certificates would perform much better if these identifiers were unique.
|
|
||
Comment 22•5 years ago
|
||
Ok clearer for me.
If the server certificate is self-signed (which it sounds like it might be?) then there wouldn't actually be two separate certificates.
there is two separates certificates, because there is two separate domains pointing on the same ip (yolo.test and yolo2.test). They are both signed by the same CA.
so to answer your original question:
Do all of those domains use the same server certificate?
Each domain has its own https certificates. An https certificate is only valid for one domain (or a wildcard) anyway, right?
It sounds like the issue with yunohost may be due to the framework generating multiple unrelated certificates that all have the same issuer/subject distinguished names
Isn't the CN contained in the distinguished names? Wouldn't that make them different from each other automatically?
Anyway, I might miss something, so : Yunohost does the self-signed certificate generation here, and I will attach the relevant conf files. For me the distinguished names are different from each other, but maybe I'm not looking at it correctly
|
|
||
Comment 23•5 years ago
|
||
|
|
||
Comment 24•5 years ago
|
||
|
|
||
Comment 25•5 years ago
|
||
So I have attached the two conf files, as they are written just before the openssl invocation (so here)
I believe the relevant sections are
[ req_distinguished_name ]
commonName = Common Name (eg, YOUR name)
commonName_max = 64
commonName_default = yolo.test
and
[ req_distinguished_name ]
commonName = Common Name (eg, YOUR name)
commonName_max = 64
commonName_default = yolo2.test
After my research, I now realize that is probably what I should have answered when you first asked for the distinguished names Dana, sorry for that and thanks for the help :-)
|
|
||
Comment 26•5 years ago
|
||
(In reply to Augustin Trancart [:autra] from comment #22)
Do all of those domains use the same server certificate?
Each domain has its own https certificates. An https certificate is only valid for one domain (or a wildcard) anyway, right?
A single certificate can have multiple entries in the subject alternative names extension, making it valid for more than one domain without necessarily having a wildcard.
It sounds like the issue with yunohost may be due to the framework generating multiple unrelated certificates that all have the same issuer/subject distinguished names
Isn't the CN contained in the distinguished names? Wouldn't that make them different from each other automatically?
Yes, but only if the CNs are different, which it looks like they should be from your config files.
Anyway, I might miss something, so : Yunohost does the self-signed certificate generation here, and I will attach the relevant conf files. For me the distinguished names are different from each other, but maybe I'm not looking at it correctly
It would be easiest if you attached the certificates themselves to this bug (the ca as well as both server certificates). As long as the files don't have any private keys in them along with the certificates, there isn't any private information.
|
|
||
Comment 27•5 years ago
|
||
|
|
||
Updated•5 years ago
|
|
|
||
Comment 28•5 years ago
|
||
|
|
||
Comment 29•5 years ago
|
||
|
|
||
Comment 30•5 years ago
|
||
It would be easiest if you attached the certificates themselves to this bug (the ca as well as both server certificates). As long as the files don't have any private keys in them along with the certificates, there isn't any private information.
Sure! Anyway, this is in a disposable vm so I can even upload the key if needed. There is only one ca because in both case they are symlinked to the same file.
Thanks again Dana
|
|
||
Comment 31•5 years ago
|
||
Great - thanks!
So what's happening is the CA has an issuer and subject DN of "CN=yolo.test". One of the server certificates also has an issuer and subject DN of "CN=yolo.test", while the other has subject DN "CN=yolo.test2" and issuer DN of "CN=yolo.test". When only the two server certificates are in Firefox's in-memory certificate cache, the first server certificate looks like it could be an issuer for the second one, because its subject DN matches the second certificate's issuer DN. However, since it doesn't have the right key usage, verification fails. Since there are no other potential issuers, Firefox reports the key usage error.
It should work if you import and trust the root certificate using the certificate manager in Firefox (about:preferences -> search for certificates -> click View Certificates -> click Authorities -> click Import -> open the CA -> check the websites box).
Yunohost can avoid this by making the CA issuer/subject DNs distinct from server subject DNs.
|
|
||
Comment 32•5 years ago
|
||
Ok, so if I understand correctly, Firefox take the wrong certificate in cache based only on the Issuer CN ? And not checking the provided certificate chain ? So there is a bug ? No ?
|
|
Reporter | |
Comment 33•5 years ago
|
||
It's simple: two or more certs with the same CN are colliding, because firefox stumpled about both of them. The selfsigned cert is marked as as bad one by default.
Conclusion:
-
A someone issued a cert with a CN he should not have ( my case / AVM fritzBox )
-
you issued two unsigned certs for the same CN, you should not have done this too.
In MY case, the unsigned/selfsigned cert as been issued by the box: AVM needs to fix this.
In YOUR case, use one cert in both places and your fine.
@Dana:
One question to answer is now, why was this accepted until FF70?
Another one is, will it be overrideable, because the situation both on the explanation side to the user and on the meassures to take side, is unsatisfactory.
|
|
||
Comment 34•5 years ago
|
||
It's simple: two or more certs with the same CN are colliding, because firefox stumpled about both of them. The selfsigned cert is marked as as bad one by default.
No. Two serveur certificate (with different DN) have the same Certificate Authority, AND the certificate authority has the same DN than one of the Server Certificate. Firefox then takes the server certificate instead of the certificate authority as certificate authority for the other server certificate. But of course, the keys then mismatch. Dana, did I get this correctly?
you issued two unsigned certs for the same CN, you should not have done this too.
That's not the problem. We didn't generate 2 unsigned certs, we generated 2 self-signed certs with a CA whose DN matches the DN of one of those server certificates.
In YOUR case, use one cert in both places and your fine.
No again :-) In our case, the fix is to make sure the DN of the CA is distinct from every other DN of server certificate.
|
|
||
Comment 35•5 years ago
|
||
(Btw guys, if you want Dana to answer, you should use the "Request Information from other, :keeler")
Dana, thanks for all the answer. It all starts to make sense for me thanks to you!
For the fritzbox problem, will the same workaround (trusting the root certificate) work?
Just to be sure : do you think there's a firefox bug or not? Should yunohost be able to do what is currently does? Or is it bad to have the same DN for a CA and a server certificate? Intuitively I think Firefox now behaves normally (and the bug was what happens before), but I'm not sure. (related to @support's question above)
|
|
||
Comment 36•5 years ago
|
||
For the fritzbox situation, I'm assuming there isn't a CA, so that unfortunately won't work. One option there would be to have a separate profile specifically for interacting with that device.
We have changed Firefox's behavior in terms of how it gathers candidate certificates, so those changes may have exposed this behavior. That said, since about version 33 (when we shipped the new certificate verifier) it has been possible to get Firefox to return this error, so I wouldn't say this issue is new.
Given that these certificates don't come from a trusted CA anyway (unless you import one as in the yunohost case), this is in some ways a question of what certificate errors we allow overrides for. There are some trade-offs, but generally, expanding this set is bad for the ecosystem. Every error we allow is another opportunity for other implementations to seem interoperable but be broken in reality. For example, we don't allow overrides for certificates that aren't encoded correctly (with some exceptions - mostly for interoperability with preexisting, broken systems).
I would like to come up with a way to make Firefox not encounter this error in cases like this, but I can't think of a way that wouldn't also prevent it from finding legitimate paths or introduce unacceptable complexity.
We are working on some changes that may make this kind of problem less likely by avoiding decoding certificates (which implicitly puts them in the cache). However, it may be a while before that's complete, and even then, it will still be possible to encounter this error, so that's not a full solution.
Long story short, we're not going to fix this issue directly, so I'm closing this as wontfix.
|
|
||
Comment 37•5 years ago
|
||
Thanks Dana I appreciate the time you took to explain the issue in details. For the curious, I fixed this for yunohost in this PR.
There are some trade-offs, but generally, expanding this set is bad for the ecosystem.
I totally agree, and in this case, I don't think it'll be a good idea. I guess the only "good" way to fix this woud be for firefox to have 2 certificate caches : one for CA and one for server certificates, but it isn't worth the effort here, as I'm now pretty sure the distinguished name is supposed to be distinct anyway.
|
||
Comment 38•5 years ago
|
||
I think the current behavior of Firefox is not satisfactory in the case of the problem. The error message is misleading. There is not a “Key Usage” certificate extension problem, but a problem of CA chain resolution algorithm as implemented by Firefox.
It can be a serious problem. Firefox does not allow to use a valid certificate and does not allow to skip the error. In the meantime, the content is properly displayed in all other browsers.
I spent some time researching the changes made in Firefox 68+. I noticed the problem is reproduced after this commit: https://phabricator.services.mozilla.com/D31368
Dana, could you review the commit and maybe commits that are nearby? Could someone else test the behavior of Firefox if we revert the commit?
Could we consider reopening the bug?
Thanks.
|
|
||
Updated•5 years ago
|
|
|
||
Comment 39•5 years ago
|
||
(In reply to Augustin Trancart [:autra] from comment #37)
Thanks Dana I appreciate the time you took to explain the issue in details. For the curious, I fixed this for yunohost in this PR.
Awesome - thanks!
deniskk25 - what systems are you trying to interact with such that Firefox is encountering this error?
|
|
||
Comment 40•5 years ago
|
||
I used IIS Express web server from Microsoft and encountered this error under the following circumstances:
- The server uses a self-signed certificate.
- There is a different certificate on a client-side, but with the same “Issuer” and “Subject” fields as the server certificate.
- The certificate is located in the “Trusted Root Certificate Authorities” in the Windows Certificate Store on the client-side.
I guess the error can occur for any system that creates a self-signed certificate and imports it to the trusted CAs. In some cases, reinstalling such systems and, as a result, re-creating certificates can lead to the error.
In my case the error is reproduced starting from Firefox 69. Before that, Firefox presented ‘UNKNOWN_ISSUER’ error and allowed to accept the certificate.
It is not a problem to fix it yourself if you know all the details, but it all looks like too many systems are prone to the problem.
|
|
||
Comment 42•5 years ago
|
||
Do you have any progress on this bug?
|
|
||
Comment 43•5 years ago
|
||
If we make any progress we'll update this bug.
|
||
Comment 44•4 years ago
|
||
I have similar problem (will now spend some time debugging to find out if it is actually teh same or not).
While I agree on the solution of "not making the platform less secure", I also concur with the idea of giving to the users a more meaningful error message. the current one is not only obscure but also misleading.
|
||
Comment 45•4 years ago
|
||
I've been running into this and found a workaround for this issue as I've been reading the comments and I'll note it here in case somebody with this issue finds the bug via Google. following setup: the Fritzbox router has a port forwarding to tcp/443 to a Linux-box with a self signed cert. this was added as an permanent exception in Firefox. so this cert was sitting in the Firefox certificate store with my dyn DNS name. I deleted this cert from the store and I've been able to connect to the fritzbox router with my dyn DNS hostname port tcp/8443 again and as the Linux server now has a letsencrypt cert this works too without any issues
Description
•