- OS Support
- Enterprise Edition Reference Manual
- NXLog Manager
- 134. Introduction
- 135. System Requirements
- 136. Supported Platforms
- 137. Installation
- 138. Dashboard and Menu
- 139. Fields
- 140. Patterns
- 141. Correlation
- 142. Agents
- 143. Templates
- 144. Agent Groups
- 145. Certificates
- 146. Settings
- 147. Users, Roles, and Access Control
- NXLog Add-Ons
NXLog Manager uses X509 certificates for various security purposes and has a built-in PKI system to manage these.F
To list the available certificates, click on the CERTIFICATES menu item under the ADMIN menu. A list similar to the following will appear.
The table contains the following information.
The certificate subject name.
This can be either CA or CERT.
The time and date after the certificate is valid.
The time and date before the certificate is valid.
The status of the certificate can be VALID, REVOKED and 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 can be used to later verify the trust relationship. To be able to create certificates, a CA is required. To create a CA cert, click on the Add new CA on the certificate list page. The following screenshot shows the certificate creator form.
Some values will be already filled in if the Certificate settings are configured. After clicking Create, the new CA should appear.
Some values will be already filled in if the Certificate settings are configured. Fill in the name (certificate subject), expiry and select the certificate purpose. It is possible to customize the certificate purpose flags, but this is not required if the certificate will be used only within NXLog Manager and with NXLog. After clicking Create, the new certificate should appear. The following screenshot shows the information page of a certificate.
To export a certificate, click Export on the certificate general information page or below the certificate list after selecting and entry. The following options will appear.
In order to support external certificate tools and PKI systems, certificates can be exported in different formats. The NXLog agents use PEM formatted X509 certificates.
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. It is recommended not to delete certificates. If the PKI system does not contain the certificate of an NXLog agent and the presented certificate is authenticated, the connection will be accepted unless the certificate is found in the local PKI system and is revoked.
This operation will issue a new certificate which can be used to replace and existing one 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 superseeded by a new one (e.g. already pushed to 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:
First time the 'admin' user logs-in, NXLog-Manager generates 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 authorized user password and saves it in the user settings in the database. When NXLog-Manager has been restarted, the authorized user with a key must login to decrypt this key with his password, so it’ll be available for certificate keys encryption/decryption.
|Authorized user eligible for this key is any user with one of the roles ROLE_ADMINISTRATOR or ROLE_CERTIFICATE (by default 'admin' user has ROLE_ADMINISTRATOR).|
|When new authorized users are added later to the system, the encryption key must also be saved in DB and encrypted with their own password. At the time of writing this manual this can only happen if the user logs-in in the same application session for which this key is already available (authorized user with 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.|
In general it’s good idea not to use the default 'admin' user for administrative purposes. It should be considered more like a backup user when something goes wrong with application administration, and possible encryption key problem:
Log-in with 'admin' and change his default password.
Create another user(s) for administrative purposes, assign them ROLE_ADMINISTRATOR and log-in with them to make sure they’ll have the encryption key stored encrypted with their password.
The admin user can be disabled further, but this is not necessary step and should be done only in case there is another user with administrative permissions to enable him when this becomes necessary.
There is an option in Agent Manager "Don’t encrypt agent manager’s private key". This is good practice to keep it running as much as possible when NXLog-Manager has to be restarted for some reason (it’s not necessary authorized user with encryption key to log-in to decrypt its keys so the manager can start). Also this is important to keep agents connected as much as possible.
When something goes wrong and the encryption key can’t be decrypted due to some configuration problem (or bug), 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 similar dialog will be shown:
If reset certificates and encryption key is the last resort and there is no other option, this can be done from this dialog. This will update also the certificates for the connected agents with the renewed ones, so it’s good outcome if as many agents are currently connected as possible (for this the manager should be already running - with non-encrypted keys). It must be noticed all offline agents during this operation must be updated locally with the new certificates, they won’t 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 UI, also in the logs.