BadCertificateInvalid

BadMalformed / empty DN

What you actually see

The handshake fails immediately with no useful detail, and moving the certificate into the trusted store makes no difference at all.

Why it happens

• Empty subject or issuer distinguished nameA certificate with an empty subject or issuer DN is rejected structurally, and that rejection is not suppressible in modern stacks. It typically comes from a generator invoked without a subject argument, or from a template where the common name field was left blank. The certificate looks fine in a file listing and fails everywhere.
• CA certificate lacking cRLSign in its key usageOPC UA expects every CA certificate in a chain to assert both keyCertSign and cRLSign. A corporate CA that omits cRLSign - which is common, because it is not required by every other protocol - breaks OPC UA, and strict stacks report it with this unhelpful code rather than a specific key usage error.
• Malformed or truncated certificate fileA PEM file with a corrupted base64 body, a DER file transferred as text, a certificate concatenated into a bundle in the wrong order, or a file truncated by an incomplete copy all fail to parse. This is the first thing to test because it is the fastest to rule out.
• Missing extensions the profile requiresAn application instance certificate needs a SubjectAltName carrying the ApplicationUri as a URI entry and the endpoint's DNS name or address, plus appropriate KeyUsage. A certificate generated as a generic TLS server certificate can be missing what OPC UA needs, and where the omission is structural rather than a mismatch it surfaces here.
• Empty or absent certificate where one was expectedA zero-length certificate file, a configuration pointing at a path that does not exist, or a container whose PKI volume was not mounted produces an empty certificate. The application starts and fails at the first handshake with a code that suggests a certificate problem rather than a missing file.

How to fix it

In diagnostic order: work down, do not skip ahead.

1. Parse the certificate outside the stackRead the certificate with a standard X.509 tool and confirm it parses at all. If it does not, the problem is the file: re-export it, check whether it is PEM or DER, and confirm the transfer did not corrupt it. This eliminates the largest single cause in one step.
2. Check the subject and issuer DNs are non-emptyPrint both. An empty DN is fatal and non-suppressible. Regenerate with an explicit subject including at minimum a common name and an organisation, matching the pattern your PKI uses for other applications.
3. Check every CA in the chain for keyCertSign and cRLSignDump each CA certificate's KeyUsage extension. Both bits must be asserted. A CA missing cRLSign cannot be used with OPC UA and must be reissued, which is a PKI change rather than an application one - raise it with whoever runs the CA early, because it takes time.
4. Regenerate the application certificate with the required extensionsInclude the ApplicationUri as a URI entry in SubjectAltName alongside the DNS names or addresses of the endpoint, set KeyUsage to include digitalSignature and the encipherment bits the transport needs, use a 2048-bit or larger RSA key, and sign with SHA-256.
5. Confirm the file the application is actually loadingLog the resolved path of the certificate and key at startup and its size. A configuration pointing at the wrong directory, or an unmounted volume in a container, is indistinguishable from a malformed certificate from the error alone.
6. Check the private key is present and matchesA certificate without its private key, or paired with a key from a different generation, fails at the handshake. Confirm the modulus of key and certificate agree, and that file permissions let the application read the key.

Where it shows up, by tool and stack

What it looks like in the log

Certificate structural validation failed: empty subject distinguished name
CA certificate CN=Corp Issuing CA lacks cRLSign key usage; chain rejected
Failed to parse certificate at /app/pki/own/certs/app.der

Confirm the fix

Confirm the certificate parses with a standard X.509 tool, that subject and issuer DNs are populated, that every CA in the chain asserts keyCertSign and cRLSign, and then that the handshake completes without the certificate reaching the rejected store.

Stop it happening again

Generate certificates from a reviewed template with explicit subject, SubjectAltName and KeyUsage, validate CA key usage before adopting a corporate CA for OPC UA, mount container PKI on persistent storage, and check certificates at commissioning rather than at first connection.

Last verified 7 September 2026 against OPC UA 1.05.07. OPC UA Connect is an educational resource and is not affiliated with the OPC Foundation.