<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body>
<p>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 <i>same </i>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.</p>
<p>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.<br>
</p>
<p>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.<br>
</p>
<p>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.</p>
<p>The swanctl.conf file segment for Windows is:</p>
<p> windows {<br>
pools = remote_pool<br>
local {<br>
auth = pubkey<br>
certs = ipgw-rsa.denninger.net.crt<br>
id = ipgw.denninger.net<br>
}<br>
remote {<br>
auth = eap-tls<br>
cacerts = CudaSystems.Int.crt<br>
eap_id = %any<br>
}<br>
children {<br>
windows {<br>
local_ts = 0.0.0.0/0<br>
}<br>
}<br>
}<br>
<br>
</p>
<p>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.)<br>
</p>
<p>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:</p>
<ul style="padding-left: 2em; margin-bottom: 2em; color: rgb(51, 51,
51); font-family: Arial, Helvetica, sans-serif; font-size: medium;
font-style: normal; font-variant-ligatures: normal;
font-variant-caps: normal; font-weight: 400; letter-spacing:
normal; orphans: 2; text-align: start; text-indent: 0px;
text-transform: none; white-space: normal; widows: 2;
word-spacing: 0px; -webkit-text-stroke-width: 0px;
text-decoration-thickness: initial; text-decoration-style:
initial; text-decoration-color: initial;">
<li style="list-style: square; margin-bottom: 0.6em;">The client
identity (e.g. the IKE or EAP identity for EAP-TLS) is again
enforced by libtls.</li>
</ul>
<p></p>
<p>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.<br>
</p>
<p>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.<br>
</p>
<div class="moz-signature">-- <br>
Karl Denninger<br>
<a href="mailto:karl@denninger.net" class="moz-txt-link-freetext">karl@denninger.net</a><br>
<i>The Market Ticker</i><br>
<font size="-2"><i>[S/MIME encrypted email preferred]</i></font></div>
</body>
</html>