990557 - Test failure "[object Object] - got 'false' " in testSecurity/testMD5HashSignature.js

Status: RESOLVED FIXED

(Mozilla QA Graveyard :: Mozmill Tests, defect, P1)

Description

[Andreea Matei [:AndreeaMatei]]

Failed several times today, mostly on OS X but also twice on Linux.

The failure happens here:
http://hg.mozilla.org/qa/mozmill-tests/file/default/firefox/tests/remote/testSecurity/testMD5HashSignature.js#l50

And related to modal dialog:
http://hg.mozilla.org/qa/mozmill-tests/file/default/firefox/lib/modal-dialog.js#l207

I didn't reproduce it so far, will investigate it further.

Comment 1

[Andreea Matei [:AndreeaMatei]]

Attachment: skip patch

Prepared skip patch, I can reproduce this on OS X. I'll attach the screenshot too, we're unable to verify the site.

Comment 2

[Andreea Matei [:AndreeaMatei]]

Attachment: Screen Shot

Comment 3

[Andrei Eftimie]

Comment on attachment 8399969 [details] [diff] [review]
skip patch

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

Please update this as it doesn't apply cleanly (probably because I recently unskipped bug 936478 on default)

Comment 4

[Andreea Matei [:AndreeaMatei]]

Attachment: skip patch

Updated it.

Comment 5

[Andrei Eftimie]

Comment on attachment 8399974 [details] [diff] [review]
skip patch

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

Disabled:
http://hg.mozilla.org/qa/mozmill-tests/rev/2221acc897c4 (default)

Comment 6

[Henrik Skupin [:whimboo][⌚️UTC+2]]

We have seen a couple of security test related failures today. I wonder if there is a regression in Firefox or if we have a network issue. Have you checked those things?

Comment 7

[Andreea Matei [:AndreeaMatei]]

This is the responsible merge and the correspondent bug 990248.
http://hg.mozilla.org/mozilla-central/rev/b82acf758624

I have used tinderbox builds, found first bad build, set the preference false in our test and this way it passes.
Still looking through the bug to understand what the changes do.

Comment 8

[Andreea Matei [:AndreeaMatei]]

Here's the actual tracking bug and explanation for the changes:
https://bugzilla.mozilla.org/show_bug.cgi?id=989516#c0

So from what I understand it's a temporary fix, we can have the pref set in our test and watch the main bug for when the situation with Go Daddy is fixed (in bug 988633).

Comment 9

[Henrik Skupin [:whimboo][⌚️UTC+2]]

I would ask Brian Smith about the correct handling for our tests.

Comment 10

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

The CA certificate that signs for the server's certificate needs to have a basic constraints extension (the server's certificate should have one, too). This is probably what's breaking all of these tests (assuming that CA is being reused), but please file bugs on any other such issues you find, and have them block bug 915930.

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 0 (0x0)
    Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=US, ST=California, L=Mountain View, O=Mozilla, CN=Mozilla QA
        Validity
            Not Before: Jan 12 03:48:25 2013 GMT
            Not After : Apr 12 03:48:25 2021 GMT
        Subject: C=US, ST=California, L=Mountain View, O=Mozilla, CN=Mozilla QA
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (1024 bit)
                Modulus:
                    00:c9:33:4e:90:6b:a1:bf:a9:17:90:46:b8:2e:be:
                    ae:e3:cd:5d:de:a9:38:f3:ff:0e:6d:22:4c:3a:0e:
                    57:a3:56:b8:ad:08:52:d9:1e:62:fe:95:6f:79:38:
                    36:c1:d1:ac:2a:cc:c0:20:23:98:bb:8b:50:45:10:
                    6e:35:94:8f:5c:37:56:51:68:0b:4e:6f:ee:cc:54:
                    13:e9:7d:92:e7:f1:6f:fa:82:5a:86:3c:ad:41:1c:
                    c6:a3:38:f7:a5:f8:19:a6:82:22:e8:55:89:2e:8d:
                    ec:1e:12:37:ab:86:c7:24:fa:30:b4:3e:09:6c:9d:
                    9b:4f:1e:e1:a6:39:41:98:e7
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            Netscape Cert Type: 
                SSL CA
    Signature Algorithm: sha1WithRSAEncryption
         84:4b:67:04:95:6f:c2:5e:ea:3f:c9:57:7b:33:c2:c8:ad:d1:
         49:45:b4:df:2a:a7:9a:74:d9:73:99:28:5c:8e:94:b5:14:05:
         12:5c:5b:e3:70:bc:aa:85:db:9d:70:75:ea:6f:02:0f:e2:6e:
         d6:71:3f:af:ec:ea:90:94:df:1b:a1:63:d3:02:3e:fa:80:0c:
         a0:b6:ac:37:a2:63:a4:03:93:fc:57:1b:d7:e4:db:98:e0:d5:
         cb:09:b7:20:be:32:5d:5a:f0:dd:cf:c3:b1:67:16:4e:67:e8:
         c1:09:9f:58:e4:74:b7:4a:df:47:b4:d3:a5:59:2e:1e:65:54:
         62:c7

