ca md too weak: reissue the certificate or lower the level?

An OpenVPN client that worked last month now fails during startup with ca md too weak, and the profile on disk is byte for byte the one that worked. The message concerns the signature on a certificate authority's certificate, not the data cipher, the auth digest or the account password. Three conditions decide whether the fix is new identity material, a new chain, or a deliberate policy change. Work them in order, and you avoid the usual outcome where the tunnel comes back by weakening every TLS connection on the host.

What the error actually names

OpenSSL raises this verify error while it builds a chain, when the certificate acting as a CA carries a signature digest that the library's security level no longer accepts. MD5 is refused at the default level, and SHA-1 is refused once the level is raised. The digest on the leaf certificate matters less here than the digest on the issuer that signs it. The same policy can refuse a root that was entirely ordinary on the day it was issued.

That is why editing auth or data-ciphers does nothing for this failure. Those settings govern how packets are protected after the handshake, while the rejected object is an identity document examined before a tunnel exists. A certificate can sit comfortably inside its validity window and still carry a signature the library will not accept.

Keep the checks separate in your head and the error stops looking mysterious. Validity dates, key usage and signature digest are independent tests, and exactly one of them has just failed.

Condition one: is the rejected object the root?

Print each certificate in the profile and read the subject and issuer fields. A self-signed root shows the same value in both, and its signature algorithm is the one the whole chain rests on. When the weak digest sits there, every leaf below it inherits the problem. Write the algorithm next to the subject so the later comparison is mechanical rather than remembered.

Bundled CA files often hold several blocks, so identify the block that is actually loaded instead of assuming the first one is at fault. The command openssl x509 -in ca.pem -noout -subject -issuer -text describes one certificate at a time, which means splitting the bundle first if it contains more. Compare the printed signature algorithm against the digest you would expect from the era the root was created.

A leaf signed with SHA-256 under a weak root still fails, because the chain check walks all the way up. That ordering is what makes the next condition matter.

Condition two: do you control the issuer?

If the root belongs to your organisation, the durable fix is a new root with a modern digest plus reissued leaves, delivered as one profile update. That costs a maintenance window and a plan for devices that cannot take the update on the same day.

If a third party issued the chain, the fix is a request to that operator, and the only useful local action is to stop relying on the old material. Editing the PEM text or re-saving the file changes nothing that the signature covers.

One middle case deserves naming: an internal root that predates current defaults but still signs material other systems trust. Replacing it means auditing every consumer, including appliances that pin the old certificate by fingerprint. Count those consumers before scheduling the change, because a root swap that misses one trades a startup error for an outage.

Condition three: what lowering the level also accepts

Lowering the security level, or selecting OpenVPN's legacy certificate profile, makes the client accept the old digest again. It also relaxes other checks in the same library, for every connection that process makes.

That can be defensible in a lab, or as a short bridge while replacement material is prepared, as long as the exception is scoped to one profile and carries an end date. As a permanent setting on a shared host it quietly widens what every TLS client there will trust.

Write the exception down with an owner and a removal step. An undocumented level change is indistinguishable from a mistake six months later, and the next engineer will not know it was ever a decision.

The decision, written as a rule

Replace the chain when you control the issuer and can enumerate its consumers. Escalate to the issuer when you do not. Lower the level only as a dated, scoped exception with the replacement already scheduled. Anything else leaves the same certificate in place and moves the risk somewhere less visible.

Then re-test the profile from a clean client, confirm the handshake completes, and keep the exact rejection text if it still fails. A precise error message is the cheapest thing you can hand to whoever owns the next layer.