unsupported certificate purpose: Why the Intermediate CA Fails

Server certificate purpose looks right, the key matches, the dates are fine, and the connection still fails with unsupported certificate purpose. The detail that resolves this is usually in the same line as the error: a depth value and a subject that name a certificate higher in the chain. Two different tests are being run, and only one of them is about the leaf. Comparing them explains why replacing the server certificate changes nothing.

Which Certificate the Verifier Actually Rejected

A chain is not one object repeated three times. The leaf carries the server's name and key, the intermediates link it to a root, and each has its own validity period, constraints and usages. When the error names a depth, that number identifies a position in the chain the verifier built, which may not be the position you expect if the server sends an unexpected chain.

Read the fields of the certificate at that depth rather than the certificate you assumed was at fault. Ask for the two extensions that constrain issuance instead of dumping every field, since the answer is nearly always one of them. Extension output is safe to share; private keys never are.

openssl x509 -in issuing-ca.pem -noout -subject -issuer -ext basicConstraints -ext extendedKeyUsage

If the named certificate is an intermediate whose extended key usage mentions something unrelated to TLS server authentication, the rest of the failure follows mechanically. The chain cannot be used for the purpose that OpenVPN requested.

Leaf Purpose and Chain Policy Are Two Tests

The leaf test asks a narrow question: does this end-entity certificate permit server authentication for this name? The chain test asks a broader one: may every certificate in the path serve that purpose? A certificate authority that is permitted to issue only client certificates will pass its own signature checks and still fail the second test, because the path it authorises does not include the purpose the application needs. The two tests fail with the same words and have entirely different repairs.

That is why a freshly issued leaf, correct in every visible field, can fail immediately. It is also why the fix usually belongs to the issuing authority's profile rather than to the VPN configuration.

An Absent EKU Is Not a Restrictive EKU

RFC 5280 makes the extended key usage extension optional and, when present, constraining. A CA certificate without the extension therefore has not said "no" to server authentication, while one that lists only an unrelated purpose has said something quite specific. Treating those two states as equivalents produces the wrong diagnosis and, worse, the wrong repair. The distinction also explains why two authorities that look similar in a console behave nothing alike in a chain.

Library behaviour is not uniform here either. OpenSSL's verification options document describes its own treatment of purpose checks on CA certificates, and that treatment is an implementation policy rather than a rule every TLS stack follows identically. Describe what your verifier does, then confirm it against the version you actually run.

Reproduce the Failure Offline Before Reissuing

An offline verification removes the application from the question. If the chain fails the same way under the same purpose, the certificate is the problem and no amount of server configuration will hide it. If the chain passes offline while the service still refuses, the application is requesting a different purpose or is using a different chain than the one you tested.

openssl verify -purpose sslserver -show_chain -CAfile root-ca.pem -untrusted issuing-ca.pem vpn-server.pem

-show_chain matters because it prints the path the tool constructed, which is often not the file order you supplied. That output is the fastest way to discover that a second intermediate is being pulled from a trust store, that the server sends a cross-signed variant you did not intend, or that the purpose flag you copied from a tutorial belongs to a different role than the one being served.

Fix the Issuance Policy, Not the Verification Call

The durable repair is an intermediate issued under a policy that permits the purposes it must serve, with the constraint written down and reviewed. Adding every purpose to every authority is not a policy; it removes the constraint that made the extension meaningful in the first place, and it usually outlives the incident that prompted it. A short note in the profile describing which roles the authority may certify prevents the next reissue from repeating the argument.

Disabling verification is the other tempting shortcut, and it converts a certificate problem into a trust problem. Keep the purpose check in place, correct the chain, and re-run the same offline verification to confirm the path now serves the intended role before touching the service again.