Go to main content

Securing the Network in Oracle® Solaris 11.3

Exit Print View

Updated: April 2019
 
 

How to Generate and Store Public Key Certificates for IKEv1 in 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

  • The hardware must be configured.

  • The hardware uses the /usr/lib/libpkcs11.so library unless the pkcs11_path keyword in the /etc/inet/ike/config file points to a different library. The library must be implemented according to the following standard: RSA Security Inc. PKCS #11 Cryptographic Token Interface (Cryptoki), that is, a PKCS #11 library.

    See How to Configure IKEv1 to Find the Sun Crypto Accelerator 6000 Board for setup instructions.

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. Generate a self-signed certificate or a CSR, and specify the token ID.

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

    Choose one of the following options:

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

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

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

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

  2. At the prompt for a PIN, type the Sun Crypto Accelerator 6000 username, a colon, and the user's password.

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

    Enter PIN for PKCS#11 token: ikemgr:rgm4tigt

    Note -  If you type the ikecert commands with the –p option, the PKCS #11 token is stored on disk as clear text and is protected by root permissions. If you do not store the PIN on disk, you must unlock the token by using the ikeadm command after the in.iked command is running.

    After you type the password, the certificate prints the following output:

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

    Choose one of the following options:

  4. 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 host1 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.0.2.16"  Local system's certificate Subject Alt Name
      cert_trust "192.0.2.213"  Remote system's certificate Subject Alt name
      
      ...
      {
       label "JA-host1 to US-host2"
       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.0.2.16;
       remote_addr 192.0.2.213
      
       p1_xform
        {auth_method rsa_sig oakley_group 2 auth_alg sha256 encr_alg aes}
      }
    • Certificate request

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

      # Trusted root cert
      # This certificate is from Example CA
      # This is the X.509 distinguished name for the CA that it issues.
      
      cert_root "C=US, O=ExampleCA\, Inc., OU=CA-Example, CN=Example CA"
      
      ...
      {
       label "JA-host1 to US-host2 - Example CA"
       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.0.2.16
       remote_addr 192.0.2.213
      
       p1_xform
        {auth_method rsa_sig oakley_group 2 auth_alg sha256 encr_alg aes}
      }
  5. Place the certificates from the other party in the hardware.

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


    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:passphrase

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

      Add the certificate that the CA generated from your certificate request and organization's certificate.

      You might also need to add intermediate certificates.

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

      To add a certificate revocation list (CRL) from the CA, see How to Handle Revoked Certificates in IKEv1.

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.