How to Configure IKE With Public Keys Signed by a Certificate Authority (IPsec and IKE Administration Guide)

IPsec and IKE Administration Guide

How to Configure IKE With Public Keys Signed by a Certificate Authority

On the system console, become superuser or assume an equivalent role.

Note –
Logging in remotely exposes security-critical traffic to eavesdropping. Even if you somehow protect the remote login, the total security of the system is reduced to the security of the remote login session.

Use the ikecert certlocal -kc command to create a certificate request.

The arguments to the command should be the same arguments that you would use for a ikecert certlocal -ks command.

# ikecert certlocal -kc -m keysize -t keytype \
-D dname -A altname[ ... ] [-f output]

`-kc`	Creates a public and private key pair. Also, `-kc` creates a certificate request that is based on the public key that was generated.
`keysize`	The size of the key. `keysize` can be 512, 1024, 2048, 3072, or 4096.
`keytype`	The type of algorithm to use. `keytype` can be rsa-sha1, rsa-md5, or dsa-sha1.
`dname`	The X.509 distinguished name for the certificate subject. `dname` typically has the form: C=country, O=organization, OU=organizational unit, CN=common name. Valid tags are C, O, OU, and CN.
`altname`	The alternate name for the certificate. `altname` should be in the form of `tag=value`. Valid tags are `IP`, `DNS`, `EMAIL`, `URI`, `DN`, and `RID`.
`output`	The format of the encoding output. The possible values are `pem` for PEM Base64, and `ber` for ASN.1 BER. If `-f` is not specified, `pem` is assumed.

For example, the following command creates a certificate request:

# ikecert certlocal -kc -m 1024 -t rsa-md5 \
> -D "C=US, O=ExampleCompany\, Inc., OU=US-Example, CN=Example" \
> -A "DN=C=US, O=ExampleCompany\, Inc., OU=US-Example"
Generating, please wait...
Certificate request generated.
-----BEGIN CERTIFICATE REQUEST-----
MIIByjCCATMCAQAwUzELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFEV4YW1wbGVDb21w
…
lcM+tw0ThRrfuJX9t/Qa1R/KxRlMA3zckO80mO9X
-----END CERTIFICATE REQUEST-----

Submit the certificate request to an organization that handles PKI.

The organization might be an outside Certificate Authority or PKI. Also, a company might run its own PKI. The PKI can tell you how to submit the certificate request. Most organizations have a web site with a submission form. The form requires proof that the submission is legitimate. Typically, you paste your certificate request into the form. When your request has been checked by the organization, the organization issues you two or three certificate objects:
- Your publickeys certificate – This certificate is based on the request you submitted to the organization. The certificate that you submitted is part of this publickeys certificate. The certificate uniquely identifies you.
- A Certificate Authority – The organization's signature. The CA verifies that your publickeys certificate is legitimate.
- A Certificate Revocation List (CRL) – The latest list of certificates that the organization has revoked. The CRL is not sent separately as a certificate object if access to the CRL is embedded in the publickeys certificate.
  
  When a URI for the CRL is embedded in the publickeys certificate, IKE can automatically retrieve the CRL for you. Similarly, when a DN entry is embedded in the publickeys certificate, IKE can automatically retrieve the CRL from an LDAP server that you specify.
  
  See How to Access a Certificate Revocation List for an example of an embedded URI and an embedded DN entry in a publickeys certificate.

Enter each certificate as the argument to one of three ikecert commands.

The commands use the -a option. The -a option adds the pasted object to the appropriate certificate database on your system. For more information, see Using Public Key Certificates.
1. On the system console, become superuser or assume an equivalent role.
2. Type the ikecert certdb –a command and type <Return>.
  # ikecert certdb -a <Type the Return key>
3. Paste the publickeys certificate that you received from the organization and type <Return>.
  -----BEGIN X509 CERTIFICATE----- … -----END X509 CERTIFICATE----<Type the Return key>
4. End the entry by typing <Control-D>.
  <Control-D>
5. Type the ikecert certdb –a command and type <Return>.
  # ikecert certdb -a <Type the Return key>
6. Paste the organization's CA. Type <Return>. Then type <Control-D> to end the entry.
  -----BEGIN X509 CERTIFICATE----- … -----END X509 CERTIFICATE-----<Type the Return key> <Control-D>
7. If the organization has sent a CRL object, type the ikecert certrldb –a command and type <Return>.
  # ikecert certrldb -a <Type the Return key>
8. Paste the organization's CRL. Type <Return>. Then type <Control-D> to end the entry.

