We are happy to announce the release of strongSwan 5.8.1, which is mainly a maintenance release but also supports an optional less strict matching of RDNs in DNs of X.509 certificates.
Less Strict Matching of RDNs in DNs of X.509 Certificates
RDNs in DNs of X.509 certificates can now optionally be matched less strict. The global strongswan.conf option charon.rdn_matching takes two alternative values (defaults to strict) that cause the matching algorithm to either ignore the order of matched RDNs (reordered) or additionally (relaxed) accept DNs that contain more RDNs than configured (unmatched RDNs are treated like wildcard matches).
Note that reordered and relaxed impose a considerable overhead on memory usage and runtime, in particular, for mismatches, compared to static.
So for example, the configured identity
C=CH, O=strongSwan, CNfirstname.lastname@example.org, SN=*
by default, matches a certificate with a subject DN like
C=CH, O=strongSwan, CNemail@example.com, SN=ZX52376
but doesn't match a certificate with the following subject DN
C=CH, O=strongSwan, SN=ZY85641, CNfirstname.lastname@example.org
as the order of the last two RDNs is different. Setting the mentioned configuration option to reordered would accept the second certificate too.
However, it wouldn't match a certificate with the following subject DN
C=CH, O=strongSwan, OU=Sales, SN=ZZ54273, CNemail@example.com
as the OU RDN isn't matched. This can be allowed by setting the option to relaxed, which treats the missing RDN like a wildcard match (i.e. as if OU=* was configured). Even with that setting, though, a certificate with the following subject DN wouldn't be accepted
C=CH, O=strongSwan, CNfirstname.lastname@example.org
because it misses the configured, and thus enforced, SN RDN.
Other Notable Features and Fixes
- The updown plugin now passes the same interface to the script that is also used for the automatically installed routes, that is, the interface over which the peer is reached instead of the interface on which the local address is found.
- TPM 2.0 contexts are now protected by a mutex to prevent issues if multiple IKE_SAs use the same private key concurrently.
- If available,
explicit_bzero()is now used as
memwipe()instead of our own implementation.
- The maximum data length of received
COOKIEnotifies (64 bytes) is now enforced.