During NSP system deployment, you can choose to use one or more TLS certificates that the NSP generates and signs, or can provide one or more of your own signed certificates, which are called custom certificates.

Note: The required NSP server certificates vary, depending on the NSP deployment options. For example, if mTLS is enabled for MDM and gNMI telemetry in the NSP cluster configuration file, you are prompted to provide the mTLS artifacts during NSP secret installation.

Note: If the NSP clusters use advertised hostnames, the SAN field of an NSP server certificate must include the advertised hostname of each NSP cluster.

Note: The private key and certificate files for an NSP deployment must be in unencrypted PEM format.

A custom TLS certificate for the NSP must:

• be CA-signed

• be a 2048-bit RSA key

• include serverAuth in the ExtendedKeyUsages field

Note: A custom NSP server certificate must be unique to an NSP cluster, and must include the NSP cluster address in the SAN field.

See To generate custom TLS certificate files for the NSP for configuration information.

If your NSP deployment includes the NFM-P and you use self-signed certificates, you must do one of the following:

• Submit separate NSP and NFM-P CSRs using the appropriate artifacts.

• Convert the signed artifacts to the appropriate format:

  • The NSP TLS artifacts are an OpenSSL RSA key and certificate

  • The NFM-P requires Java Key Store, or JKS, keystore and truststore files.

If the NFM-P main servers use hostnames for communication with other components:

• The SAN field of the TLS certificate must include the main server hostname specified in samconfig on the main server.

• The NSP clusters must use only DNS to resolve the hostnames.

Note: A short hostname is valid only if DNS can resolve the hostname.

The NSP PKI service 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:

• Required:

  • CA:TRUE

  • certificate sign key usage

  • chained .pem file in which the NSP Intermediate cert is first in the chain, followed by the intermediate certificates, and ending with the root certificate

• Recommended:

  • path length = 0, which signifies that the PKI server can sign only end-entity certificates

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

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.

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

• tlsv1ProtocolsEnabled

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.