Before You Convert It: SSH Key vs OpenVPN Certificate

The import fails with a certificate error, so the obvious move looks like a conversion. That instinct sends people down a path where the file extension changes and the rejection stays exactly the same. An ssh-ed25519 line in authorized_keys and an OpenVPN client certificate are separate credential objects, with different issuers, different encodings and different revocation paths. Running through these checks in order tells you within a minute whether conversion can help at all.

Which object do you actually hold?

There are five things people call a key, and only one of them is what a TLS profile wants. An SSH public key is a single line of text with a type prefix and base64 payload. An OpenSSH certificate is that key plus a signature, principals and options, produced by ssh-keygen acting as its own small CA. An X.509 certificate is a different structure entirely, carrying a subject, validity window, extensions and a signature from a certificate authority. A private key is the secret half, and an issued bundle is usually a certificate plus its chain plus the private key in one file.

The first test costs one command. Point openssl at the file and ask it to parse the certificate structure:

openssl x509 -in client.crt -noout -subject -issuer

If that fails with an unable-to-load or PEM error, the file is not an X.509 certificate no matter what you named it. A rename does not rewrite the ASN.1 inside, and neither does wrapping a public key line in PEM header text.

Does the profile ask for a certificate at all?

Client certificates are one authentication method among several, and plenty of working TLS profiles never request one. A server can authenticate users through a plugin, a username and password, or a token backend, while still requiring the client to verify the server's identity. If the profile does not carry a client-certificate directive, no certificate will ever be requested, and no conversion will make the gateway ask for one.

Older static-key configurations are a third case again. They predate the TLS handshake and expect a pre-shared secret file, which is why pasting a public key into that field cannot work either. Read what the profile actually asks for before deciding the credential is wrong.

What re-encoding can and cannot do

Private keys do have legitimate alternate containers. The same RSA or EC key can be written as traditional PEM, as PKCS#8, or inside a PKCS#12 bundle, and tools will happily convert between them. Public keys have a similar story: ssh-keygen can emit the RFC 4716 form of an SSH key, and OpenSSH also understands its own certificate format. All of that is representation, and representation is not trust.

What conversion cannot do is create a signature from a certificate authority that has never seen your key. A certificate is an assertion by an issuer that a particular public key belongs to a particular subject for a particular purpose. Re-encoding preserves the bytes of the key and leaves the assertion absent, so the gateway has nothing to validate against its trust store.

This is the step where most attempts quietly fail: the file now ends in .crt, the client reads it without complaint, and the handshake still aborts because the peer cannot build a chain to a trusted issuer.

Where the certificate authority enters the picture

Real enrollment starts with a key pair you control and a certificate signing request that carries the subject the operator expects. The operator verifies entitlement, signs the request with the CA key, and returns the issued certificate together with any intermediate chain the client must present. The client then needs the CA certificate that signed it, because that is what lets it confirm the server it is talking to belongs to the same deployment.

That last file is easy to forget and impossible to substitute. The CA's signing key itself never belongs in client configuration, and no amount of local conversion produces the chain you were supposed to receive.

What reusing the SSH key costs you

Suppose a conversion did produce something acceptable. Reusing one key pair across SSH access and VPN authentication still couples two independent security decisions. Removing an authorized_keys entry stops SSH logins, and it does nothing to a certificate the VPN CA already issued for the same public key. The VPN side is revoked through its own mechanism, which means the certificate revocation list or the operator's enrollment record.

So the checklist ends with a stop condition rather than a trick. If openssl will not parse the file as a certificate, stop converting and describe what you have: SSH key, SSH certificate, X.509 certificate, private key, or bundle. If the profile does not request a client certificate, stop and ask which authentication method the server expects. Only when both answers point at X.509 does enrollment become the next step, and that conversation goes much faster with the right noun in the first sentence.