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.
Choose one of the following options:
# 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.
# 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.
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
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-----
Choose one of the following options:
You can paste the certificate into an email message.
Follow the instructions of the CA to submit the certificate request. For a more detailed discussion, see Step 2 of How to Configure IKEv1 With Certificates Signed by a CA.
Choose one of the following options.
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} }
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} }
Respond to the PIN request as you responded in Step 2.
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.
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.