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.

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.

Seems you edited the question while I was writing a complicated answer. Thus an edited shorter version of that below.

You will need to represent data as 'UaNodes'. Due to history of the SDK, it is kinda hard to do "data only" representation of the server (or alternative UaNode implementations). You might try just UaServer.init without starting, or just bind to 127.0.0.1 only and use normal UaNodes. Then you can use NodeManagerUaNode.toNodeSet() + UaNodeSet.toXml(). It is not recommended to write the core namespace (index 0). Also the index 1 should typically be ignored, as often it contains diagnotics nodes only. In case you read stuff back to our SDK server, it should be noted that UaServer.init does create the namespaces in index 0 and 1 by itself, that should not be modified.

There is not a public way yet to export more than one namespace per UaNodeSet. However, we do have these "public internal" ones:
- https://documentation.prosysop.....arser.html
- https://documentation.prosysop.....arser.html

They have a bit more stuff that was not public-ready, but needed for Browser(nodeset export in pro) and SimulationServer. The classes are public, though they should be considered as internal, i.e. we could remove/modify these at will (though most likely we will need something similar anyway in some form ourselves). I can try to explain in more detail later if needed, but short versions: The InternalUaNodeSetNodeManagerUaNodeParser mostly is NodeManagerUaNode.toNodeSet() with few additional options. InternalUaNodeSetAddressSpaceParser (NodeManagerTable does implement UaAddressSpace) can write any Set of UaNodes (of that UaAddressSpace), not limited to ones of the same namespace. Though note that the constructor parameter "primaryNamespace" will become the index 1 for model purposes (since typically a model has just one "provided namespace" and it typically is index 1, rest of NamespaceUri list is typically dependencies). The rest will depend on iteration orders. Also, I heavily recommend exporting complete namespaces (one or more), or you might end up with an invalid model.

P.S.
I can explain later, if needed, but there is sort of an issue regarding cyclic dependencies, which might occur for weirder models. The internal ones have a parameter to break these if it can be done from the outside, but we have not found a proper "UA way" for this. SDK does apply some heuristics in order to determine which namespaces are dependencies and which are not regarding references.

I'd like to generate a nodesest.xml file from an in-memory addressSpace (ideally, without even running a server ). Does the SDK provide a utility for this purpose or am I required to serialize the nodes / nodeset manually to XML?

Many thanks for your support