System Administration Guide: IP Services

How to Handle a Certificate Revocation List

A certificate revocation list (CRL) contains outdated or compromised certificates from a Certificate Authority. You have four ways to handle CRLs.

You must instruct IKE to ignore CRLs if your CA organization does not issue CRLs. This option is shown in Step 6 in How to Configure IKE With Certificates Signed by a CA.
You can instruct IKE to access the CRLs from a URI (uniform resource indicator) whose address is embedded in the public key certificate from the CA.
You can instruct IKE to access the CRLs from an LDAP server whose DN (directory name) entry is embedded in the public key certificate from the CA.
You can provide the CRL as an argument to the ikecert certrldb command. For an example, see Example 23-4.

The following procedure describes how to instruct IKE to use CRLs from a central distribution point.

Display the certificate that you received from the CA.

# ikecert certdb -lv certspec

`-l`	Lists certificates in the IKE certificate database.
`-v`	Lists the certificates in verbose mode. Use this option with care.
certspec	Is a pattern that matches a certificate in the IKE certificate database.

For example, the following certificate was issued by Sun Microsystems. Details have been altered.

# ikecert certdb -lv example-protect.sun.com
Certificate Slot Name: 0   Type: dsa-sha1
   (Private key in certlocal slot 0)
 Subject Name: <O=Sun Microsystems Inc, CN=example-protect.sun.com>
 Issuer Name: <CN=Sun Microsystems Inc CA (Cl B), O=Sun Microsystems Inc>
 SerialNumber: 14000D93
   Validity:
      Not Valid Before: 2002 Jul 19th, 21:11:11 GMT
      Not Valid After:  2005 Jul 18th, 21:11:11 GMT
   Public Key Info:
      Public Modulus  (n) (2048 bits): C575A...A5
      Public Exponent (e) (  24 bits): 010001
   Extensions:
      Subject Alternative Names:
              DNS = example-protect.sun.com
      Key Usage: DigitalSignature KeyEncipherment
      [CRITICAL]
   CRL Distribution Points:
      Full Name:
         URI = #Ihttp://www.sun.com/pki/pkismica.crl#i
         DN = <CN=Sun Microsystems Inc CA (Cl B), O=Sun Microsystems Inc>
      CRL Issuer: 
      Authority Key ID:
      Key ID:              4F ... 6B
      SubjectKeyID:        A5 ... FD
      Certificate Policies
      Authority Information Access

Notice the CRL Distribution Points entry. The URI entry indicates that this organization's CRL is available on the web. The DN entry indicates that the CRL is available on an LDAP server. Once accessed by IKE, the CRL is cached for further use.

To access the CRL, you need to reach a distribution point.

Choose one of the following methods to access the CRL from a central distribution point.
- Use the URI.
  Add the keyword use_http to the host's /etc/inet/ike/config file. For example, the ike/config file would appear similar to the following:
  # Use CRL from organization's URI use_http ...
- Use a web proxy.
  Add the keyword proxy to the ike/config file. The proxy keyword takes a URL as an argument, as in the following:
  # Use own web proxy proxy "http://proxy1:8080"
- Use an LDAP server.
  Name the LDAP server as an argument to the ldap-list keyword in the host's /etc/inet/ike/config file. Your organization provides the name of the LDAP server. The entry in the ike/config file would appear similar to the following:
  # Use CRL from organization's LDAP ldap-list "ldap1.sun.com:389,ldap2.sun.com" ...
IKE retrieves the CRL and caches the CRL until the certificate expires.

Example 23-4 Pasting a CRL Into the Local `certrldb` Database

If the PKI organization's CRL is not available from a central distribution point, you can add the CRL manually to the local certrldb database. Follow the PKI organization's instructions for extracting the CRL into a file, then add the CRL to the database with the ikecert certrldb -a command.

# ikecert certrldb -a < Sun.Cert.CRL

Configuring IKE for Mobile Systems (Task Map)

The following table points to procedures to configure IKE to handle systems that log in remotely to a central site.

