1030453 - mozmill test /testSecurity/testMD5HashSignature.js needs to import the CA certificate differently when bug 1024871 lands

Status: RESOLVED WONTFIX

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

Description

[Dana Keeler (she/her) (use needinfo) [:keeler] (on leave)]

My understanding is that the mozmill test /testSecurity/testMD5HashSignature.js (and maybe others) imports a CA certificate by visiting http://mozqa.com/data/firefox/security/certificates/md5/importSSL.php and using the UI that automatically pops up as a result. Bug 1024871 is removing this functionality because it's unsafe. Luckily, there are other options for adding a new CA. One is to use the certificate manager UI (Preferences -> Advanced -> Certificates -> View Certificates). Another option would be to use the certutil command line utility to modify the certificate database before actually running any tests. Yet another option would be to use nsIX509CertDB from JS.

Comment 1

[Dana Keeler (she/her) (use needinfo) [:keeler] (on leave)]

For an example of how this breaks the test, see bug 1028178 where we did this by accident.

Comment 2

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

Thanks David for keeping us informed! I kinda like doing this via nsIX509CertDB then. The UI path can be fragile and should not be tested in this specific test. Also preparing a profile with that cert added is not possible at the moment.

So I assume we can already do this change before bug 1024871 gets fixed? That way we will have a smooth transition over.

Comment 3

[Dana Keeler (she/her) (use needinfo) [:keeler] (on leave)]

Yes, this can change before bug 1024871 lands. I don't really know how mozmill works, but in privileged code, something like this needs to happen:

let certDER = <somehow get the DER encoding of the certificate in question>;
let certDB = Cc["@mozilla.org/security/x509certdb;1"].getService(Ci.nsIX509CertDB);
certDB.addCert(certDER, "CTu,,", "Moz QA CA");

(The "CTu,," argument trusts the certificate as an SSL CA and as far as I know the third argument is actually ignored, so it doesn't matter what it is.)
Let me know how that goes - this code can be picky and difficult to work with.

Comment 4

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

(In reply to David Keeler (:keeler) [use needinfo?] from comment #3)
> let certDER = <somehow get the DER encoding of the certificate in question>;

So given that you are not sure how to retrieve this information, do you know someone we could ask? I assume there is no interface/service available to retrieve that kind of data?

Comment 5

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

(In reply to Henrik Skupin (:whimboo) from comment #4)
> (In reply to David Keeler (:keeler) [use needinfo?] from comment #3)
> > let certDER = <somehow get the DER encoding of the certificate in question>;
> 
> So given that you are not sure how to retrieve this information, do you know
> someone we could ask? I assume there is no interface/service available to
> retrieve that kind of data?

CC'ing Kai. Maybe he knows something.

Comment 6

[Dana Keeler (she/her) (use needinfo) [:keeler] (on leave)]

Well, there's a couple of ways to go. If I understand correctly, the certificate to import is hosted at
http://mozqa.com/data/firefox/security/certificates/md5/ssl-md5-mozqa-ca.pem
One option would be to copy that and include it in the test. This would break if it ever gets updated. The other option is to do an XHR to get that file and then use nsIX509CertDB2.addCertFromBase64. You might have to strip off the leading/trailing -----BEGIN CERTIFICATE-----/-----END CERTIFICATE----- and remove line breaks first.

Comment 7

[Dana Keeler (she/her) (use needinfo) [:keeler] (on leave)]

(Although, if you do use nsIX509CertDB2, keep an eye on bug 643041, which will merge that interface into nsIX509CertDB.)

Comment 8

[Kai Engert (:KaiE:)]

If your input is a raw file, David's suggestion looks good.

Comment 9

[Sylvestre Ledru [:Sylvestre]]

Mozmill is dead, WONTFIX the remaining bugs.