I've tested it and worked 😉

Also, for this reason I believe BouncyCastle will also ignore it, https://github.com/bcgit/bc-ja......java#L536 in the engineGetKey method.

So that explains why the privateKeyPassword does nothing and only the store password matters. However, based on my tests a JKS store can use both.

Then separate to this for the alias thing. SecureIdentity constructor has more documentation, https://documentation.prosysop.....ng.String- the com.prosysopc.ua.ApplicationIdentity.ApplicationIdentity(File, String, String, String, String) does call this super constructor. There is a mention "alias - string alias of the key pair, if null or not found in specified pfx-file, last entry is used". This something very old, but I would believe the intention is that .NET world used pfx files, but not in a way that there would be more than a single key so rather than fail it will fall back to the only key there is anyway. Since you probably as well have only a single key there, it is always found regardless of the alias.

P.S.
One extra note for future readers. This was a DEBUG level log. On failure it should use Charset.defaultCharset() as a fallback. With that there would only be issues if there are non-ASCII characters in the outputs.

Unfortunately formats other than the .der/.pem the samples use are not that well tested (or tested continuously/automatically).

Seems to be a bug. During https://downloads.prosysopc.co.....sion-5-4-0 + https://documentation.prosysop.....eir-usages we did do some changes. As a result BouncyCastle is not installed, only the Provider is loaded and used directly via java.security.XXX.getInstance(String, Provider). Few places are different, since e.g. BouncyCastle doesn't support the JKS type, but seems that was missed for the SecureIdentity case.

As to why it loads with wrong-things, not sure. My guess would be that since https://downloads.prosysopc.co.....sion-5-6-2 did fix a thing where BouncyCastle seems to return null for some erroneous data instead of throwing (I believe this was at least empty byte[]), maybe something similar can happen here. Then the scenario could become the same as if no cert was defined, which would be ok for NONE security connections.

Can you send mail to jsdk-support@prosysopc.com and refer this; we can give a beta build once we have fixes (might not happen today).

C:\Users\home>chcp
Aktive Codepage: 850.

There is a dot at the end. Seems to be different with different system languages.

On the machine that caused the log, could it be possible to see the output of the command "chcp" (without quotes) from the Command Prompt (specifically cmd, not powershell). It should output like this:

i.e. no dot at the end, but the number can be different on locales and regions. At least that it how it worked on the windows 10 and 11 machines we tested on.

A workaround would be to set the hostname manually (if you know it) via static ApplicationIdentity.setActualHostName(String), then SDK doesn't try to figure out it by itself.

We can also try to improve the parsing logic once we see the output. It should be noted that normally at least currently the only scenario where SDK will try to use platform specific ways is if there is or has been Docker installed on the machine at some point. The Docker's installation will write some hosts file entries that break Java's reverse-DNS lookup for the hostname that we use. This would result in an unusable "host.docker.internal" hostname, thus as a fallback we will attempt platform specific ways. On windows the console output encodings can be different and it matters for reading because there can be special characters, thus we try to parse it from the chcp output.

My pfx showed anyway 'PrivateKey (Format): PKCS#8' but it looks like it could be loaded with SDK 4.x also with "JKS" as keyStoreType

I'm using following constructor: to load a pfx file.

public ApplicationIdentity(File storeLocation,
String alias,
String privateKeyPassword,
String keyStorePassword,
String keyStoreType)

Create an identity with an application certificate. The certificate and private key are loaded from a pfx-keystore file.

keyStoreType - type of the key store, "JKS" and "PKCS12" are supported types

With SDK 4.x I used following code:

ApplicationIdentity applicationIdentity = new ApplicationIdentity(new File(keystore), alias, password, storePassword, "JKS");

With this the pfx file could be loaded and a connection to a server was possible.

With SDK 5.x the loading failed with:

2026-05-07 17:52:15,886|DEBUG|CryptoUtil |CryptoUtil init, trying to get: Windows-PRNG
2026-05-07 17:52:15,915|DEBUG|CryptoUtil |CryptoUtil init, using Windows-PRNG, random=PRNG
2026-05-07 17:52:15,915|DEBUG|CryptoUtil |Providers=[SUN version 17, SunRsaSign version 17, SunEC version 17, SunJSSE version 17, SunJCE version 17, SunJGSS version 17, SunSASL version 17, XMLDSig version 17, SunPCSC version 17, JdkLDAP version 17, JdkSASL version 17, SunMSCAPI version 17, SunPKCS11 version 17]
2026-05-07 17:52:16,563|INFO |CryptoUtil |Using CryptoProvider com.prosysopc.ua.stack.transport.security.BcCryptoProvider
2026-05-07 17:52:16,575|ERROR|CreateApplicationIdentity |Failed to load ApplicationIdentity from KeyStore ./resources/opcua-keystore.pfx with Alias myAlias
2026-05-07 17:52:16,578|ERROR|DefaultErrorHandler |com.prosysopc.ua.SecureIdentityException: Cannot load key from PKCS12 KeyStore: JKS not found
com.prosysopc.ua.SecureIdentityException: Cannot load key from PKCS12 KeyStore: JKS not found
at com.prosysopc.ua.SecureIdentity.(SourceFile:?)
at com.prosysopc.ua.ApplicationIdentity.(SourceFile:?)

