If you are using firefox and failing to reach services like BrightView or the user portal with an error of “Secure Connection Failed” with an error code similar to one of the following.
NOTE: This issue likely applies to other browsers as well since they have client certificate functions. We are working to document them better.
- SSL_ERROR_BAD_CERT_ALERT
- SSL_ERROR_UNKNOWN_CA_ALERT
This problem comes from the automatic behavior of Firefox browser when a user certificate is present in the client browser.
This indicates that firefox has sent an invalid client certificate to the server.
Understanding Why and Diagnosis
Bright Cluster Manager uses client certificates, sometimes known as mTLS ( mutual TLS ), to secure automated and manual connection from users and other nodes, it is essential to proper operation. The server will always tell clients they may sent a certificate. Depending on the version of Bright the server may not specify filters for the certificate. You can see what your server is sending with the following command.
# openssl s_client -connect master:8081 -CAfile /cm/local/apps/cmd/etc/cacert.pem < /dev/null 2>/dev/null | grep -A2 'client certificate' No client certificate CA names sent Client Certificate Types: RSA sign, DSA sign, ECDSA sign Requested Signature Algorithms: ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA512:0x07+0x08:0x08+0x08:0x09+0x08:0x0A+0x08:0x0B+0x08:0x04+0x08:0x05+0x08:0x06+0x08:RSA+SHA256:RSA+SHA384:RSA+SHA512:ECDSA+SHA224:ECDSA+SHA1:RSA+SHA224:RSA+SHA1:DSA+SHA224:DSA+SHA1:DSA+SHA256:DSA+SHA384:DSA+SHA512
In the above case the server does not send any client certificate names, this would mean the browser will show a dialog box and may send any valid certificate. If that certificate did not originate from Bright then it will likely fail with one of the above errors. Newer builds of the cmd service should automatically or via configuration should present client certificate names as seen below. Versions with the new behavior include 9.1-9, 9.0-17, 8.1-24, 8.2-27, and 8.0-23.
# openssl s_client -connect master:8081 -CAfile /cm/local/apps/cmd/etc/cacert.pem < /dev/null 2>/dev/null | grep -A2 'client certificate' Acceptable client certificate CA names /C=US/ST=CA/L=San Jose/O=Bright Computing, Inc./CN=Bright Computing CA /C=US/ST=None/L=None/O=None/OU=None/CN=ew-bootstrap.cm.cluster
In the above case we see that the server has sent a list of acceptable client certificate issuers. Browsers will only send a certificate that matches those issuers. If you are having difficulty you should review the certificates in the Browser for expired or relicensed clusters matching those identities. ( option 1 ). Versions with this new behavior include 9.1-9, 9.0-17, 8.1-24, 8.2-27, and 8.0-23.
Option 1: Upgrade
If you are on a version of cmdaemon before 9.1-9, 9.0-17, 8.1-24, 8.2-27, or 8.0-23 you can upgrade to receive the new behavior. For Bright 8.x you may need the AdvancedConfig option “AddSSLClientCA=1”.
NOTE: not all versions of Bright listed above are available at the time of publishing, please use the customer portal to be notified when the software is released.
Option 2: Clear the login cache and cancel certificate requests
If your server does not send acceptable issuers and you have already selected a certificate you will need to clear the login cache and reattempt the connection. When connecting you should only select a valid certificate issued by the cluster and cancel the dialog if none are available. Failing to select a certificate will cause the session to fall back on password authentication.
For browsers other than Firefox you will need to adapt these instructions.
- Open the history and select “clear recent history”
2. Clear “Active Logins”
3. You may now refresh the site and select “Cancel” for requests to select a certificate. Note, you may need to select cancel several times before the site loads.
Option 3: Remove offending certificate
A browser without any stored certificates will not prompt to select one. Please do this will caution as the certificate may have been issued for another purpose.
You can go into the certificate manager to remove certificates that are no longer needed, please be careful as this certificate may be necessary for other sites. Pay close attention to the Issued by field since that will indicate who has issued the certificate.
Option 4: Create valid user certificate
You can create a valid certificate from the files in your home directory that can loaded into firefox with the following steps.
# ls -al .cm total 84 drwxr-xr-x 3 root root 72 Apr 5 10:03 . dr-xr-x--- 18 root root 4096 Aug 20 22:51 .. -rw------- 1 root root 1704 Apr 5 08:59 admin.key -rw------- 1 root root 1261 Apr 5 08:59 admin.pem drwx------ 2 root root 6 Apr 5 08:59 cmsh -rw------- 1 root root 72806 Aug 20 17:02 .cmshhistory
NOTE: the files will be named admin.pem/admin.key or may also be named cert.pem/cert.key for some users
# openssl pkcs12 -inkey .cm/admin.key -in .cm/admin.pem -export -out admin.pfx Enter Export Password: XXXXXXXX Verifying - Enter Export Password: XXXXXXX
The resulting .pfx file can be transferred to the client system and imported into the certificate list. Once imported you may select it from the drop-down list. When selecting the proper certificate the Issue should match the information on the Bright head node that you are connecting with.
Issued by: CN=my-head-node,OU=None,O=None,L=None,ST=None,C=US
Option 5: Use a reverse proxy
Another possible solution would be to place Bright View and the User Portal behind a reverse proxy. This will strip the client certificate request and sessions will proceed with username and password. This solution also allows the installation of a globally valid TLS certificate.