SECLEVEL=0 Fixes the Symptom, Not the Certificate

An OpenVPN connection fails, someone finds a one-line fix that adds SECLEVEL=0, and the tunnel comes up. What changed was not the certificate and not the cipher suite; a library-wide acceptance threshold moved, and everything the process does afterwards inherits the new boundary. That is worth understanding before the same line gets copied into every profile on the estate.

Find which library and which policy are in effect

SECLEVEL is an OpenSSL concept, so the first question is whether your build uses OpenSSL at all. OpenVPN can be linked against more than one cryptography library, and a setting that applies to one of them is meaningless to the others. Ask the binary what it was built with, then ask the library what version and configuration it loaded:

openvpn --version | head -3
openssl version -a

Read the version output carefully, because distributions patch defaults. Some ship a system configuration that raises the minimum level above the upstream default, which is why the same profile behaves differently on two machines with identical OpenVPN packages. The effective policy is the one the running process loaded, not the one in the upstream manual.

Then separate the two layers people conflate. OpenVPN has its own TLS controls, including a certificate profile setting and explicit cipher lists, and those sit above whatever the library enforces. Lowering the library level does not change which ciphers your OpenVPN configuration lists, and narrowing the OpenVPN list does not raise the library threshold. Knowing which layer refused you is what keeps the fix from being a guess.

Separate the three things that can be rejected

The first candidate is identity material: a certificate whose key is too small or whose signature algorithm the policy no longer accepts. The second is a key-exchange parameter, such as a group the policy considers too weak. The third is a cipher suite the policy excludes. All three can produce a handshake failure, and only the error text and the negotiation stage tell them apart.

None of those three is the data-channel cipher. OpenVPN negotiates its tunnel encryption separately from the TLS handshake, so a connection that succeeds after a security-level change says nothing about which cipher protects your payload. If the question you are actually asking is about data confidentiality, you are looking at the wrong dial entirely.

Lowering the level widens acceptance for all three inputs at once. That is the part people miss: the fix that admits an old certificate also admits a weak group and a suite you may not have intended to permit. A single error prompted the change, and the change is broader than the error. That asymmetry is the reason a scoped exception beats an estate-wide default.

Change the input, not the threshold

Preserve the exact error before touching configuration, including the stage that reported it and the object it named. A certificate problem is resolved by replacing the certificate with something the current policy accepts, which usually means reissuing from the authority rather than reinstalling the same file.

If the rejected input belongs to a peer you do not control, the conversation is with that peer's owner about supported replacement material. Lowering your own threshold to accommodate a system nobody maintains moves the cost from them to everyone who connects after them.

Where the server enforces the policy, check whether an OpenVPN-level setting is the actual cause before blaming the library. A certificate profile that asks for a stricter class than the deployed certificate can satisfy will fail no matter what the security level is set to, and removing that profile is a narrower change than disabling library checks.

If you must lower it, scope it and record it

Sometimes an approved compatibility exception is the right answer, particularly for a legacy peer with a dated retirement plan. Scope it to the service that needs it rather than the whole host: a per-service configuration file or a dedicated OpenSSL configuration is a smaller blast radius than an export in the global profile.

Write down four things with the exception: the exact setting, the owner who approved it, the clients it affects, and the condition under which it gets removed. An exception without a retirement condition is a permanent weakening with a temporary justification attached.

Rollback should be a single step you have already tested. Keep the previous configuration, apply the change, confirm the service starts, and know exactly which file to restore if the next connection behaves differently than expected.

Verify identity and protection afterwards

A successful connection only proves the revised conditions admitted it. Confirm that hostname and peer verification are still doing their job, that the certificate in use is the one you meant to deploy, and that the negotiated data channel matches the policy you think you have.

openssl x509 -in /etc/openvpn/client.crt -noout -subject -dates -text | grep -E 'Signature Algorithm|Public-Key'
openvpn --show-tls | head -20

The OpenSSL security-level reference is explicit that the framework applies limits across keys, signatures, groups and suites together, and that level zero permits everything the callback checks. That is the scope of what you changed, and it is the sentence to quote when someone asks whether the fix was narrow.

The handoff that survives an audit says which policy rejected which input, what was changed, and what remains accepted as a result. "It works with SECLEVEL=0" is an observation about one connection, not a security assessment of the deployment.