On Tue, 12 Nov 2019, Andrew Cagney wrote:

as in ...

conn westnet-eastnet-x509
       ikev2=no
       also=westnet
       also=eastnet
       left=192.1.2.45
       leftcert=west
       leftid=%fromcert
       right=192.1.2.23
       rightid=%fromcert
       rightcert=east

Yes.

I still think this check should go away.

After checking that there are root certs, the code:

- creates a list of certs sent over the wire
- feeds this untrusted list + the root into CERT_PKIXVerifyCert() with:

       {
           .type = cert_pi_trustAnchors,
           .value = { .pointer = { .chain = trustcl } }
       },
       {
           .type = cert_pi_useOnlyTrustAnchors,
           .value = { .scalar = { .b = PR_TRUE } }
       },

so if there's no root, or the only root is wrong, how can this pass?
See lib/certdb/certt.h

Looking at the logs of x509-pluto-05, the code never calls
verify_end_cert(). I made an ikev2 version of this test,
ikev2-x509-pluto-05 and it too never calls verify_end_cert()

It does call find_and_verify_certs() which calls get_root_certs()

Changing west to use the cert "road" properly fails:

loading root certificate cache
"westnet-eastnet-x509" #1: No Certificate Authority in NSS Certificate DB! 
Certificate payloads discarded.
"westnet-eastnet-x509" #1: certificate subjectAltName extension does not match 
ID_DER_ASN1_DN 'C=CA, ST=Ontario, L=Toronto, O=Libreswan, OU=Test Department, 
CN=east.testing.libreswan.org, [email protected]'
"westnet-eastnet-x509" #1: Peer ID 'C=CA, ST=Ontario, L=Toronto, O=Libreswan, 
OU=Test Department, CN=road.testing.libreswan.org, [email protected]' 
mismatched on first found connection and no better connection found
"westnet-eastnet-x509" #1: responding to IKE_AUTH message (ID 1) from 
192.1.2.45:500 with encrypted notification AUTHENTICATION_FAILED

Paul
_______________________________________________
Swan-dev mailing list
[email protected]
https://lists.libreswan.org/mailman/listinfo/swan-dev

Reply via email to