Server Certificates

For secure SSL communication, 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 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 Gateway IP address use the same certificate.

Included Topics Obtaining and Installing a Trusted Server Certificate Viewing the 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).

The next sections describe how to get a certificate for a gateway that is signed by a known Certificate Authority (CA).

Generating the Certificate Signing Request

First, generate a Certificate Signing Request (CSR). The CSR is for a server certificate, because the gateway acts 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 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. You see this output:

   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.

Generating the P12 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 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.

Installing the Signed Certificate

Install the Third Party signed certificate to create Trust between the Mobile Access Software Blade and the clients.

All portals on the same IP address use the same certificate. Define the IP address of the portal in the Portal Settings page for the blade/feature.

1. Import the new certificate to the gateway in SmartDashboard from a page that contains the Portal Settings for that blade/feature. For example:
   • Gateway Properties > Mobile Access > Portal Settings
   • Gateway Properties > Platform Portal
   • Gateway Properties > Data Loss Prevention
   • Gateway Properties > Identity Awareness > Browser-Based Authentication > Settings > Access Settings

   In the Certificate section, click Import or Replace.

2. Install the policy on the gateway.

Note - The Repository of Certificates on the IPsec VPN page of the SmartDashboard 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 access the portal - not only the IP address configured for the portal in SmartDashboard.

To see the new certificate from SmartDashboard:

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

Transparent Kerberos Authentication Configuration

The Transparent Kerberos Authentication Single-Sign On (SSO) solution transparently authenticates users already logged into AD. This means that a user authenticates to the domain one time and has access to all authorized network resources without having to enter credentials again. If Transparent Kerberos Authentication fails, the user is redirected to the Captive Portal for manual authentication.

Note -The Endpoint Identity Agent download link and the Automatic Logout option are ignored when Transparent Kerberos Authentication SSO is successful. The user does not see the Captive Portal.

SSO in Windows domains works with the Kerberos authentication protocol.

The Kerberos protocol is based on the concept of tickets, encrypted data packets issued by a trusted authority, Active Directory (AD). When a user logs in, the user authenticates to a domain controller that gives an initial ticket granting ticket (TGT). This ticket vouches for the user's identity.

In this solution, when an unidentified user is about to be redirected to the Captive Portal for identification:

1. Captive Portal asks the browser for authentication.
2. The browser shows a Kerberos ticket to the Captive Portal.
3. Captive Portal sends the ticket to the gateway (the Security Gateway enabled with Identity Awareness).
4. The gateway decrypts the ticket, extracts the user's identity, and publishes it to all Security Gateways with Identity Awareness.
5. The authorized and identified user is redirected to the originally requested URL.
6. If transparent automatic authentication fails (steps 2-5), the user is redirected to the Captive Portal for identification.

Transparent Kerberos Authentication uses the GSS-API Negotiation Mechanism (SPNEGO) internet standard to negotiate Kerberos. This mechanism works like the mechanism that Endpoint Identity Agents use to present the Kerberos ticket.

You can configure SSO Transparent Kerberos Authentication to work with HTTP and/or HTTPS connections. HTTP connections work transparently with SSO Transparent Kerberos Authentication at all times. HTTPS connections work transparently only if the Security Gateway has a signed .p12 certificate. If the Security Gateway does not have a certificate, the user sees, and must respond to, the certificate warning message before a connection is made.

For more about Kerberos SSO, we recommend the MIT Kerberos web site and the Microsoft TechNet Library.

Configuration Overview

Transparent Kerberos Authentication SSO configuration includes these steps. They are described in details in this section.

• AD configuration - Creating a user account and mapping it to a Kerberos principal name
  • For HTTP connections: (HTTP/<captive portal full dns name>@DOMAIN)
  • For HTTPS connections: (HTTPS/<captive portal full dns name>@DOMAIN)
• SmartDashboard configuration
  • Creating an LDAP Account Unit and configuring it with SSO.
  • Enabling Transparent Kerberos Authentication on the Security Gateway configured with Identity Awareness.
• Endpoint client configuration - Configuring trusted sites in the browsers.

Where applicable, the procedures give instructions for both HTTP and HTTPS configuration.

Creating a New User Account

1. In Active Directory, open Active Directory Users and Computers (Start->Run->dsa.msc)
2. Add a new user account.

   You can choose any username and password. For example: a user account named ckpsso with the password qwe123!@# to the domain corp.acme.com.

3. Clear User must change password at next logon and select Password Never Expires.

Mapping the User Account to a Kerberos Principal Name

Run the setspn utility to create a Kerberos principal name, used by the Security Gateway and the AD. A Kerberos principal name contains a service name (for the Security Gateway that browsers connect to) and the domain name (to which the service belongs).

setspn is a command line utility that is available for Windows Server 2000 and higher.

Installing setspn.exe

Install the correct setspn.exe version on the AD server. The setspn.exe utility is not installed by default in Windows 2003.

To get the correct executable:

On Windows 2003:

1. Get the correct executable for your service pack from the Microsoft Support site before installation. It is part of the Windows 2003 support tools. For example, AD 2003 SP2 requires support tools for 2003 SP2.
2. Download the support.cab and suptools.msi files to a new folder on your AD server.
3. Run the suptools.msi.

