[strongSwan] Let's Encrypt CA Expiry & related StrongSWAN trouble

[Philip Veale]

So about a week about, one of the CAs in the chain Let'sEncrypt use (DST
Root CA X3) expired. This shouldn't have been a problem for most clients,
as it was cross signed with a CA that had not expired (ISRG Root X1) which
most modern clients and devices should trust, though some older ones may
not which was (AIUI) why they kept the DST Root CA X3 in there too.

I use a Let'sEncrypt certificate with StrongSWAN and for years it has
mostly just worked (mostly being, certbot very usefully renewed the
certificate dutifully every so many days, but it didn't get ipsec to
re-read this so I'd have to manually punt it about 4 times a year. I could
have fixed that but never bothered, anyway, I digress...)

Recently I found the StrongSWAN client on my Android 10 phone wouldn't
connect, and at first I thought I just needed to punt it again to re-read
the cert, but then I realised it was reporting it had expired even after
I'd manually run certbot. And thus I discovered that something that the
Android Client is looking at doesn't trust the cert the server was offering
as one CA was expired even though another was still valid. This I don't
entirely understand as the Let'sEncrypt people seem pretty adamant it
should all still work.

I don't entirely understand why new certificates issued today are still
being signed with a cert that expired last week, though.

Anyway, moving on. I figured the best way to solve this was to request a
cert from LE that was only signed by ISRG Root X1 and NOT by DST Root CA X3
as well, which is not the default behaviour but can be achieved by passing
a switch to certbot to ask it to do it that way.

My system was running Debian Switch and I wanted to continue to use
certbot, and I didn't want to pollute the system with certbot's suggested
tool snap, which imports a little bit of Ubuntu stuff.

Looking at repositories' versions of the certbot package, it was clear I
had to upgrade from Stretch to Bullseye, via Buster in between.

So, done that, everything all up to date, got new cert, all should be well
now, except it fails, client and server both reporting basically the same
thing;

Oct  6 15:20:30 VPN-Server charon: 10[IKE] no private key found for '
vpn.my-hostname.net'
Oct  6 15:20:30 VPN-Server charon: 10[ENC] generating IKE_AUTH response 1 [
N(AUTH_FAILED) ]

I've not modified ipsec.secrets, it's still intact and contains the correct
reference to the privkey.pem file, which pans out as running the below
command brings up the expected result;

# ipsec listcerts

List of X.509 End Entity Certificates

  subject:  "CN=vpn.my-hostname.net"
  issuer:   "C=US, O=Let's Encrypt, CN=R3"
  validity:  not before Oct 06 14:03:36 2021, ok
             not after  Jan 04 13:03:35 2022, ok (expires in 89 days)
  serial:    [redacted]
  altNames:   vpn.my-hostname.net
  flags:     serverAuth clientAuth
  OCSP URIs: http://r3.o.lencr.org
  certificatePolicies:
             2.23.140.1.2.1
             1.3.6.1.4.1.44947.1.1.1
             CPS: http://cps.letsencrypt.org
[other lines trimmed]


all looks correct to me. All certs present and correct by my reckoning,
config unaltered from previous working state before certificate trouble
started within the last week.

I say unaltered, I've obviously gone up TWO Debian release versions which
might have some bearing on it, but I can't see how and the logs and
pointing the finger at a certificate issue which seems more likely.

Only other thing I can thing of is at some point in the past I had manually
imported a cacert from Let'sEncrypt onto the system such that "ipsec
listcacerts" produced some output, they are gone now so this produces
nothing.

Not sure how they'd be needed, though


Can anyone spot or think of what I've missed, or has anyone else been
through similar recently due to what's happened with Let'sEncrypt ?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20211006/ea149386/attachment.html>