Hi,

The ‘localhost’ most likely is the issue. One of the cert checks (defined in the OPC UA Specification) is that the ApplicationUri in the certificate must match the ApplicationUri of the ApplicationDescription. In this case it would seem the server is the one rejecting the cert. The server might have some override option for these cases.

In some cases the hostname resolution cannot get the hostname correctly, in which case it will currently default to ‘localhost’. However, assuming you use the methods of ApplicationIdentitity.loadOrCreateCertificate taking the ApplicationDescription, the same string should end up in both places, which makes this a bit weird. Still it is somewhat an error as the ApplicationUris should be globally unique (or at least within the network they communicate).

At least in some cases this has been resolved by making sure /etc/hosts line for the 127.0.0.1 looks something like:

P.S.
Technically you could get the same error code also as part of the client validating the server’s certificate (for the same reason), assuming you rejected it in a DefaultCertificateValidationListener (or if none was added, as the uri check is one of the compulsory checks). However in that case you would see a ServiceException with message “Invalid server certificate” (which probably is not best option, but is what you would currently see).

Hmm… strange

If you first run the following test to ensure we actually get it:

  @Test
  public void outputHostname() throws Exception {
    System.out.println("hostname(+domain if here is):" + ApplicationIdentity.getActualHostName());
    System.out.println("hostname only:" + ApplicationIdentity.getActualHostNameWithoutDomain());
  }

(‘localhost’ and/or ‘domainname’ in ApplicationUri + ApplicationName would be replaces with the first one, ‘hostname’ would replace with the second one)

The Cert is a standard X509 cert, the “Subject Alternative Name” URL field would be the one to match ApplicationURI. Operating systems usually should have some way to show this, e.g. on windows, you should be just able to doubleclick it open and see a Certificate window to show the details. Something like the following should work in terminal, assuming openssl is available (usually should):

then find line “X509v3 Subject Alternative Name:”

P.S.
If that fails for some reason, just as a test can you just enter the hostname directly to the ApplicationURI and see if it works that way.

Probably yes. However, could you doublecheck that it was the equivalent .der file vs. the cases that worked (or was this the same one for those as well?). This is getting really weird..

One theoretical case would be if you selected incorrect .der file (e.g. in SimulationServer’s PKI/CA/private there would have been also the CA (which we use for the https cert), this would not contain the Subject Alternative Name part (here Key Usage would include e.g. Digital Signature, Certificate Signing, Off-line CRL Signing, CRL Signing (86)).

Assuming the above was not the case, next I would just try with connecting with SampleConsoleClient instead. If it works directly, then some part of your code is different. If it fails then at least we could check if the cert generation did work correctly or not.

P.S.
Additionally I need to ask what is the SDK version you are using? Also that you are using the BouncyCastle (if SDK is 4.x, then this would be the case, previously there was a fallback option which used the private sun api of the jre) + Java version and vendor? And BouncyCastle version if different than came with the SDK?

Then I would guess the check wasn’t as part of the V5.18 and has been added later to be more compliant. However it seems the issue with the ‘Subject Alternative Name’ has been around then longer, just that the server hasn’t being complaining about it.

For the sampleconsoleclient example, assuming you have javac+java in PATH, it would start from the .bat/sh (it would compile it first and then start), it will create the certificates automatically when first needed in connecting, they will appear in the PKI folder (which is then created) next to the scripts. This is the simplest way, otherwise you might need to create a project e.g. in Eclipse (see the getting started tutorial) and export it e.g. as runnable jar etc.

For https://www.prosysopc.com/products/opc-ua-browser/ the certs will be in ‘user.home’\.prosysopc\prosys-opc-ua-browser\PKI instead (after you have started the application for the first time).