policy-templates VS acme.sh

There is no such thing as a "known trusted extension" ever since they killed sideloading extensions and forced auto-updates. 10 years ago not force updating extensions was also a thing they moved behind a flag, and then just dropped.

Also - if you want to blacklist certain extensions from certain sites, you abso-freaking-lutely can already... see: https://github.com/mozilla/policy-templates/blob/master/READ...

you want the `restricted_domains` field.

It gets worse - Mozilla is the fucking worst at checking submitted extensions. They tried to the play into the whole "app store" thing that Google/Apple were doing, but those are justifiable cost centers at those two companies in a way that just doesn't work for a player like Mozilla.

Mozilla's store checks for extensions are fairly pathetic. You can submit a near empty shell with excessive permissions, get approved the first time, then auto-update to a new release (which will deploy to users immediately thanks to auto-updates). That new version has to pass a battery of useless automatic SAST checks, which will happily highlight all sorts of things it doesn't like (it flags words like "hello" because it contains a curse word) but which won't do shit to check if you're hoovering up credentials, browsing data, tracking users, etc.

If you're unlucky, at some point in the next 24 months you'll trigger a real review from Mozilla and get caught.

To be blunt - I have 15 years experience writing extensions. I don't like Google. If you think Mozilla is better you're wrong.

You can do that with policy templates. Use the Discussion tab at the top of the GitHub page if you need help setting them up.

Policy Templates for Firefox

They very well could do this for a a company that requires really strict privacy and security, but unfortunately in its current state Firefox doesn't have nearly the corporate sysadmin-friendly tooling that Chrome and especially Edge do.

When I was tasked with implementing CIS browser hardening policies at a previous job a few years ago, this was just a matter of enabling some Group Policy template settings for Chrome and Edge, but for Firefox this involved distributing a prefs.js file to all the workstations. In any corporate environment it's very likely going to be point and click Windows admins that are implementing browser standards, who tend to be allergic to anything resembling code and are already used to using GPOs for just about everything.

Yes, Firefox does have GPO templates but it's not nearly as rich as Chrome and Edge. Edge has even more GPO templates than does Chrome iirc, Chrome already had a lot to begin with and then Microsoft added even more of their own on top of that.

https://github.com/mozilla/policy-templates/blob/v4.11/READM...

https://learn.microsoft.com/en-us/deployedge/configure-micro...

That alone already puts Firefox at a huge disadvantage for corporate deployment, the other thing that makes it even less attractive, even to companies where privacy/security is a huge requirement (like my previous job) is that Edge is already bundled with the OS, and is one less thing that needs to be manually patched. In high security corporate environments, just keeping things patched is always a huge task so it's very hard to convince someone that they need to put in more work to keep an extra piece of software patched (which is already very difficult considering how frequently browsers are updated). To make things even worse, just about all vendors will only support Chromium-based browsers for whatever SaaS they sell you, so Firefox is a nonstarter for getting support, even if it will work just fine 99.9% of the time.

For all these reasons, I lost the battle to keep Firefox around, which is a huge shame because of how much I love it and wanted to fight the Chromium monoculture. So I guess for a corporation to support Firefox despite how corporate-friendliness the alternatives are, they'd have to reaaaally want to.

You can see the relevant JSON code in the changelog. As I said, you can post a comment on this page to remind Mike to update the documentation for policy templates.

This GitHub repository has a Discussions tab where you can ask questions about deploying Firefox: Policy Templates for Firefox.

Check out the official documentation here: Policy Templates for Firefox. You can use the Discussions tab if you have any questions.

A self-signed certificate was generated and used by Proxmox which will always generate a warning on the browser. I did not like seeing this when trying to work on my home lab. So, I started looking for ways to put a valid SSL certificate in Proxmox. During my research, I found that Proxmox could be made to integrate with acme.sh; a free SSL certificate generator powered by ACME(Let's Encrypt).

Next, we will install acme.sh, a command-line tool for managing SSL/TLS certificates. I prefer acme.sh over certbot, as it does not depend on the OS version. For more details about acme.sh, check its GitHub repo here.

A very relevant question. Acme.sh, a similar shell script ACME client, had a remote code execution problem last year.

https://github.com/acmesh-official/acme.sh/issues/4668

As a result, any certificates issued (or renewed) after Feb 8th will not work on older Android devices (< 7.1.1), unless the ACME client has been configure to request an alternate certificate chain. The "alternate chain" workaround will also stop working on June 6th.

I need to support these older Android devices so I am looking for alternatives. I have seen ZeroSSL mentioned a few times; it is also the default CA for acme.sh (the ACME client I am using nowadays) [2]. They have a number of paid plans but ACME certificates are free [3].

I'll be testing this over the next few days, but I would also like to ask if people here have experience with ZeroSSL (good or bad :-). Any feedback would be helpful.

[1]: https://letsencrypt.org/2023/07/10/cross-sign-expiration.html

[2]: https://github.com/acmesh-official/acme.sh

[3]: https://zerossl.com/documentation/acme/

Huh, the environment variable thing was specifically aimed at acme.sh which rather arbitrarily changed the config value from ACMEDNS_UPDATE_URL to ACMEDNS_BASE_URL, never acknowledged this in a changelog and then silently failed after an automatic upgrade as recommended by the default install:

https://github.com/acmesh-official/acme.sh/commit/2ce145f359...

It's also cleared out my .account.conf files when run on the suggested cron.

I've started using updown which also monitors my TLS certs simply because I no longer trust the process to work as documented.

It depends on your provider though. I can tell from experience that with OVH and their API, it's been easy to set up the automatic renewal via DNS verification. Apparently, the official client has support for the DNS API of 159 providers: https://github.com/acmesh-official/acme.sh/wiki/dnsapi

For the few people here that happen to run a self-hosted email server with acme.sh for TLS key/cert generation and Cloudflare for DNS management, I have made a tool that i personally use to get a perfect 100% score on Internet.nl's email test.

All of this is to say it's a decent amount of work to save the hassle of deploying certbot or acme.sh on the remote machines, pick your poison.

Here is a really solid guide for setting up the ACME DNS challenge with pretty much any DNS provider

People wonder why I like using the shell-based ACME client like dehydrated (or acme.sh):

* https://packages.debian.org/search?keywords=dehydrated

* https://github.com/acmesh-official/acme.sh

Versus the official client certbot:

* https://packages.debian.org/search?keywords=python3-certbot

A kludgy as very long shell scripts are (thought to be), I have a better chance of being able to go through all the code and understand it than a dozen(+) Python libraries.