Bad_CertificateUseNotAllowed Means Certificate Usage Is Invalid

At client.connect(), this Prosys OPC UA Java setup received Bad_CertificateUseNotAllowed with its supplied application certificate; the later Bad_CommunicationError read timeout to the device is a separate failure on the TCP path. Trace the request from the client to the listening address and port first, then separate application-certificate validation from user authentication and certificate trust.

Where does each failure stop in the OPC UA connection path?

The initial status has code 0x80180000 and says the certificate may not be used for the requested operation. That is different from the later device error, whose stack trace shows a read timeout while opening a TCP channel during endpoint retrieval. A ping reply or a TCP connection alone does not verify that the OPC UA exchange is completing.

The first setup used SecurityMode.BASIC128RSA15_SIGN_ENCRYPT and passed a certificate and private key as both application identity and user identity. The same status remained after switching to new UserIdentity(), which is the anonymous identity. That change removes a user certificate from the request, but it does not remove the client application certificate from the secure connection.

Which certificate travels through each identity check?

OPC UA separates the application’s secure-channel identity from the authenticated user. Their certificates can be examined or trusted by different server components, so diagnose the role before changing a validator.

Using one certificate for both the application and user roles obscures which validator rejected it and is not the recommended arrangement. Use separate application and user certificates when both identities require certificates. If the failure remains with an anonymous user, concentrate on the application certificate and the server’s application-certificate validator rather than repeatedly changing the user identity.

Which correction should you choose for this certificate rejection?

Correct the certificate profile and identity assignment before relaxing validation. The evidence includes both a successful connection with an SDK-generated application certificate and a later report that missing Key Usage and Extended Key Usage extensions produced this same status.

Recommend the first two approaches. The SDK 4.3 validation checks exposed certificates that had been accepted by earlier SDK behavior; success with version 2.2 is not proof that a certificate has the required extensions. In the described setup, generating an application identity through ApplicationIdentity.loadOrCreateCertificate allowed connection, while supplying the existing certificate and key did not.

How do you inspect an application-instance certificate?

First determine whether the certificate is a CA certificate. A CA certificate is not suitable as the application instance certificate in this setup; create a non-CA application certificate and have the CA sign it instead. Then inspect both the Key Usage and Extended Key Usage extensions. The certificate may be trusted and still be unusable for its requested role if those extensions are absent or do not include the required purposes.

1. Open the actual certificate file in the operating system certificate viewer or inspect its decoded output with an available certificate tool. Confirm the extensions are present and contain the purposes listed above.
2. For a Java-side spot check of the Non-Repudiation bit, inspect cert.certificate.getKeyUsage()[1]. This checks one bit only; it does not prove the other Key Usage bits or Extended Key Usage values are correct.
3. If the certificate is a CA, replace it with a non-CA application instance certificate signed by that CA. Do not try to turn the CA certificate into a leaf identity simply by adding it to a trust folder.

The application instance certificate requirements listed for this case include all four Key Usage purposes and the client/server authentication Extended Key Usage entries. Verify the specific certificate used by the running client, not only the CA certificate or a different file in the same directory.

How should application and user identity files be assigned?

Give each role its own certificate and private key. In the client, assign the application identity to the application and assign a separate user identity only if the server requires X.509 user authentication. Keep the file names distinct: reusing a file pair makes it easy to load the wrong identity and makes rejected-certificate diagnosis ambiguous.

1. Set the client application identity from the non-CA application instance certificate and its matching private key.
2. For an anonymous test, set client.setUserIdentity(new UserIdentity()). Do not also configure the application certificate as the user identity.
3. If the server requires a certificate-based user, create or load separate user certificate material, then set that as the user identity. The sample workflow uses ApplicationIdentity.loadOrCreateKeyPair for a user key pair; use distinct file names from the application certificate files.
4. Repeat the connection test with the anonymous identity, then with the user certificate. Record which attempt returns the status so the application and user validation paths remain distinguishable.

This is a role assignment correction, not a trust correction: the separate user certificate must still meet its certificate requirements and be trusted by the server’s user-certificate policy.

How do you establish trust without masking a usage defect?

Trust answers whether a certificate or signing CA is accepted; Key Usage and Extended Key Usage answer whether the certificate can perform the requested operation. Fix the certificate profile first. Moving a certificate into a trusted folder cannot supply missing usage extensions.

For a server based on the sample configuration, the default application certificate locations are under PKI/CA, while user-certificate locations are under USERS_PKI/CA. When a connection attempt is rejected for trust, the sample workflow places the certificate in the applicable rejected folder. Review that exact certificate, then move it to the matching certs folder only if the trust decision is intended.

