Static key or TLS for a two-peer OpenVPN link?

Two machines that talk only to each other can keep that topology and still get negotiated traffic keys. The network shape and the protection mode are independent choices, and conflating them is what makes people try to rotate a static secret by swapping a file while both daemons keep running. Swapping the key file under a running pair does not rotate anything. Static-key mode, which OpenVPN 2.6 marks deprecated, holds one key for the life of the tunnel, so the file on disk and the key in memory only agree again after both ends restart. If automatic renewal is the requirement, the protection mode has to change.

What static-key mode cannot do

In secret mode, both peers share a pre-shared key that encrypts and authenticates the tunnel directly. There is no handshake, so there is no mechanism for either side to propose new key material, prove an identity, or recover from a mismatch without operator intervention. Both properties follow from the absence of a control channel rather than from a missing option, and no configuration flag adds one to this mode.

The OpenVPN 2.6 manual is explicit that the key persists until a new one is generated. That is acceptable for a lab link or a fixed pair of appliances with a documented rotation procedure, and it is unacceptable wherever a long-lived secret is a real risk. A file swap does not create a new key for a running pair; it creates two peers that disagree. Replacing the file therefore adds an outage without adding rotation.

There is also no notion of peer identity beyond possession of the file. Anyone who holds the key is a peer, and nothing in the tunnel records which side is which, so revocation is all or nothing.

Moving to TLS without redesigning the link

TLS mode adds a control channel, and with it the ability to negotiate data-channel keys. In a point-to-point deployment, one side takes the server role and the other takes the client role, but the topology stays a two-peer link: each side knows the other's endpoint, and no pool or multi-user service appears. The roles are a handshake detail, not a new architecture.

Give each machine its own identity. Each side needs a certificate and private key, the trust anchor that validates the other, and a peer-verification rule that names who is expected. Do not reuse one peer's private key on the other to save time; that turns two identities into one and removes the ability to revoke either side separately. Enrollment is the place to get this right, because fixing it later means reissuing certificates.

Keep the network contract unchanged while the protection changes. The same tunnel addresses, routes and permitted services should apply before and after, so a failure during the migration is a protection problem rather than a routing surprise in disguise. Write the addresses and routes down before the change; comparing them afterwards is faster than reconstructing them from memory.

Some deployments also protect the control channel with its own static key, which does not rotate with the data channel. That key guards the handshake rather than the payload, so a compromise of it exposes negotiation rather than traffic. Store it apart from the data-channel material, and give it a replacement date that a named person owns. Rotating it means restarting both peers in a coordinated window, which is why it deserves a calendar entry rather than a memory.

Who renews what, and when

In TLS mode, renewal is driven by configured limits: a time interval, a byte count, or a packet count. The documented time control is what most deployments rely on, and the lower effective value across the two peers can start the replacement, so raising it on one side alone will not hold the event back. Volume-based limits exist because a busy link can exhaust a key long before the clock does. Neither limit is a health check, and neither one tells you that a renewal succeeded.

That is why diagnosing a recurring renegotiation from a single configuration file is misleading. Read the settings on both peers, then look at the log transition rather than assuming a fault. A renewal that completes cleanly looks like a short burst of control-channel traffic, not like a disconnect.

Keep the objects separate in your head. The certificate proves long-term identity and is replaced on a schedule you control. The data-channel key is refreshed automatically, and a separate authentication exchange, if the deployment requires one, follows the account policy and may need its own arrangements for later exchanges.

Disabling renewal entirely, by setting the interval to zero, is not a fix for a noisy log. It converts a healthy lifecycle event into a permanent key, which returns you to the property you were trying to leave behind.

Accepting the change

Build the new configuration from the installed release's supported example rather than an old minimal snippet whose algorithms and file paths were inherited from somewhere else. Coordinate the switch so both peers change together, and keep an approved recovery path in case one side fails to come up. Bring the link down deliberately rather than waiting for an outage to test the rollback. A rollback you have rehearsed is worth more than a rollback you have described.

Test three things: initial identity verification succeeds, the intended application flow works, and a controlled renewal happens without losing traffic. Then read the transition in the log for what it actually proves: a new key identifier means the peers completed a replacement, not that the tunnel reconnected. Treat it as evidence of one step, and check the traffic counters before calling the migration done.

What a zero-interruption promise would hide is the failure you have not seen yet. A renewal that fails, a certificate that expires or a path fault can still disturb the link, and none of them is ruled out by a clean test run. The property worth designing for is narrower and more useful: routine key replacement stops being a manual file swap.