Go to main content

Securing the Network in Oracle® Solaris 11.3

Exit Print View

Updated: March 2018
 
 

How to Configure IKEv2 With Self-Signed Public Key Certificates

In this procedure, you create and sign a public key certificate. The private key and certificate are stored in the PKCS #11 softtoken keystore for IKEv2. You send the public key certificate to IKE peers, who in turn, send you their public certificate.

You perform this procedure on all IKE systems that use self-signed certificates.

Before You Begin

To use the certificates, you must have completed How to Create and Use a Keystore for IKEv2 Public Key Certificates.

You must become an administrator who is assigned the Network IPsec Management rights profile. You must be using a profile shell. 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 32, 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. Create a self-signed certificate in the keystore.

    For a description of the arguments to the ikev2cert gencertcommand, review the pktool gencert keystore=pkcs11 subcommand in the pktool(1) man page.

    For the format of the subject argument, see Using Public Key Certificates in IKE.


    Note -  Give the certificate a label. The label identifies the certificate and its corresponding keys in the local keystore.
    1. For example, the command on the host2 system would appear similar to the following:
      # pfbash
      	# ikev2cert gencert \
      	label="IThost2" \
      	subject="O=exampleco, OU=IT, C=US, CN=host2" \
      	serial=0x87654321
          keytype=rsa
          keylen=2048
      	Enter PIN for Sun Software PKCS#11 softtoken: xxxxxxxx

      The following error messages indicate a mistyped PIN or an uninitialized keystore:

      Error creating certificate and keypair:
      	keystore error: CKR_PIN_INCORRECT
      	libkmf error: KMF_ERR_AUTH_FAILED
      
      	Error creating certificate and keypair:
      	keystore error: CKR_PIN_EXPIRED: PIN expired and must be changed
      	libkmf error: KMF_ERR_BAD_PARAMETER: invalid parameter

      Tip  -  A display of pktool command syntax indicates that part of your certificate entry is mistyped. Examine the command for the use of a disallowed algorithm, missing double quotes and equals signs, and other typographical errors. One strategy to locate the invalid argument is to retrieve the command, then remove the arguments one at a time.
    2. The command on the host1 system would appear similar to the following:
      # ikev2cert gencert \
      	label=IThost1 \
      	subject="O=exampleco, OU=IT, C=US, CN=host1" \
      	serial=0x86428642
          keytype=rsa
          keylen=2048
      	Enter PIN for Sun Software PKCS#11 softtoken: xxxxxxxx
  2. (Optional) List the keys and certificate.
    host1 # /usr/sbin/ikev2cert list objtype=both
    	Enter PIN for Sun Software PKCS#11 softtoken: xxxxxxxx
    	No.     Key Type        Key Len.        Key Label
    	----------------------------------------------------
    	Asymmetric private keys:
    	1)      RSA                             IThost1
    	Asymmetric public keys:
    	1)      RSA                             IThost1
    	Certificates:
    	1) X.509 certificate
    		Label: IThost1
    		Subject: C=US, O=exampleco, OU=IT, CN=host1
    		Issuer: C=US, O=exampleco, OU=IT, CN=host1
    		Not Before: April 10 21:49:00 2014 GMT
    		Not After: April 10 21:49:00 2015 GMT
    		Serial: 0x86426420
    		Signature Algorithm: sha1WithRSAEncryption
    		X509v3 Subject Key Identifier:
    			34:7a:3b:36:c7:7d:4f:60:ed:ec:4a:96:33:67:f2:ac:87:ce:35:cc
    		SHA1 Certificate Fingerprint:
    			68:07:48:65:a2:4a:bf:18:f5:5b:95:a5:01:42:c0:26:e3:3b:a5:30

    Tip  -  The default hash algorithm is SHA1. To create a certificate with a stronger signature algorithm, use the keytype option and a different hash algorithm, such as keytype=rsa hash=sha384. For the options, see the pktool(1) man page.
  3. Deliver the certificate to the other system.
    1. On each system, export only the certificate to a file.

      The outformat=pem option ensures that the public certificate is placed in the file in a format that is suitable for direct import. The label identifies the certificate in the keystore.

      # cd /tmp
      	# ikev2cert export objtype=cert outformat=pem outfile=filename label=label
      	Enter PIN for Sun Software PKCS#11 softtoken:xxxxxxxx
    2. Send the certificate to the other system by email, sftp, or ssh.

      For example, if you administer both systems, use the sftp command to bring over the certificate from the other system.

      host1 # sftp jdoe@host2:/tmp/IThost2.pem /tmp/IThost2.pem.cert
      	host2 # sftp jdoe@host1:tmp/IThost1.pem /tmp/IThost1.pem.cert

      You are prompted for your password. In this example, jdoe must provide a password.

  4. Verify that the certificates are identical.

    You want to ensure that you have received the proper certificate before you load it into your keystore.

    1. Create a digest of the exported file on each system.

      For example, the host2 administrator emails the digest of the file that contains host2's certificate to the other administrator. The host1 administrator emails the digest of the host1 certificate file.

      host2 # digest -a sha1 /tmp/IThost2.pem
      	c6dbef4136c0141ae62110246f288e5546a59d86
      
      	host1 # digest -a sha1 IThost1.pem
      	6b288a6a6129d53a45057065bd02b35d7d299b3a
      	
    2. On the other system, run the digest command on the file that contains the certificate from the first system.
      host1 # digest -a sha1 /tmp/IThost2.pem.cert
      	c6dbef4136c0141ae62110246f288e5546a59d86
      
      	host2 # digest -a sha1 /tmp/IThost1.pem.cert
      	6b288a6a6129d53a45057065bd02b35d7d299b3a

      The digests must match. If they do not match, do not import the file to the keystore. For another way of verifying certificate validity, see Example 43, Verifying a Public Key Certificate by Its Fingerprint.

  5. After verification, import the other system's certificate to your keystore.

    When you import the certificate into your keystore, you must assign a label to it that uniquely identifies the certificate on your system. The label links the public key with its public key certificate.

    host1 # ikev2cert import label=IThost2 infile=/tmp/IThost2.pem.cert
    host2 # ikev2cert import label=IThost1 infile=/tmp/IThost1.pem.cert
  6. (Optional) List the objects in your keystore.

    Compare the listing with the list in Step 2. For example, in the host1 keystore, the host2 certificate is added.

    host1 # /usr/sbin/ikev2cert list objtype=both
    	Enter PIN for Sun Software PKCS#11 softtoken: xxxxxxxx
    	No.     Key Type        Key Len.        Key Label
    	----------------------------------------------------
    	Asymmetric private keys:
    	1)      RSA                             IThost1
    	Asymmetric public keys:
    	1)      RSA                             IThost1
    	Certificates:
    	1) X.509 certificate
    		Label: IThost1
    		Subject: C=US, O=exampleco, OU=IT, CN=host1
    		Issuer: C=US, O=exampleco, OU=IT, CN=host1
    		Not Before: April 10 21:49:00 2014 GMT
    		Not After: April 10 21:49:00 2015 GMT
    		Serial: 0x86426420
    		Signature Algorithm: sha1WithRSAEncryption
    		X509v3 Subject Key Identifier:
    			34:7a:3b:36:c7:7d:4f:60:ed:ec:4a:96:33:67:f2:ac:87:ce:35:cc
    		SHA1 Certificate Fingerprint:
    			68:07:48:65:a2:4a:bf:18:f5:5b:95:a5:01:42:c0:26:e3:3b:a5:30
    
    	2) X.509 certificate
    		Label: IThost2
    		Subject: C=US, O=exampleco, OU=IT, CN=host2
    		Issuer: C=US, O=exampleco, OU=IT, CN=host2
    		Not Before: April 10 21:40:00 2014 GMT
    		Not After: April 10 21:40:00 2015 GMT
    		Serial: 0x87654321
    		Signature Algorithm: sha1WithRSAEncryption
    		X509v3 Subject Key Identifier:
    			ae:d9:c8:a4:19:68:fe:2d:6c:c2:9a:b6:06:55:b5:b5:d9:d9:45:c6
    		SHA1 Certificate Fingerprint:
    			83:26:44:29:b4:1f:af:4a:69:0d:87:c2:dc:f4:a5:1b:4f:0d:36:3b
  7. On each system, use the certificates in an IKEv2 rule.

    Use the pfedit command to edit the /etc/inet/ike/ikev2.config file.

    1. For example, on the host2 system, the rule in the ikev2.config file would appear similar to the following:
      ##  ... Global transform that applies to any rule without a declared transform
      	ikesa_xform { dh_group 21 auth_alg sha512 encr_alg aes }
      	##  ... Any self-signed
      	## end-entity certificates must be present in the keystore or
      	## they will not be trusted.
      	{
      	 label "host2-host1"
      	 auth_method cert
      	 local_id DN = "O=exampleco, OU=IT, C=US, CN=host2"
      	 remote_id DN = "O=exampleco, OU=IT, C=US, CN=host1"
      	}
      	...
    2. On the host1 system, use the DN of the host1 certificate for the value of local_id in the ikev2.config file.

      For the remote parameter, use the host2 certificate's DN as the value. Ensure that the value for the label keyword is unique on the local system.

      …
      	ikesa_xform { dh_group 21 auth_alg sha512 encr_alg aes }
      	…
      	{
      	 label "host1-host2"
      	 auth_method cert
      	 local_id DN = "O=exampleco, OU=IT, C=US, CN=host1"
      	 remote_id DN = "O=exampleco, OU=IT, C=US, CN=host2"
      	}
      	...
  8. (Optional) On each system, check the validity of the ikev2.config files.
    # /usr/lib/inet/inikev2.d -c

    Fix any typographical errors or inaccuracies before continuing.

  9. On each system, check the state of the IKEv2 service instance.
    # svcs ikev2
    	STATE          STIME    FMRI
    	disabled       Sep_07   svc:/network/ipsec/ike:ikev2
  10. On each system, enable the IKEv2 service instance.
    host2 # svcadm enable ipsec/ike:ikev2
    
    	host1 # svcadm enable ipsec/ike:ikev2
