Log In
Register
Topic RSS
20:11, EEST
March 16, 2017
Offline
Hi,
with migration from SDK 4.x to 5.x I recognized that loading a pfx file did not work when using keyStoreType JKS.
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.
13:05, EEST
April 3, 2012
Offline
Hi,
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).
15:41, EEST
April 3, 2012
Offline
Few tests later
…
So, it would seem the wrong-things working was not what I assumed. It is 2 things. It would seem PKCS12 in the Java world doesn’t use private key passwords, only the store ones, https://bugs.openjdk.org/brows…..DK-8008292, also https://docs.oracle.com/en/mid…..trust.html
“For PKCS12 keystores, keytool does not support different keystore and key passwords and uses the keystore password to persist the key. If you specify a password using the -keypass option and it differs from the password specified for the -storepass option, keytool displays a warning and ignores the keypass value. “
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.
1 Guest(s)
