Securing the Network in Oracle^® Solaris 11.3

How to Configure IKEv1 With Self-Signed Public Key Certificates

In this procedure, you create a public/private key and a certificate, called a certificate pair. The private key is stored on disk in the local certificate database and can be referenced by using the ikecert certlocal command. The public key and certificate is stored in the public certificate database. It can be referenced by using the ikecert certdb command. You exchange the public certificate with a peer system. The two certificates are used to authenticate the IKEv1 transmissions.

Self-signed certificates require less overhead than public certificates from a CA, but do not scale very easily. Unlike certificates that are issued by a CA, self-signed certificates must be verified by the two administrators who exchanged the certificates.

Before You Begin

You must become an administrator who is assigned the Network IPsec Management rights profile. For more information, see Using Your Assigned Administrative Rights in Securing Users and Processes in Oracle Solaris 11.3.

If you administer remotely, see Example 31, Configuring IPsec Policy Remotely by Using an ssh Connection and How to Remotely Administer ZFS With Secure Shell in Managing Secure Shell Access in Oracle Solaris 11.3 for secure remote login instructions.

1. On each IKEv1 system, create a self-signed certificate in the ike.privatekeys database.

   For arguments to the ikecert certlocal command, see the ikecert(1M) man page.

   1. For example, the command on the host2 system would appear similar to the following:

      # ikecert certlocal -ks -m 2048 -t rsa-sha512 \
      -D "O=exampleco, OU=IT, C=US, CN=host2" \
      -A IP=192.0.2.213
      Creating private key.
      Certificate added to database.
      -----BEGIN X509 CERTIFICATE-----
      MIIC1TCCAb2gAwIBAgIEfdZgKjANBgkqhkiG9w0BAQUFADAaMRgwFgYDVQQDEw9T
      a...+
      zBGi4QkNdI3f
      -----END X509 CERTIFICATE-----

      where

      –ks

      Creates a self-signed certificate.

      –m keysize

      Specifies the size of the key.

      –t keytype

      Specifies the type of algorithm to use.

      –D dname

      Specifies the X.509 distinguished name (DN) for the certificate subject. For an example, see Using Public Key Certificates in IKE.

      –A altname

      Specifies the alternate name or nickname for the certificate. The altname is in the form of tag=value. Valid tags are IP, DNS, email, and DN.

      ---

      Note -  The values of the –D and –A options are names that identify the certificate only, not any system, such as 192.0.2.213. In fact, because these values are certificate nicknames, you must verify out of band that the correct certificate is installed on the peer systems.

      ---

   2. The command on the host1 system would appear similar to the following:

      # ikecert certlocal -ks -m 2048 -t rsa-sha512 \
      -D "O=exampleco, OU=IT, C=US, CN=host1" \
      -A IP=192.0.2.16
      Creating private key.
      Certificate added to database.
      -----BEGIN X509 CERTIFICATE-----
      MIIC1TCCAb2gAwIBAgIEBl5JnjANBgkqhkiG9w0BAQUFADAaMRgwFgYDVQQDEw9T
      ...
      y85m6LHJYtC6
      -----END X509 CERTIFICATE-----

2. Save the certificate and send it to the remote system.

   The output is an encoded version of the public portion of the certificate. You can safely paste this certificate into an email message. The receiving party must verify out of band that they installed the correct certificate, as shown in Step 4.

   1. For example, you would send the public portion of the host2 certificate to the host1 administrator.

      To: admin@host1.ja.example.com
      From: admin@host2.us.example.com
      Message: -----BEGIN X509 CERTIFICATE-----
      MIIC1TCCAb2gAwIBAgIEfdZgKjANBgkqhkiG9w0BAQUFADAaMRgwFgYDVQQDEw9T
      a...+
      zBGi4QkNdI3f
      -----END X509 CERTIFICATE------

   2. The host1 administrator would send you the public portion of the host1 certificate.

      To: admin@host2.us.example.com
      From: admin@example.ja.example.com
      Message: ----BEGIN X509 CERTIFICATE-----
      MIIC1TCCAb2gAwIBAgIEBl5JnjANBgkqhkiG9w0BAQUFADAaMRgwFgYDVQQDEw9T
      ...
      y85m6LHJYtC6
      -----END X509 CERTIFICATE-----

3. On each system, add the certificate that you received to the public key database.
   1. Save the administrator's email to a file that is read by root.
   2. Redirect the file to the ikecert command.

      # ikecert certdb -a < /tmp/certificate.eml 

      The command imports the text between the BEGIN and END tags.

