Hi, Have you tried ipsec stroke rereadsecrets? (Btw, better switch to swanctl)
Kind regards Noel Am 06.10.21 um 16:54 schrieb 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 <http://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 <http://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 <http://vpn.my-hostname.net> flags: serverAuth clientAuth OCSP URIs: http://r3.o.lencr.org <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 <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 ?
OpenPGP_signature
Description: OpenPGP digital signature
