Certificates How to



1.            Certificates

1.1          Instance certificates


If you are interested in the difference between a CA (certificate authority) signed certificate and a self-signed certificate and the whole X.509v3 certificate story, please have a look in in Wikipedia or read the books of  Bruce Schneiers.


1.2          Why use a CA signed certificate

There is no difference in the inherent security of the communication, whether the certificate is signed or not. And you might argue in an environment, where the server and client “operator” know each other, as would be the case in most OPC-UA user applications, there is no need to have signed certificates. Any way, it has been decided to use signed certificates.


1.3          Obtaining a signed certificate


The following way is one way of doing it, there might be others just as valid. The following procedure is quite complicated and lots of things can go wrong.


1)     Go to the website of openssl (www.openssl.org) and download the version of openssl which supports your OS (in the following I’ll only refer to windows. Openssl is preinstalled in both Mac and most Linux distributions). Install it on your PC. If you want further instructions and an easy “how to” go to http://www.madboa.com/geek/openssl, where there are some good examples. The Openssl website also have both the man pages (Unix language for instruction manuals) and some “How To’s” You’ll also have to add the environment variable OPENSSL_CONF to your system It must point to the openssl.cfg file present in your bin folder of you openssl installation i.e. c:\OpenSSL-Win32\bin\openssl.cfg. Not doing so will result in an error when you try to use openssl. If you don’t like to modify the environment variables, you can set it from the cmd prompt every time you use openssl.

2)     The next step is to make a certificate request, which can be sent to the CA. This is done by executing the following command: openssl req -new -newkey rsa:2048 -nodes -subj "/CN=www.yourwebsitehere.dk/C=DK/L=YourLocationHere/O=YourCompanyNameHere/OU=YourCompanyUnitHere" -keyout YourPrivateKey.pem -out YourCertificateRequest.csr
The key must/should be at least 2048 bit (the longer the key, the more time it will take to crack it by “brute force”. It is commonly accepted that a key of 2048 bit is secure). The rest of the parameters are pretty much self-explanatory.
Further the private key created, SHOULD NOT BE SEND ANYWHERE, but kept in a safe place. Also the private key and the private *.pfx certificate should not be send to anybody, but kept safe. In theory, if you have mailed it just once, it is worthless.

3)     Send the certificate request, you have created above, to a CA, such as www.trustzone.com. (which in turn uses Global Sign)

4)     You’ll then receive a signed certificate and an intermediate certificate.  Further you must download the Root Certificate from the CA, also accessible from trustzone.com. (Using so-called chained certificates) The next step is to combine the signed certificate, with your private key into a .pfx certificate, which can be imported to  the Kepware UA Server. This is done by copy / paste the content of the key and the content of the signed certificate into a common file, which will look something like this:



Next we use openssl to “export” the certificate into a X.509 (*.pfx) certificate, which can be imported to the Kepware Server.
Use the following openssl command to do the export: openssl pkcs12 -export -out yourcert.pfx -in VerifiedTrustZone.pem -name "Your Certificate"
If you are on windows you’ll probably get the error: “unable to write 'random state'” To avoid this error, please execute the following command: “set RANDFILE=.rnd”  This must be repeated every time you use openssl i.e. every time you make a new cmd prompt window to use openssl. When prompted for the password, just hit enter (unless you want to protect you certificate with a pass phrase). Your command line should look something like this:

6)     Now we have a signed working certificate, which we can import it into our OPC-UA server and client:

7)     On the server computer:

a.     Launch the OPC UA Configuration and view the 'Instance Certificate' tab. 

b.     In the instance certificate group, click 'Import certificate' and browse for the private key certificate (.pfx extension) you just created. Import the certificate.

c.     Click 'View server certificate' and select the 'Certificate Path'.

d.     Make note of which Root and Intermediate certificates are required to complete the certificate chain. 

e.     Using MMC and the certificate snap in, import the root and intermediate certificates into Microsofts Certificate Store in the path given above.

f.      Reinitialize the server.

g.     Don’t worry about the ”Client Driver”, which you should only use, in case you have a OPC-UA Client driver running in Kepware. You should end up having something like this, where the server common name is the name configured in your certificate. Also when you “View the server certificate” it should be “OK”, i.e. valid.



On the client computer (only valid if you use a Kepware client):

a.     In the trusted servers “group” click 'Import certificate' and browse for the “CA Root Certificate” and for the CA Intermediate Certificate” (in the form of X.509 and with a pfx extension). I case you only have the certificates in the downloaded form, from their website (which is the most common case), you’ll have to import them into Windows certificate store, using MMC, and the “certificates” snap in, and thereafter export them as “DER encoded binary X.509 (.cer)” certificates, using the same tool.

b.     In the Instance certificate tab under “Client Driver” import the signed certificate for the Client organisation in the correct form, using the same tools as mentioned above.

c.     Reinitialize the server (actually the client).

d.     If you use any other client, than Kepware, please refer to the products manual. Most of the times the certificates should be placed a folder called

9)     Now both client and server are ready to get connected. You MUST of course set the server endpoint to the correct URN and security level i.e. “256 and sign & encrypt”. The next step is made from the assumption, that will use a Kepware Client, running within the Kepware Server. Make a new channel, select “OPC-UA” client, configure the correct endpoint and the corresponding security configuration.

10)  When the new Channel is finished, add a new device, by clicking on the “Add new device” line. Name it and keep all the default settings, until you get the step, where you can “select import items”. Click on this and after a short while, you’ll get an error message, that it could not connect to the server for browsing. Press cancel.

11)  Now, still on the client side, go to the “OPC-UA Configuration” and select the “Trusted Servers” tab. There you should see the server you are trying to connect to, with a red cross over it. Select it and press the “trust” button. Reinitialize the server.

12)  On the Server side, go the “OPC-UA Configuration”, and select the “Trusted Clients” tab and trust the client in question. REMEMBER to reinitialize the server, otherwise the changes will not take effect.

13)  Try step 10 one more time, and you’ll now be able to browse the server and add the tags in the client. In the end your OPC-Configuration should look similar to these dumps, of course only with the clients and servers you have configured:
Server side:

the Client side:



It is important to understand that the whole process is about “exchanging” certificates ie public keys. That is, the server needs the public key from the client and vice versa.This means that the client will use the public key from the server and the server will use the public key from the client. They will both need the Root- and Intermediate certificates necessary to validate the key’s against the CA.







The above figure show how the certificate request is sent to the CA, signed and sent back. It is then combined to create a private key certificate. The public keys (signed certificates without the private key) are exchanged between client and server and vice versa.


1.4          Performance.


The above method, where asymmetric keys are used, are only used to establish the connection. Once the connection is established, UA switches over to use symmetric keys, in order to boost performance. In order to heighten the safety, the UA protocol replaces the symmetric keys with certain intervals.

It is also important to understand the difference between the problems, where you would like to make a secure transaction on a website, and UA, where connections potentially could be up for years.