Example 42  Creating a Self-Signed Certificate With a Limited Lifetime

In this example, the administrator specifies that the certificate is valid for two years.

# ikev2cert gencert \
	 > label=DBAuditV \
	 > serial=0x12893467235412 \
	 > subject="O=exampleco, OU=DB, C=US, CN=AuditVault" \
	 > altname=EMAIL=auditV@example.com \ 
	 > keytype=rsa hash=sha512 keylen=3072 \
     > lifetime=2-year
Example 43  Verifying a Public Key Certificate by Its Fingerprint

In this example, the administrator uses the certificate fingerprint to verify the certificate. The disadvantage of this method is that the administrator must import the peer's certificate into the keystore before viewing the fingerprint.

The administrator imports the certificate, lists it with the ikev2cert list objtype=cert command, then copies the certificate fingerprint from the output and sends it to the other system administrator.

SHA1 Certificate Fingerprint:
             83:26:44:29:b4:1f:af:4a:69:0d:87:c2:dc:f4:a5:1b:4f:0d:36:3b

If the verification fails, the administrator who imported the certificate must remove it and its public key from the keystore.

# ikev2cert delete label=label-name
       Enter PIN for Sun Software PKCS#11 softtoken: xxxxxxxx
       1 public key(s) found, do you want to delete them (y/N) ? y
       1 certificate(s) found, do you want to delete them (y/N) ? y

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.