Task	Description	For Instructions
Communicate with a central site from off-site	Enables off-site systems to communicate with a central site. The off-site systems might be mobile.	How to Configure IKE for Off-Site Systems
Use a root certificate and IKE on a central system that accepts traffic from mobile systems	Configures a gateway system to accept IPsec traffic from a system that does not have a fixed IP address.	Example 23-5
Use a root certificate and IKE on a system that does not have a fixed IP address	Configures a mobile system to protect its traffic to a central site, such as company headquarters.	Example 23-6
Use self-signed certificates and IKE on a central system that accepts traffic from mobile systems	Configures a gateway system with self-signed certificates to accept IPsec traffic from a mobile system.	Example 23-7
Use self-signed certificates and IKE on a system that does not have a fixed IP address	Configures a mobile system with self-signed certificates to protect its traffic to a central site.	Example 23-8

Configuring IKE for Mobile Systems

When configured properly, home offices and mobile laptops can use IPsec and IKE to communicate with their company's central computers. A blanket IPsec policy that is combined with a public key authentication method enables off-site systems to protect their traffic to a central system.

How to Configure IKE for Off-Site Systems

IPsec and IKE require a unique ID to identify source and destination. For off-site or mobile systems that do not have a unique IP address, you must use another ID type. ID types such as DNS, DN, or email can be used to uniquely identify a system.

Off-site or mobile systems that have unique IP addresses are still best configured with a different ID type. For example, if the systems attempt to connect to a central site from behind a NAT box, their unique addresses are not used. A NAT box assigns an arbitrary IP address, which the central system would not recognize.

Preshared keys also do not work well as an authentication mechanism for mobile systems, because preshared keys require fixed IP addresses. Self-signed certificates, or certificates from a PKI enable mobile systems to communicate with the central site.

On the system console of the central system, assume the Primary Administrator role or become superuser.
The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, "Working With the Solaris Management Console (Tasks)," in System Administration Guide: Basic Administration.

Note - Logging in remotely exposes security-critical traffic to eavesdropping. Even if you somehow protect the remote login, the security of the system is reduced to the security of the remote login session.

Configure the central system to recognize mobile systems.

Set up the /etc/hosts file.
The central system does not have to recognize specific addresses for the mobile systems.
# /etc/hosts on central central 192.xxx.xxx.x
Set up the ipsecinit.conf file.
The central system needs a policy that allows a wide range of IP addresses. Later, certificates in the IKE policy ensure that the connecting systems are legitimate.
# /etc/inet/ipsecinit.conf on central # Keep everyone out unless they use this IPsec policy: {} ipsec {encr_algs aes encr_auth_algs md5 sa shared}

Set up the ike.config file.

DNS identifies the central system. Certificates are used to authenticate the system.

## /etc/inet/ike/ike.config on central
# Global parameters
#
# Find CRLs by URI, URL, or LDAP
# Use CRL from organization's URI
use_http
#
# Use web proxy
proxy "http://somecache.domain:port/"
#
# Use LDAP server
ldap_server   "ldap-server1.domain.org,ldap2.domain.org:port"
#
# List CA-signed certificates
cert_root    "C=US, O=Domain Org, CN=Domain STATE"
#
# List self-signed certificates - trust server and enumerated others
#cert_trust    "DNS=central.domain.org"
#cert_trust    "DNS=mobile.domain.org"
#cert_trust    "DN=CN=Domain Org STATE (CLASS), O=Domain Org
#cert_trust    "email=root@central.domain.org"
#cert_trust    "email=[email protected]"
#

# Rule for mobile systems with certificate
{
  label "Mobile systems with certificate"
  local_id_type DNS

# Any mobile system who knows my DNS or IP can find me.

  local_id "central.domain.org"
  local_addr 192.xxx.xxx.x

# Root certificate ensures trust,
# so allow any remote_id and any remote IP address.
  remote_id ""
  remote_addr 0.0.0.0/0

p2_pfs 5

p1_xform
{auth_method rsa_sig oakley_group 5 encr_alg blowfish auth_alg md5 }
}

Log in to each mobile system, and configure the system to find the central system.

