Log In
Register
Forum
Topic RSS
17:03, EEST
May 15, 2020
Offline
Hello,
I am using Prosys sdk 4.3. I set the application identity and user identity as below in my client application
ApplicationDescription appDescription = new ApplicationDescription();
appDescription.setApplicationName(new LocalizedText(APP_NAME + “@localhost”));
appDescription.setApplicationUri(“urn:localhost:OPCUA:” + APP_NAME);
appDescription.setProductUri(“urn:prosysopc.com:OPCUA:” + APP_NAME);
appDescription.setApplicationType(ApplicationType.Client);
//I got clientCert (X509Certificate type) and privKey (PrivKey type) from the application
ApplicationIdentity applicationIdentity = new ApplicationIdentity(new Cert(clientCert), privKey);
UserIdentity userIdentity = new UserIdentity(new Cert(clientCert), privKey);
client.setUserIdentity(userIdentity);
client.setApplicationIdentity(applicationIdentity);
applicationIdentity.setApplicationDescription(appDescription); //appDescription is ApplicationDescription.
applicationIdentity.setApplicationDescription(appDescription);
I am using SecurityMode as SecurityMode.BASIC128RSA15_SIGN_ENCRYPT. While I am trying to connect to server (client.connect()) I am getting below exception:
com.prosysopc.ua.stack.common.ServiceResultException: Bad_CertificateUseNotAllowed (code=0x80180000, description=”Bad_CertificateUseNotAllowed (code=0x80180000, description=”The certificate may not be used for the requested operation.”)”)
Please help me to resolve this issue.
Thanks,
Bibhudatta Sahu
19:47, EEST
December 21, 2011
Offline
You cannot use the same certificate for both the application and the user. Try with an Anonymous user identity (which is the default).
20:12, EEST
May 15, 2020
Offline
Hi Jouni,
Thank you for the quick response. I set the userIdentity as Anonymous as below.
client.setUserIdentity(new UserIdentity());
Still I am getting the same exception.
com.prosysopc.ua.stack.common.ServiceResultException: Bad_CertificateUseNotAllowed (code=0x80180000, description=”Bad_CertificateUseNotAllowed (code=0x80180000, description=”The certificate may not be used for the requested operation.”)”)
Can you please give some suggestion to solve it.
Thanks,
Bibhudatta Sahu
8:43, EEST
April 3, 2012
Offline
Hi,
Please also check that your Cert is not a “CA cert”, those cannot be used as application instance certs (you must instead make a non-CA cert that is then signed by it). If that was not the case then also check that the Cert you have is otherwise a valid ApplicationInstanceCertificate.
An ApplicationInstanceCertificate must have the following keyUsage bits on (per https://reference.opcfoundation.org/v104/Core/docs/Part4/7.2/, the last entry in the table):
“keyUsage [] String Specifies how the Certificate key may be used.ApplicationInstanceCertificates shall support Digital Signature, Non-Repudiation Key Encryption, Data Encryption and Client/Server Authorization.The contents of this field depend on the Certificate encoding.”
These can be usually seen if you can open the certificate file in your operating system viewer and/or otherwise output the data e.g. via openssl commands.
If you would wish to check within java, you could do so by e.g. for “Non-Repudiation” via checking for the boolean return on the Cert object by calling “cert.certificate.getKeyUsage()[1]” (for more info see https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/security/cert/X509Certificate.html#getKeyUsage()).
15:31, EEST
May 15, 2020
Offline
Hi,
I was using the same certificate when the application was running on prosys sdk version 2.2. That time it was able to connect to server. But after upgrading the sdk version from 2.2 to 4.3, the client is not able to connect to server using same certificate. So I think there may not be certificate issue.
15:52, EEST
Moderators
February 11, 2020
Offline
Hello,
Is your Server application using Prosys OPC UA for Java SDK and did you upgrade your Server application from version 2.2 to version 4.3? This certificate validation check and many other checks were added in version 4.3, which would explain why you are able to connect with the same certificate to Servers using SDK versions older than 4.3.
BR,
Matti
17:32, EEST
May 15, 2020
Offline
Hi Matti,
The Server and client, both applications are using Prosys OPC UA for java SDK. I have upgraded both server and client applications from version 2.2 to version 4.3. I have tried to connect to SampleConsoleServer server program which is coming with 4.3 Prosys SDK. I faced the same issue.
[com.prosysopc.ua.stack.common.ServiceResultException: Bad_CertificateUseNotAllowed (code=0x80180000, description=”Bad_CertificateUseNotAllowed (code=0x80180000, description=”The certificate may not be used for the requested operation.”)”)]
After analyzing the workflow, I found below points
1. When I am using ApplicationIdentity as
int[] keySizes = null;
final ApplicationIdentity identity = ApplicationIdentity.loadOrCreateCertificate(appDescription,
“Sample Organisation”, /* Private Key Password */”opcua”,
/* Key File Path */privatePath,
/* Issuer Certificate & Private Key */null,
/* Key Sizes for instance certificates to create */keySizes,
/* Enable renewing the certificate */true);
I am able to connect to the server.
2. But when I am using ApplicationIdentity as
ApplicationIdentity applicationIdentity = new ApplicationIdentity(new Cert(clientCert), privKey);
client.setUserIdentity(userIdentity);
client.setApplicationIdentity(applicationIdentity);
applicationIdentity.setApplicationDescription(appDescription); //appDescription is ApplicationDescription.
client.setUserIdentity(new UserIdentity());
then I am not able to connect to server. In this case I am using our own certificate and private key.
So from the above two points I am realizing something wrong with the ApplicationIdentity. I would like to use my own certificate and private key to generate ApplicationIdentity. Can you please help me to overcome the issue.
Thanks,
Bibhudatta Sahu
9:31, EEST
Moderators
February 11, 2020
Offline
Hello,
You can ignore specific StatusCodes related to user certificate validation by modifying the UserValidator your Server application uses to validate users. If your Server application is modelled after the SampleConsoleServer sample, you might be using MyUserValidator or a UserValidator based on it. Normally MyUserValidator will reject any user certificate if validating it returns a StatusCode that is not Good, but you could modify it to accept some other StatusCodes as well, such as Bad_CertificateUseNotAllowed.
However, prior to Prosys OPC UA SDK for Java version 4.3.0, MyUserValidator would accept all user certificates without checking them unless it was modified to check them. If you have been using MyUserValidator without any modifications in your Server application so far, there can be several problems with your user certificate that you would need to either fix or configure MyUserValidator to ignore the StatusCodes related to those problems.
EDIT: This only applies to user certificates. If there is a problem with your application certificate and you wish to keep using it, you must implement your own CertificateValidator that ignores the problems that DefaultCertificateValidator used by SampleConsoleServer is reacting to with Bad StatusCodes.
17:29, EEST
May 15, 2020
Offline
Hello,
Yes that is the way to overcome certificate validation related issue. Thank you so much. I would like to use DefaultCertificateValidator. So I was also trying in another way to implement application identity as below:
KeyPair keyPair = new KeyPair(Cert, PrivateKey);
and I am using the same keyPair to generate ApplicationIdentity.
ApplicationIdentity applicationIdentity = ApplicationIdentity.loadOrCreateCertificate(appDescription, “Tridium”, “opcua”, privatePath, keyPair, keySizes, true);
This time I am getting [ com.prosysopc.ua.stack.common.ServiceResultException: Bad_SecurityChecksFailed (code=0x80130000, description=”Bad_SecurityChecksFailed (code=0x80130000, description=”An error occurred verifying security.”)”) ].
Can you please let me know what I am missing.
10:02, EEST
Moderators
February 11, 2020
Offline
Bad_SecurityChecksFailed is a generic StatusCode that is returned for multiple different errors.
A common cause for this exception is trying to connect to a Server with a certificate that is not trusted by the Server. When attempting to connect to SampleConsoleServer or a Server based on it, you can resolve this by following the process described below:
1. Have your Client create an application certificate with ApplicationIdentity.loadOrCreateCertificate
2. Attempt to connect your Client to a Server with “Sign” or “Sign and Encrypt”
3. The Server rejects the connection and places the application certificate into PKI/CA/rejected folder
4. Open this folder and move the certificate to PKI/CA/certs folder
5. Have your Client create a user certificate with ApplicationIdentity.loadOrCreateKeyPair and make sure to not use the same filenames used by the application certificate
6. Set your Client to use this user certificate with client.setUserIdentity
7. Attempt to connect your Client to a Server with “Sign” or “Sign and Encrypt” again
8. The Server rejects the connection and places the user certificate into USERS_PKI/CA/rejected folder
9. Open this folder and move the certificate to USERS_PKI/CA/certs folder
10. Attempt to connect your Client to a Server with “Sign” or “Sign and Encrypt”
11. The Server should now accept the connection
PKI/CA for is the default folder for application certificates and USERS_PKI/CA is the default folder for user certificates used by SampleConsoleServer.
If your application or user certificates have been signed with a CA certificate, the public key (the .der file) of this CA certificate needs to be placed in PKI/CA/issuers/certs or USERS_PKI/CA/issuers/certs folder depending on whether it has been used to sign application or user certificates or both. If you wish to trust any certificate signed by the CA certificate, you can place its public key into PKI/CA/certs and/or USERS_PKI/CA/certs folder.
17:06, EEST
May 15, 2020
Offline
Thank you Matti, I am able to solve the problem by implementing custom certificate validator. However I am getting the exception when I am trying to connect to server.
I installed opcua server in the device. I ping the device, I am able to get the response in client. But when I am trying to connect to the server which is present in the device, I am getting below exception.
com.prosysopc.ua.client.ConnectException: Failed to retrieve endpoints. The server is not available: opc.tcp://sever_ip_address:52520/OPCUA/ServerName ServiceResult=Bad_CommunicationError (0x80050000) “A low level communication error occurred.”
at com.prosysopc.ua.client.UaClient.discoverEndpoints(SourceFile:1071)
at com.prosysopc.ua.client.UaClient.discoverEndpoints(SourceFile:1004)
at com.prosysopc.ua.client.UaClient.getEndpoints(SourceFile:5591)
at com.prosysopc.ua.client.UaClient.N(SourceFile:5915)
at com.prosysopc.ua.client.UaClient.connect(SourceFile:886)
at DeviceClass.lambda$doPing$0(.java:706)
at java.security.AccessController.doPrivileged(Native Method)
at java.lang.Thread.run(Thread.java:748)
Caused by: com.prosysopc.ua.stack.common.ServiceResultException: Bad_CommunicationError (code=0x80050000, description=”2147811328, Read timed out”)
at com.prosysopc.ua.stack.transport.tcp.io.TcpConnection.open(SourceFile:1281)
at com.prosysopc.ua.stack.transport.tcp.io.SecureChannelTcp.open(SourceFile:749)
at com.prosysopc.ua.stack.application.Client.createSecureChannel(SourceFile:370)
at com.prosysopc.ua.client.UaClient.discoverEndpoints(SourceFile:1051)
… 10 more
Caused by: java.net.SocketTimeoutException: Read timed out
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.socketRead(SocketInputStream.java:116)
at java.net.SocketInputStream.read(SocketInputStream.java:171)
at java.net.SocketInputStream.read(SocketInputStream.java:141)
at java.net.SocketInputStream.read(SocketInputStream.java:224)
at com.prosysopc.ua.stack.utils.bytebuffer.InputStreamReadable.atN(SourceFile:185)
at com.prosysopc.ua.stack.utils.bytebuffer.InputStreamReadable.getInt(SourceFile:110)
at com.prosysopc.ua.stack.transport.tcp.io.TcpConnection.open(SourceFile:1178)
… 13 more
Could you please help me, how to resolve the issue.
Thanks,
Bibhudatta
12:23, EEST
Moderators
February 11, 2020
Offline
Hello,
This exception is caused by a Client not being able to retrieve Endpoints from a Server because attempting to open a TCP channel times out during the handshake between the applications. Please verify whether or not the Client is able to connect to the Server when the applications are running on the same host, or in other words, the same computer.
I would recommend installing Wireshark to gain further information on the messages exchanged between your Client and Server applications. Here are instructions on how to use Wireshark with OPC UA applications: https://www.prosysopc.com/blog/opc-ua-wireshark/ To capture data exchange between application running on the same host, remember to install Npcap Loopback Adapter when prompted.
If possible, you could also attempt running SampleConsoleServer sample Server application on your device and SampleConsoleClient sample Client application on a different host and connecting from SampleConsoleClient to SampleConsoleServer while capturing data exchanged between them with Wireshark.
20:13, EEST
May 15, 2020
Offline
Hi Matti,
In same host or in the same computer client is able to connect to server. I installed the wireshark log and checked that the request is going to the server which is in the device and from the server there is no response. After that I was installed opcua client in the device and server was in my computer. I was trying to connect from client (which was in the device) to the server (which was in my computer). I was able to establish the communication between the server (which is in computer) and client (which is in device). And in Wireshark log I was able to get the request and response between client and server.
But issue is happening when I installed the server in the device and client in my system. That time I am not getting any response from the server (which is in device). The same was reflected in Wireshark log as well. I tried to connect from SampleConsoleClient to the server, I am getting the same exception.
Thanks,
Bibhudatta Sahu
14:56, EEST
Moderators
February 11, 2020
Offline
I would recommend you to check the firewall settings of the device and verifying that the port you’re using to connect to the Server running on the device allows traffic into both directions. Contact the manufacturer of the device for further information on how to configure the firewall, if necessary.
19:25, EEST
May 15, 2020
Offline
Hello Matti,
I contacted manufacturer. I came to know that the device has no firewall. I also tried to examine the port (opcua server port 52520) in the device after logged into device through ssh.
After that I ran the command netstat -an | grep 52520 in device. 52520 is the port the server is running. I got the below result.
$ netstat -an | grep 52520
tcp6 81 0 ::ffff:192.168.1.52520 ::ffff:192.168.1.60926 ESTABLISHED
tcp6 81 0 ::ffff:192.168.1.52520 ::ffff:192.168.1.60907 CLOSE_WAIT
tcp6 81 0 ::ffff:192.168.1.52520 ::ffff:192.168.1.60889 CLOSE_WAIT
tcp6 0 0 fe80::f65e:abff:.52520 *.* LISTEN
tcp6 0 0 ::ffff:192.168.1.52520 *.* LISTEN
tcp6 0 0 ::ffff:127.0.0.1.52520 *.* LISTEN
tcp6 0 0 ::1.52520 *.* LISTEN
tcp6 0 0 fe80::1%lo0.52520 *.* LISTEN
It looks like server is able to establish the connection to the port 52520 which is defined for opcua server. I am guessing there is some issue in prosy stack level, because of which client is getting readtimeout exception while trying to read from socket.
Also in wireshark log I checked that request is going from client to server. But there is no response from server. Could you please provide your thoughts on it
Thanks,
Bibhudatta Sahu
10:13, EEST
Moderators
February 11, 2020
Offline
Could you send your Wireshark logs to uajava-support@prosysopc.com so that we could take a closer look at them? You can also send logs from your Client and Server applications.
18:20, EEST
May 15, 2020
Offline
Hi Matti,
I send the wireshark log and netstat log details in the given mail id with subject line “Unable to connect to server”. Please have a look.
Thanks,
Bibhudatta Sahu
10:51, EEST
Moderators
February 11, 2020
Offline
Could you verify whether or not your device where the Server application is running has a hostname? You can use ApplicationIdentity.getActualHostName() in your Server application to get your hostname as a String. If your device doesn’t have a hostname, you should set a hostname and test if that solves your problem.
Additionally, you could also try disabling IPv6 by calling server.setEnableIPv6(false) in your Server application code, where server is your UaServer instance.
If neither of these solve your problem, please send us new Wireshark and netstat logs, so that we can see if there was any effect at all.
20:14, EEST
May 15, 2020
Offline
Hello Matti,
As per the suggestion we disable ipv6 in code level (server.setEnableIPv6(false)) and printed actual host name in log (ApplicationIdentity.getActualHostName()) to know the host name. After that we ran the server in device. Still we are getting the same exception. While checking in log we got to know the host name of the device. Below are the logger output.
—ApplicationIdentity.getActualHostName()—>127.0.0.1
—server.isEnableIPv6()—>false
In above host name of the device where server is running is “127.0.0.1” and ipv6 is disable in the code.
I send the wireshark log and netstat log in mail. Please have a look.
Thanks,
Bibhudatta Sahu
13:35, EEST
April 3, 2012
Offline
Hi,
Note that the “127.0.0.1” is not a hostname per se. That is the the usual loopback address and something java gives us if there is no hostname defined on the machine (or for any other reason if it could not be resolved). Therefore please set a hostname if possible and see if that resolves the problem. The hostname is used in many places as identifier and when binding the endpoints. It is complicated but basically usually there has been problems if it is not set. Of course eventually it would be nice if not having a hostname would not give any trouble, but in practice current testing happens on machines that do have them (since a any machine should basically always have one: https://serverfault.com/questions/532331/why-do-i-need-to-set-a-hostname).
Usually the hostname is set when installing the linux distro (I’m assuming linux here, since to my knowledge on windows getting this situation is not possible or very rare; though on linux that is should also be rare), but you can usually just edit the /etc/hosts file e.g. https://unix.stackexchange.com/questions/186859/understand-hostname-and-etc-hosts and https://en.wikipedia.org/wiki/Hosts_(file).
In addition, sometimes it could be 127.0.1.1 instead, https://serverfault.com/questions/363095/why-does-my-hostname-appear-with-the-address-127-0-1-1-rather-than-127-0-0-1-in . If that is the case, then where possible, you should make so that it is 127.0.0.1 and not 127.0.1.1. We have trouble binding on more than one local loopback, thus by default it would only bind on 127.0.0.1, which then cause problems if the hostname would resolve to 127.0.1.1 locally. Thus the “127.0.0.1 localhost myhostname” would be preferred if possible.
Eventually we need to change our defaults to use just IPv4 or IPv6 wildcards as the default bind address (since now by default we instead try to resolve all IP-addresses and bind to each one, this is also slower, but is a historical design).
Most Users Ever Online: 1919
Currently Online:
11 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: 731
Moderators: 7
Admins: 1
Forum Stats:
Groups: 3
Forums: 15
Topics: 1529
Posts: 6471
Newest Members:
inilarythikibia, rickykennion, PromotionToold, HypromeImpupe, toneylapham544, rondawolinski7, Marypof5711, roycedelargie91, kourtneyquisenbe, ellis87832073466Moderators: Jouni Aro: 1026, Pyry: 1, Petri: 0, Bjarne Boström: 1032, Jimmy Ni: 26, Matti Siponen: 349, Lusetti: 0
Administrators: admin: 1
