Certificate Management

General Information

UserGate NGFW uses the secure HTTPS protocol to manage the device. It can intercept and decrypt transit user traffic that uses SSL (HTTPS, SMTPS, POP3S) as well as authorize the administrators for web console access using their certificates.

To perform these functions, NGFW employs different types of certificates:

Name

Description

Web console SSL certificate

Used to create a secure HTTPS administrator connection to the NGFW web console.

Captive portal SSL certificate

Used to create a secure HTTPS user connection to the captive portal auth page, to display a block page or the captive portal's logout page, and to support FTP proxy operation. This certificate must be issued with the following parameters:

  • Subject name --- the value set for the Captive portal auth domain defined on the General settings page.

  • Subject Alternative names --- include all domains for which this certificate is used as they are specified on the General settings page:

    • Captive portal Auth domain

    • Captive portal Logout domain

    • Block page domain

    • FTP over HTTP domain

    • Web portal domain specified in the web portal settings.

By default, a certificate for the auth.captive domain signed with an SSL inspection certificate is used with the following parameters:

  • Subject name = auth.captive

  • Subject alternative names = auth.captive, logout.captive, block.captive, ftpclient.captive, sslvpn.captive

If the administrator has not loaded their own certificate for this role, NGFW will automatically reissue this certificate when the administrator changes one of the domains on the General settings page (those used for auth.captive, logout.captive, block.captive, ftpclient.captive, and sslvpn.captive).

Note If the administrator uses a separate certificate for the Captive portal domain, then he must add not only his Auth captive portal domain, but also the fixed cert.captive domain in the Subject Alternative name extension of the certificate. If cert.captive is not added, the browser will generate a security error when authenticating via a certificate.

SSL inspection certificate

This is a CA class certificate used to generate SSL certificates for the Internet hosts whose HTTPS, SMTPS, or POP3S traffic is intercepted. For example, when the HTTPS traffic for yahoo.com is intercepted, the original certificate issued with

Subject name = yahoo.com

Issuer name = VeriSign Class 3 Secure Server CA --- G3,

is substituted with

Subject name = yahoo.com

Issuer name = [company as stated in the CA certificate added to NGFW].

This certificate is also used to create the default certificate for the SSL captive portal role.

SSL inspection (intermediate)

An intermediate certificate in the CA chain used to issue the SSL inspection certificate. Only the public key is required for correct operation.

SSL inspection (root)

The root certificate in the CA chain used to issue the SSL inspection certificate. Only the public key is required for correct operation.

User certificate

The certificate assigned to a NGFW user. The user can be either added locally or imported from LDAP. The certificate can be used to authorize user access to the published resources using reverse proxy rules.

Web console certification chain

Certificate authority certificate for access to the web console. For successful authorization, the administrator certificate must be signed with a certificate of this type.

SAML server

Supports NGFW operation in conjunction with a SSO SAML IDP server. For more details on configuring NGFW to work with a SAML IDP authorization server, see the relevant section of this Guide.

Web portal

The certificate used for the web portal. If not specified explicitly, NGFW will use the SSL captive portal certificate signed with the SSL inspection certificate. For more details on configuring the web portal, see the relevant section of this Guide.

There can be multiple SSL web console, SSL captive portal, and SSL inspection certificates, but only one certificate of each type may be active and used for the respective purposes. There can also be multiple web console authorization CA type certificates, and each of them can be used to verify the authenticity of administrator certificates.

To create a new certificate, follow these steps:

Name

Description

Step 1. Create a new certificate.

In the Certificates section, click Create.

Step 2. Fill in the relevant fields.

Provide values for these fields:

  • Name: the name under which the certificate will be displayed in the certificate list.

  • Description: a description of the certificate.

  • Country: the country where the certificate is being issued.

  • State or province name: the state or province where the certificate is being issued.

  • Locality name: the city or town where the certificate is being issued.

  • Organization name: the name of the organization to which the certificate is being issued.

  • Common name: the certificate name. To ensure compatibility with the majority of browsers, we recommend using only Latin characters.

  • Email: your company's email.

Step 3. Specify the purpose of the certificate.

After creating the certificate, specify its intended role in NGFW. To do this, select the relevant certificate in the certificate list, click Edit, and specify the type of the certificate (web console SSL, SSL inspection, web console authorization CA). If you have selected a web console SSL certificate, NGFW will reboot the web console service and prompt you to connect using the new certificate. An SSL inspection certificate starts working immediately after you have selected it. For more details on HTTPS traffic inspection, see the SSL Inspection chapter.

NGFW allows you to export certificates created there and import certificates created in other systems --- e.g., a certificate issued by a CA that your organization trusts.

To export a certificate, follow these steps:

Name

Description

Step 1. Select a certificate for export.

Select the desired certificate in the certificate list.

Step 2. Export the certificate.