Set up the /etc/hosts file.
The /etc/hosts file does not need an address for the mobile system, but can provide one. The file must contain a public IP address for the central system.
# /etc/hosts on mobile mobile 10.x.x.xx central 192.xxx.xxx.x
Set up the ipsecinit.conf file.
The mobile system needs to find the central system by its public IP address. The systems must configure the same IPsec policy.
# /etc/inet/ipsecinit.conf on mobile # Find central {raddr 192.xxx.xxx.x} ipsec {encr_algs aes encr_auth_algs md5 sa shared}

Set up the ike.config file.

The identifier cannot be an IP address. The following identifiers are valid for mobile systems:

DN=ldap-directory-name
DNS=domain-name-server-address
email=email-address

Certificates are used to authenticate the mobile system.

## /etc/inet/ike/ike.config on mobile
# Global parameters
#
# Find CRLs by URI, URL, or LDAP
# Use CRL from organization's URI
use_http
#
# Use web proxy
proxy "http://somecache.domain:port/"
#
# Use LDAP server
ldap_server   "ldap-server1.domain.org,ldap2.domain.org:port"
#
# List CA-signed certificates
cert_root    "C=US, O=Domain Org, CN=Domain STATE"
#
# Self-signed certificates - trust me and enumerated others
#cert_trust    "DNS=mobile.domain.org"
#cert_trust    "DNS=central.domain.org"
#cert_trust    "DN=CN=Domain Org STATE (CLASS), O=Domain Org
#cert_trust    "email=[email protected]"
#cert_trust    "email=root@central.domain.org"
#
# Rule for off-site systems with root certificate
{
	label "Off-site mobile with certificate"
	local_id_type DNS

# NAT-T can translate local_addr into any public IP address
# central knows me by my DNS

	local_id "mobile.domain.org"
	local_addr 0.0.0.0/0

# Find central and trust the root certificate
	remote_id "central.domain.org"
	remote_addr 192.xxx.xxx.x

p2_pfs 5

p1_xform
{auth_method rsa_sig oakley_group 5 encr_alg blowfish auth_alg md5 }
}

Reboot each system when it is configured.
Or, stop and start the in.iked daemon.

Example 23-5 Configuring a Central Computer to Accept IPsec Traffic From a Mobile System

IKE can initiate negotiations from behind a NAT box. However, the ideal setup for IKE is without an intervening NAT box. In the following example, root certificates have been issued by a CA. The CA certificates have been placed on the mobile system and the central system. A central system accepts IPsec negotiations from a system behind a NAT box. main1 is the company system that can accept connections from off-site systems. To set up the off-site systems, see Example 23-6.

## /etc/hosts on main1
main1 192.168.0.100

## /etc/inet/ipsecinit.conf on main1
# Keep everyone out unless they use this IPsec policy:
{} ipsec {encr_algs aes encr_auth_algs md5 sa shared}

## /etc/inet/ike/ike.config on main1
# Global parameters
#
# Find CRLs by URI, URL, or LDAP
# Use CRL from organization's URI
use_http
#
# Use web proxy
proxy "http://cache1.domain.org:8080/"
#
# Use LDAP server
ldap_server   "ldap1.domain.org,ldap2.domain.org:389"
#
# List CA-signed certificate
cert_root "C=US, O=ExamplePKI Inc, OU=PKI-Example, CN=Example PKI"
#
# Rule for off-site systems with root certificate
{
  label "Off-site system with root certificate"
  local_id_type DNS
  local_id "main1.domain.org"
  local_addr 192.168.0.100

# Root certificate ensures trust,
# so allow any remote_id and any remote IP address.
  remote_id ""
  remote_addr 0.0.0.0/0

p2_pfs 5

p1_xform
{auth_method rsa_sig oakley_group 5 encr_alg blowfish auth_alg md5}
p1_xform
{auth_method rsa_sig oakley_group 5 encr_alg 3des auth_alg md5}
p1_xform
{auth_method rsa_sig oakley_group 5 encr_alg blowfish auth_alg sha}
p1_xform
{auth_method rsa_sig oakley_group 5 encr_alg 3des auth_alg sha}
}

Example 23-6 Configuring a System Behind a NAT With IPsec