1. For an application certificate signed by a CA, place the CA public certificate file, such as the DER file, in PKI/CA/issuers/certs. For a user certificate, use USERS_PKI/CA/issuers/certs. If the CA signs both roles, follow the issuer path for both.
2. To trust any certificate signed by that CA, the described sample workflow places the CA public key in the relevant PKI/CA/certs and/or USERS_PKI/CA/certs folder. Choose the application or user trust store according to the role being validated.
3. Retry using a signed connection mode such as Sign or Sign and Encrypt, then inspect the new status and rejected folder if the server still rejects the certificate.

Bad_SecurityChecksFailed is a generic security failure, and an untrusted client certificate is one common cause. A trust-store change may address that status, but it does not establish that the certificate has the correct profile or that a user validator is applying the intended policy.

How do you verify the certificate correction in SDK 4.3?

Use the SDK-generated identity as a known-good comparison, then substitute the corrected custom certificate. This separates certificate construction from a broad validator change. The described client connected when it used ApplicationIdentity.loadOrCreateCertificate; the supplied custom certificate failed. SDK 4.3 added certificate validation checks that were absent or less strict in the earlier 2.2 behavior described here.

1. Run the client with a generated application instance certificate and an anonymous user identity. Keep the secure mode enabled and verify that connection succeeds.
2. Replace only the application certificate and matching private key with the custom non-CA certificate. Confirm its Key Usage and Extended Key Usage values before retrying.
3. If the status changes to Bad_SecurityChecksFailed, investigate application-certificate trust separately. Check the application rejected and certs paths rather than changing the user validator.
4. If the application test succeeds but the certificate-authenticated user test fails, inspect the user certificate and the server’s user validator, including any sample-derived MyUserValidator behavior.
5. Retest with the exact client and server SDK versions deployed. Do not treat a successful connection on 2.2 as validation of the certificate under 4.3.

Changing a sample server’s UserValidator to accept selected statuses applies only to user certificates. If the server rejects an application certificate, the relevant component is its application CertificateValidator; accepting a bad status there is a deliberate policy exception, not the preferred repair.

What does the device’s separate TCP timeout show?

After the certificate-validator change, the client reported a different failure while contacting the server on the device: Failed to retrieve endpoints, Bad_CommunicationError (0x80050000), and Read timed out while opening the TCP channel. The endpoint shown later was opc.tcp://bibhu:52520/OPCUA/N4OpcUaServer. This is a no-response transport/handshake symptom, not a certificate-use rejection.

The device manufacturer reportedly said the device had no firewall, but verify the actual packet path rather than inferring application availability from ping or a listening socket. The server was also tested with IPv6 disabled through server.setEnableIPv6(false); that did not resolve the timeout. Its reported actual hostname changed from 127.0.0.1 to bibhu, and the failure persisted. The loopback address is not a usable remote host name, but correcting it alone was not sufficient in this case.

How do you narrow the server-side path without guessing?

Use tests that preserve the direction and endpoint which fail. For the device case, the server ran on the device and the remote laptop initiated the connection. The listener output included port 52520, including mapped IPv4-looking entries under a tcp6 label. Do not infer from that display alone that the server is listening on every address or that it has bound incorrectly: a server socket listens on an address-and-port combination, and a wildcard address differs from a specific interface address.

1. On the device, record the server’s actual hostname and resolve that name from the laptop. Confirm the endpoint host resolves to the intended device interface, not loopback. The earlier value 127.0.0.1 was a loopback address; setting a host name to bibhu did not by itself fix this reported timeout.
2. Compare the server’s listening address and port with the remote destination and capture the attempt in Wireshark. Confirm whether the request reaches the device interface and whether any response leaves it. A TCP ESTABLISHED state or a packet arriving at the device does not prove that endpoint discovery completed.
3. Repeat the four path comparisons from the table, keeping client/server placement explicit. For a same-host capture, the diagnostic guidance calls for the Npcap Loopback Adapter when prompted so loopback traffic is visible.
4. Compare SDK releases only as a controlled test. The discussion proposed testing 2.3.2 with both the stack and SDK jars updated, because that release line included socket CLOSE_WAIT fixes. The new SDK had IPv6 enabled by default in the described comparison, so record IPv6 configuration and bound addresses rather than attributing the timeout to IPv6 without a test result.
5. If the target still receives the request and sends no response, retain the Wireshark capture and collect SDK TRACE logs from both applications. The guidance recommends rolling logs into multiple files of 50 or 100 MB because loading the address-space model can produce substantial output.

The certificate correction and device timeout require separate closure criteria. Close the certificate fault only after the custom certificate passes profile, role, and trust checks. Close the device-path fault only after the target replies to the endpoint/secure-channel exchange and the client completes endpoint retrieval.

What do engineers ask about this OPC UA failure?