Select the export type:

  • Export certificate: export certificate data in the .der format without exporting the certificate's private key. Use the exported SSL inspection certificate file to set it as the local CA on user computers. For more details on this, see the Installing local CA certificates appendix.

  • Export CSR: export a CSR, e.g., to be signed by a CA.

Note It is recommended to save the certificate to be able to restore it later.

Note For security purposes, UserGate does not allow the export of private keys for certificates.

Note Users can download a SSL inspection certificate for installation on their own computers from the UserGate server from a direct link: http://UserGate_IP:8002/cps/ca

To import a certificate, you need to have the certificate files (and, optionally, the private key for the certificate). If you have those, follow the steps below:

Name

Description

Step 1. Start the import procedure.

Click Import.

Step 2. Fill in the relevant fields.

Provide values for these fields:

  • Name: the name under which the certificate will be displayed in the certificate list.

  • Description: a description of the certificate.

  • Certificate file: upload the certificate data file.

  • Private key: upload the private key file for the certificate.

  • Passphrase: specify the private key passphrase (if required).

  • Certificate's chain: a file containing the upstream CA certificates used when creating this certificate. This field is optional.

Using Corporate CA to Create an SSL Inspection Certificate

If a corporate CA or CA chain already exists in the company, you can specify a certificate issued by the corporate CA as the SSL inspection certificate. If the corporate CA is trusted by all corporate users, SSL interception will be transparent, and users will not get a certificate warning.

Let us consider in more detail how to configure NGFW in this scenario. Suppose that the organization uses a corporate CA based on the Microsoft Enterprise CA integrated into Active Directory. The CA hierarchy is as follows:

Example hierarchy of a corporate CA

You will need to issue a certificate for NGFW using Sub CA2 and configure it as the SSL inspection certificate. In addition, you will need to issue a UserGate SSL decrypt certificate as the CA.

Important! An imported certificate can be used as an SSL inspection certificate only if it satisfies these two requirements:

  1. Certification Authority (CA) class certificate:

  • Must have the attribute CA:TRUE in its X509v3 Basic Constraints (RFC 5280) extension.

  • In the UserGate ➜ Certificates section of the admin console, such certificates have the CA certificate file icon to the left of the certificate name.

  1. The certificate has no usage restrictions or has explicitly set Digital signature and Certificate signing attributes in its purpose section.

  • The certificate does not use any X509v3 Key Usage (RFC 5280) extension attributes.

    • Such a certificate will have a value of None in the Certificate purpose column of the admin console's UserGate ➜ Certificates section.

  • If the certificate uses the X509v3 Key Usage extension, it must contain the digitalSignature and keyCertSign attributes for it to be used for SSL inspection.

    • In that case, Digital signature and Certificate signing will be listed in the Certificate purpose column of the admin console's UserGate ➜ Certificates section.

Note UserGate does not support the rsassaPss signature algorithm. Make sure that no part of the certificate chain used to issue the SSL inspection certificate uses this algorithm.

To do the above, follow these steps:

Name

Description

Step 1. Create a CSR request for creating a certificate in NGFW.

Click Generate ➜ New CSR. Fill in the relevant fields and create the CSR. A private key and a request file will be created. Download the request file by clicking Export.

Step 2. Create the certificate based on the prepared CSR.

In Microsoft CA, create a certificate based on the CSR file you obtained in the previous step using the certreq utility:

certreq.exe -submit -attrib "CertificateTemplate:SubCA" HTTPS_csr.pem

As an alternative, you can do this using the Microsoft CA web console by selecting the "Subordinate Certification Authority" template. For more details, consult the Microsoft documentation. When the procedure completes, you will obtain the certificate (public key) signed by Sub CA2.

Step 3. Download the resulting certificate.

Download the certificate (public key) you created from the Microsoft CA web console.

Step 4. Upload the certificate to the CSR you created earlier.

In NGFW, select the CSR created earlier and click Edit. Upload the certificate file and click Save.

Step 5. Specify the SSL inspection certificate type.

In NGFW, select the CSR created earlier and click Edit. In the Use as field, specify SSL inspection certificate.

Step 6. Download the certificates for the intermediate CAs (Sub CA1 and Sub CA2).

In the Microsoft CA web console, select and download the certificates (public keys) for Sub CA1 and Sub CA2.

Step 7. Upload the Sub CA1 and Sub CA2 certificates to NGFW.

Click Import and upload the Sub CA1 and Sub CA2 certificates you downloaded in the previous step.

Step 8. Set the "SSL inspection intermediate CA" type for the Sub CA1 and Sub CA2 certificates.

Select the uploaded certificates in UserGate and click Edit. In the Use as field, specify SSL inspection intermediate CA for both certificates.

Step 9. (Optional) Upload the Root CA certificate to UserGate.

Click Import to upload the organization's root certificate to NGFW. Click Edit and specify SSL inspection root CA in the Use as field.