Configuring TLS for the NSP

Using a custom TLS certificate

You can generate and use a custom TLS certificate in an NSP deployment, as described in To generate custom TLS certificate files for the NSP.

A custom TLS certificate that you provide must meet the following criteria:

Note: After you redeploy an NSP cluster that uses a custom TLS certificate and has deleteOnUndeploy set to false in the nsp-config.yml file, you must reset the OpenSearch security configuration, as described in To reset the OpenSearch security configuration.

Using a PKI server

To reduce the complexity of configuring TLS in a new NSP system, or adding components to an existing system, you can use the Public Key Infrastructure server. A PKI server can create and sign certificates, if required, and distribute certificates to NSP components that are configured as requestors.

Note: The NSP messaging subsystems require a separate TLS certificate that is used internally. The certificate is generated and distributed automatically by the PKI server, which runs automatically during an NSP installation or upgrade. The separate internal certificate is required regardless of the external TLS configuration or deployment method.

In addition to simplifying TLS deployment, the benefits of using a PKI server include:

See To configure and enable a PKI server for information about using a PKI server to deploy TLS.

Functional description

A PKI server is a standalone utility that implements TLS certificate signing requests (CSRs) from requesting NSP components. A PKI server is available on a station to which you extract an NSP software bundle.

Note: Only one PKI server instance is required for automated TLS deployment throughout an entire NSP system.

Note: Nokia recommends that you run the PKI server from the default installation location; optionally, you can run a copy of the utility on any host that is reachable by each requestor.

Initially, a PKI server attempts to import an existing local TLS certificate; if no certificate is found, the server prompts the operator for certificate parameters, creates a local private root CA service, and polls for CSRs.

After receiving a CSR from a requestor, a PKI server uses the local root CA to sign the requestor certificate, and then returns the signed certificate to the requestor. The requestor uses the signed certificate to create the required keystore and truststore files, and then enables TLS on the required local interfaces.

In order for a PKI server to implement TLS on an NSP component that is not deployed in an NSP cluster, you must enable the PKI server in the component configuration. If a PKI server is specified:

Using intermediate signing certificates

A PKI server can act as an intermediate CA. The supported intermediate key type is a 4096-bit RSA key.

The required and recommended key extensions are the following:

For example:

Note: Required restrictions are in boldface type:

X509v3 Basic Constraints: critical

CA:TRUE, pathlen:0

X509v3 Key Usage: critical

Digital Signature, Certificate Sign, CRL Sign

TLS version and cipher support

By default, only TLS 1.2 is enabled. However, external systems such as OSS clients may use deprecated TLS versions. For NSP compatibility with such systems, you can enable older TLS versions.

Note: You must enable support for the deprecated TLS versions in a shared-mode NSP system that includes a Release 20 WS-NOC, if the secure parameter in the nspos section of the NSP configuration file is set to true.

The following parameter in the NSP configuration file enables or disables the support for the deprecated TLS versions:

NFM-P TLS version and cipher support

The NFM-P includes a tool for managing the supported TLS versions and ciphers. A TLS version or cipher may be required for compatibility with an older OSS, or may be considered unsecure and need to be disabled if a security vulnerability is identified. You can configure the NFM-P to enable or disable the support for specific versions and ciphers, as required.