[strongSwan] FreeBSD 12.x .vs. 13.x - change in strongswan as well?

[Karl Denninger]

I've been running Strongswan on FreeBSD/Stable-12 for quite some time 
(and on earlier versions of FreeBSD before that) serving both Android 
clients via certificates and, on the /same /certificate, Windows 
machines using EAP-TLS -- the same cert that people use for S/Mime 
signatures and such.  This has been working quite well and allows anyone 
with one issued by that intermediate to connect one device at a time 
whether on Windows or an Android device, and use the same cert for 
S/Mime signing and encryption.

Recently I upgraded one of the gateways that does this to Stable-13 and, 
as part of that, StrongSwan went from 5.9.5 to 5.9.6.  I also 
transitioned to using vici from stroke (yeah, I know, been using this 
for a while and probably should have long ago) and on -12 this seems to 
work when back-checked -- that is, I can boot the gateway using 12 on 
the same config files, but with 5.9.5, set to use vici in the startup 
script and everything works as expected thus apparently my conversion of 
the "older way" appears to be correct.

As an aside I am also at present chasing what looks like a new bogon out 
of Android 13 that, when the Windows machine is behind an Android 
tether, breaks routing entirely -- but I don't think that's related to 
the below because when I put the gateway back on -12 its still broken; 
thus I doubt that StrongSwan's fault.  I'm chasing that separately.

What I am running into that I've traced to StrongSwan, however, is that 
suddenly the current StrongSwan code is very unhappy about the 
certificates I've been using.  They're issued by my local CA and now 
StrongSwan is claiming that when using EAP-TLS it cannot validate them, 
shows the CN as the failed identifier and thus the connections fail.  If 
I set the client on Windows to allow me to change the user parameter and 
enter the email address in the certificate (which IS in the SAN field - 
the "CN" of these certs is the full name of the person, not an email 
address) then the connection succeeds.

The swanctl.conf file segment for Windows is:

         windows {
                 pools = remote_pool
                 local {
                         auth = pubkey
                         certs = ipgw-rsa.denninger.net.crt
                         id = ipgw.denninger.net
                 }
                 remote {
                         auth = eap-tls
                         cacerts = CudaSystems.Int.crt
                         eap_id = %any
                 }
                 children {
                         windows {
                                 local_ts = 0.0.0.0/0
                         }
                 }
         }

The error looks like the StrongSwan server is insisting on using the CN, 
not looking at the SAN field of the presented certificate at all and, as 
far as I can tell, its not validating that it was actually signed by the 
intermediate certificate even though it does it have it and does know 
that's the correct certificate to check it against, as it does request 
it and in fact has it in the ca directory (and a status request does 
show it.)

Using the "stroke" interface does not impact this; it appears to be 
something changed between 5.9.5 and 5.9.6 and the release notes imply 
this is likely the cause:

  * The client identity (e.g. the IKE or EAP identity for EAP-TLS) is
    again enforced by libtls.

And, it appears, Windows is insisting on using the CN when presenting 
the identity (instead of the field(s) in the SAN) unless you set the 
option on the VPN profile to allow an override -- and then you have to 
hand-key it on each connection.  I don't believe there is any way to 
tell Windows to use the SAN identity or identities on its own.

I'm not sure if Windows did this to me and the 5.9.6 upgrade exposed it 
or what, but it certainly is rather annoying and, at present, it appears 
the only "fix" is to have the user enter their email address on each 
connection via Windows by telling to let the user change their identity 
when connecting.

-- 
Karl Denninger
karl at denninger.net
/The Market Ticker/
/[S/MIME encrypted email preferred]/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20221015/1a9c2993/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4864 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.strongswan.org/pipermail/users/attachments/20221015/1a9c2993/attachment.bin>