openvpn · openssl

OpenVPN "CA signature digest algorithm too weak" when your CA is SHA-256

Published 2026-11-06 · HardStacked · 9 min

You upgraded your OpenVPN server (Debian 11 to 12 to 13, or a recent Ubuntu) and some clients no longer connect. The server log says VERIFY ERROR: depth=0, error=CA signature digest algorithm too weak: CN=.... Or a client that is up to date dies at startup with OpenSSL: error:0A00018E:SSL routines::ca md too weak. You open your CA: SHA-256. A Server Fault question from April 2024 (question 1157597, 7,050 views on 2026-11-06, one answer, written by the asker, not accepted) says it better than we can: "It looks like we're already using SHA256 and our certificates are good. So I'm super confused by this error".

Your CA is fine. "CA signature digest" is not the digest of the CA's certificate, it is the digest the CA used to sign another certificate, and the log line names that certificate: depth=0 and CN=. Since OpenSSL 3.0, a certificate signed with SHA-1 is refused at security level 1, and level 1 is exactly OpenVPN's default, which its own manual describes as "SHA1 and newer". The tool you run to check, openssl verify, says OK to the guilty certificate. The fix is to re-sign that one certificate in SHA-256, same key. The workaround (tls-cert-profile insecure) is temporary, and it lets MD5 in too.

In that question the move was Debian Buster to Bookworm, OpenVPN 2.4.7 to 2.6.3, OpenSSL 3.0.13. The asker's culprit was the client certificates, signed in SHA-1 by a SHA-256 CA. Measured on a fresh Debian 13.7 virtual machine (arm64, official cloud image), openvpn 2.6.14-1+deb13u3, easy-rsa 3.2.2-1, OpenSSL 3.5.7, on 2026-11-06.

01. Two messages, one certificate

Everything here lives in ~/demo-ovpn and carries demo in its name. Nothing touches a real OpenVPN server: the demo server listens on 127.0.0.1 port 11940 with dev null, so no tunnel and no network interface, and OpenVPN itself runs without root (sudo is only for apt-get). Everything is removed at the end (section 07). We write /usr/sbin/openvpn in full because /usr/sbin is not in the PATH of a normal user on Debian. We cut the easy-rsa noise from the outputs (progress dots, the openssl ca report), never a command.

The PKI: a CA, a server certificate, demo-new in SHA-256 (the default), and demo-old signed with --digest=sha1, playing the certificate issued years ago.

Two small config files, then the server in the background:

First, the client with the SHA-1 certificate, on an up to date OpenVPN. This is the second form of the message. OpenSSL refuses to load the client's own certificate, before a single packet leaves.

Now the form of the question. We give the client --tls-cert-profile insecure, so it plays an older client, for example one built with OpenSSL 1.1.1, which still accepted SHA-1 at level 1 according to the OpenSSL changelog (see section 03). That is very probably the situation of the Server Fault question, where the error shows only on the server. The client prints nothing, no Initialization line: it does not get in. The server log has the line:

02. Read the line: the CA is not the one being blamed

depth=0 is the certificate presented by the peer. depth=1 would be the CA. CN=demo-old is its name. The message says "CA" because it is the CA's signature on that certificate that is too weak. The asker found this too: "The error message specifically indicates the CA, not the server or client certificates, so that's what was throwing me."

The signature algorithm of each certificate:

The CA, the server and demo-new are SHA-256. Only demo-old is sha1WithRSAEncryption.

03. Why it worked before the upgrade

The OpenSSL changelog, changes between 1.1.1 and 3.0.0: "X509 certificates signed using SHA1 are no longer allowed at security level 1 and above." Buster had OpenSSL 1.1.1, Bookworm 3.0, Debian 13 has 3.5. And the OpenVPN manual contradicts itself: legacy (default) is "SHA1 and newer", and a few lines further, for OpenSSL builds, legacy (default) "sets security level 1". With OpenSSL 3, the first sentence is false. Writing tls-cert-profile legacy yourself changes nothing, it is already the default (we measured it on the workstation).

04. Find every certificate that will break

Here is the trap. openssl verify, the command everybody runs, says OK to demo-old. With -auth_level 1, it applies the same rule as OpenVPN, on the whole PKI at once:

The man page of OpenSSL 3.5.7 (openssl-verification-options) explains both. "The default security level is -1, or "not set". At security level 0 or lower all algorithms are acceptable." That is why the first command blesses the certificate. And "The signature algorithm security level is enforced for all the certificates in the chain except for the chain's trust anchor": a self-signed SHA-1 root CA triggers nothing. We measured it on the workstation, SHA-1 root with SHA-256 certificates, full connection. Good news if your old CA is a root.

05. The fix: re-sign the certificate, keep the key

First look at vars (and pki/vars if you have one, we measured both). Commented out means the default, SHA-256. If it holds set_var EASYRSA_DIGEST "sha1" uncommented, remove that line before anything else: we measured, with a control, that easyrsa renew then says "Renew was successful." and signs in SHA-1 again.

The client now gets in with the same key and the new certificate, and the server log shows the error from before, then VERIFY OK. The private key does not change (we compared the public keys, identical), only the .crt. Each client gets a new certificate, not a new key. If you distribute pki/inline/private/<name>.inline, renew regenerates it.

easy-rsa then suggests revoke-renewed, once the new certificate is deployed, and that one in turn says "You must run 'gen-crl' and upload a new CRL". On the OpenVPN side, the list is read by crl-verify ("Check peer certificate against a Certificate Revocation List"), an option the manual calls "not mandatory": check that your server has it. A second renew of the same name is refused ("a conflicting file exists") until the old one is revoked.

06. If you can't re-issue today

The workaround admits more than you think. We issue a certificate signed with MD5. On the default server it is refused with the same message as the SHA-1 one. We add tls-cert-profile insecure to the server and restart it. The client also gets that option, for the reason of section 01.

The workaround does not say "accept SHA-1", it says "accept anything", MD5 included, and the error message was the same for both: you do not know what you let in. If you must use it, put it on the server, which verifies and logs, and only until every client has its new certificate. We measured tls-cipher "DEFAULT:@SECLEVEL=0" on the workstation: same effect on the SHA-1 certificate. We did not test MD5 with it, but level 0 is the one where "all algorithms are acceptable" (section 04). And a client whose own certificate is SHA-1 stops at startup (section 01), so it needs the same setting too: it is not "one line on the server".

07. Clean up

If you installed the packages only for this test, you can remove them. Check first that you do not have a real OpenVPN server on the machine.

Scope: Debian 13.7 arm64 virtual machine and a Debian 13 workstation, same versions, 2026-11-06. The refusal comes from OpenSSL 3.0 and later, so any distribution that ships OpenSSL 3 with OpenVPN should behave the same (inferred from the changelog, not measured). Not measured: Windows, macOS and mobile clients (OpenVPN Connect, Viscosity), builds with mbed TLS (the manual says profiles are handled differently there), OpenVPN 2.5 and 2.7. Another upgrade that breaks OpenVPN, this time the kernel: dkms "failed for ovpn-dco" after the kernel 7.0 update.