Last Comment Bug 683261 - Better coverage for DigiNotarGate in NSS
: Better coverage for DigiNotarGate in NSS
Status: VERIFIED FIXED
[qa+]
: verified-beta, verified1.9.2
Product: NSS
Classification: Components
Component: Libraries (show other bugs)
: 3.12.11
: All All
: -- normal with 1 vote (vote)
: ---
Assigned To: Kai Engert (:kaie)
:
Mentors:
Depends on: 682927
Blocks: 683455
  Show dependency treegraph
 
Reported: 2011-08-30 12:35 PDT by Kai Engert (:kaie)
Modified: 2011-10-24 16:38 PDT (History)
33 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
.2-fixed
fixed
fixed
fixed
.22-fixed


Attachments
zip file - collection of certs (19.04 KB, application/octet-stream)
2011-08-31 08:13 PDT, Kai Engert (:kaie)
no flags Details
patch for NSS 3.12.x and stable mozilla branches (54.83 KB, patch)
2011-08-31 08:28 PDT, Kai Engert (:kaie)
no flags Details | Diff | Review
patch for NSS 3.13 and mozilla-central (54.68 KB, patch)
2011-08-31 09:34 PDT, Kai Engert (:kaie)
no flags Details | Diff | Review
patch v2 for NSS 3.13 and mozilla-central (63.10 KB, patch)
2011-08-31 09:46 PDT, Kai Engert (:kaie)
no flags Details | Diff | Review
Verizon cross-certificates (4.44 KB, application/octet-stream)
2011-08-31 12:06 PDT, Steven Medin
no flags Details
Patch v3 for NSS 3.12.x and stable mozilla branches - MUST RUN "gmake generate" AFTER APPLYING PATCH (31.04 KB, patch)
2011-08-31 14:02 PDT, Kai Engert (:kaie)
rrelyea: review+
Details | Diff | Review
zip file, collection of certs used for patch v3 (35.33 KB, application/octet-stream)
2011-08-31 14:06 PDT, Kai Engert (:kaie)
no flags Details
Patch v3 for NSS 3.13 and mozilla-central - MUST RUN "gmake generate" AFTER APPLYING PATCH (30.95 KB, patch)
2011-09-01 04:28 PDT, Kai Engert (:kaie)
no flags Details | Diff | Review
zip file - overheid intermediates (20.11 KB, application/octet-stream)
2011-09-01 18:06 PDT, Kai Engert (:kaie)
no flags Details
additional patch v4 - for NSS 3.12.x and stable mozilla branches - MUST RUN "gmake generate" AFTER APPLYING PATCH (17.85 KB, patch)
2011-09-01 18:08 PDT, Kai Engert (:kaie)
rrelyea: review+
Details | Diff | Review
patch v4 for mozilla-central and NSS 3.13 - MUST RUN "gmake generate" (17.79 KB, patch)
2011-09-02 11:54 PDT, Kai Engert (:kaie)
no flags Details | Diff | Review

Description Kai Engert (:kaie) 2011-08-30 12:35:23 PDT

    
Comment 1 Kai Engert (:kaie) 2011-08-30 12:36:39 PDT
This is a follow-up to 682927.

Let's use this bug to add overriding blocker certs to NSS.
Comment 2 Kai Engert (:kaie) 2011-08-30 12:46:51 PDT
Please see bug 682927 comment 82 to 84 for the initial TODO list for this one.

I can do the testing that Bob suggested in comment 84, but I'm quite exhausted already for today.

Also, Bob suggested that we should include two additional intermediate certs.
This means,
I propose we do a
  NSS_BUILTINS_LIBRARY_VERSION "1.85"

that overrides (at least) three certs - the root, and two intermediates.

Also, the blocker cert that I had added to bug 683261 might be insufficient.
Bob suggested I must make that one "newer" than all intermediates we want to override.
Haven't checked that yet.

Also, regarding serial numbers, I probably must keep track of the serial numbers we use for the blocker certs, and avoid duplicates.

For the root blocker cert I had used 0x0fffffffffffffff as the serial number.
Comment 5 Kai Engert (:kaie) 2011-08-30 13:20:41 PDT
Hold on. Updated information. Let me rework comment 2 and comment 3.
Comment 6 Kai Engert (:kaie) 2011-08-30 13:22:40 PDT
i2

