Hard to debug certificate issues

[robert-schaft-hon]

trafficstars

Given the situation: Milo Java and Prosys stacks are not connecting. Something is wrong with my certificates.

Actual behaviour

• Milo stack doesn't tell me, which certificate it has an issue: client, server or even one in the CA chain.
• Milo stack doesn't tell me, if an error message comes from the other side or from its own checks. Since they are standardized, they read all the same.
• Milo stack doesn't tell me, what it expected of a certificate.

Expected behavior

• "Identity Certificate xyz is missing X509v3 Key Usage Data Encipherment"
• "Identity Certificate xyz uses key size greater than 4096 bit"
• "Connection refused by server with reason Bad_CertificateUseNotAllowed: The Certificate may not be used for the requested operation."
• "Missing NonRepudiation flag in server certificate id 1234"

Logs s java.util.concurrent.CompletionException: UaServiceFaultException: status=Bad_CertificateUseNotAllowed, message=The Certificate may not be used for the requested operation. at java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:292) ~[?:1.8.0_242] at java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:308) ~[?:1.8.0_242] at java.util.concurrent.CompletableFuture.uniApply(CompletableFuture.java:607) ~[?:1.8.0_242] at java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:591) ~[?:1.8.0_242] at java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:488) ~[?:1.8.0_242] at java.util.concurrent.CompletableFuture.completeExceptionally(CompletableFuture.java:1990) ~[?:1.8.0_242] at org.eclipse.milo.opcua.stack.client.UaStackClient.lambda$deliverResponse$5(UaStackClient.java:273) ~[stack-client-0.3.3.jar:0.3.3] at org.eclipse.milo.opcua.stack.core.util.ExecutionQueue$Task.run(ExecutionQueue.java:119) [stack-core-0.3.3.jar:0.3.3] ] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:1.8.0_242] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:1.8.0_242] at java.lang.Thread.run(Thread.java:748) [?:1.8.0_242] Caused by: org.eclipse.milo.opcua.stack.core.UaServiceFaultException: status=Bad_CertificateUseNotAllowed, description=The Certificate may not be used for the requested operation. ... 5 more

Additional context I use milo 0.3.3 as client connecting to C++ prosys server.

[kevinherron]

Unfortunately there's not much more info I could tell you. The Bad_CertificateUseNotAllowed StatusCode comes from the server and does not include more information.

If you can share your certificate(s) I may be able to help you figure out what's wrong. How did you generate them?

[robert-schaft-hon]

The issue is: You - as a milo developer - can see (based on the stack?), that the Bad_CertificateUseNotAllowed comes from the server. But it is not obvious to me. Can't you make that more obvious, that the other side returned that status code?

[kevinherron]

I will take that into consideration but it's not immediately obvious to make that more clear.

FWIW, a UaServiceFaultException can only be generated when a ServiceFault is received from the server, and more generally, in very few circumstances does the client return a StatusCode of its own choosing in an exception (Bad_Timeout is the only one I can immediately think of); they are generally returned by the server in response to some request from the client.

[robert-schaft-hon]

So what does the client do if the server certificate e.g. doesn't have the keyEncipherment flag?

You could add a little more text to the UaServiceFaultException message: "Connection refused by server with status=Bad_CertificateUseNotAllowed, message=The Certificate may not be used for the requested operation."

[kevinherron]

Yeah that would be another case that would need to be determined by looking the stack trace. I had once considered using a different Exception type for errors generated client-side versus server-side but it was difficult to implement in practice. Maybe I should take another look at that before 1.0 is released and the API needs to freeze.