Strongswan client to a Cisco VPN fails after upgrading to Fedora 41

Fedora 41 removes SHA1 signatures, but Cisco VPNs really want those.

I'm using strongSwan to connect in to a Cisco ASA running an ipsec VPN. Authentication is through certificates with a local certificate authority. It works, it's stable, and it's been interesting to learn about all the spots where assertions are made, and then must be cryptographically verified, often in different ways.

Earlier this month, I also upgraded my laptop to Fedora 41. I'm on the Kinoite spin so that was a straightforward application of the same instructions used for Silverblue.

The first time after the upgrade that I tried to connect in to my VPN, it failed. I immediately suspected expired certificates, but a quick glance at each of the certs in use showed me that wasn't it.

Because my VPN config is all through NetworkManager, I perused the logs there with journalctl -u NetworkManager to see what I could find. The failure seemed to happen right in here.

charon-nm[23537]: 09[IKE] sending cert request for "CN=VPN CA"
charon-nm[23537]: 09[IKE] authentication of 'CN=vpnclient' (myself) with RSA signature failed

That didn't give me quite enough information to go on. I wanted to know whether someting on the remote side or on the client side was rejecting that RSA signature. Adding more logging to charon-nm is surprisingly subtle. It doesn't look at the normal sections of strongswan.conf to see what level to log at. I need to add a dedicated charon-nm stanza in /etc/strongswan/strongswan.conf

charon-nm {
  syslog {
    daemon {
      default=2
    }
  }
}

After that and killing the extant charon-nm process, I was able to retry the VPN connection and get a whole heap of logs.

Unfortunately, more logs didn't tell me more about why the signature failed. What it did tell me was that there was no additional communcation happening between the creation of the cert request and the signature failure. That was helpful because it meant that whatever was going on was solely in the laptop client.

I did a bunch of research on what all signatures exist in the VPN negotiation. All of my certificates are signed with SHA256, and all the signatures verified. The various crypto policies could also be changed around without affecting what eneded up in any of the logs, implying that wasn't the source of the problem.

Eventually I found https://github.com/strongswan/strongswan/discussions/2093 which looked eerily similar: new version of a RedHat-derived OS, and sudden signature failures. It turns out that Fedora 41 fully deprecated SHA1 signatures after threatening to do so for years. I didn't think there was any SHA1 in the handshake, but there's some rumors and evidence that Cisco VPNs rely on SHA1 for one specific signature, which can't currently be changed. Annoying.

The recommended command that helped the person in the thread was

update-crypto-policies --set DEFAULT:SHA1

That command sets the crypto policy (some defaults in config files for openssl and gnutls and such) to the defaults for Fedora 41, but adds in allowing SHA1 based signatures. That's the command that I ran, and suddenly my VPN started working just as before.

Apparently update-crypto-policies --set LEGACY can work too, at the cost of including compatibility with more weakly encrypted systems. I'm holding off on that one until I see other kinds of failures.