Go to main content

Securing the Network in Oracle® Solaris 11.4

Exit Print View

Updated: January 2019
 
 

How to Handle Revoked Certificates in IKEv2

Revoked certificates are certificates that are compromised for some reason. A revoked certificate that is in use is a security risk. You have options when verifying certificate revocation. You can use a static list or you can verify revocations dynamically over the HTTP protocol.

Before You Begin

You have received and installed certificates from a CA.

You are familiar with the CRL and OCSP methods of checking for revoked certificates. For information and pointers, see IKE With Public Key Certificates.

You must become an administrator who is assigned the Network IPsec Management rights profile, and use a profile shell. For more information, see Using Your Assigned Administrative Rights in Securing Users and Processes in Oracle Solaris 11.4.

  1. Locate the CRL and OCSP sections in the certificate that you received from the CA.

    You can identify the certificate from the label of your CSR.

    $ pfbash
    $ ikev2cert list objtype=cert | grep Label:
    Enter PIN for Sun Software PKCS#11 softtoken: 
            Label: Example1m1

    For example, the following truncated output highlights the CRL and OCSP URIs in a certificate.

    $ ikev2cert list objtype=cert label=Example1m1
    X509v3 extensions:
        ...
        X509v3 CRL Distribution Points:
             Full Name:
           URI:http://onsitecrl.PKI.example.com/OCCIPsec/LatestCRL.crl
        X509v3 Authority Key Identifier:
             ...
        Authority Information Access:
            OCSP - URI:http://ocsp.PKI.example.com/revokes/
        X509v3 Certificate Policies:
             Policy: 2.16.840.1.113733.1.7.23.2

    Under the CRL Distribution Points entry, the URI value indicates that this organization's CRL is available in a file on the web. The OCSP entry indicates that the status of individual certificates can be determined dynamically from a server.

  2. Enable the use of CRLs or an OCSP server by specifying a proxy.
    # kmfcfg modify \
    dbfile=/etc/inet/ike/kmf-policy.xml \
    policy=default \
    http-proxy=www-proxy.ja.example.com:80

    At sites where a proxy is optional, you do not need to specify one.

  3. Verify that the certificate validation policy is updated.

    For example, verify that the OCSP was updated.

    $ kmfcfg list \
    dbfile=/etc/inet/ike/kmf-policy.xml \
    policy=default
    ...
        OCSP:
            Responder URI: [not set]
            Proxy: www-proxy.ja.example.com:80
            Use ResponderURI from Certificate: true
            Response lifetime: [not set]
            Ignore Response signature: false
            Responder Certificate: [not set]
  4. Restart the IKEv2 service.
    $ pfexec svcadm restart ikev2
  5. (Optional) Stop using CRLs or OCSP.
    • To stop using CRLs, type:
      $ pfexec kmfcfg modify \
      dbfile=/etc/inet/ike/kmf-policy.xml policy=default \
      crl-none=true

      The crl-none=true argument forces the system to use downloaded CRLs from the local cache.

    • To stop using OCSP, type:
      $ pfexec kmfcfg modify \
      dbfile=/etc/inet/ike/kmf-policy.xml policy=default \
      ocsp-none=true
Example 33  Changing the Time That a System Waits For IKEv2 Certificate Verification

In this example, the administrator limits the wait to twenty seconds for a certificate to be verified.

# kmfcfg modify dbfile=/etc/inet/ike/kmf-policy.xml policy=default \
    cert-revoke-responder-timeout=20

By default, when a response times out, the authentication of the peer succeeds. Here, the administrator configures a policy where the connection is refused when authentication fails. In this configuration, certificate validation fails when an OCSP or CRL server becomes unresponsive.

# kmfcfg modify dbfile=/etc/inet/ike/kmf-policy.xml policy=default \
    ignore-cert-revoke-responder-timeout=false

To activate the policy, the administrator restarts the IKEv2 service.

# svcadm restart ikev2