Please consider registering

sp_LogInOut Log In sp_Registration Register

Register | Lost password?
Advanced Search

— Forum Scope —

— Match —

— Forum Options —

Minimum search word length is 3 characters - maximum search word length is 84 characters

sp_Feed Topic RSS sp_TopicIcon
help certificate management
May 12, 2023
13:23, EEST
Francesco Zambon
Forum Posts: 62
Member Since:
December 20, 2021
sp_UserOfflineSmall Offline


Please I need some advice about certificate management:

// *** Certificates
logger.info("Loading certificates..");

File privatePath = new File(applicationCertificateStore.getBaseDir(), "private");

// Define a certificate for a Certificate Authority (CA) which is used
// to issue the keys. Especially
// the HTTPS certificate should be signed by a CA certificate, in order
// to make the .NET applications trust it.
// If you have a real CA, you should use that instead of this sample CA
// and create the keys with it.
// Here we use the IssuerCertificate only to sign the HTTPS certificate
// (below) and not the Application Instance Certificate.
KeyPair issuerCertificate = ApplicationIdentity.loadOrCreateIssuerCertificate(
"ProsysSampleCA@" + ApplicationIdentity.getActualHostNameWithoutDomain() + "_https_" + certKeySize, privatePath,
"opcua", 3650, false, certKeySize);

int[] keySizes = new int[] {certKeySize};
// If you wish to use big certificates (4096 bits), you will need to
// define two certificates for your application, since to interoperate
// with old applications, you will also need to use a small certificate
// (up to 2048 bits).
// keySizes = new int[] { 2048, 4096 };

// *** Application Identity
// Define the Server application identity, including the Application
// Instance Certificate (but don’t sign it with the issuerCertificate as
// explained above).
final ApplicationIdentity identity = ApplicationIdentity.loadOrCreateCertificate(appDescription,
"Sample Organisation", /* Private Key Password */"opcua", /* Key File Path */privatePath,
/* Issuer Certificate & Private Key */null,
/* Key Sizes for instance certificates to create */keySizes,
/* Enable renewing the certificate */true);

// Create the HTTPS certificate bound to the hostname.
// The HTTPS certificate must be created, if you enable HTTPS.
String hostName = ApplicationIdentity.getActualHostName();
identity.setHttpsCertificate(ApplicationIdentity.loadOrCreateHttpsCertificate(appDescription, hostName, "opcua",
issuerCertificate, privatePath, true, certKeySize));


In the demo code, the password used to protect the certificate’s private key is stored in the Java class.

My OPC UA server will be installed on premise. How could I protect the password?

I was planning to encrypt the password with The AES Encryption algorithm, but I should still save the parameters of the algorithm (main password, salt, iv, …).

Could you explain how to handle a real case?

Best regards,

May 12, 2023
15:51, EEST
Bjarne Boström
Forum Posts: 941
Member Since:
April 3, 2012
sp_UserOfflineSmall Offline

You have hit one of the fundamental problems of programming as far as I’m aware. This is why some say passwords are a broken concept.

We do have a issue in our internal bugtracker that the sample private key passwords should be removed at some point in the future. A bit similar to opc.https, they “serve no purposes”. The password would only be useful if you have some external system (e.g. human) inject the password at runtime, anything else is security by obscurity (like there are different levels of that, but I would categorize more like is X possible or not possible).

So basically this is a good question, but it is a general one of “how to store secrets that must be able to be reverted to their cleartext formats” and thus outside of the SDK.

You should also define “protect from what/who” and “attack scenario” in these types of questions.

Anyway, our own applications pretty much work like the samples. For example your users might wish to change the default certificate (e.g. https://forum.prosysopc.com/forum/opc-ua-simulation-server/how-to-set-custom-server-application-instance-certificate/). As a rule of thumb the user of the application is the one who “owns the certificate”. Thus there shouldn’t be a need to protect the password from them. So the only general scenario is that someone else would steal the private key, and it shouldn’t not be useable if you do not know the password. However, if the attacker was able to access the machine (since the priv.key shouldn’t leave that), it might be impossible to protect it.

OK, it would be possible to make a system to ask the priv.key password from the user. In a client application this could be easier. But in a server app you most likely do not have that option. So, you will need to somehow store the password and have it back in the cleartext form. As far as I’m aware, there is basically almost none ways to do this in a secure way (depends on the attack scenario). IF you happen to have a TPM (Trusted Platform Module) chip on the hardware, you could in theory maybe store it there. Though, at this point my knowledge ends, I’m not sure is even that 100% secure. And it wouldn’t probably help if someone just steals the whole machine. Or like you can encrypt the disk, but then the machine wouldn’t start without human interaction and if you can have human interaction at the start you can just have a human enter the password via some prompt when the machine starts.
In theory you could store main password in code, but since java basically perfectly decompiles (and it is easy enough to look for strings in binary anyway), it doesn’t really help. Most likely if the attacker could read the priv key file, they could also read the program jar(s).

Thus, it depends on what exactly you wish to protect it from.

What do you think?

The best way would be if the crypto operation itself and the priv key would be external e.g. within a TPM module, and then it would do all crypto operations. However we do not support this nor we have tried. Also it wouldn’t no longer be pure java at that point. So this is a theory-only level comment. Basically the operations SDK does via Java/BouncyCastle do need the key. In some distant future we might support this.

May 22, 2023
17:09, EEST
Francesco Zambon
Forum Posts: 62
Member Since:
December 20, 2021
sp_UserOfflineSmall Offline

Dear Bjarne,

Thank you very much for your help.
I like your idea of ​​using a TPM (Trusted Platform Module).

Best regards,

Forum Timezone: Europe/Helsinki

Most Users Ever Online: 518

Currently Online:
9 Guest(s)

Currently Browsing this Page:
1 Guest(s)

Top Posters:

hbrackel: 130

pramanj: 86

ibrahim: 75

rocket science: 72

Francesco Zambon: 62

Sabari: 62

kapsl: 57

gjevremovic: 49

Xavier: 43

fred: 41

Member Stats:

Guest Posters: 0

Members: 651

Moderators: 16

Admins: 1

Forum Stats:

Groups: 3

Forums: 15

Topics: 1415

Posts: 6035

Newest Members:

u310498, ntd, francescac, yahya95, leomajoe, Gus, sdfsdfsdfsd, riatuccker

Moderators: Jouni Aro: 988, Otso Palonen: 32, Tuomas Hiltunen: 5, Pyry: 1, Petri: 0, Bjarne Boström: 941, Heikki Tahvanainen: 402, Jukka Asikainen: 1, moldzh08: 0, Jimmy Ni: 25, Teppo Uimonen: 21, Markus Johansson: 42, Niklas Nurminen: 0, Matti Siponen: 288, Lusetti: 0, Ari-Pekka Soikkeli: 5

Administrators: admin: 1