990603 - Unable to view or add exception for self signed certificate

Status: RESOLVED FIXED

(Core :: Security: PSM, defect)

Description

[Nick Barrington]

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:31.0) Gecko/20100101 Firefox/31.0 (Beta/Release)
Build ID: 20140401030203

Steps to reproduce:

User agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:31.0) Gecko/20100101 Firefox/31.0

Specifically this appeared in Nightly 31.0a1 20140401030203 and was not present a day earlier in Nightly 31.0a1 20140401030201

I am attempting to access an internal ClearOS machine's admin web interface, which has been working fine up until yesterday's nightly build.  This may be an issue related to using a non-standard port, I can't test 443 unfortunately.  I have tested this with a fresh profile in Firefox.

1. Visit a site with a self signed certificate (e.g. https://server.domain:81)
2. The Untrusted Connection warning page should appear
3. Click Technical Details to view the specific message:

An error occurred during a connection to server.domain:81.
Issuer certificate is invalid.
(Error code: sec_error_ca_cert_invalid)

4. Click Add Exception to try adding an exception for the site
5. The Add Security Exception dialog should appear
6. Click Get Certificate
7. The Certificate Status panel will return an error message:

No Information Available
Unable to obtain identification status for the given site.

8. The View and Confirm buttons are disabled.




Actual results:

The Untrusted Connection page "Technical Details" section reports:

An error occurred during a connection to server.domain:81.
Issuer certificate is invalid.
(Error code: sec_error_ca_cert_invalid)


The Add Security Exception dialog has the View and Confirm buttons disabled and reports:

No Information Available
Unable to obtain identification status for the given site.


Expected results:

This is a self-signed certificate, so it is correct that the Untrusted Connection page is shown.  However, up until Nightly 31.0a1 20140401030203, the message returned by the Untrusted Connection page was:

server.domain:81 uses an invalid security certificate.
The certificate is not trusted because it is self-signed.
(Error code: sec_error_untrusted_issuer)

The steps for adding an exception worked fine.

I'm assuming the previous behaviour was correct because it allowed me to add an exception, but I don't know if some security feature has been tightened in Firefox to be more strict about certificate content.

Comment 1

[Nick Barrington]

I had a brief look at the recent commits from http://hg.mozilla.org/mozilla-central/pushloghtml?startdate=48+hours+ago&enddate=now and the only ones I could find that seemed related to the certificate handling area were:

50ff5b820452	David Keeler — bug 990248 - enable mozilla::pkix by default in Firefox Nightly r=briansmith r=cviecco

a8fd27b3dbae	David Keeler — bug 989516 - mozilla::pkix: temporarily allow improper basicConstraint:cA encodings r=cviecco

6b570ab31d19	David Keeler — bug 987295 - mozilla::pkix: test ocsp extension decoding r=cviecco

b591f6b11bec	David Keeler — bug 987295 - mozilla::pkix: fix decoding OCSP response extensions r=cviecco

7bb2a113f16b	Camilo Viecco — Bug 986156 - Allow anypolicyoid and reject on inhibitAnypolicy (mozilla::pkix). r=bsmith


Sorry if those have nothing to do with it, they just caught my eye while scrolling through.

Comment 2

[beingalink]

I can reproduce this on a mac (mavericks).

Comment 3

[m.]

I can also reproduce on Linux x86_64.

Comment 4

[alex_mayorga]

Marking NEW and broadening the platform based on 3rd party confirmations.

Comment 5

[Dana Keeler (she/her) [:keeler]]

Nick - can you post an example of a certificate that fails? We just switched to using a new verification library that is more strict than the old one.

Comment 6

[beingalink]

I can reproduce it on my server: https://192.161.48.10/

Comment 7

[Dana Keeler (she/her) [:keeler]]

That certificate has a basic constraints extension with CA:true, which isn't valid for an end-entity certificate.

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 9251007090457959348 (0x80622def515ddbb4)
    Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=DE, ST=Some-State, O=Internet Widgits Pty Ltd
        Validity
            Not Before: Dec 14 13:16:54 2013 GMT
            Not After : Dec 12 13:16:54 2023 GMT
        Subject: C=DE, ST=Some-State, O=Internet Widgits Pty Ltd
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (1024 bit)
                Modulus:
                    00:d9:0d:4c:4f:c9:d7:51:02:f3:7b:75:7b:0d:e1:
                    f2:e2:04:de:87:4a:fb:3e:0b:88:68:21:f5:b1:d5:
                    b1:98:00:fd:c3:35:9b:d9:f3:b3:58:45:f1:86:7e:
                    b1:5a:da:70:99:40:32:07:2c:aa:61:fb:ba:99:29:
                    24:fd:70:4d:3a:22:d5:b9:0b:24:dc:53:b5:0d:d7:
                    26:0a:bc:bd:be:d4:b3:ec:5f:56:4a:94:9a:0c:5a:
                    c9:9f:7a:d8:3c:38:fa:31:f7:4b:2c:6e:99:37:72:
                    fd:21:9c:9b:b0:14:29:62:ac:f4:e3:d1:64:22:fc:
                    cf:36:b5:84:8f:da:2e:80:df
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Subject Key Identifier: 
                F5:EF:CC:89:8D:FF:1B:AF:99:01:AF:70:64:65:C4:E3:BB:49:9A:74
            X509v3 Authority Key Identifier: 
                keyid:F5:EF:CC:89:8D:FF:1B:AF:99:01:AF:70:64:65:C4:E3:BB:49:9A:74

            X509v3 Basic Constraints: 
                CA:TRUE
    Signature Algorithm: sha1WithRSAEncryption
         d2:79:02:99:92:9d:33:e0:1f:32:ab:86:a7:32:58:07:40:06:
         1c:ee:98:31:f5:ce:50:9c:26:74:67:1b:47:63:0c:4f:ff:e8:
         7d:94:47:f8:4a:81:df:cd:89:0d:18:4d:03:78:04:21:89:fe:
         eb:bb:da:fe:ff:31:a4:5c:8d:e7:00:86:0c:83:c5:e2:38:f7:
         81:d3:49:3b:a6:1d:51:d8:4d:0a:4d:52:65:bf:ec:26:f5:57:
         e3:1f:16:8d:ee:4c:9e:bd:af:32:e5:f4:27:a5:96:d0:75:13:
         9f:22:4e:79:66:8f:3f:06:41:55:d2:02:ad:af:8f:f1:fa:ab:
         c0:64

Comment 8

[Finn Bryant]

I'm hitting this problem at work, and it appears that the certificates at my workplace have "Basic Constraints: CA:TRUE" too.

Fwiw, toggling "security.use_mozillapkix_verification" in about:config returned to the previous behaviour.

So the issue is that these sites have been using invalid self-signed certificates for a long time, but firefox has been ignoring it (and so have safari/chrome/etc)? Given that, has changing this behavior been intentional, or an accidental side effect? If intentional, do you have any data on how many sites have been broken? That could be tricky given many self-signed sites are internal tools not accessible on the open internet...

Whether you fix this or not, we need at the very least a way to get more info on the failure, at the moment i needed to open safari to even access the certificate to find out why it failed, nightly seems to disable viewing the certificate for some reason? Even better would be a message explaining that the certificate was invalid due to a broken constraint...

Comment 9

[Nick Barrington]

(In reply to David Keeler (:keeler) from comment #5)
> Nick - can you post an example of a certificate that fails? We just switched
> to using a new verification library that is more strict than the old one.

A few people have beaten me to it, but fwiw mine also has the issue of CA:TRUE

Unfortunately, this is the type of certificate that the instructions provided by Apache for self-signed certificates ends up producing (as at http://httpd.apache.org/docs/2.2/ssl/ssl_faq.html#aboutcerts ).  I gather quite a few web appliances do the same thing when they generate their certificates, presumably because of the Apache instructions.


Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 1346728449 (0x50457201)
    Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=CA, ST=Ontario, L=Toronto, O=ClearFoundation, OU=None, CN=server.domain/emailAddress=none
        Validity
            Not Before: Sep  4 03:14:09 2012 GMT
            Not After : Nov 21 03:14:09 2020 GMT
        Subject: C=CA, ST=Ontario, L=Toronto, O=ClearFoundation, OU=None, CN=server.domain/emailAddress=none
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (1024 bit)
                Modulus:
                    00:d6:60:14:35:87:93:79:1f:81:2d:8a:5a:1d:00:
                    12:59:2b:8d:a7:46:63:7b:6f:68:2f:d1:a5:40:32:
                    60:51:98:4e:33:61:52:13:93:36:d6:9c:62:fe:2d:
                    f7:ab:4a:9e:34:fd:68:e5:c8:b2:96:dd:b3:80:8d:
                    e7:32:15:bc:cf:9d:51:38:d4:46:4e:84:9c:df:57:
                    b2:a5:b4:bb:45:7f:78:b9:01:6e:3a:97:be:fb:8c:
                    07:db:41:e0:b8:1b:ad:16:4c:99:a9:2d:9b:b7:a1:
                    53:15:bd:23:24:18:56:f7:27:58:d3:38:92:95:ed:
                    91:31:4a:23:69:d6:c9:6e:0f
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Subject Key Identifier:
                76:39:2A:41:99:ED:DE:C3:04:26:E4:0C:C6:F6:1A:AC:42:52:65:24
            X509v3 Authority Key Identifier:
                keyid:76:39:2A:41:99:ED:DE:C3:04:26:E4:0C:C6:F6:1A:AC:42:52:65:24

            X509v3 Basic Constraints:
                CA:TRUE
    Signature Algorithm: sha1WithRSAEncryption
         87:c5:43:12:bc:9a:c6:76:6d:10:87:6f:48:e5:0d:59:a2:8a:
         aa:48:d9:e1:21:84:59:57:8f:14:0c:6d:ad:d5:56:34:10:dc:
         a3:2e:f5:c8:98:46:07:30:74:56:81:82:93:06:df:45:da:6d:
         22:1f:1b:54:2d:43:43:6a:25:6b:cb:98:ff:ee:eb:99:e1:58:
         14:82:5e:3c:22:9b:80:2a:25:4b:a8:bd:39:f4:78:28:aa:7a:
         3c:b7:a0:c1:be:cd:f9:5a:91:40:a7:12:d1:25:3d:5f:5b:82:
         15:f7:88:8f:be:e7:33:5d:70:9e:8c:4c:cc:b2:79:19:b7:b7:
         6d:ce

Comment 10

[Dana Keeler (she/her) [:keeler]]

Thanks, Nick. I filed a bug on the apache documentation: https://issues.apache.org/bugzilla/show_bug.cgi?id=56346

Comment 12

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

IIRC, there was already another bug on file about us being too strict about checking the issuer-independent properties of self-signed certificates, but I cannot find it right now.

I think we should do the following:

1. For end-entity certificates, check the trust bits, then build the chain, then check the other issuer-independent properties. If we fail to build a chain to a trust anchor, then skip the issuer-independent checks and return SEC_ERROR_UNKNOWN_ISSUER.

2. For CA certificates, keep the current order of checks: trust bits, other issuer-independent properties, then build the chain.

It is important that we check issuer-independent properties before building the chain for CA certificates, because these cheap checks are used to prune bad paths ASAP during path building. However, this performance concern is not an issue for the end-entity certificate since it will never be pruned during path building.

The way that ERROR_UNTRUSTED and ERROR_TIME are calculated in SSLServerCertVerification should make this suggestion "just work."

Comment 13

[Dana Keeler (she/her) [:keeler]]

Attachment: patch

I think this implements what you suggest (not exactly as described, but I think it's equivalent).

Comment 14

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

Comment on attachment 8401625 [details] [diff] [review]
patch

Review of attachment 8401625 [details] [diff] [review]:
-----------------------------------------------------------------

Looks good.

I think we should add a new test case that tests this exact scenerio--self-signed certificate with isCA=true--separately, with a comment referencing this bug and the compatibility issue.

Also, the "ERROR RANKING" section of the documentation in pkix/pkix.h needs to be updated to reflect your changes.

::: security/manager/ssl/tests/unit/test_cert_trust.js
@@ +137,5 @@
>                                                   : SEC_ERROR_INADEQUATE_CERT_TYPE,
>                           certificateUsageObjectSigner);
>    check_cert_err_generic(ee_cert, useMozillaPKIX ? SEC_ERROR_CA_CERT_INVALID
>                                                   : 0,
>                           certificateUsageVerifyCA);

Please add a comment that in mozilla::pkix, but not NSS, cert chain properties are checked before the end-entity's properties are checked.

::: security/pkix/lib/pkixbuild.cpp
@@ +209,5 @@
>    rv = CheckIssuerIndependentProperties(trustDomain, subject, time,
>                                          endEntityOrCA,
>                                          requiredKeyUsagesIfPresent,
>                                          requiredEKUIfPresent, requiredPolicy,
>                                          subCACount, &trustLevel);

Please add a comment here. That comment might be as simple as "see the explanation of error prioritization in pkix.h".

@@ +251,5 @@
>                             requiredEKUIfPresent, requiredPolicy,
>                             n->cert, stapledOCSPResponse, subCACount,
>                             results);
>      if (rv == Success) {
> +      if (deferredEndEntityError != 0) {

I understand the original comment is no longer good, but I do think a little explanation here would be helpful.

Comment 15

[Nick Barrington]

(In reply to David Keeler (:keeler) from comment #10)
> Thanks, Nick. I filed a bug on the apache documentation:
> https://issues.apache.org/bugzilla/show_bug.cgi?id=56346

Cheers David, that's awesome :)  Your suggested change of adding -extensions usr_cert when generating the cert does the trick, but also great to see the compatibility patch will get traction.  Thanks!

Comment 16

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

(In reply to Brian Smith (:briansmith, was :bsmith; NEEDINFO? for response) from comment #14)
> I think we should add a new test case that tests this exact
> scenerio--self-signed certificate with isCA=true--separately, with a comment
> referencing this bug and the compatibility issue.

Note: this test case would probably be best as a case inside test_cert_overrides.js.

Comment 17

[Dana Keeler (she/her) [:keeler]]

Attachment: patch v2

Thanks for the review, Brian. Let me know if the comments I added are sufficient.

Comment 18

[Dana Keeler (she/her) [:keeler]]

Attachment: test

Here's the additional test you asked for.

Comment 19

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

Comment on attachment 8402060 [details] [diff] [review]
patch v2

Review of attachment 8402060 [details] [diff] [review]:
-----------------------------------------------------------------

::: security/manager/ssl/tests/unit/test_cert_trust.js
@@ +81,5 @@
>                           certificateUsageVerifyCA);
> +  // In mozilla::pkix (but not classic verification), certificate chain
> +  // properties are checked before the end-entity. Thus, if we're using
> +  // mozilla::pkix and the root certificate has been distrusted, the error
> +  // will be "untrusted issuer", and not "inadequate cert type" as usual.

nit: now that mozilla::pkix is the default, "as usual" should refer to the mozilla::pkix behavior. I suggest you reword this; at least drop "as usual."

@@ +145,5 @@
>                           certificateUsageVerifyCA);
> +  // In mozilla::pkix (but not classic verification), certificate chain
> +  // properties are checked before the end-entity. Thus, if we're using
> +  // mozilla::pkix and the root certificate has been distrusted, the error
> +  // will be "untrusted issuer", and not "inadequate cert type" as usual.

ditto.

Comment 20

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

Comment on attachment 8402061 [details] [diff] [review]
test

Review of attachment 8402061 [details] [diff] [review]:
-----------------------------------------------------------------

::: security/manager/ssl/tests/unit/test_cert_overrides.js
@@ +185,5 @@
> +
> +  // Bug 990603: Apache documentation has recommended generating a self-signed
> +  // test certificate with basic constraints: CA:true. For compatibility, this
> +  // is a scenario in which an override is allowed.
> +  add_cert_override_test("ca-as-server-cert.example.com",

It would be better to remove the cert name mismatch here, since cert name mismatch is not related to the issue.

::: security/manager/ssl/tests/unit/tlsserver/cmd/BadCertServer.cpp
@@ +40,5 @@
>    { "md5signature-expired.example.com", "md5signature-expired" },
>    { "mismatch-untrusted-expired.example.com", "mismatch-untrusted-expired" },
>    { "inadequatekeyusage.example.com", "inadequatekeyusage" },
>    { "selfsigned-inadequateEKU.example.com", "selfsigned-inadequateEKU" },
> +  { "ca-as-server-cert.example.com", "otherCA" },

The problem with using "otherCA" here is that it is confusing and will mislead us in the motivation for doing this in the first place.

It would be better to generate a new self-signed certificate with isCA=true and with subjectAltName dNSName=self-signed-end-entity-with-cA-true.example.com, and then connect to self-signed-end-entity-with-cA-true.example.com.

Comment 21

[Dana Keeler (she/her) [:keeler]]

Attachment: patch v2

Good call - I generated a separate cert for this test.

Comment 22

[Dana Keeler (she/her) [:keeler]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/17c67e825939
https://hg.mozilla.org/integration/mozilla-inbound/rev/9f6c65c78cad

Comment 23

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/17c67e825939
https://hg.mozilla.org/mozilla-central/rev/9f6c65c78cad

Comment 25

[Maximilian Lotz]

Not fixed in Stable?

Until i disable security.use_mozillapkix_verification FF produces high load when accessing a site with a Self-Signed Cert. After about half a minute the page loads but the process starts over again after browsing such a site for a while.

Encryption is tls_ecdhe_rsa_with_aes_128_gcm_sha256 in my case. Couldn't test other ciphers yet.

Comment 26

[Camilo Viecco (:cviecco)]

(In reply to Maximilian Lotz from comment #25)
> Not fixed in Stable?
> 
> Until i disable security.use_mozillapkix_verification FF produces high load
> when accessing a site with a Self-Signed Cert. After about half a minute the
> page loads but the process starts over again after browsing such a site for
> a while.
> 
> Encryption is tls_ecdhe_rsa_with_aes_128_gcm_sha256 in my case. Couldn't
> test other ciphers yet.

Maximilian, This does not seem like the same bug. Can you open a new one with the problematic url
or if not possible, the problematic cert and the apache/nginx configuration?

Comment 27

[Gus Heck]

I'm not sure, but this appears to be marked as something that would be fixed in the recent version 31 release of firefox? I recently restarted firefox and suddenly couldn't access my self signed tomcat on localhost:443 that I have been using for the last 11 months (cert has not expired yet). No option to add an exception is presented, and Preferences > Certificates > View Certificates shows I already have an exception stored for localhost:443, and if I try to add this again via the Add Exception button, the "Get Certificate" button appears to be a no-op and the "Confirm Security Exception" button and the store permanently checkbox never are enabled. 

guss-mbp:apache-tomcat-7.0.42 gus$ uname -a
Darwin guss-mbp.lan 13.2.0 Darwin Kernel Version 13.2.0: Thu Apr 17 23:03:13 PDT 2014; root:xnu-2422.100.13~1/RELEASE_X86_64 x86_64
guss-mbp:apache-tomcat-7.0.42 gus$ openssl 
OpenSSL> version
OpenSSL 1.0.1g 7 Apr 2014
OpenSSL> exit
guss-mbp:apache-tomcat-7.0.42 gus$  openssl s_client -connect localhost:443 
<snip cert etc>
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES256-SHA384
    Session-ID: 53DAB1160BF7C8D967F16D8DEE06E0C84DC978DC160D3741AE73395C7E6AF93B
    Session-ID-ctx: 
    Master-Key: 85A5D0B33C4C53C8AB6E6266E08936F2933B65C510C01F461ED8E8334702C594A01F67C10C3883380193F5902ED194BB
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1406841110
    Timeout   : 300 (sec)
    Verify return code: 19 (self signed certificate in certificate chain)


Since functionality degraded without any changes on my part for a common use case (developer using self signed cert on local machine), I'm guessing that this degradation would be a bug. I'm not sure if it's this bug, or a new one. If there's

Comment 28

[Gus Heck]

(sorry for the accidental submit) ...a better issue, or documentation for the workaround that I've missed, my apologies. I don't see it discussed in any of these:

https://www.mozilla.org/en-US/firefox/31.0/releasenotes/
https://blog.mozilla.org/security/2014/04/24/exciting-updates-to-certificate-verification-in-gecko/
https://wiki.mozilla.org/SecurityEngineering/mozpkix-testing#Behavior_Changes

Comment 29

[Dana Keeler (she/her) [:keeler]]

Gus, that is probably a similar issue with a different root cause. Please file a new bug in this component with a copy of the public part of your certificate. Thanks.

Comment 30

[Gus Heck]

I just noticed that the link in comment 6 displays different behavior... for that I get an option to add an exception. So yeah, new bug.