> This page is for version 10.
> For other versions, use one of these documentation indexes:
> - 11 (default): https://docs.nvidia.com/base-command-manager/product-manuals/11/llms.txt
> - 10: https://docs.nvidia.com/base-command-manager/product-manuals/10/llms.txt

> For clean Markdown of any page, append .md to the page URL.
> For a complete documentation index, see https://docs.nvidia.com/base-command-manager/product-manuals/llms.txt.
> For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://docs.nvidia.com/base-command-manager/product-manuals/_mcp/server.

# Create Self-Signed Server Certificate Pair For Testing Purposes

The cluster administrator can issue self-signed server certificates. For testing purposes, a self-signed certificate pair can be installed on any device where authentication is needed via the web interface, for example on an Ingress client connecting to an Ingress server (section [4.22.12](/containerization/kubernetes#42212-configuring-the-ingress-https-server-certificate)). The configuration is carried out as follows:

The `cm-kubernetes-setup` wizard is started up on the active head node by the cluster administrator.

The menu item `Configure Ingress` is selected (figure [A.1](#fig-ingress-configure-ingress)).

![Option to configure Ingress](/base-command-manager/product-manuals/_fern-img/21bf403ccc11d88231b4a136495c89075ef3e412d3039ee321ccd9f587ded024.webp)

*Figure A.1: Option to configure Ingress*

The Kubernetes cluster is chosen in the next screen. The Kubernetes cluster is the one on which Ingress is to be configured (figure [A.2](#fig-ingress-choose-kube-cluster))

![Prompt for the Kubernetes cluster to configure Ingress for](/base-command-manager/product-manuals/_fern-img/b709528fd6fc5a9f21964333ce5ac67387d31be01809811e0bf3bbc10d01c667.webp)

*Figure A.2: Prompt for the Kubernetes cluster to configure Ingress for*

A prompt appears asking if an existing server certificate pair should be used. Since a self-signed pair is to be used for testing purposes, `no` is selected (figure [A.3](#fig-ingress-question-self-signed))

![Prompt to select existing certificate (choose “no” here for self-signed.)](/base-command-manager/product-manuals/_fern-img/7da45c004945a13c51adbf344e9ce6b9204ac4cbceaa6b9717487f0f39d40a05.webp)

*Figure A.3: Prompt to select existing certificate (choose “no” here for self-signed.)*

A list of domains to customize is displayed (figure [A.4](#fig-ingress-configure-trusted-domains))

![Prompt for customizing trusted domains that need to be part of the self-signed certificate.](/base-command-manager/product-manuals/_fern-img/d4fc9e7fc7391bba84bdfeb4e4c0a56e3ffa8cd819fb0b18c7a3866ccba77823.webp)

*Figure A.4: Prompt for customizing trusted domains that need to be part of the self-signed certificate.*

For this example, the domain is customized to `superpod.nvidia.local` (figure [A.5](#fig-ingress-configure-trusted-domains-2))

![Prompt answered with an entry superpod.nvidia.local](/base-command-manager/product-manuals/_fern-img/e2648f835d298ee7e99d41704995e7a028737e93c24298383c79c2535d3fb8e3.webp)

*Figure A.5: Prompt answered with an entry superpod.nvidia.local*

All the names entered end up in the SAN part of the server certificate as valid DNS names. Continuing with `Ok` executes steps to take care of the configuration (figure [A.6](#fig-ingress-self-signed-done))

![The output when the self-signed configuration has completed.](/base-command-manager/product-manuals/_fern-img/fc11ef3129c772b683b85b666f235a62fcf94d51eff49f6c6778ccbdd37570a4.webp)

*Figure A.6: The output when the self-signed configuration has completed.*

So far in the procedure, the following has been carried out:

* a private CA key pair has been created (`ingeress-ca.key` and `ingress-ca.crt` in figure [A.7](#fig-ingress-self-signed-cert-files))

* a server certificate (`ingress-server.crt`) has been made and signed by the private CA

* Ingress has been patched to use the server certificate pair (`ingress-server.crt` and `ingres-server.key`)

![The server certificate files on the active head node.](/base-command-manager/product-manuals/_fern-img/4f3a9c8c87a3b5d350fa0bf2909a9259269f179e937f05ffb4abeaf67a3cabd0.webp)

*Figure A.7: The server certificate files on the active head node.*

The `default` in this path is the label of the Kubernetes cluster for which the certificates have been created.

**A Note On Using Self-Signed Certificates**

The use of self-signed certificates is not recommended. It is only useful for testing purposes. The use of self-signed certificates may cause users can run into obscure issues, where it is hard to uncover that the problem is because of self-signed certificates.

The private key for the server certificate has been uploaded, from its location on the active head node at:\
`/etc/kubernetes/pki/default/ingress-server.key`

The certificate has also been uploaded from its location on the active head node at:\
`/etc/kubernetes/pki/default/ingress-server.crt`

The self-signed CA, taken from: `/etc/kubernetes/pki/default/ingress-ca.crt`, can alternatively be installed on the local machine (the cluster administrator laptop, for example) in order for the browser to recognize the certificate as trusted. Details are typically OS dependent, but for Chrome on a Linux system it follows a method of accepting the certificate by ignoring a warning about the site certificate being untrusted.

The warning is due to the CA server not being a recognized Certificate Authority (CA) like the CAs that are recognized by a browser.

If there is no internet access to the cluster URL, then the warning about the CA not being a recognized Certificate Authority is not an issue, and the user can simply accept the “untrusted” certificate.

If there is internet access to the cluster URL, then some cluster administrators may regard it as more secure to trust the self-signed certificate rather than external certificate authorities anyway.