VMware Cloud Community
albatros99
Enthusiast
Enthusiast

No access with firefox 120 for vsphere esxi 7.0.3

only on mac osx 14 with firefox 120

on vsphere 7.0.3
https://192.168.13.51
secured connection not allowed
Errorcode: SEC_ERROR_BAD_SIGNATURE

the same for vcenter
https://192.168.13.60 or https://192.168.13.60:5480
secured connection not allowed
Errorcode: SEC_ERROR_BAD_SIGNATURE

Who have a solution?

With Safari on the same Macbook no problem, also not a problem with firefox, edge on Windows 10/11

There is no antivirus-software, installed, cache was deleted, firefox completely removed and reinstalled.

Certificates are ok on vmware vsphere and vcenter!

Thanks for help!

Reply
0 Kudos
4 Replies
NateNateNAte
Hot Shot
Hot Shot

Well, based on your troubleshooting, you have a work-around with Safari on Mac OS and using other Win OS as well.  

Is there a hard requirement to use Firefox from a Mac OS?  

If the answer is yes, then you may want to open a case with both VMware and Firefox (to let them both know of the bug).  Since you have proven work-arounds, it sounds as if there is a bad call return to the Firefox browser, or the Firefox browser is not reading the return correctly to pass the security confirmation. 

Also, did vSphere access work on an earlier version of Firefox on the Mac OS in question?  That would be the other short-term fix to roll-back (if it is not a security violation) until you can use either the work-around or a patch is pushed from Mozilla.

Tags (1)
Reply
0 Kudos
albatros99
Enthusiast
Enthusiast

i had spoke only from firefox on one Macbook with the newest osx 14.1!

On a Imac Pro, with the same software, there is not a problem!

On all win7/win10/win11 machines there is no problem to access on vspehre or vcenter (Firefox, Saphari, Edge, etc)

There is no antivirus-software, cache was deleted!

How can i solve this problem? Any idea?

Reply
0 Kudos
NateNateNAte
Hot Shot
Hot Shot

With the added information (works on the Mac Pro, same OS) then it looks like it is a minor bug in the Firefox browser working with the M1 that is using OSx 14.1

I'm not aware of any good fix beyond submitting a ticket to Mozilla, with a tracelog of the access error, if you can record and release that. 

Again, you seem to have work-arounds (which means there's no reason to submit a ticket to VMware), so I'd go with the work-around (edge, safari, etc.) until the next update of Firefox from Mozilla for OSx.

Sorry I don't have any better advice.

Tags (1)
Reply
0 Kudos
vitaprimo
Enthusiast
Enthusiast

Firefox uses its own certificate store, have you attempted importing the CA to Firefox?

Here are two solutions, I already tested the first one. Being in the same situation landed me here, BTW. 🙂

I left out some steps to save time, they should be obvious though.

Import the CA to Firefox

The problem is that you first need to get it and the connection is encrypted.

It's on https://<VCSA-IP/DNS-ADDRESS>/certs/download.zip

You might try getting around it using curl:

curl -kLO https://<VCSA-IP/DNS-ADDRESS>/certs/download.zip

Where:

-k accepts all certs,

-L follows redirects,

-O writes the output with the same filename (so you don't have to pick one),

or alternatively:

curl -kLo something.zip https://<VCSA-IP/DNS-ADDRESS>/certs/download.zip

If you don't have curl, you might need to get Homebrew or MacPorts or whatever it's called. That's on you though, this is already too long. wget might work too. On Windows: Invoke-WebRequest https://… -OutFile xxx.zip does it but skipping the cert check is very hard. The exception is if you use PowerShell Core which has the -SkipCertificateCheck option.

But, since you mentioned you can access it in Safari, might as well (and thanks for the tip) just go there and before clicking on Screen Shot 2023-12-03 at 16.46.04.png, look to the right for the links on the side:

Screen_Shot_2023-12-03_at_15_46_58.png

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

The public of the root is in the win directory of the compressed file. The others are copies of the same but require renaming to be recognized.Screen Shot 2023-12-03 at 15.49.13.png

Press ⌘, (Settings) in Firefox, search the settings for "cert" to get there fast, click the View Certificates… button and add the authority:

Screen_Shot_2023-12-03_at_16_11_17.png

 

Set Firefox to read the certs* from your keychain

Another option is to navigate to  about:config in Firefox and search for roots, double-click the last two result entries to change them to true:

Screen Shot 2023-12-03 at 15.54.47.png

The most important one is the one grayed out in the screenshot above — security.enterprise_roots.enabled — it's grayed out in my case because it's forced with a config profile. The other one is the same thing with some detection voodoo.

This allows Firefox to read certs from your keychain's (Keychain Access.app) login (user) and System (system-wide) stores. They must be set as trusted, which you probably already know. Just being thorough. 🙂

Screen_Shot_2023-12-03_at_16_00_07.png

You used to be able to skip all this by preemptively downloading the cert right in Firefox (you might still can):

Screen_Shot_2023-12-03_at_16_04_49.png

But it seems an encryption level-related issue now. Firefox is quite annoying with this… well I guess all of them are now.

So, that's about it. Good luck if still unresolved…who knows how old is this thread, I didn't check, or spellchecked for that matter. =P

 

--------------------------

*: they should be imported and trusted at some point for this to work.