11:22, EET
January 27, 2022
Hi everyone,
I was following the examples in order to establish a secure connection from our application to an OPC-UA server. My code goes like this:
uaClient = clientFactory.createClient(serverUrl);
ApplicationDescription appDescription = new ApplicationDescription();
appDescription.setApplicationName(new LocalizedText(“AppName”));
appDescription.setApplicationUri(“urn:test.com:OPCUA:AppName”);
appDescription.setProductUri(“urn:test.com:OPCUA:AppName”);
appDescription.setApplicationType(ApplicationType.Client);
File privatePath = new File(“./keys”, “private”);
// Create self-signed certificates
KeyPair issuerCertificate = null;
int[] keySizes = null;
ApplicationIdentity identity = ApplicationIdentity.loadOrCreateCertificate(
appDescription,
“CompanyName”,
“password”,
privatePath,
issuerCertificate,
keySizes,
true);
uaClient.setApplicationIdentity(identity);
uaClient.setSecurityMode(SecurityMode.BASIC128RSA15_SIGN_ENCRYPT);
uaClient.setValidateDiscoveredEndpoints(!debugMode);
uaClient.setInitTypeDictionaryOnConnect(false);
This works perfectly fine if I have set the OPC server to accept untrusted certificates. However, if I set it to accept only trusted certificates and add the certificate generated by the above code to its “trusted” folder (after converting from .der to .pem as this is required by the OPC server) the communication fails with the following error:
Failed to create secure channel to server
Bad_SecurityChecksFailed (0x80130000) “An error occurred verifying security
However, I noticed that a file with identical contents to my .pem placed in the “trusted” folder gets created in the “untrusted” folder of the server, but this time named “23AD68F5.0”. I tried restarting the OPC server and this time renamed my .pem to “23AD68F5.0” and placed it in the “trusted” folder and the communication works fine.
I have no idea where this 23AD68F5.0 comes from – can someone here explain? Why doesn’t it work if I set an arbitrary name for the certificate?
11:55, EET
Moderators
February 11, 2020
Hello,
Which version of the Prosys OPC UA SDK for Java are you using? Some older versions might require restarting the Server to notice manually added and removed certificates in trusted and untrusted folders.
If you’re using 4.6.2 or a more recent version, could you provide the exact steps on replicating this issue? With newer versions of the SDK, you should be able move a certificate from untrusted folder to trusted folder and have the Server consider it trusted immediately without having to restart the Server.
When saving a certificate received via OPC UA to file system, the SDK uses the thumbprint of the certificate to decide the file name. However, the filenames of certificate files shouldn’t matter as the SDK checks all certificate files in trusted and untrusted folders whenever it checks if a certificate is trusted.
12:47, EET
January 27, 2022
Hi Matti and thank you very much for your reply. We are using version 4.4.0-1240 of the prosys-opc-ua-sdk-client for Java – I will try to update to the newest one.
However, we are adding the certificate to the trusted folder of the OPC server prior to its startup (we copy it there when the docker container for the OPC server is starting up). Our client app attempts to connect to the OPC server long after that. We are using the Tani OPC server if that matters.
13:07, EET
Moderators
February 11, 2020
Hello,
I made a mistake and assumed that the Server you were attempting to connect to had been developed with Prosys OPC UA SDK for Java. While updating your Client to use a newer version of the SDK won’t affect this issue, the newest version of the SDK includes a security fix and everyone is recommended to update to it. See https://downloads.prosysopc.com/opcua/Prosys_OPC_UA_SDK_for_Java_4_Release_Notes.html#version-4-7-0 for more information.
Regarding the issue with certificates, please, contact the manufacturers of the Server for assistance.
13:50, EET
January 27, 2022
Thanks a lot, I had asked them as well.
With regards to the name of the certificate file – I tried extracting the thumbprint you mentioned via openssl by following the advice here: https://community.rsa.com/t5/securid-knowledge-base/how-to-view-a-certificate-fingerprint-as-sha-256-sha-1-or-md5/ta-p/4230 and here: https://support.comodo.com/index.php?/comodo/Knowledgebase/Article/View/706/17/ but the output never contains 23AD68F5.0. Can you suggest an openssl command that would print the information you mentioned – i.e. one that should match the name of the file as per created by the Prosys OPC UA SDK had we been using it?
14:31, EET
Moderators
February 11, 2020
14:58, EET
January 27, 2022
Yeah, sorry, I realise that. It is just that I haven’t got a response from them yet and I was wondering if I can try to reverse engineer the name somehow in the meantime.
I was asking about the openssl command in case they are using the same logic for the file name (I can quickly check that given the openssl command)
Most Users Ever Online: 1919
Currently Online:
8 Guest(s)
Currently Browsing this Page:
1 Guest(s)
Top Posters:
Heikki Tahvanainen: 402
hbrackel: 144
rocket science: 88
pramanj: 86
Francesco Zambon: 83
Ibrahim: 78
Sabari: 62
kapsl: 57
gjevremovic: 49
Xavier: 43
Member Stats:
Guest Posters: 0
Members: 738
Moderators: 7
Admins: 1
Forum Stats:
Groups: 3
Forums: 15
Topics: 1524
Posts: 6451
Newest Members:
rickyjuarez140, jonathonmcintyre, fannielima, kristiewinkle8, rust, christamcdowall, redaahern07571, nigelbdhmp, travistimmons, AnnelCibModerators: Jouni Aro: 1026, Pyry: 1, Petri: 0, Bjarne Boström: 1026, Jimmy Ni: 26, Matti Siponen: 346, Lusetti: 0
Administrators: admin: 1