When I change the keyStoreType from JKS to PKCS12 ....

ApplicationIdentity applicationIdentity = new ApplicationIdentity(new File(keystore), alias, password, storePassword, "PKCS12");

...then it loads, but I observed it is always loading as long as the storePassword is correct.

If I use a wrong-alias or a wrong-password it is still loading and I can get a connection to an OpcUa server.

ApplicationIdentity applicationIdentity = new ApplicationIdentity(new File(keystore), wrong-alias, wrong-password, storePassword, "PKCS12");

With 4.x and JKS a connection was not possible when alias ot key password was wrong.

Was there any change in the internal implementation? I could'nt find any hint in the Migration Guide or in the ReleaseNotes.

I've updated an application to SDK 5.6.2 (from 4.x) and there seems to be one exception in the log file.

Cannot resolve windows console charset
java.nio.charset.UnsupportedCharsetException: CP850.
at java.base/java.nio.charset.Charset.forName
at com.prosysopc.ua.stack.utils.OSUtil.eMY
at com.prosysopc.ua.stack.utils.OSUtil.a
at com.prosysopc.ua.stack.utils.OSUtil.exec
at com.prosysopc.ua.stack.utils.OSUtil.exec
at com.prosysopc.ua.stack.utils.OSUtil.eNa
at com.prosysopc.ua.stack.utils.OSUtil.eMZ
at com.prosysopc.ua.stack.utils.OSUtil.getDomainNameFromOs
at com.prosysopc.ua.stack.utils.OSUtil.getHostNameWithDomain
at com.prosysopc.ua.ApplicationIdentity.getActualHostName

One observation on the exception...

java.nio.charset.UnsupportedCharsetException: CP850.

...is that there is a dot at the end of CP850.

The Java class Charset does not add the dot at the end of the charset name when it throws the exception.

public static Charset forName(String charsetName) {
Charset cs = lookup(charsetName);
if (cs != null)
return cs;
throw new UnsupportedCharsetException(charsetName);
}

So my guess is as CP850 is valid, that somehow you have used 'CP850.' somewhere in your SDK instead of 'CP850'

Can you check this?

What SDK version you are using?

Any option you could send one of the .pem to jsdk-support@prosysopc.com?

Alternatively, you could try loading them manually using (exactly these methods) com.prosysopc.ua.stack.utils.FileUtil.readFile(File) and then PrivKey.load(byte[], null) on the returned byte[]. This should throw an Exception that might help to explain what happened. In the loadOrCreate there is a fallback to try in another format (loadFromKeyStore), and the posted error is from that, but it failed before that (that would output a DEBUG level log only) because SDK writes them in format the load(..) should be able to load.

So my guess would be that somehow the writing of the .pem didn't work or it got corrupted somehow (or the filesystem did it afterwards somehow). SDK doesn't load them back on the method call that created them, it would only fail on the next call.

Also as a sidenote, unless I missed something, you are calling https://documentation.prosysopc.com/JSDK/javadoc/com/prosysopc/ua/ApplicationIdentity.html#loadOrCreateCertificate-com.prosysopc.ua.stack.core.ApplicationDescription-java.lang.String-java.lang.String-java.io.File-boolean-java.lang.String...-
whose signature is
loadOrCreateCertificate(ApplicationDescription applicationDescription, String organisation, String privateKeyPassword, File path, boolean enableRenew, String... hostNames) so your comments on the parameters are wrong. You give a null File as the folder where the keys would be stored so they become relative Files instead so it is possibly dependent on how your application is executed could the previously created be found. The boolean enableRenew means SDK will attemt to re-create the certificate if it expires. By default the certificates SDK creates are valid for 10 years. Thus, I think that has not happened yet.

All server-side UaNodes are (and must be) ServerNode-based, so they can be casted to it (or if creating instances, the XXXTypeNode.class can be used instead of XXXType.class, if known and using class-based createInstance methods).

