[Swan-dev] match_certs_id()

[Tuomo Soini]

On Thu, 7 Feb 2019 22:43:52 -0500 (EST)
"D. Hugh Redelmeier" <hugh at mimosa.com> wrote:

> | From: Paul Wouters <paul at nohats.ca>
> 
> | 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 <tis at foobar.fi>
Foobar Linux services
+358 40 5240030
Foobar Oy <https://foobar.fi/>