A very good question.

Internally, this leads to the following code:

But reading the documentation of KeyStore says if you use “JKS”,

“The system will return the most preferred implementation of the specified keystore type available in the environment.”

And since PKCS12 is nowadays the preferred KeyStore format, I guess it works like you experience. So, in other words, “JKS” and “PKCS12” are equal in practice.

Hi,

As far as I’m aware, we do not use this version of the constructor ourselves (nor any tests of today call it). That constructor predates me working with the SDK and it is possible that it had more use in the past (or that some use was intended but not finalized in a release, this is ~10 years old stuff).

That being said, we could maybe use a bit more support for more standard “security APIs” in the SDK etc. so if something doesn’t work let us know and hopefully we can fix things if needed. I know that historically there were some problems in older java versions and doing things via BouncyCastle directly was a working solution. Also I believe in Java 6 time the keytool did lack some parameters that would be needed for OPC UA, but my understanding of the keytool is a bit limited (I have used it, but not much).

Anyway all other ApplicationIdentity constructors take in paths to the certificate (typically as .der file)+private keys (typically as .pem file) or them directly as objects. I would personally probably say they would be the preferred way as of today, i.e. the way SDK is normally expected to be used (and we use it like this) does not involve any KeyStores etc. and keytool usage. The CertificateStore interface is used to hold the “truststore” so to say and the normally used (included) implementation PkiDirectoryCertificateStore stores them in .der files on disk. That being said, we do not have “a CertificateStore” concept for the application’s own certs.

The constructor you are using basically just delegates to the super class’ constructor:
“
/**
* Creates a new SecureIdentity object from a pfx-keystore file.
*
* @param storeLocation location of the pfx-file
* @param alias string alias of the key pair, if null or not found in specified pfx-file, last
* entry is used
* @param privateKeyPassword password of the private key
* @param keyStorePassword password of the keystore
* @param keyStoreType type of the key store, “JKS” and “PKCS12” supported
* @throws KeyStoreException if the keystore has not been initialized (loaded)
* @throws NoSuchProviderException if the specified provider (Bouncy Castle) is not registered in
* the security provider list
* @throws NoSuchAlgorithmException if the algorithm used to check the integrity of the keystore
* cannot be found
* @throws CertificateException if any of the certificates in the keystore could not be loaded
* @throws IOException
* @throws UnrecoverableKeyException if a key in the keystore cannot be recovered
*/
public SecureIdentity(File storeLocation, String alias, String privateKeyPassword, String keyStorePassword,
String keyStoreType) throws IOException, SecureIdentityException
“
Thus, per that documentation (which is very old) “JKS” and “PKCS12” are the supported ones. That being said, as long as code-wise the return of KeyStore.getKey of the loaded keystore from the file given can be casted to java.security.interfaces.RSAPrivateKey it should maybe work (and KeyStore.getCertificate must be castable to java.security.cert.X509Certificate, but that I would assume to be more likely to happen always). Please let us know if something does not work.