On Thu, 7 Feb 2019 22:43:52 -0500 (EST) "D. Hugh Redelmeier" <[email protected]> wrote:
> | From: Paul Wouters <[email protected]> > > | On Thu, 7 Feb 2019, D. Hugh Redelmeier wrote: > | > | > | > > testing/pluto/nss-cert-chain-01-ikev2/OUTPUT/east.pluto.log:1758:"nss-cert-chain" > | > | > #1: EXPECTATION FAILED: cert->next == NULL (in > match_certs_id() at | > | > x509.c:779) | > | > | > | This does indicate that certificate chains are passed to the > function. | > | Perhaps we are not guaranteed the order of the chain > of certificates, | > | and we still havent figured out which is the > EE cert and which is the | > | intermediary root CA ? > | > > | > There are 29 instances of this in the test run. > | > > | > What should be happening? > | > | What is currently happening? > | > | > This is a matter of design and not conjecture. But the design > isn't | > recorded. It needs to be. > | > | We could rename match_certs_id() to matchid_from_certbundle() ? > > So: I changed match_certs_id to loop over the whole list. If any cert > matched, a match was declared. But the whole list was processed. > > ID_FROMCERT processing wasn't really affected because the first match > would replace it. > > So: what would be new? If the match of the first element failed, > perhaps a match against a cert further down the chain would succeed. > Without knowing the structure of the list, it isn't clear. > > Here are some results. It sure looks as if the only cert of interest > is the first. So I'll delete the looping code (it was never > committed) and add some comments. It should only match to end certificate, which should be the first one always it must not match intermediate of root CA. -- Tuomo Soini <[email protected]> Foobar Linux services +358 40 5240030 Foobar Oy <https://foobar.fi/> _______________________________________________ Swan-dev mailing list [email protected] https://lists.libreswan.org/mailman/listinfo/swan-dev
