Skip to content

Custom CA

As we have seen in the section on security, to put a client in communication with the server, it is necessary to manually intervene by moving the client certificates from "rejected" to "trusted" folders.

It is also possible to configure the server to trust all clients whose certificate is signed by a specific Certificate Authority: the CA acts as guarantor for the certificates, and following a few steps you can use it to allow the server to trust all those clients who have a certificate signed by this authority.

Trusting Application Certificates from Custom CA

The server can be configured to trust the certificates created by the custom CA by performing the following steps:

  • If the custom CA consists only of the root, then just copy its certificate to the directory trusted within the usual server certificate path (default: /var/lib/com.eurotech.framework.opcua.server/$APPLICATION_PID). Then the user must create a Certificate Revocation List for the CA (mandatory in .crl format) and copy it inside the /crl folder.
  • If the custom CA consists of root CA and intermediate, then you need to copy the root certificate in the /issuers/trusted folder and the intermadiate certificate in the directory /trusted within the usual server certificate path (default: /var/lib/com.eurotech.framework.opcua.server/$APPLICATION_PID). After that a Certificate Revocation List for both the root and intermediate must be created and copied inside the /issuers/crl (root's one) and /crl folder (intermediate's one).

This way, whenever a customer who has certificates signed by the custom CA or intermediate tries to access, the server will recognize the signer among its trusted certificates and, if the certificate is not present in the CRL, it will automatically admit the new client.

It's best practise that the PKI files are provided in the following format:

  • the server private key and the root and intermediate certificate in .pem format
  • the server certificate in .der format
  • the crls must be crl format

Trusting User Tokens from Custom CA

If everything is done correctly, the server is now able to automatically trust application certificates signed by a custom CA. But now you have to go to the user token certification phase: depending on the server settings, in case the customer accesses with a token type Anonymous or User&Password, there are no further problems, as the first will always be accepted and the second will have to pass the credentials check.

In the case of the token Certificate, the customer would again have to expose the certificates as an access method, so that the need to intervene manually to move the certificates from rejectedto trusted.

However, this situation can also be automated as in the case of Application Certificates: in fact, even in this case we can copy the certificates, but in the section users of the usual path to certificates.

The steps to follow are:

  • If the custom CA consists only of the root, then just copy its certificate to the directory trusted within the usual server's "users" certificate path (default: /var/lib/com.eurotech.framework.opcua.server/$APPLICATION_PID/users/), along with its Certificate Revocation List in .crl format, to be put in the /crl folder.
  • If the custom CA consists of root and intermediate, then you need to copy the root certificate in the /issuers/trusted folder and the intermadiate certificate in the directory trusted within the usual server's "users" certificate path (default: /var/lib/com.eurotech.framework.opcua.server/$APPLICATION_PID/users/), along with their CRLs to be put inside /issuers/crl (root crl) and /crl (intermediate one).

By following these steps it will be possible to automatically trust the user tokens that have been signed by the Custom CA specification.

CRL and certificate revocation

We said earlier that one of the key steps to automate the trusting process is to create a CRL: this is a file that contains the list of certificates that were trusted, but for some reason are no longer trusted. It is therefore a fundamental tool to keep under control those clients that were previously reliable, but that are no longer (incorrect use of the server, posing unsafe, etc.).

It is possible both to create the crl, and to revoke the certificates: when the crl is created and every time a revocation is made, it is necessary to create/update the crl, and to copy the file (always in format .crl) in the suitable folders (default: /var/lib/com.eurotech.framework.opcua.server/$APPLICATION_PID/crl, /var/lib/com.eurotech.framework.opcua.server/$APPLICATION_PID/issuers/crl, /var/lib/com.eurotech.framework.opcua.server/$APPLICATION_PID/users/crl e /var/lib/com.eurotech.framework.opcua.server/$APPLICATION_PID/users/issuers/crl).

The server, whenever a client tries to connect through a certificate signed by a CA, checks that the certificate is not present in the crl before accepting the connection. This is done both at the level of ApplicationCertificate, and at that of UserToken (for this reason there is the crl folder both at the root of the certificates, and in the path /users).

Once a client is revoked, it won't be able to connect to the server anymore. To allow it again, it is mandatory the creation of new certificates.