What is NSP TLS?

NSP TLS administration overview

The NSP uses TLS to secure the following:

The NSP includes a Public Key Infrastructure, or PKI server, to distribute TLS certificates. A PKI server can generate internal and external certificates using private root CA certificates. See the NSP Installation and Upgrade Guide for more information about NSP TLS deployment using a PKI server.

You can generate your own TLS certificates. The NSP PKI server can be used as a certificate authority to sign your certificates, or you can use other tools to generate and sign certificates.

Support for deprecated TLS versions

You can choose to use TLS 1.2 or 1.3 by selecting either option for the Protocol Version parameter on the TLS server profile form (see How do I configure NE TLS server authentication?, Step 3) or on the TLS client profile form (see How do I configure NE TLS client authentication?, Step 5). External systems such as OSS clients may use older versions, which are deprecated. You can enable the older TLS versions in the NSP for compatibility with such systems.

The tlsv1ProtocolsEnabled parameter in the nsp-config.yml file enables or disables the support for deprecated TLS versions:

Kubernetes infrastructure security

The NSP Kubernetes infrastructure certificates undergo automatic scheduled renewal, but manual renewal or replacement options are also available; see Kubernetes infrastructure certificate replacement for information.

NSP cluster

The TLS certificates that secure the NSP Kubernetes infrastructure automatically and silently renew monthly.

No alarm is raised regarding the expiry or renewal; however, the renewal action is logged in the /var/log/messages file on the NSP cluster host. The following is the starting log entry for a renewal operation:

timestamp node1-3 systemd: Starting Renew K8S control plane certificates...

NSP deployer host

The NSP automatically renews the Kubernetes infrastructure TLS certificates twice annually, based on an internal schedule; no operator action is required.

NSP container registry

The NSP cluster communication with the NSP container registry for pulling container images and Helm charts is secured using a TLS certificate that you can manually update.

NSP internal TLS

The internal TLS certificate secures the internal NSP processes. For maximum security, an NSP PKI server uses an internally generated private root CA to create the certificate. Consequently, no certificate from any external CA is trusted for access to system processes.

A PKI server generates an internal certificate automatically during initialization. During an NSP system installation or upgrade, the NSP PKI server must be running in order for each component to request and receive an internal certificate, as described in each NSP and NFM-P installation and upgrade procedure.

When you add or replace an NSP system element such as an NSP Flow Collector or an NFM-P component, the PKI server provides an internal certificate during initialization, as described in the component installation procedure.

Note: To reduce complexity, each upgrade procedure instructs you to start the PKI server, regardless of the upgrade conditions.

NSP external TLS

The external TLS certificate secures the NSP interfaces used by clients and external systems. The certificate can be signed by an external CA, or by the private root CA of an NSP PKI server.

Managing NSP TLS certificates

NSP internal or external TLS certificate replacement may be required when:

How do I replace the internal or external NSP TLS certificate? describes how to replace the internal TLS certificate, the external certificate, or both, in an NSP system.

Kubernetes infrastructure certificate replacement

You can manually update the NSP deployer host certificate, as may be required for security reasons, or, for example, if the NSP deployer host is shut down at the scheduled renewal time. See How do I update the K3s certificate for an NSP deployer host VM? for information.

You can also manually replace the NSP container registry certificate; see How do I update the NSP container registry TLS certificate? for information.

Internal certificate replacement

To replace the internal certificate used in an NSP system, you must start the PKI server, enable the NSP to regenerate internal certificates, and then run the installation script.

External certificate replacement

The external certificate replacement method depends on the TLS deployment method:

Note: Some system conversion or migration operations may include additional TLS configuration requirements; see the NSP Installation and Upgrade Guide for more information.

TLS certificate expiry notifications

The NSP checks the expiry date of each TLS certificate during initialization, and every 24 hours thereafter. After an NSP TLS certificate expires, the NSP cluster continues to operate, but functions that depend on secure communication are unavailable.

When a certificate expires or approaches expiry, the NSP raises one of the following server or internal certificate alarms:

Note: The NSP raises one alarm per certificate.

Note: The alarms for internal or external NSP certificate expiry do not clear automatically.

Note: No alarm is raised for an expiring or expired NSP Kubernetes infrastructure certificate.

Note: The Days Remaining value in an expiry alarm is based on the number of complete 24-hour periods until the certificate expiry time. If fewer than 24 hours remain until expiry, the Days Remaining value is zero; however, the NSP does not raise an alarm about the certificate expiry until the next periodic check, 24 hours later.