The default bug view has changed. See this FAQ.

Better coverage for DigiNotarGate in NSS

VERIFIED FIXED

Status

NSS
Libraries
VERIFIED FIXED
6 years ago
6 years ago

People

(Reporter: kaie, Assigned: kaie)

Tracking

({verified-beta, verified1.9.2})

3.12.11
verified-beta, verified1.9.2
Dependency tree / graph

Firefox Tracking Flags

(firefox6 .2-fixed, firefox7 fixed, firefox8 fixed, firefox9 fixed, status1.9.2 .22-fixed)

Details

(Whiteboard: [qa+])

Attachments

(7 attachments, 4 obsolete attachments)

4.44 KB, application/octet-stream
Details
31.04 KB, patch
Robert Relyea
: 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
Robert Relyea
: review+
Details | Diff | Splinter Review
17.79 KB, patch
Details | Diff | Splinter Review
Comment hidden (empty)
(Assignee)

Comment 1

6 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

6 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

6 years ago
Hold on. Updated information. Let me rework comment 2 and comment 3.
(Assignee)

Comment 6

6 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

6 years ago
marking comments 3 and 4 as private, to reduce confusion.
(Assignee)

Comment 8

6 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

6 years ago
Kai: using 0x0fffffffffffffff, 0x0ffffffffffffffe,
0x0ffffffffffffffd, etc. as serial numbers should
be unlikely to conflict with serial numbers of real
certificates.

Comment 10

6 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

6 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

6 years ago
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.
(Assignee)

Comment 13

6 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

6 years ago
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.
Kai: can we open this bug, now the others are open?

Gerv
(Assignee)

Comment 16

6 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
Group: core-security
(Assignee)

Comment 17

6 years ago
Created attachment 557212 [details] [diff] [review]
patch for NSS 3.13 and mozilla-central
(Assignee)

Comment 18

6 years ago
Created attachment 557219 [details] [diff] [review]
patch v2 for NSS 3.13 and mozilla-central

(branch patch is good - updating bad trunk patch)
Attachment #557212 - Attachment is obsolete: true

Comment 19

6 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

6 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

6 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

6 years ago
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.
(Assignee)

Comment 23

6 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

6 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

6 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.
(Assignee)

Updated

6 years ago
Blocks: 683455

Comment 26

6 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

6 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

6 years ago
Created attachment 557313 [details] [diff] [review]
Patch v3 for NSS 3.12.x and stable mozilla branches - MUST RUN "gmake generate" AFTER APPLYING PATCH
Assignee: nobody → kaie
Attachment #557183 - Attachment is obsolete: true
Attachment #557219 - Attachment is obsolete: true
(Assignee)

Comment 29

6 years ago
Created attachment 557315 [details]
zip file, collection of certs used for patch v3
Attachment #557179 - Attachment is obsolete: true
(Assignee)

Updated

6 years ago
Attachment #557315 - Attachment description: zip file collection used for patch v3 → zip file, collection of certs used for patch v3
(Assignee)

Updated

6 years ago
Attachment #557313 - Flags: review?(rrelyea)
(Assignee)

Comment 30

6 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

6 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

6 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

6 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

6 years ago
I've tagged the roots module directory as NSSCKBI_1_86_RTM
(Assignee)

Comment 35

6 years ago
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
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

6 years ago
Created attachment 557727 [details]
zip file - overheid intermediates
(Assignee)

Comment 38

6 years ago
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
Attachment #557729 - Flags: review?(rrelyea)

Comment 39

6 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+
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
Do we have DigiNotar Public CA 2025 somewhere?
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

6 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

6 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

6 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

6 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!
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
Last Resolved: 6 years ago
Resolution: --- → FIXED
(Assignee)

Comment 48

6 years ago
Created attachment 557905 [details] [diff] [review]
patch v4 for mozilla-central and NSS 3.13 - MUST RUN "gmake generate"
Also: http://hg.mozilla.org/mozilla-central/rev/cf1ba8f0dbf7
(Assignee)

Comment 50

6 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
Also: http://hg.mozilla.org/releases/mozilla-aurora/rev/d0763ce2460a
http://hg.mozilla.org/releases/mozilla-beta/rev/be5822b6bccc
http://hg.mozilla.org/releases/mozilla-beta/rev/30ce464d49a0
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
http://hg.mozilla.org/releases/mozilla-1.9.2/rev/98a24c7f3fd2
http://hg.mozilla.org/releases/mozilla-1.9.2/rev/78a7b1b19e8f

Updated

6 years ago
status-firefox6: --- → .2-fixed
status-firefox7: --- → fixed
status-firefox8: --- → fixed
status-firefox9: --- → fixed

Updated

6 years ago
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.
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
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
Keywords: verified-aurora, verified-beta, verified1.9.2
Keywords: verified-aurora
Verified on latest Nightly on Mac as well.
Status: RESOLVED → VERIFIED

Comment 59

6 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

6 years ago
FYI: Comment 59 refers to a non-default configuration.

Comment 61

6 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.
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.