Server Certificates

For secure SSL connection, gateways must establish trust with endpoint computers by showing a Server Certificate. This section discusses the procedures necessary to generate and install server certificates.

Check Point gateways, by default, use a certificate created by the Internal Certificate Authority on the Security Management ServerClosed Dedicated Check Point server that runs Check Point software to manage the objects and policies in a Check Point environment within a single management Domain. Synonym: Single-Domain Security Management Server. as their server certificate. Browsers do not trust this certificate. When an endpoint computer tries to connect to the gateway with the default certificate, certificate warning messages open in the browser. To prevent these warnings, the administrator must install a server certificate signed by a trusted certificate authority.

All portals on the same Security GatewayClosed Dedicated Check Point server that runs Check Point software to inspect traffic and enforce Security Policies for connected network resources. IP address use the same certificate.

Obtaining and Installing a Trusted Server Certificate

To be accepted by an endpoint computer without a warning, gateways must have a server certificate signed by a known certificate authority (such as Entrust, VeriSign or Thawte). This certificate can be issued directly to the gateway, or be a chained certificate that has a certification path to a trusted root certificate authority (CA).

Follow the next procedures to get a certificate for a gateway that is signed by a known Certificate Authority (CA).

First, generate a Certificate Signing Request (CSR). The CSR is for a server certificate, because the gateway works as a server to the clients.

Note - This procedure creates private key files. If private key files with the same names already exist on the computer, they are overwritten without warning.

  1. From the gateway command line, log in to the Expert mode.

  2. Run:

    cpopenssl req -new -out <CSR file> -keyout <private key file> -config $CPDIR/conf/openssl.cnf

    This command generates a private key. This output comes into view:

    Generating a 2048 bit RSA private key
    .+++
    ...+++
    writing new private key to 'server1.key'
    Enter PEM pass phrase:

  3. Enter a password and confirm.

    Fill in the data.

    • The Common Name field is mandatory. This field must have the Fully Qualified Domain Name (FQDN). This is the site that users access. For example: portal.example.com.

    • All other fields are optional.

  4. Send the CSR file to a trusted certificate authority. Make sure to request a Signed Certificate in PEM format. Keep the .key private key file.

After you get the Signed Certificate for the gateway from the CA, generate a P12 file that has the Signed Certificate and the private key.

  1. Get the Signed Certificate for the gateway from the CA.

    If the signed certificate is in P12 or P7B format, convert these files to a PEM (Base64 encoded) formatted file with a CRT extension.

  2. Make sure that the CRT file has the full certificate chain up to a trusted root CA.

    Usually you get the certificate chain from the signing CA. Sometimes it split into separate files. If the signed certificate and the trust chain are in separate files, use a text editor to combine them into one file. Make sure the server certificate is at the top of the CRT file.

  3. From the gateway command line, log in to the Expert mode.

  4. Use the *.crt file to install the certificate with the *.key file that you generated.

    1. Run:

      cpopenssl pkcs12 -export -out <output file> -in <signed cert chain file> -inkey <private key file>

      For example:

      cpopenssl pkcs12 -export -out server1.p12 -in server1.crt -inkey server1.key

    2. Enter the certificate password when prompted.

  1. Log in to SmartConsoleClosed Check Point GUI application used to manage a Check Point environment - configure Security Policies, configure devices, monitor products and events, install updates, and so on..

  2. From the left Navigation Toolbar, click Gateways & Servers.

  3. Open the Identity AwarenessClosed Check Point Software Blade on a Security Gateway that enforces network access and audits data based on network location, the identity of the user, and the identity of the computer. Acronym: IDA. Gateway object.

  4. In the navigation tree, click the applicable Software BladeClosed Specific security solution (module): (1) On a Security Gateway, each Software Blade inspects specific characteristics of the traffic (2) On a Management Server, each Software Blade enables different management capabilities. page:

    • Mobile Access > Portal Settings

    • Platform Portal

    • Data Loss Prevention

    • Identity Awareness > Captive Portal > Settings > Access Settings

    In the Certificate section, click Import or Replace.

  5. Install the Access Control Policy on the gateway.

    Note - The Repository of Certificates on the IPsec VPNClosed Check Point Software Blade on a Security Gateway that provides a Site to Site VPN and Remote Access VPN access. page of the gateway object is only for self-signed certificates. It does not affect the certificate installed manually using this procedure.

Viewing the Certificate

To see the new certificate from a Web browser:

The Security Gateway uses the certificate when you connect with a browser to the portal. To see the certificate when you connect to the portal, click the lock icon that is next to the address bar in most browsers.

The certificate that users see depends on the actual IP address that they use to get an access to the portal - not only the IP address configured for the portal in SmartConsole.

To see the new certificate from SmartConsole:

From a page that contains the portal settings for that blade/feature, click View in the Certificate section.