For now the UaNodeSetExtensions is still quite ... crude. It is just a wrapper for the raw whole Extensions XML element, including the Extensions element definition. It be created with UaNodeSetExtensions.parse(String) (doesn't validate anything yet) and the UaNodeSetExtensions.getRawXml() gives the raw xml back. Note that it might not be 1:1 for exporting/loadingh the model e.g. some whitespaces might change and the xml namespaces might need some experimenting, we have not explored this that much. The following should work, let us know if there are issues:

(... some day we will have better code-block for the forum, anyway think there is a newline character at the end of each line's String data)

The xmlns needs to be defined for the Extensions element. And since it and Extension element are in the UANodeSet.xsd, I think using any own namespaces must be defined within each element that is inside the Extension like above. The resulted total XML for the model isn't as pretty as I would like it to be, as the xmlns:prosys part wont get "elevated" yet to the whole document root element XML namespaces definition.

If you can contact our support by email, we can check this in more detail.

var newServer = new UaServer();
ApplicationDescription appDescription = new ApplicationDescription();
appDescription.setApplicationName(new LocalizedText("SimpleServer", Locale.ENGLISH));
appDescription.setApplicationUri("urn:localhost:UA:SimpleServer");
appDescription.setProductUri("urn:prosysopc.com:UA:SimpleServer");
appDescription.setApplicationType(ApplicationType.Server);
ApplicationIdentity identity = ApplicationIdentity.loadOrCreateCertificate(
appDescription,
"MyCompany", // Organization
null, // Common Name for certificate
null, // Hostname override
true // Create if missing
);
newServer.setApplicationIdentity(identity);
newServer.addUserTokenPolicy(UserTokenPolicies.ANONYMOUS);
newServer.init();

Everything seemed to work fine, until I noticed that on a few PCs I get the error:

com.prosysopc.ua.SecurityIndetityException: Private key cannot be loaded from file SimpleServer_2048.pem
at com.prosysopc.ua.ApplicationIdentity.loadOrCreateKeyPair(SourceFile:930)
Caused by: java.io.IOException: Short read of DER length
at java.base/sun.security.util.DerInputStream.getLength(DerInputStream.java:588)
at java.base/sun.security.util.DerValue.init(DerValue.java:390)
at java.base/sun.security.util.DerValue.(DerValue.java:331)
at java.base/sun.security.util.DerValue.(DerValue.java:344)
at java.base/sun.security.pkcs12.PKCS12KeyStore.engineLoad(PKCS12KeyStore.java:1993)
at java.base/java.security.KeyStore.load(KeyStore.java:1479)
at com.prosysopc.ua.stack.utils.CertificateUtils.loadFromKeyStore(SourceFile:660)
at com.prosysopc.ua.stack.transport.security.PrivKey.loadFromKeyStore(SourceFile:200)
at com.prosysopc.ua.stack.transport.security.PrivKey.loadFromKeyStore(SourceFile:183)
at com.prosysopc.ua.ApplicationIdentity.loadOrCreateKeyPair(SourceFile:925)

any idea on where the issue might be? The certificates are created by the SDK and never touched by any other process.

Thanks!

I think that either of the 3 options will work for producing a nodeset. The only open subject would be the addition of NodeSet Extensions elements. We would want to add non-OPC UA configuration information like PLC data tag mappings etc into the nodeset as well as a single-source-of-truth.

I got everything working with the dynamic types now (at least I thought so) but found a new, somewhat peculiar, issue.

When I run my program in 32Bit everything works just fine but running it in 64Bit got me an exception that a structure is missing mandatory field values.

Project raised exception class EUaException with message 'Mandatory Field Values for DynamicStructure type ExtensionObjectType undefined: ID,Name,ValueString'.

After digging around a bit I found that the following code snipped seems not to work in 64Bit.

pNames := IStruct.GetFieldNames; //<- this return [] in 64 bit and ['ID', 'Name', 'ValueString'] in 32Bit (for this specific type, of course the names can vary depending on the type definition)

for s in pNames do
begin
pField := IStruct.FieldValues[s];
[...]
IBuilder.SetFieldValue(s, TUaVariant.Create(V));
end;

The GetFieldNames returns the list with the correct field names in 32Bit, but returns an empty list in 64Bit. The curios part is, when I hardcode a field name I know exist, the FieldValues[] function returns the field and the exception message gives me the missing field names as well. So the type itself seems to be correct and knows those fields do exist, just the GetFieldNames function won't disclose that information.

IStruct is a created by doing this:

pTo.Value.AsStructure

where pTo is a TUaVariable holding a custom structure type (checked with IsStructure beforehand).

Any Idea what might be the cause of this?