JavaScript is required to for searching.
Skip Navigation Links
Exit Print View
System Administration Guide: IP Services     Oracle Solaris 10 8/11 Information Library
search filter icon
search icon

Document Information

Preface

Part I Introducing System Administration: IP Services

1.  Oracle Solaris TCP/IP Protocol Suite (Overview)

Part II TCP/IP Administration

2.  Planning Your TCP/IP Network (Tasks)

3.  Introducing IPv6 (Overview)

4.  Planning an IPv6 Network (Tasks)

5.  Configuring TCP/IP Network Services and IPv4 Addressing (Tasks)

6.  Administering Network Interfaces (Tasks)

7.  Configuring an IPv6 Network (Tasks)

8.  Administering a TCP/IP Network (Tasks)

9.  Troubleshooting Network Problems (Tasks)

10.  TCP/IP and IPv4 in Depth (Reference)

11.  IPv6 in Depth (Reference)

Part III DHCP

12.  About DHCP (Overview)

13.  Planning for DHCP Service (Tasks)

14.  Configuring the DHCP Service (Tasks)

15.  Administering DHCP (Tasks)

16.  Configuring and Administering the DHCP Client

17.  Troubleshooting DHCP (Reference)

18.  DHCP Commands and Files (Reference)

Part IV IP Security

19.  IP Security Architecture (Overview)

20.  Configuring IPsec (Tasks)

21.  IP Security Architecture (Reference)

22.  Internet Key Exchange (Overview)

23.  Configuring IKE (Tasks)

Configuring IKE (Task Map)

Configuring IKE With Preshared Keys (Task Map)

Configuring IKE With Preshared Keys

How to Configure IKE With Preshared Keys

How to Refresh IKE Preshared Keys

How to View IKE Preshared Keys

How to Add an IKE Preshared Key for a New Policy Entry in ipsecinit.conf

How to Verify That IKE Preshared Keys Are Identical

Configuring IKE With Public Key Certificates (Task Map)

Configuring IKE With Public Key Certificates

How to Configure IKE With Self-Signed Public Key Certificates

How to Configure IKE With Certificates Signed by a CA

How to Generate and Store Public Key Certificates on Hardware

How to Handle a Certificate Revocation List

Configuring IKE for Mobile Systems (Task Map)

Configuring IKE for Mobile Systems

How to Configure IKE for Off-Site Systems

Configuring IKE to Find Attached Hardware (Task Map)

Configuring IKE to Find Attached Hardware

How to Configure IKE to Find the Sun Crypto Accelerator 1000 Board

How to Configure IKE to Find the Sun Crypto Accelerator 4000 Board

Changing IKE Transmission Parameters (Task Map)

Changing IKE Transmission Parameters

How to Change the Duration of Phase 1 IKE Key Negotiation

24.  Internet Key Exchange (Reference)

25.  IP Filter in Oracle Solaris (Overview)

26.  IP Filter (Tasks)

Part V Mobile IP

27.  Mobile IP (Overview)

28.  Administering Mobile IP (Tasks)

29.  Mobile IP Files and Commands (Reference)

Part VI IPMP

30.  Introducing IPMP (Overview)

31.  Administering IPMP (Tasks)

Part VII IP Quality of Service (IPQoS)

32.  Introducing IPQoS (Overview)

33.  Planning for an IPQoS-Enabled Network (Tasks)

34.  Creating the IPQoS Configuration File (Tasks)

35.  Starting and Maintaining IPQoS (Tasks)

36.  Using Flow Accounting and Statistics Gathering (Tasks)

37.  IPQoS in Detail (Reference)

Glossary

Index

Configuring IKE With Public Key Certificates

Public key certificates eliminate the need for communicating systems to share secret keying material out of band. Unlike preshared keys, a public key certificate can be used on a mobile machine or on a system that might be renumbered.

Public key certificates can also be stored on attached hardware. For the procedure, see Configuring IKE to Find Attached Hardware (Task Map).

