1. Home
  2. Support and Documentation
  3. Firefox issue – Secure Connection Failed

Firefox issue – Secure Connection Failed

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.


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

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.

  1. 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.

Updated on November 4, 2021

Related Articles

Leave a Comment