In the following example, root certificates have been issued by a CA and placed on the mobile system and the central system. mobile1 is connecting to the company headquarters from home. The Internet service provider (ISP) network uses a NAT box to enable the ISP to assign mobile1 a private address. The NAT box then translates the private address into a public IP address that is shared with other ISP network nodes. Company headquarters is not behind a NAT. For setting up the computer at company headquarters, see Example 23-5.

## /etc/hosts on mobile1
mobile1 10.1.3.3
main1 192.168.0.100

## /etc/inet/ipsecinit.conf on mobile1
# Find main1
{raddr 192.168.0.100} ipsec {encr_algs aes encr_auth_algs md5 sa shared}

## /etc/inet/ike/ike.config on mobile1
# Global parameters
#
# Find CRLs by URI, URL, or LDAP
# Use CRL from organization's URI
use_http
#
# Use web proxy
proxy "http://cache1.domain.org:8080/"
#
# Use LDAP server
ldap_server   "ldap1.domain.org,ldap2.domain.org:389"
#
# List CA-signed certificate
cert_root "C=US, O=ExamplePKI Inc, OU=PKI-Example, CN=Example PKI"
#
# Rule for off-site systems with root certificate
{
  label "Off-site mobile1 with root certificate"
  local_id_type DNS
  local_id "mobile1.domain.org"
  local_addr 0.0.0.0/0

# Find main1 and trust the root certificate
  remote_id "main1.domain.org"
  remote_addr 192.168.0.100

p2_pfs 5

p1_xform
{auth_method rsa_sig oakley_group 5 encr_alg blowfish auth_alg md5 }
}

Example 23-7 Accepting Self-Signed Certificates From a Mobile System

In the following example, self-signed certificates have been issued and are on the mobile and the central system. main1 is the company system that can accept connections from off-site systems. To set up the off-site systems, see Example 23-8.

## /etc/hosts on main1
main1 192.168.0.100

## /etc/inet/ipsecinit.conf on main1
# Keep everyone out unless they use this IPsec policy:
{} ipsec {encr_algs aes encr_auth_algs md5 sa shared}

## /etc/inet/ike/ike.config on main1
# Global parameters
#
# Self-signed certificates - trust me and enumerated others
cert_trust    "DNS=main1.domain.org"
cert_trust    "[email protected]"
cert_trust    "[email protected]"
cert_trust    "[email protected]"
#
# Rule for off-site systems with trusted certificate
{
  label "Off-site systems with trusted certificates"
  local_id_type DNS
  local_id "main1.domain.org"
  local_addr 192.168.0.100

# Trust the self-signed certificates
# so allow any remote_id and any remote IP address.
  remote_id ""
  remote_addr 0.0.0.0/0

p2_pfs 5

p1_xform
{auth_method rsa_sig oakley_group 5 encr_alg blowfish auth_alg md5 }
}

Example 23-8 Using Self-Signed Certificates to Contact a Central System

In the following example, mobile1 is connecting to the company headquarters from home. The certificates have been issued and placed on the mobile and the central system. The ISP network uses a NAT box to enable the ISP to assign mobile1 a private address. The NAT box then translates the private address into a public IP address that is shared with other ISP network nodes. Company headquarters is not behind a NAT. To set up the computer at company headquarters, see Example 23-7.

## /etc/hosts on mobile1
mobile1 10.1.3.3
main1 192.168.0.100

## /etc/inet/ipsecinit.conf on mobile1
# Find main1
{raddr 192.168.0.100} ipsec {encr_algs aes encr_auth_algs md5 sa shared}

## /etc/inet/ike/ike.config on mobile1
# Global parameters

# Self-signed certificates - trust me and the central system
cert_trust    "[email protected]"
cert_trust    "DNS=main1.domain.org"
#
# Rule for off-site systems with trusted certificate
{
  label "Off-site mobile1 with trusted certificate"
  local_id_type email
  local_id "[email protected]"
  local_addr 0.0.0.0/0

# Find main1 and trust the certificate
  remote_id "main1.domain.org"
  remote_addr 192.168.0.100

p2_pfs 5

p1_xform
{auth_method rsa_sig oakley_group 5 encr_alg blowfish auth_alg md5 }
}