OpenVPN "error=CA signature digest algorithm too weak"

Question

After upgrading our OpenVPN server from Debian Buster to Bookworm, which also upgraded OpenVPN from 2.4.7 to 2.6.3, we're now getting this when any client tries to connect:

error=CA signature digest algorithm too weak

I've searched for this error and have found the usual work-arounds, like adding tls-cipher "DEFAULT:@SECLEVEL=0" to the config (we're doing that in the interim, but downgrading security isn't a permanent fix). Additional Googling seems to consistently indicate using an outdated algorithm to generate the certs (like MD5 or SHA1), but that doesn't seem to be the case here. When I look at our CA, Server, and Client certs, they all contain this:

Signature Algorithm: sha256WithRSAEncryption

It looks like we're already using SHA256 and our certificates are good. So I'm super confused by this error and not sure where to go from here. I know that I could probably just generate new certs (we have dozens of client endpoints that connect, so not ideal). Also, that wouldn't tell me what the underlying actual issue is.

This is a pretty stock Debian system with OpenSSL 3.0.13 installed.

Answer 1

I actually figured this out as I was posting the question, but wanted to keep it here (and write an answer) in case anyone else has the same problem and would like some resolution.

I had mentioned that the CA, Server, and Client certificates were all good with SHA256. Upon closer examination, that was not the case. The Client certificates had this:

Signature Algorithm: sha1WithRSAEncryption

...when viewing the certificate. The error message specifically indicates the CA, not the server or client certificates, so that's what was throwing me. The issue was with the means by which the client certificates were being generated that they were using SHA1 instead, but the CA and Server certificates are indeed SHA256. Since it was happening upon client connection (but in the server logs), I decided I'd check the client certificate, and that was the issue.

So it looks like the solution will be, despite having many clients, to regenerate and redistribute client certificates. So we'll leave the work-around in place for now until we can hit all of the clients, then remove it once they're all upgraded.