For those of you supporting Firefox in a Windows environment, and doing SSL inspection, however are you getting the cert trusts in place? Anyone leveraging GPO extensions, and if so, to what success? If you have any special use boxes how are you handling those?
It's time for us to update our SSL certs as the ones we installed when we onboarded to MWG are expiring. This is causing us to revisit our deployment of them. In this environment, we support 3 web browsers. Chrome and IE are easy, or course, on group policy managed machines. Firefox is a little trickier and became even more annoying with Firefox 46, when the developers decided that no one uses the default profile functionality, and removed the ability for you to put in a default certs8.db file into your deployment images. The reason that default is important is that when a user creates a new firefox profile (e.g. when logging into a new machine the first time), they won't trusting the middling SSL cert for the gateway and they'll have SSL warnings galore. Our end user computing folks used to handle that with the default profile and an AutoIT program that leveraged an old NSS certutil, but while that approach still successfully injects the certs into existing Firefox profiles, we're now hunting for a way to make sure the certs get into newly created firefox user profiles too in a post-Firefox-46 regime.
Thanks much for any insights. If I've overlooked any best practices docs that were created in the past few years, I'd enjoy pointers to them as well.
This thread didn't get any uptake, and I'm wondering now if no one is supporting firefox, and/or do that few places actually SSL middle?
This environment made it through the Certificate update, though it became a call to action for another group managing the MIcrosoft CA server that's still issuing SHA1 based certs. Chrome gets rather crabby about a SHA1 based cert that expires 1/1/17 or later (it puts the https in red with a slash but at least doesn't pop anything up), and Firefox and IE are about to join that club since SHA1 has been broken for a while. That has sped up some upgrade plans for the CA server though which will take about a month to work though.
We never did really solve the what to do about newly created profiles issue that Firefox created when they stopping using the default profile's cert8.db file as a template for new profiles.
Thanks for the reply Unblack. Can you say how you script goes looking for the profile, just search up any certs8.db's in the profiles subdirectories and copy over any existing? Also, how often do you run it/in what key?
How do you handle new machine provisioning so new profiles a user creates (either during first login, or if they create a new profile for some odd reason)?
Those are some of the details we're working out now that putting certs8.db in the default profile no long covers those cases.
The script runs on userlogin.
Here is the batch script:
if not exist "%appdata%\mozilla\firefox\profiles" goto:eof
dir "%profiledir%" /a:d /b > "%temp%\temppath.txt"
for /f "tokens=*" %%i in (%temp%\temppath.txt) do (
cd /d "%profiledir%\%%i"
copy cert8.db cert8.db.orig /y
copy \\folder\cert8.db cert8.db /y
del /f /q "%temp%\temppath.txt"
Thanks much for this. Seems quite straightforwad.
How long do you find it taking during login? My guy dabbled in this but using the old NSS certutil to import rather than a file copy, the time it took was too long to avoid user pitchforks with a login script. It also has the down side of tromping on any user saved certs from internal self-signed servers of which there are always many (especially for those poor groups of admins who have deal with a lot of iDrac and iLO interfaces and appliances etc). Something that maintains those would be ideal, but I suppose one way to handle that would be to just check the size or date of the file vs the default and if it's smaller than X replace it.
We use NSS cerutil to add certificates to cert8.db. Wrote script for it and added it to logon script. As I understand, you do the same.
We do the same, except it takes many many seconds to run such that we never implemented it as a logon script. How fast does yours run?
I don't have the code for ours, but it's something written in AutoIT if I recall correctly.