NXLog Manager uses X.509 certificates for various security purposes and has a built-in PKI system to manage them.
To list the available certificates, click CERTIFICATES under the ADMIN menu. A list similar to the following appears.
The table contains the following information.
The certificate subject name.
The type is either CA or CERT.
The time and date after which the certificate is valid.
The time and date before which the certificate is valid.
This status is either VALID, REVOKED, or EXPIRED.
- Private Key
This field indicates whether the private key pair of the certificate is available or not.
The certificate list shows entries in a hierarchical (tree) structure. Certificates (and sub-CAs) will be rooted under the CA which was used to sign it.
If the PKI system does not have any certificates, you will need to create a CA first.
The certificate authority is used to issue and sign certificates and, subsequently, to verify the associated trust relationships. To be able to create certificates, a CA is required. To create a CA cert, click Add new CA on the certificate list page. The certificate creator dialog is displayed.
Some field values are pre-filled if certificate settings are already configured. After clicking Create, the new CA appears.
Some field values are pre-filled if the certificate settings are already configured. Fill in the name (certificate subject) and expiry and select the certificate purpose. It is possible to customize the certificate purpose flags, but this is not required if the certificate is only used within NXLog Manager with NXLog. After clicking Create, the new certificate appears, displaying information similar to the following screenshot.
To export a certificate, click Export on a certificate’s general information page or below the certificate list after selecting one certificate. The following options appear.
In order to support external certificate tools and PKI systems, certificates can be exported in different formats. The NXLog agents use PEM formatted X.509 certificates.
To export selected certificates from the list in PKCS#12 key store format, click on the export PKCS#12 button from the certificates page. It will ask for an optional password to protect the PKCS#12 key store:
In order to support external certificate tools and PKI systems, certificates can be imported in different formats.
It is not possible to delete a certificate unless it is revoked. If the PKI system does not contain the certificate of an NXLog agent and the presented certificate is authenticated, the connection will be accepted.
If the PKI system does contain the certificate of an NXLog agent and the certificate is found to be revoked, the connection will be refused.
|Deleting certificates is not recommended.|
This operation will issue a new certificate. It can be used to replace an existing certificate which has already expired, will shortly expire, or is revoked.
|Generally, it is not a good idea to have multiple valid certificates with the same subject. If a certificate has been superseded by a new one (e.g. already pushed to the agent), make sure to revoke the former.|
By default, NXLog-Manager encrypts the private keys of certificates in the database, to prevent stealing them if the database is hacked. This is 2-phase encryption with predefined algorithms:
The first time the 'admin' user logs-in, NXLog-Manager generates a random encryption key with predefined length. This key is only kept in application memory space and certificate keys will be encrypted with it.
NXLog-Manager then encrypts this key with the authorized user password and saves it in the user settings in the database. When NXLog-Manager is restarted, the authorized user with a key must login to decrypt this key with the password to make it available for encryption/decryption of certificate keys.
|An authorized user is eligible for this key when it has the role of ROLE_ADMINISTRATOR or ROLE_CERTIFICATE. By default an 'admin' user has ROLE_ADMINISTRATOR.|
|When a new authorized user is added, the encryption key must also be encrypted with the new user’s password and saved in the database. Currently, this can only happen if the user logs in to the same application session for which this key is already available (an authorized user with a stored key has logged in to unlock the key). In the future, there will be enhancements in NXLog Manager to skip the log-in step for new authorized users.|
There is an option Do not encrypt agent manager’s private key in Agent Manager. With this option active, when the NXLog Manager has to be restarted for some reason it is not necessary for the administrator to log in to decrypt their keys so the manager can (re)start.
If the encryption key cannot be decrypted due to some configuration problem or defect, NXLog Manager offers a recover option to reset all the certificates with encrypted keys and reset the encryption key for them. When the encryption key is not available after log in with authorized user, a dialog similar to this one is displayed:
If reset certificates and encryption key is the last resort and there is no other option, this action can be done from this dialog. This will update the certificates for the connected agents with renewed certificates. It is a good outcome if there are as many agents as possible connected and the manager should be already running with non-encrypted keys.
All offline agents during this operation must be updated locally with the new certificates. They will not be able to connect to the manager when it is running with new certificates for authentication.
There will be notifications for each change/failure in the UI and also in the logs.