Closed Bug 1590217 Opened 6 months ago Closed 5 months ago

FF presents SSL Error: SEC_ERROR_INADEQUATE_KEY_USAGE

Categories

(Firefox :: Security, defect)

69 Branch
defect
Not set

Tracking

()

RESOLVED WONTFIX

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.

Can you attach a packet trace of the TLS handshake with the router? Thanks!

Flags: needinfo?(support)
Has Regression Range: --- → no
Component: Untriaged → Security

File one

Flags: needinfo?(support)

Thanks! Do you see the same behavior with Firefox 70? (released today) Or Firefox ESR 68.2.0?

Flags: needinfo?(support)

as soon as it hits Fedora i will check it.

No change with FF 70. Problem NOT solved.

Flags: needinfo?(support)

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.

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!

Flags: needinfo?(servizio.antifumo)
Attached file cert9.db

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:

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.

Flags: needinfo?(servizio.antifumo)

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

The priority flag is not set for this bug.
:wleung, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(wleung)

(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?

Flags: needinfo?(support)

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.

Flags: needinfo?(support)

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 ;)

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:

  1. for some reason, the CN key changes (in my case, by recreating the dev vm).
  2. 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

Flags: needinfo?(dkeeler)

What is the issuer distinguished name of the ynh.local certificate?

Flags: needinfo?(dkeeler) → needinfo?(augustin.trancart)

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?

Flags: needinfo?(augustin.trancart) → needinfo?(dkeeler)

Do all of those domains use the same server certificate?

Flags: needinfo?(dkeeler)
Flags: needinfo?(augustin.trancart)

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.

Flags: needinfo?(augustin.trancart) → needinfo?(dkeeler)

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.

Flags: needinfo?(dkeeler)

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

Flags: needinfo?(dkeeler)

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 :-)

(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.

Flags: needinfo?(dkeeler)
Attachment #9108995 - Attachment mime type: application/x-x509-ca-cert → text/plain

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

Flags: needinfo?(dkeeler)

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.

Flags: needinfo?(dkeeler)

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 ?

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:

  1. A someone issued a cert with a CN he should not have ( my case / AVM fritzBox )

  2. 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.

Flags: needinfo?(wleung)

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.

(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)

Flags: needinfo?(dkeeler)

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.

Status: UNCONFIRMED → RESOLVED
Closed: 5 months ago
Flags: needinfo?(dkeeler)
Resolution: --- → WONTFIX

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.

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.

Flags: needinfo?(support)
Flags: needinfo?(dkeeler)
Flags: needinfo?(augustin.trancart)
Flags: needinfo?(augustin.trancart)

(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?

Flags: needinfo?(support)
Flags: needinfo?(dkeeler)
Flags: needinfo?(deniskk25)

I used IIS Express web server from Microsoft and encountered this error under the following circumstances:

  1. The server uses a self-signed certificate.
  2. There is a different certificate on a client-side, but with the same “Issuer” and “Subject” fields as the server certificate.
  3. 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.

Flags: needinfo?(deniskk25) → needinfo?(dkeeler)

Thanks for the info. We'll see what we can do.

Flags: needinfo?(dkeeler)

Do you have any progress on this bug?

Flags: needinfo?(jhofmann)
Flags: needinfo?(dkeeler)

If we make any progress we'll update this bug.

Flags: needinfo?(jhofmann)
Flags: needinfo?(dkeeler)
You need to log in before you can comment on or make changes to this bug.