If you use Active Directory with Windows Server 2008 and higher, the setspn utility is installed on your server in the Windows\System32 folder. Run the command prompt as an Administrator.

Using setspn

Important - If you used the setspn utility before, with the same principal name, but with a different account, you must delete the different account or remove the association to the principal name.
To remove the association, run:
setspn -D HTTP/<captive_portal_full_dns_name> <old_account name>

If you do not do this, authentication will fail.

To use setspn:

1. Open the command line (Start > Run > cmd).
2. Run setspn with this syntax:

   For HTTP connections:

   > setspn -A HTTP/<captive_portal_full_dns_name> <username>

   For HTTPS connections:

   > setspn -A HTTPS/<captive_portal_full_dns_name> <username>

   Important - Make sure that you enter the command exactly as shown. All parameters are case sensitive.

   Example:

   > setspn -A HTTP/mycaptive.corp.acme.com ckpsso

   The AD is ready to support Kerberos authentication for the Security Gateway.

To see users associated with the principle name, run: setspn -Q HTTP*/*

Configuring an Account Unit

If you already have an account unit from the Identity Awareness First Time Configuration Wizard, use that unit. Do not do the first steps. Start with: "Click Active Directory SSO configuration and configure the values".

To configure an account unit:

1. Add a new host to represent the AD domain controller: Network Objects tab > Nodes > Node > Host.
2. Enter a name and IP address for the AD object.
3. Click OK.
4. Add a new LDAP Account Unit: In Objects tree > Servers and OPSEC Applications, right-click Servers > New > LDAP Account Unit.
5. In the General tab of the LDAP Account Unit:
   1. Enter a name.
   2. In Profile, select Microsoft_AD.
   3. In Domain, enter the domain name.

      We recommend that you enter the domain for existing account units to use for Identity Awareness. If you enter a domain, it does not affect existing LDAP Account Units.

   4. Select CRL retrieval and User management.
6. Click Active Directory SSO configuration and configure the values:
   1. Select Use Kerberos Single Sign On.
   2. Enter the domain name.
   3. Enter the account username you created in Creating a New User Account.
   4. Enter the account password for that user (the same password you configured for the account username in AD) and confirm it.
   5. Leave the default settings for Ticket encryption method.
   6. Click OK.
7. In the Servers tab:
   1. Click Add and enter the LDAP Server properties.
   2. In Host, select the AD object you configured.
   3. In Login DN, enter the login DN of a predefined user (added in the AD) used for LDAP operations.
   4. Enter the LDAP user password and confirm it.
   5. In the Check Point Gateways are allowed to section, select Read data from this server.
   6. In the Encryption tab, select Use Encryption (SSL). Fetch the fingerprint and click OK.

      Note - LDAP over SSL is not supported by default. If you did not configure your domain controller to support LDAP over SSL, configure it, or make sure Use Encryption (SSL) is not selected.

8. In the Objects Management tab:
   1. In Manage objects on, select the AD object you configured.
   2. Click Fetch Branches to configure the branches in use.
   3. Set the number of entries supported.
9. In the Authentication tab, select Default authentication scheme > Check Point Password.
10. Click OK.

Enabling Transparent Kerberos Authentication

1. Log in to SmartDashboard.
2. From the Network Objects tree, expand the Check Point object.
3. Double-click the gateway enabled with Identity Awareness.
4. Select Browser-Based Authentication - Settings.

   The Portal Settings window opens.

5. Select Authentication Settings - Edit.

   The Authentication Settings window opens.

6. Select Automatically authenticate users from machines in the domain.
   • Main URL: The URL used to begin the SSO process. If transparent authentication fails, users are redirected to the configured Captive Portal.
   • IP Address: The IP address to which the Portal URL is resolved if DNS resolution fails.

Browser Configuration

To work with Transparent Kerberos Authentication, it is necessary to configure your browser to trust Captive Portal URL. If the portal is working with HTTPS, you must also enter the URL in the Local Internet field using HTTPS.

Internet Explorer

It is not necessary to add the Captive Portal URL to Trusted Sites.

To configure Internet Explorer for Transparent Kerberos Authentication:

1. Open Internet Explorer.
2. Go to Internet Tools > Options > Security > Local intranet > Sites > Advanced.
3. Enter the Captive Portal URL in the applicable and then click Add.

Google Chrome

If you have already configured Internet Explorer for Transparent Kerberos Authentication, that configuration also works with Chrome. Use this procedure only if you did not configure Internet Explorer for Transparent Kerberos Authentication.

To configure Google Chrome for Transparent Kerberos Authentication:

1. Open Chrome.
2. Click the menu (wrench) icon and select Settings.
3. Click Show advanced settings.
4. In the Network section, click Change Proxy Settings.
5. In the Internet Properties window, go to Security > Local intranet > Sites > Advanced.
6. Enter the Captive Portal URL in the applicable field.

Firefox

For Firefox, the Negotiate authentication option is disabled by default. To use Transparent Kerberos Authentication, you must enable this option.

To configure Firefox for Transparent Kerberos Authentication:

1. Open Firefox.
2. In the URL bar, enter about:config
3. Search for the network.negotiate-auth.trusted-uris parameter.
4. Set the value to the DNS name of the Captive Portal Security Gateway. You can enter multiple URLs by separating them with a comma.