TLSv1.2 certificate renewal cipher support considerations for CA PAM appliances
Article ID: 273960
Updated On:
Products
Issue/Introduction
Starting CA PAM version 4.1.X there is a new tab in the Configuration/Security/Cryptography for CA PAM which indicates the TLSv1.2 certificates supported
Typically, the tab will look like the following
As per CA PAM documentation, the TLSv1.2 tab allows Global Admin users to enable or disable ciphers by CA PAM cryptography security settings, and it is determined by which type of certificate is currently configured under
It is possible to select or unselect ciphers to be used by just unchecking them in the tab and rebooting the appliance.
There is also another setting which will control whether CA PAM will accept TLSv1.1 and TLSv1.0 connections under Configuration/Security/Access
By default the options to accept TLSv1.0/1.1 connections is disabled, meaning only TLSv1.2 connections will be accepted
While this is enough to provide secure access to any appliance one must be careful while creating a new certification request in case the certificate of a given appliance needs to be renewed
Whenever a certificate is renewed, on generating the Certificate Signing Request to be sent to the certification authority, there is the possibility to choose to create the certification request for an RSA or an ECDSA-type certificate
However, there is no mention in the CSR of the ciphers the certificate should be providing support for.
It may very well be that if the ciphers to be supported by the new certificate are not the right ones, it is no longer possible to connect to the CA PAM appliance holding the certificate: every connection will be terminated at the ssl side and appliances will become unusable, even if their internal processes continue to work fine.
In the xcd_spfd.log tracking the connections to the appliances the following line will be shown for every connection
2023-09-08 11:18:13 159313 ERROR HandshakeSSL: Failed to SSL_accept() - can't match cipher suite
Environment
CA PAM 4.1.X
Cause
This is due to the fact that, even though the new certificate has been correctly generated, it does NOT support any of the ciphers presented in the Configuration/Security/Cryptography tab, that is, for instance:
TLS_RSA_WITH_AES_256_GCM_SHA384 (rsa 4096)
TLS_RSA_WITH_AES_128_GCM_SHA256 (rsa 4096)
TLS_RSA_WITH_AES_128_CBC_SHA (rsa 4096)
TLS_RSA_WITH_AES_256_CBC_SHA (rsa 4096)
for an RSA certificate, or
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (secp256r1)
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (secp256r1)
for an ECDSA one. The lists of ciphers may vary depending on the appliance and version used
What happens in this case is that the ssl client tries to establish a connection, the certificate in the PAM side works, but since it does not have support for the ciphers PAM expects to use, it can't establish the communication properly because CA PAM is lacking support for one of the ciphers it can use for TLSv1.2 operation
A simple way to see what ciphers are offered by a cerfiticate once installed in CA PAM is to use an nmap command to retrieve them
nmap -sV -p 443 --script ssl-enum-ciphers <CA PAM IP>
It should be able to offer, for TLSv1.2 one or more of the certificates listed under Cryptography/TLSv1.2 Ciphers
Resolution
Please instruct the certification authority to which the RSA or ECDSA CSR is being forwarded to include support for the respective ciphers you can see listed under Configuration/Security/Cryptography/TLSv1.2 Ciphers
If the ciphers supported in the certificate are not clear, it is also possible to momentarily enable TLSv1.1and TLSv1.0 access while it is verified via the nmap command mentioned, and disable the less secure access once it is clear that the certificate will work
Feedback
