Closed
Bug 683261
Opened 13 years ago
Closed 13 years ago
Better coverage for DigiNotarGate in NSS
Categories
(NSS :: Libraries, defect)
Tracking
(firefox6 .2-fixed, firefox7 fixed, firefox8 fixed, firefox9 fixed, status1.9.2 .22-fixed)
People
(Reporter: KaiE, Assigned: KaiE)
References
Details
(Keywords: verified-beta, verified1.9.2, Whiteboard: [qa+])
Attachments
(7 files, 4 obsolete files)
4.44 KB,
application/octet-stream
|
Details | |
Patch v3 for NSS 3.12.x and stable mozilla branches - MUST RUN "gmake generate" AFTER APPLYING PATCH
31.04 KB,
patch
|
rrelyea
:
review+
|
Details | Diff | Splinter Review |
35.33 KB,
application/octet-stream
|
Details | |
30.95 KB,
patch
|
Details | Diff | Splinter Review | |
20.11 KB,
application/octet-stream
|
Details | |
17.85 KB,
patch
|
rrelyea
:
review+
|
Details | Diff | Splinter Review |
17.79 KB,
patch
|
Details | Diff | Splinter Review |
No description provided.
Assignee | ||
Comment 1•13 years ago
|
||
This is a follow-up to 682927. Let's use this bug to add overriding blocker certs to NSS.
Depends on: 682927
Assignee | ||
Comment 2•13 years ago
|
||
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.
Assignee | ||
Comment 5•13 years ago
|
||
Hold on. Updated information. Let me rework comment 2 and comment 3.
Assignee | ||
Comment 6•13 years ago
|
||
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
Assignee | ||
Comment 7•13 years ago
|
||
marking comments 3 and 4 as private, to reduce confusion.
Assignee | ||
Comment 8•13 years ago
|
||
(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•13 years ago
|
||
Kai: using 0x0fffffffffffffff, 0x0ffffffffffffffe, 0x0ffffffffffffffd, etc. as serial numbers should be unlikely to conflict with serial numbers of real certificates.
Comment 10•13 years ago
|
||
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.
Assignee | ||
Comment 11•13 years ago
|
||
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.
Assignee | ||
Comment 12•13 years ago
|
||
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.
Assignee | ||
Comment 13•13 years ago
|
||
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
Assignee | ||
Comment 14•13 years ago
|
||
not yet tested. I will test it in approx. 1 to 1.5 hours.
Comment 15•13 years ago
|
||
Kai: can we open this bug, now the others are open? Gerv
Assignee | ||
Comment 16•13 years ago
|
||
(In reply to Gervase Markham [:gerv] from comment #15) > Kai: can we open this bug, now the others are open? fine with me
Updated•13 years ago
|
Group: core-security
Assignee | ||
Comment 17•13 years ago
|
||
Assignee | ||
Comment 18•13 years ago
|
||
(branch patch is good - updating bad trunk patch)
Attachment #557212 -
Attachment is obsolete: true
Comment 19•13 years ago
|
||
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•13 years ago
|
||
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
Assignee | ||
Comment 21•13 years ago
|
||
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•13 years ago
|
||
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.
Assignee | ||
Comment 23•13 years ago
|
||
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•13 years ago
|
||
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.
Assignee | ||
Comment 25•13 years ago
|
||
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•13 years ago
|
||
CRL reflecting revocations posted to proper CRL DP referenced within the certificates, at: http://www.public-trust.com/cgi-bin/CRL/2018/cdp.crl
Assignee | ||
Comment 27•13 years ago
|
||
The certs with serial numbers 092006 and 092706 have the same subject name. We can used a single special cert that overrides both.
Assignee | ||
Comment 28•13 years ago
|
||
Assignee: nobody → kaie
Attachment #557183 -
Attachment is obsolete: true
Attachment #557219 -
Attachment is obsolete: true
Assignee | ||
Comment 29•13 years ago
|
||
Attachment #557179 -
Attachment is obsolete: true
Assignee | ||
Updated•13 years ago
|
Attachment #557315 -
Attachment description: zip file collection used for patch v3 → zip file, collection of certs used for patch v3
Assignee | ||
Updated•13 years ago
|
Attachment #557313 -
Flags: review?(rrelyea)
Assignee | ||
Comment 30•13 years ago
|
||
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.
Assignee | ||
Comment 31•13 years ago
|
||
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•13 years ago
|
||
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;).
Attachment #557313 -
Flags: review?(rrelyea) → review+
Assignee | ||
Comment 33•13 years ago
|
||
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
Assignee | ||
Comment 34•13 years ago
|
||
I've tagged the roots module directory as NSSCKBI_1_86_RTM
Assignee | ||
Comment 35•13 years ago
|
||
(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•13 years ago
|
||
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
Assignee | ||
Comment 37•13 years ago
|
||
Assignee | ||
Comment 38•13 years ago
|
||
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
Attachment #557729 -
Flags: review?(rrelyea)
Comment 39•13 years ago
|
||
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
Attachment #557729 -
Flags: review?(rrelyea) → review+
Comment 40•13 years ago
|
||
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•13 years ago
|
||
Do we have DigiNotar Public CA 2025 somewhere?
Comment 42•13 years ago
|
||
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•13 years ago
|
||
(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
Assignee | ||
Comment 44•13 years ago
|
||
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.
Assignee | ||
Comment 45•13 years ago
|
||
> 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•13 years ago
|
||
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 47•13 years ago
|
||
http://hg.mozilla.org/mozilla-central/rev/9e815dd55d24 http://hg.mozilla.org/releases/mozilla-aurora/rev/011b7b819020 http://hg.mozilla.org/releases/mozilla-beta/rev/7ebbadf67279 http://hg.mozilla.org/releases/mozilla-beta/rev/66c5548f6b8a http://hg.mozilla.org/releases/mozilla-release/rev/6f059ddb2272 http://hg.mozilla.org/releases/mozilla-release/rev/48d4637b0b94 http://hg.mozilla.org/releases/mozilla-1.9.2/rev/0658b306feb9 http://hg.mozilla.org/releases/mozilla-1.9.2/rev/42692076dc19
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 48•13 years ago
|
||
Comment 49•13 years ago
|
||
Also: http://hg.mozilla.org/mozilla-central/rev/cf1ba8f0dbf7
Assignee | ||
Comment 50•13 years ago
|
||
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•13 years ago
|
||
Also: http://hg.mozilla.org/releases/mozilla-aurora/rev/d0763ce2460a
Comment 52•13 years ago
|
||
http://hg.mozilla.org/releases/mozilla-beta/rev/be5822b6bccc http://hg.mozilla.org/releases/mozilla-beta/rev/30ce464d49a0
Comment 53•13 years ago
|
||
http://hg.mozilla.org/releases/mozilla-release/rev/5fbbd7810a07 http://hg.mozilla.org/releases/mozilla-release/rev/55b5cd1ce8fe http://hg.mozilla.org/releases/mozilla-release/rev/5d45329bf90e
Comment 54•13 years ago
|
||
http://hg.mozilla.org/releases/mozilla-1.9.2/rev/98a24c7f3fd2 http://hg.mozilla.org/releases/mozilla-1.9.2/rev/78a7b1b19e8f
status-firefox6:
--- → .2-fixed
status-firefox7:
--- → fixed
status-firefox8:
--- → fixed
status-firefox9:
--- → fixed
status1.9.2:
--- → .22-fixed
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•13 years ago
|
||
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•13 years ago
|
||
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
Updated•13 years ago
|
Keywords: verified-aurora
Comment 59•13 years ago
|
||
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"
Assignee | ||
Comment 60•13 years ago
|
||
FYI: Comment 59 refers to a non-default configuration.
Comment 61•13 years ago
|
||
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•13 years ago
|
||
QA tracking; needs verification on Aurora using test in comment 57.
Whiteboard: [qa+]
You need to log in
before you can comment on or make changes to this bug.
Description
•