Comment 11

[Henrik Skupin [:whimboo][⌚️UTC+2]]

David, not sure which subdomain of mozqa.com you were checking but when I open https://ssl-md5.mozqa.com/ I can see the following error:

Error code: sec_error_cert_signature_algorithm_disabled

Does it mean that for this test we fail because MD5 (PKCS #1 MD5 With RSA Encryption) is disabled?

Comment 12

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

MD5 has been disabled for a long time - I believe this test makes sure that certificate error overrides work as expected. The issue is that Firefox 31 has a new certificate verification library that is more strict than the classic verifier. So, when visiting that site with the new verifier enabled (with the pref security.use_mozillapkix_verification=true), it sees that the certificate that issued the server's certificate does not have a basic constraints extension and thus will not allow it to be trusted to issue certificates. This causes the verification to fail in a way that is not overridable. Because we don't want to allow certificates without a basic constraints extension to issue certificates in general, I think the right thing to do here is to re-generate the issuer certificate for this test with the appropriate extensions.

Comment 13

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Brandon, can you please check comment 12? I hope it is something IT can fix quickly? Thanks

Comment 14

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

(In reply to David Keeler (:keeler) from comment #10)
> The CA certificate that signs for the server's certificate needs to have a
> basic constraints extension (the server's certificate should have one, too).

The server's certificate doesn't need a basic constraint extension and in fact probably shouldn't since having no extension is more efficient. But, you are right that the CA cert needs to have the basic constraints extension with cA=true.

>         X509v3 extensions:
>             Netscape Cert Type: 
>                 SSL CA

The old, NSS-based, validation logic supports the obsolete and proprietary Netscape Cert Type extension. mozilla::pkix intentionally doesn't. David's suggestion of re-generating the certificates seems like the correct fix to me. Also, I don't think this should block bug 915930; we wouldn't revert bug 915930 because of this, since it seems to be a problem in the test suite, and not a problem in Gecko or Firefox.

Comment 15

[Henrik Skupin [:whimboo][⌚️UTC+2]]

(In reply to Brian Smith (:briansmith, was :bsmith; NEEDINFO? for response) from comment #14)
> me. Also, I don't think this should block bug 915930; we wouldn't revert bug
> 915930 because of this, since it seems to be a problem in the test suite,
> and not a problem in Gecko or Firefox.

It wasn't meant that way. Feel free to remove. I wonder if we should have a tracking bug for websites which are broken because of this change. This bug would fall under this bucket.

Comment 16

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

(In reply to Henrik Skupin (:whimboo) from comment #15)
> I wonder if we should have a tracking bug for websites which
> are broken because of this change. This bug would fall under
> this bucket.

It is unlikely that (m)any real-world websites are affected by us dropping support for the netscape cert type extension, because it was proprietary to Netscape/Mozilla-based products. MSIE and other browsers never implemented support for it, for example. Also, we've done some scans of popular websites and not found any incompatibilities that can be traced back to this particular change.

Comment 17

[Henrik Skupin [:whimboo][⌚️UTC+2]]

So IT created those certificates for us. We should at least check our internal domains in use, if some of those are affected then.

Comment 18

[Brandon Burton [:solarce]]

(In reply to Henrik Skupin (:whimboo) from comment #17)
> So IT created those certificates for us. We should at least check our
> internal domains in use, if some of those are affected then.

For help from webops, you need to file a bug in https://bugzilla.mozilla.org/enter_bug.cgi?product=Infrastructure%20%26%20Operations&component=WebOps%3A%20Other to track the webops specific request

In this particular case, please include what options should be used to generate the new CA certificate, like how options were provided in https://bugzilla.mozilla.org/show_bug.cgi?id=804952#c10

Thanks

Comment 19

[Henrik Skupin [:whimboo][⌚️UTC+2]]

(In reply to Brandon Burton [:solarce] from comment #18)
> In this particular case, please include what options should be used to
> generate the new CA certificate, like how options were provided in
> https://bugzilla.mozilla.org/show_bug.cgi?id=804952#c10

David, can you please have a look? Once we got that information I will file the webops bug.

Comment 20

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

Attachment: generate_certs.sh

This should do it.

Comment 21

[Andreea Matei [:AndreeaMatei]]

Bug 992753 fixed the certificate. I backed out the skip patch:
http://hg.mozilla.org/qa/mozmill-tests/rev/fc3679b51b82 (default)