Log In
Register
Forum
Topic RSS
17:48, EET
February 21, 2014
Offline
Good evening,
an OPC UA Server (based on SDK 4.3.0) uses a default file certificate validator. When a client initially connects, its certificate can be found in the rejected folder, and after trusting it, the client can connect (mutual trusting certs, of course). So far all is good.
Case 1: The client disconnects and the client certificate is untrusted (moved to rejected). When the client tries to reconnect, the connection is rejected => as expected
Case 2: The client disconnects and the client certificate is deleted. When the client tries to reconnect, the connection is accepted => this is unexpected, as there is no certificate in the trusted folder.
What could be the explanation for this behavior and how could it be corrected?
Thanks,
Hans-Uwe
8:38, EET
Moderators
February 11, 2020
Offline
Hello,
Can you reproduce this behavior with SampleConsoleClient and SampleConsoleServer sample applications bundled with the Prosys OPC UA SDK for Java or your Client application and SampleConsoleServer? I tried to reproduce this behavior with the sample applications and I deleted the Client’s certificate file from the Server’s rejected folder and then tried to connect again but the Server rejected the Client’s certificate even after the file had been deleted.
Could you provide debug level logs from your Client (if developed with the SDK) and Server applications that show this bug happening? You can send those logs to uajava-support@prosysopc.com so that we can take a look at them.
21:22, EET
February 21, 2014
Offline
Hi Matti,
today I compiled and run both the SampleConsoleServer and -Client (SDK 4.3.0) and was able to produce the described behaviour. I started both applications, after initially trusting the client with the server the connection succeeded. Shutting down the client, deleting the cert from the trusted folder, starting the client again and connecting the client to the server then succeeded without the client’s cert at the server side in any folder. I also confirmed that putting the cert into the rejected folder works as expected.
NB: the server was not shut down in between.
Hans-Uwe
9:36, EET
Moderators
February 11, 2020
Offline
Hello,
I was now able to reproduce this behavior and know what is causing it. In short, whenever certificates are validated, the lists of trusted and rejected certificates are refreshed and stored to memory based on the certificate files found in certs and rejected folders. Instead of creating these lists from the scratch, certificates are added to and removed from the existing lists as necessary. However, the used logic neglects to verify that all the certificates on the lists still exist on the file system. Thus, deleting a certificate manually doesn’t affect either of the lists, which could be seen as a bug.
PkiDirectoryCertificateStore has methods addTrustedCertificate and addRejectedCertificate that can be used to add certificate to trusted or rejected certificates respectively. Whenever either of these methods is called, the added certificate is removed from the other folder, if it exists there. For example, if a certificate exists in certs and addRejectedCertificate is called for that certificate, the certificate is added to rejected folder and removed from certs folder and vice-versa for addTrustedCertificate.
You can also use clear method of PkiDirectoryCertificateStore to clear the lists of trusted and rejected certificates. This will guarantee that the next time a list of trusted certificates is requested from the store the list won’t contain any certificates that don’t exist in the file system. This should allow you to manipulate the contents of certs and rejected programmatically and have the changes reflected to the lists of trusted and rejected certificates. However, calling clear with its boolean parameter set to true will also delete all the certificates in certs and rejected folder, so take care when using this method!
If you need to handle trusting and rejecting certificates by moving certificate files between the folders manually, you will need to move certificates from certs folder to rejected folder to change the status of a certificate from trusted to rejected while the Server application is running. If you don’t mind me asking, is this something your Server application would need to do regularly? Once a certificate has been trusted, there is typically no need to reject it manually outside the application.
12:28, EET
February 21, 2014
Offline
Hi,
our system exclusively uses file system based certificates stores, where an operator has to inspect the certs and then decide to either trust or reject them. We also have the possibility to delete an instance certificate, if the related client is no longer expected to connect. This is a standard procedure as otherwise the cert store would soon be very crowded. The described behavior has been discovered during a test of this ‘cleanup feature’.
We cannot manually instruct the (Prosys) server to ‘clear’ its certificate cache – this would require the integration of a file system watcher. Frankly, I would expect the OPC UA server to validate and verify each connection attempt from scratch. Caching the certs is perfectly fine, but a client’s cert should be removed from the cache after an intentional disconnect.
– Hans-Uwe
13:30, EET
April 3, 2012
Offline
Hi,
As said by Matti, this can be treated as our bug, though it is a bit more complicated. Anyway we will try to fix this for upcoming 4.5.2 that is to be released still during this month. Though note that at least the current API for the getTrustedCerts+getRejectedCerts is meant to reflect the state of the store, that is to say, it is more than a cache per se. It is for example used in UI’s of our SimulationServer.
Note that at least in that fix scope the Sets only update once a validation of a cert is needed. Some future version of the SDK could probably change them always when there is just a filesystem change (personally I would prefer to use https://docs.oracle.com/javase/8/docs/api/java/nio/file/FileSystem.html + https://docs.oracle.com/javase/8/docs/api/java/nio/file/WatchService.html but we would need to be in Java 7/8 land then, which I would hope can happen with SDK version 5 at some point).
While not a good solution for this case (i.e. we need to fix that bug), but mentioning just in case this is read by others later: SDK does support user-created CertificateStore implementations if you have special needs.
10:16, EEST
February 21, 2014
Offline
Hi,
I pick up on this topic again as I think I do experience another certificate caching issue. (SDK 4.5.2.)
Following situation:
A ProSys SDK based client is connected to an OPC UA server. That server is stopped, receives a new certificate, and is then restarted. The client is not able to reconnect to the server and returns a Bad_SecurityChecksFailed. The new server certificate has been trusted and vice versa. Even when the old server certificate has been deleted from the file store, it shows up again by some “magic”. This behaviour is reproducible. It looks like the Client SDK is caching the previous certificate and tries to verify against it by the applicationUri of the server and recreating the cert in the trusted file store.
The only way to recover from this situation is to stop the OPC UA client application and restart it.
NB: the client has been programmed to disconnect() and manually connect() when the serverState goes from Running to any other state in order to avoid the reuse of the cert.
11:55, EEST
Moderators
February 11, 2020
Offline
Hello,
Instances of UaClient class keep the Server’s EndpointDescription cached in memory to be able to reconnect to a Server without having to fetch the EndpointDescription from the Server. This EndpointDescription contains Server’s Application Instance certificate, which is where the Client keeps getting the old certificate even after it has been deleted from the file system.
You can call UaClient.resetEndpoint() to remove the cached EndpointDescription from memory and get the new one from the Server when calling UaClient.connect().
Most Users Ever Online: 1919
Currently Online:
29 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: 6452
Newest Members:
rickyjuarez140, jonathonmcintyre, fannielima, kristiewinkle8, rust, christamcdowall, redaahern07571, nigelbdhmp, travistimmons, AnnelCibModerators: Jouni Aro: 1026, Pyry: 1, Petri: 0, Bjarne Boström: 1027, Jimmy Ni: 26, Matti Siponen: 346, Lusetti: 0
Administrators: admin: 1
