Creating a certificate signing request for a custom intermediate certificate authority

Technical Articles ID: KB94034
Last Modified: 2023-06-22 12:13:28 Etc/GMT

Environment

Skyhigh Web Gateway (SWG) 10.x, 9.x, 8.x, 7.8.x

Summary

This article describes how to create a certificate-signing request (CSR) for a custom intermediate certificate authority (for HTTPS Inspection) or server certificate.

With SWG, typically, there are two types of SSL certificates that are needed and that you might want to have officially signed:

Intermediate certificate authorities
Server certificates

This article describes how to create a CSR for both types of certificates. This CSR is signed by a third-party certificate authority (CA), such as your internally used PKI.

You might want to use a custom intermediate certificate authority for HTTPS inspection instead of the default self-signed one that's shipped with the product. When using HTTPS inspection, SWG acts as a man-in-the-middle for the HTTPS connection and replaces the certificate provided to the user. The CA then signs the certificate.
The server certificate can be used to secure access to SWG. For example, when accessing the user interface, intercepting a connection in a reverse proxy environment, or securing the connection to the ICAP server.

NOTE: To use the certificate, the third-party CA must sign the CSR. The private key and CSR created below aren't sufficient.

IMPORTANT:

SWG provides the technical mechanism to support the integration of third-party certificates. But, the generation, validation, or troubleshooting of third-party certificates isn't supported.
This article explains how to create the CSR for an intermediate CA or a server certificate.
The article doesn't explicitly cover how and where to import the certificate into the product. See your product documentation for further details.

Solution

To configure a custom intermediate CA or server certificate, you need the private key and the certificate. The following steps create the private key and CSR. The CSR is sent to the signing CA. After it's signed, the signing CA sends the certificate.

The following steps can be followed on every device running a recent version of the OpenSSL toolkit. We recommend connecting to a system running SWG via SSH or command line, and running the steps. The example steps outlined below were performed on such a device. These steps might differ on other devices.

Log on to SWG (or another device providing OpenSSL toolkit) using SSH or a command-line session.
Create a temporary directory:
1. Type mkdir -p ~/new_certificate/private ~/new_certificate/csr and press Enter.
2. Type cd ~/new_certificate and press Enter.
Set permissions so other users can't read sensitive data:
Type chmod 700 private and press Enter.
Create a new private key:
Type openssl genrsa -aes256 -out private/new_certificate.key 4096 and press Enter.

NOTE: When creating the private key, you're asked for a passphrase. This passphrase is needed later.
Create a CSR:
1. Download one of the attached openssl configuration files (.zip) and extract it.
  - To create an intermediate CA, download openssl_intermediate.zip.
  - If you want to create a server certificate, download openssl_server.zip.
2. Extract the downloaded .zip file.
3. Place openssl.cnf from the extracted archive to the previously created working directory (~/new_certificate).
  This action can be performed via WinSCP for example.
4. OPTIONAL STEP:
  If you must create a server certificate for multiple names (How to use the "subject alternative names" extension):
  1. Open openssl.cnf in an editor of your choice.
  2. Remove the comment (#) from the line starting with #subjectAltName.
  3. At the bottom of the file, in the [alt_names] section, add all the needed subject alternative names.
  IMPORTANT: When subject alternative names are used, the common name set in the certificate is ignored. If you use subject alternative names, make sure that the primary name is listed in the subject alternative names section as well. (The primary name is normally put into the common name.)
5. Type openssl req -new -nodes -config openssl.cnf -key private/new_certificate.key -out csr/new_certificate.csr -sha512 and press Enter.
6. OpenSSL now asks for details to configure the meta information for the common name configuration as below:
  - For Intermediate certificate authority: Pick a name that's visible as the CA that signed the certificate. You can pick any name that suits your needs.
  - For Server certificate: When you create a server certificate, the common name must match the host name of the service that the certificate is going to secure.
    For example, if you access the user interface of your SWG using https://mwg-admin.mycorp.tld:4712, the common name must be mwg-admin.mycorp.tld
7. You're prompted for the private keys passphrase that you set up earlier. Enter the passphrase.
8. Get the private key and CSR. When working on an SWG installation, you can use WinSCP to get the files. They're stored in your home directory. For example:
  - /home/my_user/new_certificate/private/new_certificate.key
  - /root/new_certificate/private/new_certificate.key
  - /home/my_user/new_certificate/csr/new_certificate.csr
  - /root/new_certificate/csr/new_certificate.csr
Have the CSR signed:
After you've obtained the two files, you must have the CSR signed by your third-party CA.
How the CSR is signed depends on the third-party vendor or your local PKI administrators. The usual process is to send the CSR file and have it signed, which means you get a signed certificate as a response.

IMPORTANT:
- Do NOT share the private key. It's not needed for signing.
- The CSR contains the recommended or needed extensions, but it's possible for the signing instance to overwrite the extensions.
- Make sure that the new certificate is granted the needed extensions to sign other server certificates. A certificate without these extensions can't be used for HTTPS inspection.
Import the new certificate into SWG:
After you receive the signed certificate back from the signing instance, import the certificate and the private key to SWG.
For information about this process, see the Skyhigh Web Gateway Product Guide for your release.

Attachment 1

openssl_intermediate.zip
649Bytes • < 1 minute @ broadband

Attachment 2

openssl_server.zip
707Bytes • < 1 minute @ broadband

Affected Products

Languages:

This article is available in the following languages:

Knowledge Center

Creating a certificate signing request for a custom intermediate certificate authority

Environment

Summary

Solution

Attachment 1

Attachment 2

Affected Products

Languages:

Title

Title

Knowledge Center

Creating a certificate signing request for a custom intermediate certificate authority

Environment

Summary

Solution

Attachment 1

Attachment 2

Affected Products

Languages:

Choose your region

Title

Title