Closed Bug 990557 Opened 7 years ago Closed 7 years ago
Test failure "[object Object] - got 'false' " in test
Security/test MD5Hash Signature .js
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.
Prepared skip patch, I can reproduce this on OS X. I'll attach the screenshot too, we're unable to verify the site.
Assignee: nobody → andreea.matei
Status: NEW → ASSIGNED
Attachment #8399969 - Flags: review?(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 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)
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?
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.
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).
I would ask Brian Smith about the correct handling for our tests.
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
See Also: → 991177
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?
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.
Brandon, can you please check comment 12? I hope it is something IT can fix quickly? Thanks
(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.
(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.
(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.
No longer blocks: mozilla::pkix
So IT created those certificates for us. We should at least check our internal domains in use, if some of those are affected then.
(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
(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.
This should do it.
Bug 992753 fixed the certificate. I backed out the skip patch: http://hg.mozilla.org/qa/mozmill-tests/rev/fc3679b51b82 (default)
You need to log in before you can comment on or make changes to this bug.