New commits:
commit f38b488fbbd6a1263ecd928349f48f4428fdebfa
Author: Paul Wouters <>
Date:   Tue Sep 10 20:48:14 2019 -0400

    documentation: updated CHANGES

commit 30173d016e9ddc442eff1009f5943e0eb3c5320b
Author: Paul Wouters <>
Date:   Tue Sep 10 20:44:23 2019 -0400

    testing: added ikev2-x509-05-san-firstemail-match-respponder to TESTLIST

commit 2ee4cb953f9f39bcdbcf47c61430d2a0b800081b
Author: Paul Wouters <>
Date:   Tue Sep 10 20:43:44 2019 -0400

    testing: updated SAN/ID tests, added 

commit 91a67319ba0bc0aba1ee01c1a4c7b2fe54b21060
Author: Paul Wouters <>
Date:   Tue Sep 10 20:39:15 2019 -0400

    x509: Use match_dn_any_order_wild() instead of same_dn_any_order() for SAN 
    same_dn_any_order() would see specified local wildcard ID's as different 
    a peer ID that would match the wildcard.
    This required changing match_dn_any_order_wild() from static to public.

commit 80d68d57a57c7984cd2e2029519cc2765daab912
Author: Paul Wouters <>
Date:   Tue Sep 10 20:34:20 2019 -0400

    pluto: new option require-id-on-certificate=yes|no
    When using X.509 certificates, this option can be used to accept 
    that violate the rules of RFC 4945 Section 3.1 by not having their IKE ID
    listed as a subjectAltName (SAN) on their certificate. The default (yes)
    is to not accept these certificates as it enables an attack where a 
    host can use its valid certificate and some other hosts' peer ID to pretend
    to be that other host.
    This commit also fixes decode_peer_id_counted() called via decode_peer_id()
    that would mistakenly skip the peer ID check on the responder, resulting in
    IKE peer ID's not specified on the certificate to be accepted on responders.

Swan-commit mailing list

Reply via email to