OpenVPN Profile Has Three Certificate Blocks: Which Is Secret?

You open a .ovpn file to change one line and find three blocks of base64 that all look like credentials. One is safe to publish, one is as sensitive as a password, and one is a public key that means nothing unless something else signed with its pair. People paste the whole file into a support thread because the blocks look interchangeable, and that is how a client key ends up in a public archive. Sorting out which block does what explains most of the confusion around these profiles, and it also tells you which failures are yours to fix.

One file, three blocks, different jobs

A typical profile embeds a ca block, a cert block and a key block between BEGIN and END markers, or points at the same three as separate files. Some profiles add a fourth block for a tls-auth or tls-crypt key, which is a shared secret rather than a certificate. The client reads each block according to the directive that names it, so the labels matter more than the order they appear in.

Treat the assembled profile as sensitive until you have actually looked inside. A public certificate and a private key can sit a few lines apart in the same file, and a screenshot that includes the header may include both. Redacting the visible base64 by hand is unreliable too, because a partial block still leaks the certificate metadata that names your deployment. Copying the three directives without their values is usually enough to ask a useful question.

The directives around the blocks decide how they are used. Change ca and the client trusts a different authority; change cert without changing key and the handshake fails with a mismatch that has nothing to do with trust.

The CA block is public, the CA key never is

A certificate authority signs certificates that bind a public key to an identity, and its own certificate is the anchor a client uses to decide whether a chain is trustworthy. That certificate is public by design: shipping it inside every profile is normal, and it is the reason a self-signed deployment can work without a commercial authority.

What must never appear in a client profile is the authority's private signing key. The client does not need it to validate anything, and its presence means whoever holds the profile can mint new identities for the whole deployment.

Trusting an authority is also narrower than it sounds. A client that accepts any certificate signed by the CA will still accept a certificate issued for a different service on the same CA. Options that pin the expected server role or name close that gap, and the TLS options reference lists the verification directives that do it.

Server and client certificates point in opposite directions

The server's certificate is what the client inspects to confirm it reached the right endpoint. Your client certificate runs the other way: the server uses it to decide that this device or user is one it enrolled. Same format, opposite direction of trust.

An address is not an identity. Reaching the right IP proves nothing about who answered, which is why hostname or certificate-name checking still belongs in the profile. An account password does not quietly replace a required client certificate either, because the two are checked at different stages and a deployment can demand both.

The client private key is the part that must stay private. If it may have been exposed, deleting the file from your laptop changes nothing on the server, which will keep accepting the corresponding certificate until the operator revokes it. Asking the operator to replace or revoke that identity is the only fix that travels.

Two prompts that look identical and are not

A key stored in encrypted form asks for a passphrase before the client can use it. The VPN service may separately ask for an account password, and the two prompts can appear seconds apart with almost the same wording. The passphrase protects a file on your disk; the password proves an account to a server. Confusing them sends people to password resets that cannot possibly help.

Read the prompt before resetting anything. An account password reset does nothing for a forgotten key passphrase, a revoked certificate or an expired one, and resetting the password when the failure is certificate validation turns a two-minute fix into a support case. If the complaint mentions validity dates, check the device clock first, then the named certificate's own window.

When the certificate really has expired, the replacement has to come from whoever issued it. A key belonging to someone else is not a renewal path, and neither is borrowing a working profile from a colleague.

What a clean handshake does and does not prove

Reaching a completed TLS handshake means the configured identity relationship held: the server's certificate chained to your CA and your certificate was accepted. It says nothing about the operator's logging policy, and nothing about whether your applications will work once the tunnel is up.

Routes and DNS are later stages of the connection, so an unreachable intranet host after a successful login is a connectivity problem rather than a certificate problem. Work that layer instead of swapping credentials, and keep the profile's origin, its private material and its identity checks together when you hand it to anyone.