Multiple certificate selection
System TLS allows up to four certificates to be assigned to a secure environment. The purpose of multiple certificates is to enable the use of 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 TLS capabilities. When one client does not support ECDSA certificates, the server must retain the ability to use an RSA certificate in order to negotiate a secure connection with that client.
- 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 TLS handshake, the appropriate certificate is selected for use by the session based on the attributes for the session. The selection process uses the TLS 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, or SSLv3 the first RSA certificate found that also has an RSA signature is used.
-
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.
- 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 tried for selection after this step. If no certificates remain eligible after this step, revert to the previous step.
-
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.
- 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. If no RSA certificate is selected, then the first ECDSA certificate that is processed is selected provided an ECDSA cipher suite is in the list.
- The negotiated cipher suite is not part of the certificate selection process.
- The named elliptic curve group list is not part of the certificate selection process.
- The signature algorithm certificate list is the primary factor for certificate selection. Both RSA and ECDSA certificates have a signature from the certificate’s issuing certificate authority. The certificate with the signature most preferred by the peer list is selected. When ECDSA is the key type of the certificate under consideration, the certificate’s key size must match the signature algorithm’s hash. If a match, the certificate is selected. If key size does not match hash size, the certificate is selected if no configured certificates match this requirement.
- When processing completes with no certificate that meets the preceding selection criteria, the first certificate encountered with a signature that is not SHA1 or MD5 is selected.