Issuer: C=US, O=Entrust.net, OU=www.entrust.net/CPS incorp. by ref. (limits liab.), OU=(c) 1999 Entrust.net Limited, CN=Entrust.net Secure Server Certification Authority
Validity
  Not Before: Jul 26 15:59:00 2007 GMT
  Not After : Aug 26 16:29:00 2013 GMT
Subject: C=NL, O=DigiNotar, CN=DigiNotar Services 1024 CA/emailAddress=info@diginotar.nl


i3

Issuer: C=US, O=GTE Corporation, OU=GTE CyberTrust Solutions, Inc., CN=GTE CyberTrust Global Root
Validity
  Not Before: Oct  4 10:54:11 2006 GMT
  Not After : Oct  4 10:53:11 2011 GMT
Subject: C=NL, O=DigiNotar, CN=DigiNotar Cyber CA/emailAddress=info@diginotar.nl
Comment 7 Kai Engert (:kaie) 2011-08-30 13:23:16 PDT
marking comments 3 and 4 as private, to reduce confusion.
Comment 8 Kai Engert (:kaie) 2011-08-30 13:24:54 PDT
(a) + (b)
Which serial numbers should I use for the blocker certs?

Is it necessary to ask Entrust and GTE Corporation to assign a serial number for us, so we don't have collisions with other valid Entrust/GTE certs?


(c)
Bob, you're saying, the blocker cert for the "DigiNotar Root CA" should have a "Not Before" that's in the future of both i2 and i3 ?
Comment 9 Wan-Teh Chang 2011-08-30 13:28:03 PDT
Kai: using 0x0fffffffffffffff, 0x0ffffffffffffffe,
0x0ffffffffffffffd, etc. as serial numbers should
be unlikely to conflict with serial numbers of real
certificates.
Comment 10 Wan-Teh Chang 2011-08-30 17:20:05 PDT
Kai: in certdata.txt, you added
  "Explicity Disable DigiNotar Root CA"

Please change the first two words to "Explicitly Distrusted".
Note that "Explicitly" was misspelled.
Comment 11 Kai Engert (:kaie) 2011-08-31 03:20:38 PDT
We may want to do 683455 as part of this bug.
I plan to block multiple certificates at the NSS level.

Note, this approach ensures the basic (potentially overridable) blocking is "at least complete".

By "at least complete" I mean, it includes all of SSL, S/MIME, code signing.
The patch for PSM that we did yesterday covers SSL, only.

Because yesterday we also removed trust for the root, this also covers parts of S/MIME and code signing, but only those chains that use the root.

Because of the cross signing from other CAs, yesterday's solution was not complete.
Comment 12 Kai Engert (:kaie) 2011-08-31 08:13:16 PDT
Created attachment 557179 [details]
zip file - collection of certs

This is a collection of zip files that I have created.

It includes 3 certs - but it covers 5 certs.

For each of the original 3 certs, it also includes an override cert, which I have manually edited, to use a new serial number and have special validity.
Comment 13 Kai Engert (:kaie) 2011-08-31 08:19:03 PDT
addbuiltin -n "Explicitly Distrust DigiNotar Root CA" -t ,, < ~/moz/nss/head/diginotar/im/Root-DigiNotarRootCA-override.der  >> certdata.txt

addbuiltin -n "Explicitly Distrust DigiNotar Services 1024 CA" -t ,, < ~/moz/nss/head/diginotar/im/A-override-DigiNotarServices1024CA.der  >> certdata.txt

addbuiltin -n "Explicitly Distrust DigiNotar Cyber CA" -t ,, < ~/moz/nss/head/diginotar/im/B-override-real-cyberca.der  >> certdata.txt
Comment 14 Kai Engert (:kaie) 2011-08-31 08:28:03 PDT
Created attachment 557183 [details] [diff] [review]
patch for NSS 3.12.x and stable mozilla branches

not yet tested. I will test it in approx. 1 to 1.5 hours.
Comment 15 Gervase Markham [:gerv] 2011-08-31 08:33:51 PDT
Kai: can we open this bug, now the others are open?