Edit the /etc/inet/ike/config file to recognize the organization.

Use the name that the organization tells you to use. For example,

# Trusted root cert
# This certificate is from Example PKI
# This is the X.509 distinguished name for the CA that it issues.

cert_root "C=US, O=ExamplePKI\, Inc., OU=PKI-Example, CN=Example PKI"

## Parameters that may also show up in rules.

p1_xform { auth_method rsa_sig oakley_group 1 auth_alg sha1 encr_alg des }
p2_pfs 2

{
 label "US-Example to UN-Example - Example PKI"
 local_id_type dn
 local_id  "C=US, O=ExampleCompany, OU=US-Example, CN=Example"
 remote_id "C=US, O=ExampleCompany, OU=UN-Example, CN=Example"

 local_addr 192.168.116.16
 remote_addr 192.168.13.213

 p1_xform
  { auth_method rsa_encrypt oakley_group 2  auth_alg md5  encr_alg 3des }
}

Note –

All arguments to auth_method must be on the same line.

If the PKI organization does not provide a CRL, add the keyword ignore_crls to the ike/config file.

ignore_crls tells IKE not to search for CRLs. For example,
# Trusted root cert … cert_root "C=US, O=ExamplePKI\, Inc., OU=PKI-Example, CN=Example PKI" ignore_crls …

If the PKI organization provides a central distribution point for CRLs, you can modify the ike/config file to point to that location.

See How to Access a Certificate Revocation List for examples.

Repeat Step 1 through Step 7 on the communicating system.

Following the example, the “…OU=UN-Example…” system runs the ikecert commands as you have done. The /etc/inet/ike/config file of the “…OU=UN-Example…” system uses its local information for local parameters. The system uses your system's information for the remote parameters.

For example,

# Trusted root cert
# This certificate is from Example PKI

cert_root "C=US, O=ExamplePKI\, Inc., OU=PKI-Example, CN=Example PKI"
ignore_crls

## Parameters that may also show up in rules.

p1_xform { auth_method rsa_sig oakley_group 1 auth_alg sha1 encr_alg des }
p2_pfs 2

{
 label "UN-Example to US-Example - Example PKI"
 local_id_type dn
 local_id "C=US, O=ExampleCompany, OU=UN-Example, CN=Example"
 remote_id "C=US, O=ExampleCompany, OU=US-Example, CN=Example"

 local_addr 192.168.13.213
 remote_addr 192.168.116.16

 p1_xform
  { auth_method rsa_encrypt oakley_group 2  auth_alg md5  encr_alg 3des }
}

Because auth_method is rsa_encrypt, add the peer's certificate to the publickeys database.

Note –

The following substeps are necessary only if the p1_xform in the /etc/inet/ike/config file uses the rsa_encrypt authentication method.

Send the certificate to the communicating system's administrator.

You can cut-and-paste the certificate into an email, as in:

To: root@un.example.com
From: root@us.example.com
Message: -----BEGIN CERTIFICATE REQUEST-----
MIIByjCCATMCAQAwUzELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFEV4YW1wbGVDb21w
…
lcM+tw0ThRrfuJX9t/Qa1R/KxRlMA3zckO80mO9X
-----END CERTIFICATE REQUEST-----

On each system, add its peer's certificate to the local publickeys database.

For example, on the un.example.com system, type the following and paste the contents of the email:

# ikecert certdb -a <Type the Return key>
-----BEGIN CERTIFICATE REQUEST-----
MIIByjCCATMCAQAwUzELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFEV4YW1wbGVDb21w
…
lcM+tw0ThRrfuJX9t/Qa1R/KxRlMA3zckO80mO9X
-----END CERTIFICATE REQUEST-----

The authentication method for RSA encryption hides identities in IKE from eavesdroppers. Because the rsa_encrypt method hides identities, IKE does not know the peer. Therefore, IKE cannot retrieve the peer's certificate. As a result, the method requires that the IKE peers know each other's public keys. Therefore, when you use auth_method rsa_encrypt in the /etc/inet/ike/config file, you must add the peer's certificate to the publickeys database. So, the publickeys database then holds three certificates for each communicating pair of systems. The database holds your publickeys certificate, the CA certificate, and the peer's certificate. The CRL database still holds any revoked certificates.

The IKE daemon authenticates itself with the public keys and with the CA when the following completes:

The /etc/hosts file on each system has been modified to include the protected interfaces
The /etc/inet/ipsecinit.conf file on each system has been modified to include the protected interfaces
Both systems are rebooted.