Using hash and URL certificate encoding types

During an IKE flow, security endpoints can authenticate each other by exchanging certificate information in certificate payloads and by performing digital signature operations on that certificate information. When the IKED negotiates an IKEv2 phase 1 Security Association on behalf of a network security client, the IKED uses the network security server for these digital signature operations. Encoded certificate information that is received from a remote security endpoint is forwarded to the network security server. Encoded certificate information that is sent to a remote security endpoint by the IKED is obtained from the network security server.

There are several encoding types defined for use in IKEv1, but the only encoding type that must be supported by an IKEv1 implementation is an X.509 certificate signature. Two additional certificate encoding types must be supported by an IKEv2 implementation:

Hash and URL of an X.509 certificate
Hash and URL of an X.509 bundle

Generally a hash and URL of a certificate or certificate bundle is considerably smaller than the certificate or the bundle that it represents. Less data is exchanged between IKE peers and between the IKED and the network security server. Although smaller message sizes might improve the efficiency of network resources, using hash and URL encoding requires more processing. The NSSD must communicate with an HTTP server to retrieve the certificate using the URL, and it must validate the certificate using the hash. This communication, when needed, increases the amount of time it takes to complete an IKEv2 phase 1 negotiation.

If you want the NSSD to create hash and URL certificates to send to peers, you must create files on an HTTP server that contain the certificates and the certificate bundles. You must also include the URLs of those files in the NSSD configuration file. See Enabling the NSSD to generate hash and URL certificate encoding.

Rule: Even if you put a certificate or a certificate bundle on an HTTP server and add the URLs to the NSSD configuration file, you still need to store that certificate on the key ring of the NSSD.

The NSSD can accept hash and URL encoded certificates that it receives from its peers. In that case, the NSSD uses the URLs sent by the peers to locate the certificates. The NSSD caches data that it retrieves from an HTTP server using a URL. See Enabling the NSSD to process received hash and URL certificate encoding.

Even when URL information is configured for the NSSD, it is ultimately the responsibility of the network security client to decide whether the network security server should use hash and URL encoding. See Controlling the use of hash and URL certificate encoding.