Gerv
Comment 16 Kai Engert (:kaie) 2011-08-31 09:31:08 PDT
(In reply to Gervase Markham [:gerv] from comment #15)
> Kai: can we open this bug, now the others are open?

fine with me
Comment 17 Kai Engert (:kaie) 2011-08-31 09:34:33 PDT
Created attachment 557212 [details] [diff] [review]
patch for NSS 3.13 and mozilla-central
Comment 18 Kai Engert (:kaie) 2011-08-31 09:46:55 PDT
Created attachment 557219 [details] [diff] [review]
patch v2 for NSS 3.13 and mozilla-central

(branch patch is good - updating bad trunk patch)
Comment 19 Robert Relyea 2011-08-31 10:20:01 PDT
Kai, The DigiNotar Root interference cert needs a different issuance date: I needs to ble later than Jul 26, 2007, or more specifically later than "070726155739Z" (Thu Jul 26 15:57:39 2007) so 070726155740Z would be sufficient.

bob
Comment 20 Robert Relyea 2011-08-31 10:36:39 PDT
Never mind, I was looking at the original root cert, not the interference/override cert. The override cert looks good! I'll go review the patches now...

bob
Comment 21 Kai Engert (:kaie) 2011-08-31 11:52:57 PDT
FYI, update:

During testing, we learned that these override certs cause blocking - but too much blocking - it's no longer possible to override certs.

We understand you're not happy with this. We understand, you want that we still have overridable soft-blocking.

Because of this, Genius Bob Relyea came up with another idea. He does additional manipulation to the intermediate certs - causing them to look like self signed certs.

Bob just gave me the first cert - and it works.

What does this mean?

- we'll shortly have a new patch

- Bob must do some tricky binary editing, calculating, shortening/extended file sizes, and adjusting encoding lengths in multiple layers

- Bob will have to do this tricky work for each of the additional intermediates that need to be blocked
Comment 22 Steven Medin 2011-08-31 12:06:55 PDT
Created attachment 557270 [details]
Verizon cross-certificates

Per Kathleen's request, I attach a zip containing three cross certificates issued under the GTE CyberTrust Global Root presently managed by Verizon.  Within the next hour, we will revoke these cross certificates and post a new CRL.

These cross certificates were provided under contract to DigiNotar to provide legacy browser support as DigiNotar's root gained its own independent ubiquity.  One of these cross certificates has life until September of 2013, and two will expire within weeks.

While DigiNotar no longer distributes these cross certificates, they once did and therefore these are to be considered easily accessible as a method of bypassing revocation and blacklisting of the DigiNotar root.  We have researched and concluded that these alternate paths to unauthorized trust would perpetuate the issues that led to the actions of the past two days and are a threat to the trust of our GTE CyberTrust Global Root PKI and therefore must be revoked.
Comment 23 Kai Engert (:kaie) 2011-08-31 12:25:08 PDT
Ok. We already had the 100406 certs in our list (it's contained in my earlier zip file, named B-real-cyberca.der

We will add the additional two roots - 092006 and 092706

It would be nice if we could have test sites for all 3 certs.
(If you don't want to mention them in the public, please send them to me by private email, and I'll keep the lists confidential amongst testers.)
Comment 24 Steven Medin 2011-08-31 12:39:15 PDT
Test EE cert information and chains on operational servers would need to come from DigiNotar.  It is possible that DigiNotar do not currently operate any test sites that chain through these any longer.  Our cross certificates are not documented at their PKI hierarchy page, http://www.diginotar.nl/Klantenservice/Rootcertificaten/tabid/308/Default.aspx.  We are also absent at their history page as well, where one of our peers does appear.
Comment 25 Kai Engert (:kaie) 2011-08-31 13:31:47 PDT
Bob is away for a couple of hours, so I'm trying to do it myself.
Looking at what Bob did in detail, I am able to repeat the procedure for the additional two certs. I already succeded with the first, now doing the second one, so I should have a new patch within 30 minutes.
Comment 26 Steven Medin 2011-08-31 13:52:38 PDT
CRL reflecting revocations posted to proper CRL DP referenced within the certificates, at:

http://www.public-trust.com/cgi-bin/CRL/2018/cdp.crl
Comment 27 Kai Engert (:kaie) 2011-08-31 13:56:14 PDT
The certs with serial numbers 092006 and 092706 have the same subject name.
We can used a single special cert that overrides both.
Comment 28 Kai Engert (:kaie) 2011-08-31 14:02:06 PDT
Created attachment 557313 [details] [diff] [review]
Patch v3 for NSS 3.12.x and stable mozilla branches - MUST RUN "gmake generate" AFTER APPLYING PATCH
Comment 29 Kai Engert (:kaie) 2011-08-31 14:06:59 PDT
Created attachment 557315 [details]
zip file, collection of certs used for patch v3
Comment 30 Kai Engert (:kaie) 2011-08-31 14:11:34 PDT
Bob, the "Root" cert is the "DigiNotar Root CA", we had that already.

The A and B certs are the one that you had created.
(B is one of the additional 3 certs from Verizon)

E and F are the two additional certs from Verizon.
Inside the zip file, you'll find E and F certs in the directory "invididual-E-F".

I had manually tweaked both certs, in the same way you did.
When you reminded me that one cert will be sufficient, because E and F have the same subject, I created the combined EF file.

The EF files uses the newest NotBefore + 1 second, and the newest NotAfter + 1 second.
Comment 31 Kai Engert (:kaie) 2011-08-31 14:23:59 PDT
I built mozilla-beta using this patch.

Testing I have performed:

(root)
Visiting
  https://www.evssl.nl
which chains up to DigiNotar Root CA,
I get "untrusted", and I am still able to add an override.

This proofs, our blocker cert for the root doesn't disable the override capability.


(intermediates)
Visiting
  https://www.csnad.nl/
which chains up to DigiNotar Services 1024 CA.
I get "untrusted", and I'm still able to add an override.

This proofs, our blocker certs for the intermediates don't disable the override capability.
Comment 32 Robert Relyea 2011-08-31 15:02:43 PDT
Comment on attachment 557313 [details] [diff] [review]
Patch v3 for NSS 3.12.x and stable mozilla branches - MUST RUN "gmake generate" AFTER APPLYING PATCH

r+   These binary blobs look correct... (bob looking cross-eyed trying to decode Ascii date codes in octal blobs;).
Comment 33 Kai Engert (:kaie) 2011-08-31 15:53:58 PDT
Thanks for the review.
It's very late already at my place, so I will check this in to the stable branch of NSS only, for now.
(I will work on the slightly different patch for NSS trunk tomorrow.)

Checking in certdata.c;
/cvsroot/mozilla/security/nss/lib/ckfw/builtins/certdata.c,v  <--  certdata.c
new revision: 1.67.2.12; previous revision: 1.67.2.11
done
Checking in certdata.txt;
/cvsroot/mozilla/security/nss/lib/ckfw/builtins/certdata.txt,v  <--  certdata.txt
new revision: 1.64.2.12; previous revision: 1.64.2.11
done
Checking in nssckbi.h;
/cvsroot/mozilla/security/nss/lib/ckfw/builtins/nssckbi.h,v  <--  nssckbi.h
new revision: 1.24.2.7; previous revision: 1.24.2.6
Comment 34 Kai Engert (:kaie) 2011-08-31 15:56:00 PDT
I've tagged the roots module directory as NSSCKBI_1_86_RTM
Comment 35 Kai Engert (:kaie) 2011-09-01 04:28:04 PDT
Created attachment 557458 [details] [diff] [review]
Patch v3 for NSS 3.13 and mozilla-central - MUST RUN "gmake generate" AFTER APPLYING PATCH

(In reply to Kai Engert (:kaie) from comment #33)
> It's very late already at my place, so I will check this in to the stable
> branch of NSS only, for now.
> (I will work on the slightly different patch for NSS trunk tomorrow.)

This is the equivalent for the truink.
I've already checked it in:

Checking in certdata.c;
/cvsroot/mozilla/security/nss/lib/ckfw/builtins/certdata.c,v  <--  certdata.c
new revision: 1.81; previous revision: 1.80
done
Checking in certdata.txt;
/cvsroot/mozilla/security/nss/lib/ckfw/builtins/certdata.txt,v  <--  certdata.txt
new revision: 1.78; previous revision: 1.77
done
Checking in nssckbi.h;
/cvsroot/mozilla/security/nss/lib/ckfw/builtins/nssckbi.h,v  <--  nssckbi.h
new revision: 1.31; previous revision: 1.30
done
Comment 36 Gervase Markham [:gerv] 2011-09-01 07:32:58 PDT
If we make a further update to this, it would be clearer if the certificate names were of the form:

"Explicitly Distrusted DigiNotar Root CA"

rather than

"Explicitly Distrust DigiNotar Root CA"

The latter is a statement of intent, not a name for something. The former is a name of a certificate.

Gerv
Comment 37 Kai Engert (:kaie) 2011-09-01 18:06:45 PDT
Created attachment 557727 [details]
zip file - overheid intermediates
Comment 38 Kai Engert (:kaie) 2011-09-01 18:08:39 PDT
Created attachment 557729 [details] [diff] [review]
additional patch v4 - for NSS 3.12.x and stable mozilla branches - MUST RUN "gmake generate" AFTER APPLYING PATCH

I don't know if this will be needed.
I'm just doing this in order to be prepared - you never know!
I'm asking for a code review.
Will not be checked in unless requested by Mozilla
Comment 39 Robert Relyea 2011-09-01 18:27:58 PDT
Comment on attachment 557729 [details] [diff] [review]
additional patch v4 - for NSS 3.12.x and stable mozilla branches - MUST RUN "gmake generate" AFTER APPLYING PATCH

r+ This patch removes trust for the PKIoverheid DigiNotar certs. 

I leave it to mozilla policy people to thumbs up or down on applying this patch, but I've verified it's technically correct. It is applied on top of the v3 patch, not in liu of it.

bob
Comment 40 Gervase Markham [:gerv] 2011-09-02 02:47:30 PDT
Due to the kindness of another CA, I have copies of certs for most DigiNotar chains, and clues as to where to find them. We also have the big list we were using to warn people. The following are live at the time of writing:

Staat der Nederlanden Root CA - G2 via Diginotar PKIOverheid CA Organisatie - G2: 
  https://belastingbalie.eindhoven.nl/ (Issued: 4th Feb 2011)

Staat der Nederlanden Root CA via Diginotar PKIoverheid CA Overheid en Bedrijven:
  https://www.nifpnet.nl/ (Issued 12th May 2011)

GTE CyberTrust Global Root via DigiNotar Cyber CA:
  https://sbc.lodder.com (Issued 27th July 2007)
  (Note: expired 27th July 2011)

Entrust Secure Server Certification Authority via DigiNotar Services 1024 CA:
  https://www.aacweb.nl/ (Issued 23rd April 2008)
  https://acceptation.cbpublications.ingcommercialbanking.com/

DigiNotar Root CA via DigiNotar Services CA:
  https://toegang.eindhoven.nl/ (Issued 25th May 2011)

DigiNotar Root CA via DigiNotar Extended Validation CA:
  https://yob.goestenopdam.nl/ (Issued 13th July 2011)

That last one should be good for testing date-based behaviour.

Gerv
Comment 41 Mike Hommey [:glandium] 2011-09-02 05:08:08 PDT
Do we have DigiNotar Public CA 2025 somewhere?
Comment 42 Gervase Markham [:gerv] 2011-09-02 05:16:04 PDT
Mike: I have the following info:

DigiNotar Public CA 2025
Serial Number: 1E7D 7A53 3D45 3041 9640 OF71 481F 4504
Validity: Feb 6, 2006 18:07:02 - March 28, 2025 18:07:02
Certificate Fingerprint: 3F01 8E6F E336 096A 791B 81E7 69BE 701A AF21 E307
Intended use: email and personal certificates.

But I don't think I have a copy of the complete cert.

Gerv
Comment 43 Kaspar Brand 2011-09-02 06:18:29 PDT
(In reply to Mike Hommey [:glandium] from comment #41)
> Do we have DigiNotar Public CA 2025 somewhere?

You can retrieve it from here:

http://www.diginotar.nl/LinkClick.aspx?fileticket=lSCwDq6q038%3d&tabid=308
Comment 44 Kai Engert (:kaie) 2011-09-02 06:51:24 PDT
I've tested my local mozilla-beta build, with
  Bug 683883 (attachment 557592 [details] [diff] [review]) (patch v4 from that bug)
  this bug patch v3 (attachment 557313 [details] [diff] [review])

> Staat der Nederlanden Root CA - G2 via Diginotar PKIOverheid CA Organisatie - G2: 
>  https://belastingbalie.eindhoven.nl/ (Issued: 4th Feb 2011)
> Staat der Nederlanden Root CA via Diginotar PKIoverheid CA Overheid en Bedrijven:
>   https://www.nifpnet.nl/ (Issued 12th May 2011)

both are allowed


>GTE CyberTrust Global Root via DigiNotar Cyber CA:
>  https://sbc.lodder.com (Issued 27th July 2007)
>  (Note: expired 27th July 2011)
>
>Entrust Secure Server Certification Authority via DigiNotar Services 1024 CA:
>  https://www.aacweb.nl/ (Issued 23rd April 2008)
>  https://acceptation.cbpublications.ingcommercialbanking.com/
>
>DigiNotar Root CA via DigiNotar Services CA:
>  https://toegang.eindhoven.nl/ (Issued 25th May 2011)

All 4 sites are treated as "untrusted" with a cert error page.
I open the "add override" dialog, and looked at the chain.
All certs chain up to one of our kock-out certs (detectable, because those certs have a serial numbers like 0x*FFFFFFF

I am able to add overrides for all these certs.


>DigiNotar Root CA via DigiNotar Extended Validation CA:
>  https://yob.goestenopdam.nl/ (Issued 13th July 2011)

I get "cert is revoked", no override possible.
Comment 45 Kai Engert (:kaie) 2011-09-02 06:53:25 PDT
> DigiNotar Public CA 2025 somewhere?
> http://www.diginotar.nl/LinkClick.aspx?fileticket=lSCwDq6q038%3d&tabid=308

This cert chains up to "DigiNotar Root CA", which we already handle, so it should be covered?
Comment 46 christian 2011-09-02 10:01:05 PDT
We'll wanted this landed everywhere once it is reviewed and tested:

* mozilla-central (default branch)
* releases/mozilla-aurora (default branch)
* releases/mozilla-beta (default branch)
* releases/mozilla-release (default branch)
* releases/mozilla-1.9.2 (default branch)

I can take care of transplanting to whatever relbranches we need. Thanks!
Comment 48 Kai Engert (:kaie) 2011-09-02 11:54:29 PDT
Created attachment 557905 [details] [diff] [review]
patch v4 for mozilla-central and NSS 3.13 - MUST RUN "gmake generate"
Comment 49 :Ehsan Akhgari (out sick) 2011-09-02 12:02:36 PDT
Also: http://hg.mozilla.org/mozilla-central/rev/cf1ba8f0dbf7
Comment 50 Kai Engert (:kaie) 2011-09-02 12:41:30 PDT
Landing patch v4 into NSS 3.12 branch:

Checking in certdata.c;
/cvsroot/mozilla/security/nss/lib/ckfw/builtins/certdata.c,v  <--  certdata.c
new revision: 1.67.2.13; previous revision: 1.67.2.12
done
Checking in certdata.txt;
/cvsroot/mozilla/security/nss/lib/ckfw/builtins/certdata.txt,v  <--  certdata.txt
new revision: 1.64.2.13; previous revision: 1.64.2.12
done
Checking in nssckbi.h;
/cvsroot/mozilla/security/nss/lib/ckfw/builtins/nssckbi.h,v  <--  nssckbi.h
new revision: 1.24.2.8; previous revision: 1.24.2.7
done


Landing patch v4 into NSS trunk:

Checking in certdata.c;
/cvsroot/mozilla/security/nss/lib/ckfw/builtins/certdata.c,v  <--  certdata.c
new revision: 1.82; previous revision: 1.81
done
Checking in certdata.txt;
/cvsroot/mozilla/security/nss/lib/ckfw/builtins/certdata.txt,v  <--  certdata.txt
new revision: 1.79; previous revision: 1.78
done
Checking in nssckbi.h;
/cvsroot/mozilla/security/nss/lib/ckfw/builtins/nssckbi.h,v  <--  nssckbi.h
new revision: 1.32; previous revision: 1.31
done
Comment 51 :Ehsan Akhgari (out sick) 2011-09-02 12:41:50 PDT
Also: http://hg.mozilla.org/releases/mozilla-aurora/rev/d0763ce2460a
Comment 55 Geo Mealer [:geo] -- This account is inactive after 2015-07-07 2011-09-04 18:17:15 PDT
QA would like to verify this behavior prior to signing off, but it's not 100% clear what we should be using as testcases and what the final behavior should be. Any hints would be very appreciated.
Comment 56 Gervase Markham [:gerv] 2011-09-05 02:47:31 PDT
See comment #40 - none of those sites should be trusted. I believe the expected behaviour is an overrideable cert_not_trusted error for most of them, but a non-overrideable cert_revoked error for the last one, as it was issued before 1st July 2011.

(You should check, though, that none of the sites has changed their cert since I made that list. This can be seen by looking at the cert chain in the certificate viewer, using a browser without any DigiNotar-related patches.)

Gerv
Comment 57 juan becerra [:juanb] 2011-09-05 12:31:20 PDT
QA has gone through a list of urls pulled from spreadsheet Gerv had compiled, and we've made sure to verify that the sites in question are not trusted, and we've seen that some of them are not overridable. In a couple of cases, the urls are now trusted because they have updated their certificates.

We verified by checking the URLs in XP using all branches where the problem was fixed, including 3.6.22(build2), 6.0.2(build2), and 7.0b4 (build2).

For good measure, please take a look at the following spreadsheet where we wrote down our results:

https://docs.google.com/spreadsheet/ccc?key=0AnEJ45MnstYjdGVLc0hQV3M0RE1ENDlZOTJqX204ZXc&hl=en_US#gid=0
Comment 58 juan becerra [:juanb] 2011-09-05 12:43:53 PDT
Verified on latest Nightly on Mac as well.
Comment 59 Wan-Teh Chang 2011-09-05 13:14:32 PDT
The testing performed by Mike Hommey and me showed that
the explicitly distrusted CA certificates added in this
bug do not work for libpkix.

This problem is important to the NSS team, but probably
can be ignored by Mozilla QA.

Here is the output of the NSS 'vfychain' test program.
By default it uses the "classic" certificate verification
function.  If -pp is specified, it uses CERT_PKIXVerifyCert.
cert.001, cert.002, and cert.003 are the certificate chain
for https://sha2.diginotar.nl/.

$ vfychain -v cert.001 cert.002 cert.003
Chain is bad!
PROBLEM WITH THE CERT CHAIN:
CERT 1. Builtin Object Token:Explicitly Distrusted DigiNotar PKIoverheid G2 [Cer
tificate Authority]:
  ERROR -8171: Peer's certificate has been marked as not trusted by the user.
  ERROR -8179: Peer's Certificate issuer is not recognized.
    CN=DigiNotar PKIoverheid CA Organisatie - G2,O=DigiNotar B.V.,C=NL

$ vfychain -v -pp cert.001 cert.002 cert.003
Chain is good!
Root Certificate Subject:: "CN=Staat der Nederlanden Root CA - G2,O=Staat der
     Nederlanden,C=NL"
Certificate 1 Subject: "CN=sha2.diginotar.nl,serialNumber=0000000334104947000
    0,O=DigiNotar B.V. (0034104947),C=NL"
Certificate 2 Subject: "CN=DigiNotar PKIoverheid CA Organisatie - G2,O=DigiNo
    tar B.V.,C=NL"
Certificate 3 Subject: "CN=Staat der Nederlanden Organisatie CA - G2,O=Staat
    der Nederlanden,C=NL"
Comment 60 Kai Engert (:kaie) 2011-09-05 13:25:56 PDT
FYI: Comment 59 refers to a non-default configuration.
Comment 61 Wan-Teh Chang 2011-09-06 18:38:38 PDT
With Bob's patch in bug 642503, and the PKIoverheid G2 cert
(explicitly distrusted) added to certdata.txt, libpkix
correctly rejects the certificate chain:

$ vfychain -v -pp cert.001 cert.002 cert.003
Chain is bad!
PROBLEM WITH THE CERT CHAIN:
CERT 1. Builtin Object Token:Explicitly Distrusted DigiNotar PKIoverheid G2 [Certificate Authority]:
  ERROR -8171: Peer's certificate has been marked as not trusted by the user.
  ERROR -8171: Peer's certificate has been marked as not trusted by the user.

So I will make it a priority to review Bob's patch in bug 642503.
Comment 62 Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2011-09-09 15:45:18 PDT
QA tracking; needs verification on Aurora using test in comment 57.

Note You need to log in before you can comment on or make changes to this bug.