4. Verify with the other administrator that the certificate is from that administrator.

   For example, you can telephone the other administrator to verify that the hash of their public certificate, which you have, matches the hash of their private certificate, which only they have.

   1. List the stored certificate on host2.

      In the following example, Note 1 indicates the distinguished name (DN) of the certificate in slot 0. The private certificate in slot 0 has the same hash (see Note 3), so these certificates are the same certificate pair. For the public certificates to work, you must have a matching pair. The certdb subcommand lists the public portion, while the certlocal subcommand lists the private portion.

      host2 # ikecert certdb -l
      
      Certificate Slot Name: 0   Key Type: rsa
      	(Private key in certlocal slot 0)
      	Subject Name: <O=exampleco, OU=IT, C=US, CN=host2>Note 1
      	Key Size: 2048
      	Public key hash: 80829EC52FC5BA910F4764076C20FDCF
      
      Certificate Slot Name: 1   Key Type: rsa
      	(Private key in certlocal slot 1)
      	Subject Name: <O=exampleco, OU=IT, C=US, CN=Ada>
      	Key Size: 2048
      	Public key hash: FEA65C5387BBF3B2C8F16C019FEBC388
      host2 # ikecert certlocal -l
      Local ID Slot Name: 0   Key Type: rsa
      	Key Size: 2048
      	Public key hash: 80829EC52FC5BA910F4764076C20FDCFNote 3
      
      Local ID Slot Name: 1   Key Type: rsa-sha512
              Key Size: 2048
              Public key hash: FEA65C5387BBF3B2C8F16C019FEBC388
      
      Local ID Slot Name: 2   Key Type: rsa
      	Key Size: 2048
      	Public key hash: 2239A6A127F88EE0CB40F7C24A65B818

      This check has verified that the host2 system has a valid certificate pair.

   2. Verify that the host1 system has host2's public certificate.

      You can read the public key hash over the telephone.

      Compare the hashes from Note 3 on host2 in the preceding step with Note 4 on host1.

      host1 # ikecert certdb -l
      
      Certificate Slot Name: 0   Key Type: rsa
              (Private key in certlocal slot 0)
              Subject Name: <O=exampleco, OU=IT, C=US, CN=Ada>
              Key Size: 2048
              Public key hash: 2239A6A127F88EE0CB40F7C24A65B818
      
      Certificate Slot Name: 1   Key Type: rsa
              (Private key in certlocal slot 1)
              Subject Name: <O=exampleco, OU=IT, C=US, CN=host1>
              Key Size: 2048
              Public key hash: FEA65C5387BBF3B2C8F16C019FEBC388
      
      Certificate Slot Name: 2   Key Type: rsa
              (Private key in certlocal slot 2)
              Subject Name: <O=exampleco, OU=IT, C=US, CN=host2>
              Key Size: 2048
              Public key hash: 80829EC52FC5BA910F4764076C20FDCFNote 4

      The public key hash and subject name of the last certificate stored in host1's public certificate database match the private certificate for host2 from the preceding step.

5. On each system, trust both certificates.

   Edit the /etc/inet/ike/config file to recognize the certificates.

   The administrator of the remote system provides the values for the cert_trust, remote_addr, and remote_id parameters.

   1. For example, on the host2 system, the ike/config file would appear similar to the following:

      # Explicitly trust the self-signed certs
      # that we verified out of band. The local certificate
      # is implicitly trusted because we have access to the private key.
      
      cert_trust "O=exampleco, OU=IT, C=US, CN=host1"
      # We could also use the Alternate name of the certificate,
      # if it was created with one.  In this example, the Alternate Name
      # is in the format of an IP address:
      # cert_trust "192.0.2.16"
      
      ## Parameters that may also show up in rules.
      
      p1_xform 
        { auth_method preshared oakley_group 14 auth_alg sha256 encr_alg 3des }
      p2_pfs 14
      
      {
       label "US-host2 to JA-host1;"
       local_id_type dn
       local_id "O=exampleco, OU=IT, C=US, CN=host2"
       remote_id "O=exampleco, OU=IT, C=US, CN=host1"
       local_addr  192.0.2.213 
      # We could explicitly enter the peer's IP address here, but we don't need
      # to do this with certificates, so use a wildcard address. The wildcard
      # allows the remote device to be mobile or behind a NAT box
       remote_addr 0.0.0.0/0
      
      
       p1_xform
        {auth_method rsa_sig oakley_group 2 auth_alg sha256 encr_alg aes}
      }

   2. On the host1 system, add host1 values for local parameters in the ike/config file.

      For the remote parameters, use host2 values. Ensure that the value for the label keyword is unique on the local system.

      ...
      {
       label "JA-host1 to US-host2"
       local_id_type dn
       local_id "O=exampleco, OU=IT, C=US, CN=host1"
       remote_id "O=exampleco, OU=IT, C=US, CN=host2"
      
       local_addr  192.0.2.16
       remote_addr 0.0.0.0/0
      
       p1_xform
        {auth_method rsa_sig oakley_group 2 auth_alg sha256 encr_alg aes}
      }

6. On the peer systems, enable IKEv1.

   host2 # svcadm enable ipsec/ike:default
   host1 # svcadm enable ipsec/ike

Next Steps

If you have not completed establishing IPsec policy, return to the IPsec procedure to enable or refresh IPsec policy. For examples of IPsec policy protecting VPNs, see Protecting a VPN With IPsec. For other examples of IPsec policy, see How to Secure Network Traffic Between Two Servers With IPsec.