Assigning CSR-based Certificates to TLS Contexts

You can request a digitally signed certificate from a Certification Authority (CA) for a TLS Context. This process is referred to as a certificate signing request (CSR) and is required if your organization employs a Public Key Infrastructure (PKI) system. The CSR contains information identifying the device such as a Distinguished Name (DN) or subject alternative names in the case of an X.509 certificate.

➢

To assign a CSR-based certificate to a TLS Context:

1.

Open the TLS Contexts table (see Configuring TLS Certificate Contexts).

2.

Select the required TLS Context, and then click the Change Certificate link located below the table; the Change Certificates page appears.

3.

Under the Certificate Signing Request/ Generate Self-Signed Certificate Request group, fill in the following fields according to your security provider's instructions:

a.

Distinguished Name (DN) fields (uniquely identifies the device):

◆

In the 'Common Name [CN]' field, enter the common name. If you leave this field empty, the device generates the CSR with the default CN "CN=ACL_<device's 6-digit serial number>".

◆

In the 'Organizational Unit [OU]' field, enter the section of the organization.

◆

In the 'Company name [O]' field, enter the legal name of your organization.

◆

In the 'Locality or city name [L]' field, enter the city where your organization is located.

◆

In the ' State [ST]' field, enter the state or province where your organization is located.

◆

In the 'Country code [C]' field, enter the two-letter ISO abbreviation for your country.

a.

If you want to generate a CSR for SAN (with multiple subject alternate names), then from the 'Subject Alternative Name [SAN]' drop-down list, select the type of SAN (e-mail address, DNS hostname, URI, or IP address), and then enter the relevant value. You can configure multiple SAN names, using the 1st to 5th 'Subject Alternative Name [SAN]' fields.

b.

From the 'Subject Key Identifier' drop-down list, configure the subject key identifier (SKI) X.509 field:

◆

User-defined hex value (max. 128 characters), without "0x, for example, "00D06F00D4D06746"

◆

hash-SHA1 (sets SKI to 160 bits of SHA-1 digest on public key)

◆

hash-SHA1-60lsb (sets SKI to 0100 followed by least significant 60 bits of SHA-1 digest on public key)

a.

From the 'Key Usage' drop-down list, select the key usage X.509 field values:

◆

Digital Signature (Certificate can be used to apply a digital signature)

◆

Non Repudiation (Certificate can be used to sign data as above, but the certificate's public key may be used to provide non-repudiation services, preventing the signing entity from falsely denying some action)

◆

Key Encipherment (Certificate may be used by the subject to encrypt a symmetric key which is then transferred to the target, decrypted, and subsequently used to encrypt and decrypt data sent between the two entities)

◆

Data Encipherment (Certificate can be used by the subject to encrypt and decrypt actual application data)

◆

Key Agreement (Certificate's subject can use a key agreement protocol such as Diffie-Hellman to establish a symmetric key with a target that may then be used to encrypt and decrypt data sent between the two entities)

◆

Key Certificate Sign (Certificate's subject can use public key for verifying Digital Signature on Public Key certificates)

◆

Certificate Revocation List Sign (Certificate's subject can use public key for verifying signatures on Certificate Revocation List lists, e.g., CRLs)

◆

Encipher Only (Certificate's subject can use public key only for enciphering data while performing Key agreement)

◆

Decipher Only (Certificate's subject can use public key only for deciphering data while performing Key agreement)

You can define the key as critical (mandatory), by selecting the 'Critical' check box.

a.

From the 'Extended Key Usage' drop-down list, select the extended key usage X.509 field values:

◆

Server Authentication

◆

Client Authentication

You can define the key as critical (mandatory), by selecting the 'Critical' check box.

a.

From the 'Signature Algorithm' drop-down list, select the hash function algorithm (SHA-256 or SHA-512) with which to sign the certificate.

4.

Click the Create CSR button; a textual certificate signing request is displayed below the button:

5.

Copy the text and then send it to your security provider (CA) to sign this request.

6.

When the CA sends you a server certificate, save the certificate to a file (e.g., cert.txt). Make sure that the file is a plain-text file containing the "BEGIN CERTIFICATE" header.

7.

Scroll down to the Upload Certificates Files From Your Computer group, and then select and upload the cert.txt file, by clicking Load Device Certificate File:

8.

Wait for the certificate to successfully upload to the device.

9.

Save configuration.

10.

Verify that the private key is correct:

a.

Open the TLS Contexts table, and then select the TLS Context.

b.

Click the Certificate Information link located below the table.

c.

Make sure that the 'Status' field displays "OK"; otherwise, consult with your security administrator: