--- title: "Managing Certificates" canonical: "https://docs.infoblox.com/space/nios85/35381871/Managing%20Certificates" format: markdown --- This section covers the following: > Macro (toc) # About HTTPS Certificates The NIOS appliance generates a self-signed certificate when it first starts. A self-signed certificate is signed by the subject of the certificate, and not by a CA (Certificate Authority). This is the default certificate. When your computer first connects to the NIOS appliance, the appliance sends this certificate to authenticate itself to your browser. Because the default certificate is self-signed, your browser does not have a trusted CA certificate or a cached NIOS appliance server certificate (saved from an earlier connection) to authenticate the NIOS appliance certificate. Also, the host name in the default certificate is *www.infoblox.com,* which is unlikely to match the host name of your NIOS appliance. Consequently, messages appear warning that the certificate is not from a trusted certifying authority and that the host name on the certificate is either invalid or does not match the name of the site that sent the certificate. Either accept the certificate just for this session or save it to the certificate store of your browser. To eliminate certificate warnings, you can replace the default self-signed certificate with a different certificate that has the host name of your NIOS appliance. The NIOS appliance supports X.509 certificates in .PEM format. After the initial login, you can do one of the following: - Generate another self-signed certificate with the correct host name and save it to the certificate store of your browser. - Request a CA-signed certificate with the correct host name and load it on the NIOS appliance. For more information, see Generating Certificate Signing Requests below. - When you receive the certificate from the CA, upload it to the appliance. Additionally, you can upload a certificate along with the private key, as described below in Uploading HTTPS Certificates. - Download the certificate from a trusted CA, as described below in Downloading HTTPS Certificates. ## Generating Self-Signed Certificates You can replace the default certificate with a self-signed certificate that you generate. When you generate a self-signed certificate, you can specify the correct host name and change the public/private key size, enter valid dates and specify additional information specific to the NIOS appliance. If you have multiple appliances, you can generate a certificate for each appliance with the appropriate host name. You can generate a self-signed certificate using either the SHA-1 or SHA-256 (SHA-2) hash algorithm. To generate a self-signed certificate: 1. Grid: From the **Grid** tab, select the **Grid ****Manager** tab -> **Members** tab -> *member* checkbox, and then click **Certificates** -> **HTTPS ****Cert** -> **Generate ****Self-signed ****Certificate** from the Toolbar. In a Grid, ensure that you select the Grid Master when generating a self-signed certificate. 2. In the *Generate **Self-Signed **Certificate* dialog box, complete the following: - **Secure ****Hash ****Algorithm ****and ****Key ****Size: **You can select one of the following: SHA-1 with a RSA key size of 1024 or 2048, SHA-256 (SHA-2) with a RSA key size of 2048 or 4096, SHA-384 with a RSA key size of 2048 or 4096, SHA-512 with a RSA key size of 2048 or 4096. The default value is SHA-256 2048. Note that The SHA-384 and SHA-512 are not supported during scheduled full upgrades for the Grid. If your Grid includes a reporting server, ensure that you **DO NOT** select a key size of 4096 bit for SHA-256. Otherwise, the reporting feature might not function properly because Java does not support SHA-256 with a key size of 4096. - **Days ****Valid:** Specify the validity period of the certificate. - **Common ****Name:** Specify the domain name of the NIOS appliance. You can enter the FQDN (fully qualified domain name) of the appliance. - **Organization:** Enter the name of your company. - **Organizational ****Unit:** Enter the name of your department. - **Locality:** Enter a location, such as the city or town of your company. - **State ****or ****Province:** Enter the state or province. - **Country ****Code:** Enter the two-letter code that identifies the country, such as US. - **Admin ****E-mail ****Address:** Enter the email address of the appliance administrator. - **Comment:** Enter information about the certificate. - **Subject Alternative Name**: You can specify Subject Alternative Names (SAN) in order to secure additional host names across different domains or subdomains. You can add the following entries to be included as SAN extension to self-signed certificate: **DNS**, **Email**, **IP Address**, and **URI**. Click the Add icon and Grid Manager adds a row to the table. Click the row and select the entry from the drop-down list, and then enter the value for the SAN entry. You can add up to 30 entries. To remove an entry from the list, select the SAN entry, and then click the Delete icon. For Google Chrome version 58 and later, Firefox version 101.0 and later, Safari in iOS 13 and macOS 10.15, and some other browsers, it is mandatory to enter the subject alternative name. 3. Click **OK**. 4. If the appliance already has an existing HTTPS certificate, the new certificate replaces the existing one. In the *Replace **HTTPS **Certificate **Confirmation* dialog box, click **Yes**. The appliance logs you out, or you can manually log out. When you log in to the appliance again, it uses the new certificate you generated. > ⚠️ **Note** > ⚠️ > ⚠️ If you have enabled the DNS over TLS or the DNS over HTTPS feature on a Grid member, then every time a new self-signed certificate is generated, the DNS over TLS or the DNS over HTTPS service (depending on which feature is enabled) automatically restarts to upload the new certificate. ## Generating Certificate Signing Requests You can generate a CSR (certificate signing request) that you can use to obtain a signed certificate from your own trusted CA. Once you receive the signed certificate, you can import it in to the NIOS appliance. To generate a CSR: 1. Grid: From the **Grid** tab, select the **Grid ****Manager** tab -> **Members** tab -> *member* checkbox, and then click **Certificates** -> **HTTPS ****Cert** -> **Create ****Signing ****Request** from the Toolbar. 2. In the *Create **Certificate **Signing **Request* dialog box, enter the following: - **Secure ****Hash ****Algorithm ****and ****Key****Size:** You can select one of the following: SHA-1 with a RSA key size of 1024 or 2048, SHA-256 (SHA-2) with a RSA key size of 2048 or 4096, SHA-384 with a RSA key size of 2048 or 4096, SHA-512 with a RSA key size of 2048 or 4096. The default value is SHA-256 2048. Note that the SHA-384 and SHA-512 are not supported during scheduled full upgrades for the Grid. - **Common ****Name**: Specify the domain name of the NIOS appliance. You can enter the FQDN of the appliance. - **Organization**: Enter the name of your company. - **Organizational ****Unit**: Enter the name of your department. - **Locality**: Enter a location, such as a city or town of your company. - **State ****or ****Province**: Enter the state or province. - **Country ****Code**: Enter the two-letter code that identifies the country, such as US. - **Admin ****E-mail ****Address**: Enter the email address of the appliance administrator. - **Comment**: Enter information about the certificate. - **Subject Alternative Name**: You can specify Subject Alternative Names (SAN) in order to secure additional host names across different domains or subdomains. You can add the following entries to be included as SAN extension to CSR (Certificate Signing Requests): **DNS**, **Email**, **IP Address**, and **URI**. Click the Add icon and Grid Manager adds a row to the table. Click the row and select the entry from the drop-down list, and then enter the value for the SAN entry. You can add up to 30 entries. To remove an entry from the list, select the SAN entry, and then click the Delete icon. 3. Click **OK**. ## Uploading HTTPS Certificates When you receive the certificate from the CA, and import it to the appliance, the NIOS appliance finds the matching CSR and takes the private key associated with the CSR and associates it with the newly imported certificate. The appliance then automatically deletes the CSR. You can also upload the certificate along with its private key. When you do so, you do not need to generate a CSR on the NIOS appliance. Before you upload the certificate, Infoblox recommends that you save the certificate on the local disk and set the private key permissions to 600 and owned by root. Note that you might need to set the private key permissions to other values, depending on your business requirements. Also ensure that both the certificate and the private key are in PEM format and in the same upload file, and that the private key is not protected. If the CA sends an intermediate certificate that must be installed along with the server certificate, you can upload both certificates to the appliance. The appliance supports the use of intermediate certificates to complete the chain of trust from the server certificate to a trusted root CA. This eliminates intermediate certificate security warnings that appear when you open a web browser and try to connect to an Infoblox appliance. For instructions to upload a CA certificate, see Uploading CA Certificates below. To import a HTTPS certificate: 1. Grid: From the **Grid** tab, select the **Grid** **Manager** tab -> **Members** tab -> *member* checkbox, and then click **Certificates** -> **HTTPS** **Cert** -> **Upload** **Certificate** from the Toolbar. 2. Navigate to where the certificate is located and click **Open**. 3. If the appliance already has an existing HTTPS certificate, the new certificate replaces the existing one. In the *Replace* *HTTPS* *Certificate* *Confirmation* dialog box, click **Yes**. The appliance imports the certificate and logs you out. When you log in to the appliance again, it uses the certificate you imported. > ⚠️ **Note** > ⚠️ > ⚠️ If you have enabled the DNS over TLS or the DNS over HTTPS feature on a Grid member, then every time you upload an HTTPS certificate, the DNS over TLS or the DNS over HTTPS service (depending on which feature is enabled) automatically restarts to upload the new certificate. For more information, see *[Configuring DNS over TLS and DNS over HTTPS Services](https://infoblox-docs.atlassian.net/wiki/spaces/nios85/pages/35418166)*. ## Downloading HTTPS Certificates You can download the current certificate or a self-signed certificate, as described in the *Generating Certificate Signing Requests* section. To download a certificate: 1. Grid: From the **Grid** tab, select the **Grid** **Manager** tab -> **Members** tab -> *member* checkbox, and then click **Certificates** -> **HTTPS** **Cert** -> **Download** **Certificate** from the Toolbar. 2. Navigate to where you want to save the certificate, enter the file name, and then click **Save**. # About Client Certificates You can generate client certificates for a Grid Master or a Grid Master candidate, and then send it to another server, such as a Hardware Security Module (HSM). ## Generating a Client Certificate To generate a client certificate: 1. Grid: From the **Grid** tab, select the **Grid ****Manager** tab. Grid Master Candidate: From the **Grid** tab, select the **Grid ****Manager** tab -> **Members** tab -> *member* checkbox. 2. From the Toolbar, click **Certificates** -> **Client ****Cert** -> **Generate ****Client ****Certificate**, and select either **RSASHA1** or **RSASHA256**. - If you are generating a certificate for an HSM group with SafeNet Luna SA 4 devices, you must select **RSASHA1**; and if the certificate is for an HSM group with SafeNet Luna SA 5 or later, select **RSASHA256**. The appliance displays a confirmation dialog after it generates the certificate. If a certificate had been previously generated, the appliance displays a dialog warning that if the previous certificate was registered with a server, then the new certificate must be registered with the server. ## Viewing Client Certificates To view the client certificates that were generated: 1. Grid: From the **Grid** tab, select the **Grid** **Manager** tab. Grid Master Candidate: From the **Grid** tab, select the **Grid** **Manager** tab -> **Members** tab -> *member* checkbox. 2. From the Toolbar, click **Certificates** -> **Client** **Cert** -> **View** **Client** **Certificate**, and select either **RSASHA1** or **RSASHA256.** The appliance displays the selected certificate. ## Downloading Client Certificates To download a client certificate: 1. Grid: From the **Grid** tab, select the **Grid** **Manager** tab. Grid Master Candidate: From the **Grid** tab, select the **Grid** **Manager** tab -> **Members** tab -> *member* checkbox. 2. From the Toolbar, click **Certificates** -> **Client** **Cert** -> **Download** **Client** **Certificate**, and select either **RSASHA1** or **RSASHA256.** 3. Save the certificate. # About CA Certificates If the CA sends an intermediate certificate that must be installed along with the server certificate, you can upload both certificates to the appliance. The appliance supports the use of intermediate certificates to complete the chain of trust from the server certificate to a trusted root CA. This eliminates intermediate certificate security warnings that appear when you open a web browser and try to connect to an Infoblox appliance. When you configure two-factor authentication for smart card users, ensure that you upload the required CA certificates before you enable the certificate authentication service. For information about two factor authentication and how to configure it, see* *[*Defining the Authentication Policy*](https://infoblox-docs.atlassian.net/wiki/spaces/nios85/pages/35882322). Only superusers and limited-access users with the required permissions can manage CA certificates. For information about admin permissions, see [*Administrative Permissions for Certificate Authentication Services and CA Certificates*](https://infoblox-docs.atlassian.net/wiki/spaces/nios85/pages/35817303). Also, see About CA Certificates for CISCO APIC below. ## Uploading CA Certificates To upload a CA-signed certificate: 1. Grid: From the **Grid** tab, select the **Grid ****Manager** tab. Member: From the **Grid** tab, select the **Grid ****Manager** tab -> **Members** tab -> *member* checkbox. 2. Select **Certificates** -> **Manage ****CA ****Certificates** from the Toolbar. 3. In the *CA **Certificates* editor, click the Add icon. 4. In the *Upload* dialog box, click **Select** and navigate to the certificate you want to upload. 5. Select the file and click **Upload**. > ⚠️ **Note** > ⚠️ > ⚠️ - NIOS can only upload certificates that are in PEM format. A.PEM file can contain more than one certificate. For information about how to convert CA certificates to .PEM format, see Converting CA Certificates to PEM below. > ⚠️ - If you have enabled the DNS over TLS or the DNS over HTTPS feature on a Grid member, then every time you upload a CA certificate, the DNS over TLS or the DNS over HTTPS service (depending on which feature is enabled) automatically restarts to upload the new certificate. For more information, see [*Configuring DNS over TLS and DNS over HTTPS Services*](https://infoblox-docs.atlassian.net/wiki/spaces/nios85/pages/35418166). Repeat the steps to add additional CA-signed certificates. The *CA* *Certificates* dialog box displays the following information about the intermediate certificates: - **Subject**: The name of the certificate. - **Issuer**: The name of the trusted CA that issued the certificate. - **Serial**: The serial number of the certificate. - **Valid**: The validity period of the certificate. - **Used ****by**: Displays **SSL/TLS,** when CA certificate is not used for certificate authentication, or **CAS**, when CA certificate is associated with a certificate authentication service. You can also do the following: - Select a certificate and click the Delete icon to delete it. - Print the data or export it in .csv format. ## About CA Certificates for Cisco ACI Grid Manager accepts CA certificates and certificate chains; therefore, you can upload both root and intermediate (one-file certificate chain) certificates. Following are recommendations and best practices for having valid Cisco ACI certificates authenticated via Grid Manager. For a Root CA certificate, complete the following on the Cisco ACI side: 1. Select the Root CA certificate as the default Certificate Authority. 2. Issue a Key Ring certificate request signed by this Certificate Authority. Make sure that the APIC Key Ring certificate is created. 3. In the Cisco ACI GUI, select **Fabric** -> **Fabric Policies** -> **Pod Policies** -> **Policies** -> **Management Access** -> **default**. 4. Make sure that the Admin Key Ring and Oper Key Ring correspond to the one created in step 2. Now you can upload and select the Root CA certificate in Grid Manager. For an Intermediate CA certificate, complete the following on the Cisco ACI side: 1. Select the certificate chain as the default Certificate Authority. This certificate chain must include at least one Intermediate and Root CA certificate. 2. Issue a Key Ring certificate request signed by this Certificate Authority. Make sure that the APIC Key Ring certificate is created. 3. In the Cisco ACI GUI, select **Fabric** -> **Fabric Policies** -> **Pod Policies** -> **Policies** -> **Management Access** -> **default**. 4. Make sure that the Admin Key Ring and Oper Key Ring correspond to the one created in step 2. Now you can upload and select the certificate chain in Grid Manager. If you are unable to select the whole chain in the CISCO APIC Configuration tab, choose the Intermediate certificate. Recommended best practices: - Make sure that the CA marker is set to "True" in the CA certificate. You can check it in OpenSSL. - Make sure that the Subject (CN) of the APIC Key Ring certificate is a fully qualified domain name or a distinguished name of the requesting device. When NIOS tries to establish a connection to the APIC using SSL, it compares the APIC host name value with the value specified in the APIC Key Ring certificate CN (common name). If they do not match, the certificate verification fails. If you want to specify something different than FQDN, for example, an IP address, for the APIC Key Ring certificate CN, include an additional Subject Alternative Name marker in X509v3 extensions: X509v3 Subject Alternative Name: IP Address:[ip-addr] or X509v3 Subject Alternative Name: DNS:FQDN or both of them X509v3 Subject Alternative Name: DNS:FQDN, IP Address:ip-addr where ip-addr is a valid IP address of the APIC device, and FQDN is a valid fully qualified domain name. - Make sure to include the following markers in the APIC Key Ring certificate: X509v3 extensions: X509v3 Basic Constraints: CA:FALSE Netscape Cert Type: SSL Server ... X509v3 Key Usage: critical Digital Signature, Key Encipherment X509v3 Extended Key Usage: TLS Web Server Authentication - Certificate date must be valid. - The time settings in Cisco ACI and NIOS must be valid and accurate. # Converting CA Certificates to PEM Format NIOS can only upload certificates that are in PEM format. PEM files are Base64 encoded ASCII files. You can use OpenSSL to convert other certificate formats, such as P7B and DER, into PEM format. You can run OpenSSL on Linux and Windows systems. For Linux, OpenSSL is pre-installed. For Windows, you can manually install an OpenSSL for Windows. For information about OpenSSL, visit its web site at [*http://www.openssl.org/*](http://www.openssl.org/). To convert a P7B file to PEM format using OpenSSL: 1. Download and unzip the CA certificate file in P7B format. 2. Navigate to the directory where you unzip the CA certificate file. 3. Identify the PKCS7 directory. 4. Use the following OpenSSL command to convert the P7B file to PEM format: `$ openssl pkcs7 -in xxxx.p7b -print_certs -out yyyy.pem` where xxxx is the name of the P7B file and yyyy is the name of the converted PEM file. To convert a DER file to PEM format using OpenSSL: 1. Download and unzip the CA certificate file in DER format. 2. Navigate to the directory where you unzip the CA certificate file. 3. Use the following OpenSSL command to convert the DER file to PEM format: `$ openssl x509 -inform DER -outform PEM -in xxxx.cer -out yyyy.pem` where xxxx is the name of the DER file and yyyy is the name of the converted PEM file. > Macro (__confluenceADFMigrationUnsupportedContentInternalExtension__)