How to Configure IKE With Self-Signed Public Key Certificates

Self-signed certificates require less overhead than public certificates from a CA, but do not scale very easily.

  1. On the system console, 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. Use the ssh command for secure remote login.


  2. Add a self-signed certificate to the ike.privatekeys database.
    # ikecert certlocal -ks|-kc -m keysize -t keytype \
    -D dname -A altname \
    [-S validity-start-time] [-F validity-end-time] [-T token-ID]
    -ks

    Creates a self-signed certificate.

    -kc

    Creates a certificate request. For the procedure, see How to Configure IKE With Certificates Signed by a CA.

    -m keysize

    Is the size of the key. The keysize can be 512, 1024, 2048, 3072, or 4096.

    -t keytype

    Specifies the type of algorithm to use. The keytype can be rsa-sha1, rsa-md5, or dsa-sha1.

    -D dname

    Is the X.509 distinguished name for the certificate subject. The dname typically has the form: C=country, O=organization, OU=organizational unit, CN=common name. Valid tags are C, O, OU, and CN.

    -A altname

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

    -S validity-start-time

    Provides an absolute or relative valid start time for the certificate.

    -F validity-end-time

    Provides an absolute or relative valid end time for the certificate.

    -T token-ID

    Enables a PKCS #11 hardware token to generate the keys. The certificates are then stored in the hardware.

    1. For example, the command on the partym system would appear similar to the following:
      # ikecert certlocal -ks -m 1024 -t rsa-md5 \
      -D "C=US, O=PartyCompany, OU=US-Partym, CN=Partym" \
      -A IP=192.168.13.213
      Creating software private keys.
        Writing private key to file /etc/inet/secret/ike.privatekeys/0.
      Enabling external key providers - done.
      Acquiring private keys for signing - done.
      Certificate: 
       Proceeding with the signing operation.
       Certificate generated successfully (…/publickeys/0)
      Finished successfully.
      Certificate added to database.
      -----BEGIN X509 CERTIFICATE-----
      MIICLTCCAZagAwIBAgIBATANBgkqhkiG9w0BAQQFADBNMQswCQYDVQQGEwJVUzEX
      …
      6sKTxpg4GP3GkQGcd0r1rhW/3yaWBkDwOdFCqEUyffzU
      -----END X509 CERTIFICATE-----
    2. The command on the enigma system would appear similar to the following:
      # ikecert certlocal -ks -m 1024 -t rsa-md5 \
      -D "C=JA, O=EnigmaCo, OU=JA-Enigmax, CN=Enigmax" \
      -A IP=192.168.116.16
      Creating software private keys.
        …
      Certificate added to database.
      -----BEGIN X509 CERTIFICATE-----
      MIICKDCCAZGgAwIBAgIBATANBgkqhkiG9w0BAQQFADBJMQswCQYDVQQGEwJVUzEV
      …
      jpxfLM98xyFVyLCbkr3dZ3Tvxvi732BXePKF2A==
      -----END X509 CERTIFICATE-----
  3. Save the certificate and send it to the remote system.

    You can paste the certificate into an email.

    1. For example, you would send the following partym certificate to the enigma administrator:
      To: admin@ja.enigmaexample.com
      From: admin@us.partyexample.com
      Message: -----BEGIN X509 CERTIFICATE-----
      MIICLTCCAZagAwIBAgIBATANBgkqhkiG9w0BAQQFADBNMQswCQYDVQQGEwJVUzEX
      …
      6sKTxpg4GP3GkQGcd0r1rhW/3yaWBkDwOdFCqEUyffzU
      -----END X509 CERTIFICATE-----
    2. The enigma administrator would send you the following enigma certificate:
      To: admin@us.partyexample.com
      From: admin@ja.enigmaexample.com
      Message: -----BEGIN X509 CERTIFICATE-----
      MIICKDCCAZGgAwIBAgIBATANBgkqhkiG9w0BAQQFADBJMQswCQYDVQQGEwJVUzEV
      …
      jpxfLM98xyFVyLCbkr3dZ3Tvxvi732BXePKF2A==
      -----END X509 CERTIFICATE-----
  4. On each system, add the certificate that you received.
    1. Copy the public key from the administrator's email.
    2. Type the ikecert certdb -a command and press the Return key.

      No prompts display when you press the Return key.

      # ikecert certdb -a Press the Return key
    3. Paste the public key. Then press the Return key. To end the entry, press Control-D.
      -----BEGIN X509 CERTIFICATE----- MIIC… … ----END X509 CERTIFICATE----- Press the Return key
      <Control>-D
  5. Verify with the other administrator that the certificate is from that administrator.

    For example, you can telephone the other administrator to compare the values of the public key hash. The public key hash for the shared certificate must be identical on the two systems.

    1. List the stored certificate on your system.

      For example, on the partym system, the public certificate is in slot 1, and the private certificate is in slot 0.

      partym # ikecert certdb -l
      Certificate Slot Name: 0   Type: rsa-md5 Private Key
          Subject Name: <C=US, O=PartyCompany, OU=US-Partym, CN=Partym>
          Key Size: 1024
          Public key hash: B2BD13FCE95FD27ECE6D2DCD0DE760E2
      
      Certificate Slot Name: 1   Type: rsa-md5 Public Certificate
          (Private key in certlocal slot 0) Points to certificate's private key
          Subject Name: <C=JA, O=EnigmaCo, OU=JA-Enigmax, CN=Enigmax>
          Key Size: 1024
          Public key hash: 2239A6A127F88EE0CB40F7C24A65B818
    2. Compare this value with the public key hash on the enigma system.

      You can read the public key hash over the telephone.

      enigma # ikecert certdb -l
      Certificate Slot Name: 4   Type: rsa-md5 Private Key
          Subject Name: <C=JA, O=EnigmaCo, OU=JA-Enigmax, CN=Enigmax>
          Key Size: 1024
          Public key hash: DF3F108F6AC669C88C6BD026B0FCE3A0
      
      Certificate Slot Name: 5   Type: rsa-md5 Public Certificate
          (Private key in certlocal slot 4)
          Subject Name: <C=US, O=PartyCompany, OU=US-Partym, CN=Partym>
          Key Size: 1024
          Public key hash: 2239A6A127F88EE0CB40F7C24A65B818
  6. 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 partym system, the ike/config file would appear similar to the following:
      # Explicitly trust the following self-signed certs
      # Use the Subject Alternate Name to identify the cert
      
      # Verified remote address and remote ID
      # Verified public key hash per telephone call from administrator
      cert_trust "192.168.13.213" Local system's certificate Subject Alt Name
      cert_trust "192.168.116.16" Remote system's certificate Subject Alt Name
      
      ## Parameters that may also show up in rules.
      
      p1_xform 
        { auth_method preshared oakley_group 5 auth_alg sha encr_alg des }
      p2_pfs 5
      
      {
       label "US-partym to JA-enigmax"
       local_id_type dn
       local_id "C=US, O=PartyCompany, OU=US-Partym, CN=Partym"
       remote_id "C=JA, O=EnigmaCo, OU=JA-Enigmax, CN=Enigmax"
      
       local_addr  192.168.13.213
       remote_addr 192.168.116.16
      
       p1_xform
        {auth_method rsa_sig oakley_group 2 auth_alg sha1 encr_alg aes}
      }
    2. On the enigma system, add enigma values for local parameters in the ike/config file.

      For the remote parameters, use partym values. Ensure that the value for the label keyword is unique. This value must be different from the remote system's label value.

      …
      {
       label "JA-enigmax to US-partym"
       local_id_type dn
       local_id "C=JA, O=EnigmaCo, OU=JA-Enigmax, CN=Enigmax"
       remote_id "C=US, O=PartyCompany, OU=US-Partym, CN=Partym"
      
       local_addr  192.168.116.16
       remote_addr 192.168.13.213
      …

Example 23-4 Verifying That a Certificate From Another Administrator is Valid

In this example, the administrators use the Subject Name to verify that the certificates are identical.

The first administrator saves the output of generating and listing the certificate to a file. Because the output of the ikecert command prints to standard error, the administrator redirects standard error to the file.

sys1# cd /
sys1# ikecert certlocal -ks -m1024 -t rsa-md5 \
-D"C=US, O=TestCo, CN=Co2Sys" 2>/tmp/for_co2sys
Certificate added to database.
sys1# ikecert certdb -l "C=US, O=TestCo, CN=Co2Sys" 2>>/tmp/for_co2sys

The administrator verifies the contents of the file.

sys1# cat /tmp/for_co2sys
Creating private key.
-----BEGIN X509 CERTIFICATE-----
MIIB7TCCAVagAwIBAgIEZkHfOTANBgkqhkiG9w0BAQQFADAxMQwwCgYDVQQGEwNV
U0ExEDAOBgNVBAoMB3Rlc3RfY28xDzANBgNVBAMTBkVuaWdtYTAeFw0wODAxMTUx
OTI1MjBaFw0xMjAxMTUxOTI1MjBaMDExDDAKBgNVBAYTA1VTQTEQMA4GA1UECgwH
dGVzdF9jbzEPMA0GA1UEAxMGRW5pZ21hMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCB
iQKBgQCPxGv0rUzHMnFtkx9uwYuPiWbftmWfa9iDt6ELOEuw3zlboy2qtuRUZohz
FIbCxAJevdCY6a+pktvYy3/2nJL0WATObO5T0FKn3F0bphajinLYbyCrYhEzD9E2
gkiT2D9/ttbSiMvi9usphprEDcLAFaWgCJiHnKPBEkjC0vhA3wIDAQABoxIwEDAO
BgNVHQ8BAf8EBAMCBaAwDQYJKoZIhvcNAQEEBQADgYEAL/q6xgweylGQylqLCwzN
5PIpjfzsNPf3saTyh3VplwEOW6WTHwRQT17IO/1Oc6Jnz9Mr0ZrbHWDXq+1sx180
F8+DMW1Qv1UR/lGMq3ufDG3qedmSN6txDF8qLlPCUML0YL8m4oGdewqGb+78aPyE
Y/cJRsK1hWbYyseqcIkjj5k=
-----END X509 CERTIFICATE-----
Certificate Slot Name: 2   Key Type: rsa
        (Private key in certlocal slot 2)
        Subject Name: <C=US, O=TestCo, CN=Co2Sys>
        Key Size: 1024
        Public key hash: C46DE77EF09084CE2B7D9C70479D77FF

Then, the administrator sends the file in an email to the second administrator.

The second administrator places the file in a secure directory, then imports the certificate from the file.

sys2# cd /
sys2# ikecert certdb -a < /sec/co2sys

The ikecert command imports only the text between the -----BEGIN and -----END lines. The administrator verifies that the local certificate has the same public key hash as the public key hash in the co2sys file.

sys2# ikecert certdb -l
Certificate Slot Name: 1   Key Type: rsa
        (Private key in certlocal slot 1)
        Subject Name: <C=US, O=TestCo, CN=Co2Sys>
        Key Size: 1024
        Public key hash: C46DE77EF09084CE2B7D9C70479D77FF

To ensure that the first administrator sent this email, the second administrator telephones the first administrator to verify the Subject Name of the certificate.

Example 23-5 Specifying a Start Time and an End Time for a Certificate

In this example, the administrator on the partym system establishes dates within which the certificate is valid. The certificate is backdated by 2 1/2 days, and is valid for 4 years and 6 months from the date of creation.

# ikecert certlocal -ks -m 1024 -t rsa-md5 \
-D "C=US, O=PartyCompany, OU=US-Partym, CN=Partym" \
-A IP=192.168.13.213 \
-S -2d12h -F +4y6m

The administrator on the enigma system establishes dates within which the certificate is valid. The certificate is backdated by 2 days and is valid until midnight of December 31, 2010.

# ikecert certlocal -ks -m 1024 -t rsa-md5 \
-D "C=JA, O=EnigmaCo, OU=JA-Enigmax, CN=Enigmax" \
-A IP=192.168.116.16 \
-S -2d -F "12/31/2010 12:00 AM"

How to Configure IKE With Certificates Signed by a CA

Public certificates from a Certificate Authority (CA) require negotiation with an outside organization. The certificates very easily scale to protect a large number of communicating systems.

  1. On the system console, 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. Use the ssh command for secure remote login.


  2. Use the ikecert certlocal -kc command to create a certificate request.

    For a description of the arguments to the command, see Step 2 in How to Configure IKE With Self-Signed Public Key Certificates.

    # ikecert certlocal -kc -m keysize -t keytype \
    -D dname -A altname
    1. For example, the following command creates a certificate request on the partym system:
      # ikecert certlocal -kc -m 1024 -t rsa-md5 \
      > -D "C=US, O=PartyCompany\, Inc., OU=US-Partym, CN=Partym" \
      > -A "DN=C=US, O=PartyCompany\, Inc., OU=US-Partym"
      Creating software private keys.
        Writing private key to file /etc/inet/secret/ike.privatekeys/2.
      Enabling external key providers - done.
      Certificate Request: 
        Proceeding with the signing operation.
        Certificate request generated successfully (…/publickeys/0)
      Finished successfully.
      -----BEGIN CERTIFICATE REQUEST-----
      MIIByjCCATMCAQAwUzELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFEV4YW1wbGVDb21w
      …
      lcM+tw0ThRrfuJX9t/Qa1R/KxRlMA3zckO80mO9X
      -----END CERTIFICATE REQUEST-----
    2. The following command creates a certificate request on the enigma system:
      # ikecert certlocal -kc -m 1024 -t rsa-md5 \
      > -D "C=JA, O=EnigmaCo\, Inc., OU=JA-Enigmax, CN=Enigmax" \
      > -A "DN=C=JA, O=EnigmaCo\, Inc., OU=JA-Enigmax"
      Creating software private keys.
      …
      Finished successfully.
      -----BEGIN CERTIFICATE REQUEST-----
      MIIBuDCCASECAQAwSTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDFBhcnR5Q29tcGFu
      …
      8qlqdjaStLGfhDOO
      -----END CERTIFICATE REQUEST-----
  3. Submit the certificate request to a PKI organization.

    The PKI organization can tell you how to submit the certificate request. Most organizations have a web site with a submission form. The form requires proof that the submission is legitimate. Typically, you paste your certificate request into the form. When your request has been checked by the organization, the organization issues you the following two certificate objects and a list of revoked certificates:

    • Your public key certificate – This certificate is based on the request that you submitted to the organization. The request that you submitted is part of this public key certificate. The certificate uniquely identifies you.

    • A Certificate Authority – The organization's signature. The CA verifies that your public key certificate is legitimate.

    • A Certificate Revocation List (CRL) – The latest list of certificates that the organization has revoked. The CRL is not sent separately as a certificate object if access to the CRL is embedded in the public key certificate.

      When a URI for the CRL is embedded in the public key certificate, IKE can automatically retrieve the CRL for you. Similarly, when a DN (directory name on an LDAP server) entry is embedded in the public key certificate, IKE can retrieve and cache the CRL from an LDAP server that you specify.

      See How to Handle a Certificate Revocation List for an example of an embedded URI and an embedded DN entry in a public key certificate.

  4. Add each certificate to your system.

    The -a option to the ikecert certdb -a adds the pasted object to the appropriate certificate database on your system. For more information, see IKE With Public Key Certificates.

    1. On the system console, assume the Primary Administrator role or become superuser.
    2. Add the public key certificate that you received from the PKI organization.
      # ikecert certdb -a
      Press the Return key
      Paste the certificate:
      -----BEGIN X509 CERTIFICATE----- … -----END X509 CERTIFICATE----
      Press the Return key
      <Control>-D
    3. Add the CA from the PKI organization.
      # ikecert certdb -a
      Press the Return key
      Paste the CA:
      -----BEGIN X509 CERTIFICATE----- … -----END X509 CERTIFICATE----
      Press the Return key
      <Control>-D
    4. If the PKI organization has sent a list of revoked certificates, add the CRL to the certrldb database:
      # ikecert certrldb -a
      Press the Return key
      Paste the CRL:
      -----BEGIN CRL----- … -----END CRL----
      Press the Return key
      <Control>-D
  5. Use the cert_root keyword to identify the PKI organization in the /etc/inet/ike/config file.

    Use the name that the PKI organization provides.

    1. For example, the ike/config file on the partym system might appear similar to the following:
      # Trusted root cert
      # This certificate is from Example PKI
      # This is the X.509 distinguished name for the CA that it issues.
      
      cert_root "C=US, O=ExamplePKI\, Inc., OU=PKI-Example, CN=Example PKI"
      
      ## Parameters that may also show up in rules.
      
      p1_xform 
       { auth_method rsa_sig oakley_group 1 auth_alg sha1 encr_alg des }
      p2_pfs 2
      
      {
       label "US-partym to JA-enigmax - Example PKI"
       local_id_type dn
       local_id  "C=US, O=PartyCompany, OU=US-Partym, CN=Partym"
       remote_id "C=JA, O=EnigmaCo, OU=JA-Enigmax, CN=Enigmax"
      
       local_addr  192.168.13.213
       remote_addr 192.168.116.16
      
       p1_xform
        {auth_method rsa_sig oakley_group 2 auth_alg sha1 encr_alg aes}
      }

      Note - All arguments to the auth_method parameter must be on the same line.


    2. On the enigma system, create a similar file.

      Specifically, the enigma ike/config file should do the following:

      • Include the same cert_root value.

      • Use enigma values for local parameters.

      • Use partym values for remote parameters.

      • Create a unique value for the label keyword. This value must be different from the remote system's label value.

      …
      cert_root "C=US, O=ExamplePKI\, Inc., OU=PKI-Example, CN=Example PKI"
      …
      {
       label "JA-enigmax to US-partym - Example PKI"
       local_id_type dn
       local_id   "C=JA, O=EnigmaCo, OU=JA-Enigmax, CN=Enigmax"
       remote_id  "C=US, O=PartyCompany, OU=US-Partym, CN=Partym"
       
       local_addr  192.168.116.16
       remote_addr 192.168.13.213
      …
  6. Tell IKE how to handle CRLs.

    Choose the appropriate option:

    • No CRL available

      If the PKI organization does not provide a CRL, add the keyword ignore_crls to the ike/config file.

      # Trusted root cert
      …
      cert_root "C=US, O=ExamplePKI\, Inc., OU=PKI-Example,…
      ignore_crls

      The ignore_crls keyword tells IKE not to search for CRLs.

    • CRL available

      If the PKI organization provides a central distribution point for CRLs, you can modify the ike/config file to point to that location.

      See How to Handle a Certificate Revocation List for examples.

Example 23-6 Using rsa_encrypt When Configuring IKE

When you use auth_method rsa_encrypt in the ike/config file, you must add the peer's certificate to the publickeys database.

  1. Send the certificate to the remote system's administrator.

    You can paste the certificate into an email.

    For example, the partym administrator would send the following email:

    To: admin@ja.enigmaexample.com
    From: admin@us.partyexample.com
    Message: -----BEGIN X509 CERTIFICATE-----
    MII…
    ----END X509 CERTIFICATE-----

    The enigma administrator would send the following email:

    To: admin@us.partyexample.com
    From: admin@ja.enigmaexample.com
    Message: -----BEGIN X509 CERTIFICATE-----
    MII
    …
    -----END X509 CERTIFICATE-----
  2. On each system, add the emailed certificate to the local publickeys database.

    # ikecert certdb -a
    Press the Return key
    -----BEGIN X509 CERTIFICATE----- MII… -----END X509 CERTIFICATE-----
    Press the Return key
    <Control>-D

The authentication method for RSA encryption hides identities in IKE from eavesdroppers. Because the rsa_encrypt method hides the peer's identity, IKE cannot retrieve the peer's certificate. As a result, the rsa_encrypt method requires that the IKE peers know each other's public keys.

Therefore, when you use an auth_method of rsa_encrypt in the /etc/inet/ike/config file, you must add the peer's certificate to the publickeys database. The publickeys database then holds three certificates for each communicating pair of systems:

Troubleshooting – The IKE payload, which includes the three certificates, can become too large for rsa_encrypt to encrypt. Errors such as “authorization failed” and “malformed payload” can indicate that the rsa_encrypt method cannot encrypt the total payload. Reduce the size of the payload by using a method, such as rsa_sig, that requires only two certificates.

How to Generate and Store Public Key Certificates on Hardware

Generating and storing public key certificates on hardware is similar to generating and storing public key certificates on your system. On hardware, the ikecert certlocal and ikecert certdb commands must identify the hardware. The -T option with the token ID identifies the hardware to the commands.

Before You Begin

  1. On the system console, 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. Use the ssh command for secure remote login.


  2. Generate a self-signed certificate or a certificate request, and specify the token ID.

    Choose one of the following options:


    Note - The Sun Crypto Accelerator 4000 board supports keys up to 2048 bits for RSA. For DSA, this board supports keys up to 1024 bits.


    • For a self-signed certificate, use this syntax.
      # ikecert certlocal -ks -m 1024 -t rsa-md5 \
      > -D "C=US, O=PartyCompany, OU=US-Partym, CN=Partym" \
      > -a -T dca0-accel-stor IP=192.168.116.16
      Creating hardware private keys.
      Enter PIN for PKCS#11 token: Type user:password

      The argument to the -T option is the token ID from the attached Sun Crypto Accelerator 4000 board.

    • For a certificate request, use this syntax.
      # ikecert certlocal -kc -m 1024 -t rsa-md5 \
      > -D "C=US, O=PartyCompany, OU=US-Partym, CN=Partym" \
      > -a -T dca0-accel-stor IP=192.168.116.16
      Creating hardware private keys.
      Enter PIN for PKCS#11 token: Type user:password

    For a description of the arguments to the ikecert command, see the ikecert(1M) man page.

  3. At the prompt for a PIN, type the Sun Crypto Accelerator 4000 user, a colon, and the user's password.

    If the Sun Crypto Accelerator 4000 board has a user ikemgr whose password is rgm4tigt, you would type the following:

    Enter PIN for PKCS#11 token: ikemgr:rgm4tigt

    Note - The PIN response is stored on disk as clear text.


    After you type the password, the certificate prints out:

    Enter PIN for PKCS#11 token: ikemgr:rgm4tigt
    -----BEGIN X509 CERTIFICATE-----
    MIIBuDCCASECAQAwSTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDFBhcnR5Q29tcGFu
    …
    oKUDBbZ9O/pLWYGr
    -----END X509 CERTIFICATE-----
  4. Send your certificate for use by the other party.

    Choose one of the following options:

    • Send the self-signed certificate to the remote system.

      You can paste the certificate into an email.

    • Send the certificate request to an organization that handles PKI.

      Follow the instructions of the PKI organization to submit the certificate request. For a more detailed discussion, see Step 3 of How to Configure IKE With Certificates Signed by a CA.

  5. On your system, edit the /etc/inet/ike/config file to recognize the certificates.

    Choose one of the following options.

    • Self-signed certificate

      Use the values that the administrator of the remote system provides for the cert_trust, remote_id, and remote_addr parameters. For example, on the enigma system, the ike/config file would appear similar to the following:

      # Explicitly trust the following self-signed certs
      # Use the Subject Alternate Name to identify the cert
      
      cert_trust "192.168.116.16"  Local system's certificate Subject Alt Name
      cert_trust "192.168.13.213"  Remote system's certificate Subject Alt name
      
      
      # Solaris 10 1/06 release: default path does not have to be typed in #pkcs11_path
      "/usr/lib/libpkcs11.so" Hardware connection
      
      # Solaris 10 release: use this path
      #pkcs11_path "/opt/SUNWconn/cryptov2/lib/libvpkcs11.so"
      …
      {
       label "JA-enigmax to US-partym"
       local_id_type dn
       local_id "C=JA, O=EnigmaCo, OU=JA-Enigmax, CN=Enigmax"
       remote_id "C=US, O=PartyCompany, OU=US-Partym, CN=Partym"
      
       local_addr  192.168.116.16
       remote_addr 192.168.13.213
      
       p1_xform
        {auth_method rsa_sig oakley_group 2 auth_alg sha1 encr_alg aes}
      }
    • Certificate request

      Type the name that the PKI organization provides as the value for the cert_root keyword. For example, the ike/config file on the enigma system might appear similar to the following:

      # Trusted root cert
      # This certificate is from Example PKI
      # This is the X.509 distinguished name for the CA that it issues.
      
      cert_root "C=US, O=ExamplePKI\, Inc., OU=PKI-Example, CN=Example PKI"
      
      # Solaris 10 1/06 release: default path does not have to be typed in #pkcs11_path
      "/usr/lib/libpkcs11.so" Hardware connection
      
      # Solaris 10 release: use this path
      #pkcs11_path "/opt/SUNWconn/cryptov2/lib/libvpkcs11.so"
      …
      {
       label "JA-enigmax to US-partym - Example PKI"
       local_id_type dn
       local_id "C=JA, O=EnigmaCo, OU=JA-Enigmax, CN=Enigmax"
       remote_id  "C=US, O=PartyCompany, OU=US-Partym, CN=Partym"
      
       local_addr  192.168.116.16
       remote_addr 192.168.13.213
      
       p1_xform
        {auth_method rsa_sig oakley_group 2 auth_alg sha1 encr_alg aes}
      }
  6. Place the certificates from the other party in the hardware.

    Respond to the PIN request as you responded in Step 3.


    Note - You must add the public key certificates to the same attached hardware that generated your private key.


    • Self-signed certificate.

      Add the remote system's self-signed certificate. In this example, the certificate is stored in the file, DCA.ACCEL.STOR.CERT.

      # ikecert certdb -a -T dca0-accel-stor < DCA.ACCEL.STOR.CERT
      Enter PIN for PKCS#11 token: Type user:password

      If the self-signed certificate used rsa_encrypt as the value for the auth_method parameter, add the peer's certificate to the hardware store.

    • Certificates from a PKI organization.

      Add the certificate that the organization generated from your certificate request, and add the certificate authority (CA).

      # ikecert certdb -a -T dca0-accel-stor < DCA.ACCEL.STOR.CERT
      Enter PIN for PKCS#11 token: Type user:password
      # ikecert certdb -a -T dca0-accel-stor < DCA.ACCEL.STOR.CA.CERT
      Enter PIN for PKCS#11 token: Type user:password

      To add a certificate revocation list (CRL) from the PKI organization, see How to Handle a Certificate Revocation List.

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.

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

  1. 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.

  2. 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-7 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