Multiple Certificate Selection

System SSL allows up to four certificates to be assigned to a secure environment. The purpose of multiple certificates is to enable Elliptic Curve Digital Signature Algorithm (ECDSA) certificates while still allowing RSA certificates to be used with clients that require RSA.

For maximum interoperability, a server must be able to negotiate with a wide range of clients with varying SSL capabilities. When one client does not support TLSv1.2 or ECDSA certificates, the server must retain the ability to negotiate with an RSA certificate.

Two methods exist to configure multiple certificates for an environment:
  • Use the Digital Certificate Manager (DCM) to assign multiple certificates to the application definition configured for the secure environment.
  • Use the GSKit API gsk_attribute_set_buffer(GSK_KEYRING_LABEL_EX) to configure a list of certificate labels to be used.

During each SSL handshake, the appropriate certificate is selected for use by the session based on the attributes for the session. The selection process uses the SSL attributes from both the client and server to make the decision. It is possible that no certificate is usable for a combination of attributes.

Selection Considerations

When the negotiated protocol is TLSv1.1, TLSv1.0, SSLv3, or SSLv2 the first RSA certificate found that also has an RSA signature is used.

When the negotiated protocol is TLSv1.2, the selection process involves several steps.

  1. The key type of the server’s most preferred cipher suite that is supported by the client starts the selection process. A certificate has either an ECDSA or RSA key. If the cipher suite name contains “ECDSA”, then an ECDSA key/certificate must be used. If the cipher suite name contains “RSA”, then an RSA key/certificate must be used. If a matching certificate does not exist, then selection moves to the next cipher suite in the list until it finds a cipher suite that works with one of the certificates.

    When one or more certificate key type matches are found, additional criteria are checked to determine which if any can be used based on the rest of the handshake attributes.

  2. When ECDSA is the key type that is being considered, the named curve (which equates to key size) must be supported by the peer. If the ECDSA certificates under consideration have different named curves, the peer’s preferred order of named curves is used to determine the preferred certificate. One or more certificates can be tied for selection after this step. If no certificates remain eligible after this step, revert to the previous step.

  3. Both RSA and ECDSA certificates have a signature from the certificate’s issuing certificate authority. The signature key type can be different from the server certificate key type. When multiple certificates remain eligible for selection in this phase, the one with the signature most preferred by the peer is selected.

    An ECDSA certificate must have a signature algorithm that is allowed by the peer’s ordered signature algorithm list. If no ECDSA certificates in this step have a supported signature algorithm, revert to the previous step where a less preferred named curve can be considered for additional selection processing.

    If no RSA certificates in this step have a supported signature algorithm, revert to the first step where a different key type can be considered for additional selection processing.

    If there are multiple certificates still equivalent after this step, the first one processed is selected. The other equivalent certificates are never selected as they are cryptographically identical to the first certificate. Remove the additional certificates from the configuration to eliminate the extra selection processing.

  4. For compatibility with previous releases, there is one final consideration for RSA certificates. When processing completes with no certificate that meets the preceding selection criteria, the first RSA certificate that is processed is selected provided an RSA cipher suite is in the list.