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.4.
If you administer remotely, see Example 19, 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.4 for secure remote login instructions.
For arguments to the ikecert certlocal command, see the ikecert(8) man page.
# 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
Creates a self-signed certificate.
Specifies the size of the key.
Specifies the type of algorithm to use.
Specifies the X.509 distinguished name (DN) for the certificate subject. For an example, see Using Public Key Certificates in IKE.
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.
# 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-----
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.
To: [email protected] From: [email protected] Message: -----BEGIN X509 CERTIFICATE----- MIIC1TCCAb2gAwIBAgIEfdZgKjANBgkqhkiG9w0BAQUFADAaMRgwFgYDVQQDEw9T a...+ zBGi4QkNdI3f -----END X509 CERTIFICATE------
To: [email protected] From: [email protected] Message: ----BEGIN X509 CERTIFICATE----- MIIC1TCCAb2gAwIBAgIEBl5JnjANBgkqhkiG9w0BAQUFADAaMRgwFgYDVQQDEw9T ... y85m6LHJYtC6 -----END X509 CERTIFICATE-----
# ikecert certdb -a < /tmp/certificate.eml
The command imports the text between the BEGIN and END tags.
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.
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.
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.
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.
# 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}
}
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}
}
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.