Go to main content

Securing the Network in Oracle® Solaris 11.3

Exit Print View

Updated: September 2018
 
 

How to Configure IKEv1 With Certificates Signed by a CA

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.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. Use the ikecert certlocal -kc command to create a certificate signing request (CSR).

    For a description of the arguments to the command, see Step 1 in How to Configure IKEv1 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 CSR on the host2 system:
      # ikecert certlocal -kc -m 2048 -t rsa-sha384 \
      > -D "C=US, O=Example2Co\, Inc., OU=US-Example2m, CN=Example2m" \
      > -A "DN=C=US, O=Example2Co\, Inc., OU=US-Example2m"
      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 CSR on the host1 system:
      # ikecert certlocal -kc -m 2048 -t rsa-sha384 \
      > -D "C=JA, O=Example1Co\, Inc., OU=JA-Example1x, CN=Example1x" \
      > -A "DN=C=JA, O=Example1Co\, Inc., OU=JA-Example1x"
      Creating software private keys.
      ...
      Finished successfully.
      -----BEGIN CERTIFICATE REQUEST-----
      MIIBuDCCASECAQAwSTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDFBhcnR5Q29tcGFu
      ...
      8qlqdjaStLGfhDOO
      -----END CERTIFICATE REQUEST-----
  2. Submit the CSR to a CA.

    The CA can tell you how to submit the CSR. Most organizations have a web site with a submission form. The form requires proof that the submission is legitimate. Typically, you paste your CSR into the form. When your request has been checked by the organization, the organization issues you signed certificates. For more information, see Using Public Key Certificates in IKE.

  3. 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. Become an administrator.

      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.

    2. Add the public key and its certificate that you received from the CA.
      # ikecert certdb -a < /tmp/PKIcert.eml
    3. Add the CA's public certificate.

      You might also need to add intermediate certificates.

      # ikecert certdb -a < /tmp/PKIca.eml
    4. If the CA 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
      Press Control-D
  4. Use the cert_root keyword in the /etc/inet/ike/config file to identify the CA that issued the certificate.

    Use the Distinguished Name (DN) of the CA's certificate.

    1. For example, the ike/config file on the host2 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's cert 
      
      cert_root "C=US, O=ExampleCA\, Inc., OU=CA-Example, CN=Example CA"
      
      ## Parameters that may also show up in rules.
      
      p1_xform 
       { auth_method rsa_sig oakley_group 14 auth_alg sha384 encr_alg aes}
      p2_pfs 14
      
      {
       label "US-host2 to JA-host1 - Example CA"
       local_id_type dn
       local_id  "C=US, O=Example2Co, OU=US-Example2m, CN=Example2m"
       remote_id "C=JA, O=Example1Co, OU=JA-Example1x, CN=Example1x"
      
       local_addr  192.0.2.213
       remote_addr 192.0.2.16
      
       p1_xform
        {auth_method rsa_sig oakley_group 2 auth_alg sha256 encr_alg aes}
      }

      Note -  All arguments to the auth_method parameter must be on the same line.
    2. On the host1 system, create a similar file.

        Specifically, the host1 ike/config file must do the following:

      • Include the same cert_root value.

      • Use host1 values for local parameters.

      • Use host2 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=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=Example1Co, OU=JA-Example1x, CN=Example1x"
       remote_id  "C=US, O=Example2Co, OU=US-Example2m, CN=Example2m"
       
       local_addr  192.0.2.16
       remote_addr 192.0.2.213
      ...
  5. Set the IKEv1 policies for handling revoked certificates.

    Choose the appropriate option:

    • No OCSP available

      If the public key certificate provides a URI to reach the OCSP server but your system cannot connect to the Internet, add the keyword ignore_ocsp to the ike/config file.

      # Trusted root cert
      ...
      cert_root "C=US, O=ExampleCA\, Inc., OU=CA-Example,...
      ignore_ocsp
      ...

      The ignore_ocsp keyword tells IKEv1 to assume that the certificate is valid.

    • No CRL available

      If the CA does not provide a reliable source for CRLs or your system cannot connect to the Internet to retrieve CRLs, add the keyword ignore_crls to the ike/config file.

      # Trusted root cert
      ...
      cert_root "C=US, O=ExampleCA\, Inc., OU=CA-Example,...
      ignore_crls
      ...
    • URI for CRLs or OCSP available

      If the CA provides a central distribution point for revoked certificates, you can modify the ike/config file to use the URI.

      See How to Handle Revoked Certificates in IKEv1 for examples.

Example 46  Using rsa_encrypt When Configuring IKEv1

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

    For example, the host2 administrator would send the following message:

    To: admin@host1.ja.example.com
    From: admin@host2.us.example.com
    Message: -----BEGIN X509 CERTIFICATE-----
    MII...
    ----END X509 CERTIFICATE-----

    The host1 administrator would send the following message:

    To: admin@host2.us.example.com
    From: admin@host1.ja.example.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 < /tmp/saved.cert.eml

The authentication method for RSA encryption hides identities in IKE from eavesdroppers. Because the rsa_encrypt method hides the peer's identity, IKEv1 cannot retrieve the peer's certificate. As a result, the rsa_encrypt method requires that the IKEv1 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 at least three certificates for each communicating pair of systems:

  • Your public key certificate

  • The CA's certificate chain

  • The peer's public key certificate

Troubleshooting – The IKEv1 payload, which includes at least 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.

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.