One Old Peer Forces TLS 1.0: Scope the Exception, Not the Host

One old device turns up, fails to connect, and the fastest-looking repair is to weaken the whole host until the connection succeeds. That trade is invisible in the moment and permanent in practice, because nobody removes a floor that finally works. Two very different faults create the pressure, and only one of them is about ciphers at all. Sort the fault first, then put the exception somewhere it cannot spread.

Split the failure in two before editing a directive

A server log line about no shared cipher, or about an unsupported protocol version, comes from the control channel: the two ends could not agree on how to protect the negotiation itself. A client line saying that no server certificate verification method is enabled comes from somewhere else entirely, because that client is not checking who answered at all. Changing a data cipher does nothing for the second case, and adding a role check does nothing for the first.

Take the earliest failing line from each side rather than the last line before the disconnect, since the final one is usually a consequence. Then establish which file the client actually opened: an imported profile often exists twice under different display names, and editing the copy nobody reads produces a convincing non-change. A running process keeps the settings it started with, so a saved file is not a loaded file. The commands below show the client's negotiation beside the server's view of the same attempt.

openvpn --config <profile>.ovpn --verb 4 2>&1 | head -n 40
journalctl -u [email protected] --since '-10 min' | grep -iE 'cipher|tls|verify'

A second listener is the honest place for a weaker floor

When the device tops out at TLS 1.0 with a pre-2.5 data channel, the server has to offer a lower control-channel floor and a data cipher the old client recognises. The fallback directive exists for exactly that peer, while the cipher list keeps modern clients on modern suites. Both directives belong to the listener rather than to a user or a connection, and no per-client option narrows them afterwards. That is why one legacy device on the main port is a decision about every peer that shares it.

Where the platform allows it, run the legacy listener as its own instance on a separate port, allow that port only from the device's address, and leave the main service alone. Write down why the second listener exists, in the file that carries its configuration, because a future cleanup will otherwise read it as leftover debris. The split is only worth having if the weaker floor ends where the device does.

tls-version-min 1.0
data-ciphers AES-128-GCM:AES-256-GCM:AES-256-CBC
data-ciphers-fallback AES-256-CBC

What an old provider certificate actually breaks

The verification error is a missing role binding: without it the client will accept any certificate that chains to a trusted CA, whether or not that certificate was issued for a server. Bind the certificate to the server role first, and treat the binding as a requirement instead of a tuning knob. Only a profile that still fails after that step has a genuine certificate problem.

An old provider certificate whose key size or signature algorithm no longer satisfies the default OpenSSL policy is the case for a scoped security-level change on the control channel. Lowering the level there does not switch verification off, and it must never be combined with an empty CA, a disabled verification setting or an unchecked hostname. Keep the line inside the one profile that needs it; exporting a relaxed OpenSSL configuration globally would hand the same relaxation to every program on the machine.

remote-cert-tls server
tls-cipher "DEFAULT:@SECLEVEL=0"

Reading the negotiated values, not the banner

At verbosity 4 both ends print the control-channel TLS version and cipher they settled on, and the data cipher for the session. Read those lines rather than the initialisation banner, which reports success and not the terms of it. Then reconnect a modern client to the main listener and confirm it still lands on a modern suite, because an exception that leaked into shared configuration shows up here first. The values you copy out become the baseline for the next review.

Test the old device on its own: it should connect, and it should be the only session in the logs showing the weaker parameters. If a second peer also negotiates the old suite, the exception is broader than intended and the listener split did not really happen. Record both observations rather than the conclusion alone.

Every exception needs an owner and a date

An exception with no removal condition quietly becomes the default, so put the device, the owner, the reason and the date it goes away next to the configuration it justifies. Without that line the weaker floor outlives the hardware that needed it.

Replacing the client, or asking the provider for a current profile, is the outcome to aim for; the exception is a delay and not a design. When the device retires, remove the listener and the profile in the same change so neither half stays running. None of this makes the old parameters safe, it only keeps one device's limit from becoming everyone's baseline.