Self-signed client certificate? The VPN server still refuses it

The operator sends an address and a username, and the client asks for a CA file, a certificate, and a key. Generating those three locally feels like the obvious next step. It produces a certificate that only your own machine believes in. The server's trust is anchored in a CA you do not control, so the handshake ends before it starts.

Trust lives on the server, not in your profile

Certificate authentication is a comparison. The client presents a certificate; the gateway checks whether it was signed by one of the CAs in its configuration.

Your profile names the CA file the client should use to verify the server. It cannot name a CA the server should use to verify you. That half of the configuration is not yours.

A self-made certificate fails this comparison even when it is technically perfect. It has a valid signature, a subject, and dates, but the issuer is a CA the gateway has never heard of. The error appears during the handshake, after the server has already asked for a certificate. Nothing in the client profile can change the answer.

Why a self-signed certificate cannot substitute

A self-signed certificate is signed by its own key. The signature verifies against the same file, which makes it self-consistent and useless as a credential for someone else's gateway.

The gateway is not asking whether the certificate is internally consistent. It is asking whether a trusted issuer signed it.

This is why the error messages are confusing. The client may report a verification failure that sounds like a server problem, while the server logs an unknown issuer. Both are describing the same mismatch from opposite ends.

The CSR path keeps your private key

You can still do most of the work locally. Generate a key pair, build a certificate signing request around the public half, and send that request to the operator. Only the request leaves your machine. The private half stays where you generated it.

openssl req -new -newkey rsa:3072 -nodes -keyout client.key -out client.csr -subj "/CN=laptop-01"

The operator signs the request with their CA and returns a certificate. Your private key never traveled, and the result chains to the anchor the gateway trusts.

Managed services often skip the CSR and issue the whole bundle. That is a reasonable trade when the same provider already terminates the tunnel and holds the CA. The key's custody is not improved by keeping it, because the provider could mint a new one at any time.

Bundles are imported, not installed

Vendor bundles with security-sounding names are frequently OpenVPN profiles. They contain configuration and sometimes certificates, and they do not install anything. Import the file into a client that speaks the protocol, and the connection is configured.

The handling rule follows from the contents. If the profile embeds a private key, it is a credential and deserves the same care as a password: no email, no repository, no shared downloads folder. When the operator ships ca.crt, client.crt, and client.key separately, store them together with restrictive permissions and point the profile at them.

Add the checks the operator may have skipped

A router-generated profile sometimes lacks peer verification. remote-cert-tls server requires the peer certificate to carry the server authentication purpose, so a client certificate cannot be replayed as a server. That one line is a small change with a clear justification.

verify-x509-name goes further when the operator can name the expected subject or SAN. Both are small additions to a profile, and both are defensible. Inspect what you received before importing it.

openssl x509 -in client.crt -noout -issuer -subject -dates
openssl verify -CAfile ca.crt client.crt

Verification settings are not a repair for a broken chain. If the issuer is wrong, the answer is a certificate from the right CA, not a flag that turns checking off. Turning verification off converts an authentication failure into an undetected one.

Ask for one bundle: the authority certificate as PEM, a client certificate that authority signed, a key you generated or that arrived through a channel you trust, and the exact server name the certificate should present. Note the expiry date in the same message, since a lapsed certificate looks like a network fault months later.