Closed aral closed 1 year ago
Have you tried using /usr/local/lib/mozilla
? Sometimes software does not mention it but still supports it.
According to https://github.com/mozilla/policy-templates/blob/master/README.md#certificates--install you can use ~/.mozilla/certificates
.
@tcitworld Thanks, Thomas. I’m going to give that another shot now and I’ll update the issue based on what I find. (My initial tests before lunch didn’t work but I didn’t have much time to dig deeper.)
OK, after a bit of fiddling, here’s how you do it:
~/.mozilla/certificates
(e.g., my-ca.pem
)/etc/firefox/policies
policy.json
file like the following to /etc/firefox/policies
:{
"policies": {
"Certificates": {
"Install": ["~/.mozilla/certificates/my-ca.pem"]
}
}
}
Thank you for pointing me in the right direction and here’s hoping this’ll help anyone else who might come across the same issue.
Since there’s a working method, I’m closing this issue.
Per the page you reference, you can use a fully qualified path and put the certs anywhere.
Ideally, Mozilla shouldn’t make it so difficult to add custom certificate authorities. None of the other browsers do.
Can you provide more detail here? I can't find any information on adding CAs to Chrome on Linux except via manual methods, which Firefox supports.
@mkaply Ah, missed that. Good to know, thanks.
Re: Chrom(ium), I’ll have to look at it again. I thought it picked it up from the system store but I might be mistaken. I’m floating between three platforms right now, trying to write a mkcert alternative in pure JavaScript (without using certutil) all because browsers can’t pop-up a simple ”Looks like you’re doing web dev, would you like us to trust https://localhost? [Yes/No]” prompt :)
Update: Yep, they changed it starting in 105. FFS! *sigh* *starts looking for ways to make it work in Chrom(ium)*
Update 2: Just tested it and Chromium does automatically pick up custom certificate authorities you’ve installed in your system trust store. This also matches what they state here (see end of article for quote from Google): https://www.entrust.com/blog/2020/11/how-the-changes-to-google-chromes-root-program-might-impact-your-enterprise-pki/
That's interesting. When we did the system store work, Linux didn't have a cert store that we knew of. I'll get a bug open to see if we can add support for this.
@mkaply Neat, thanks, Michael. That’ll be a chunk of code I can remove when that happens, which is always good :)
That's interesting. When we did the system store work, Linux didn't have a cert store that we knew of. I'll get a bug open to see if we can add support for this.
well, you might have fun. "Linux" doesn't exactly have a system trust store. Distributions implement it differently, with differing support for the different major SSL libraries.
I have an old blog post on this that's a bit of a cult classic - https://www.happyassassin.net/posts/2015/01/12/a-note-about-ssltls-trusted-certificate-stores-and-platforms/ . Things have changed a bit since then but, uh, not a lot.
The docs at https://docs.fedoraproject.org/en-US/quick-docs/using-shared-system-certificates/ explain how to use the Fedora/RH-y system trust store. That should work on Fedora, RHEL and derivatives (including Silverblue, right now - I can't think why it shouldn't, so I don't think Silverblue has anything to fix here, unless you try that and it doesn't work). I think you can do broadly the same on Arch - ISTR that Arch adopted the Fedora/RHEL-y system, and https://wiki.archlinux.org/title/User:Grawity/Adding_a_trusted_CA_certificate suggests the same.
For Ubuntu (and I think Debian and other Debian derivatives), https://ubuntu.com/server/docs/security-trust-store should be correct.
Update: OK, so I was wrong (and the documentation may be wrong also).
On Fedora Silverblue 37 with bundled native Firefox 108.0:
about:policies#active
reporting The Enterprise Policies service is inactive.
and without a policies.json
file at /etc/firefox/policies
/etc/pki/ca-trust/source/anchors/
and the system trust store is updated using update-ca-trust extract
I see that Firefox imports the certificate authority automatically from the system trust store.
I’m not sure yet whether this is due to some Firefox configuration that Fedora ships with or if it behaves this way on other distributions also. I’m going to test with Ubuntu next and see what happens.
I do see that under Security Devices, the system trust store paths/p11-kit-proxy is listed.
Yes, Fedora's system Firefox is very definitely set up to work with the system trust store. (Of course, these days and particularly for Silverblue we should also consider folks installing Firefox from the upstream flatpak; I've no idea how that one is set up).
In Firefox version 64+, you can add your custom certificate authorities to Firefox using an enterprise policy file and by copying your certificates to
/usr/lib/mozilla/certificates
or/usr64/lib/mozilla/certficiates
.https://support.mozilla.org/en-US/kb/setting-certificate-authorities-firefox
Describe the bug
/usr/lib/mozilla
is read-only under Fedora Silverblue.So you cannot add certificates using the enterprise policy flow.
To Reproduce
Expected behavior
On non-mutable platforms, works.
OS version:
Additional context
This isn’t an issue Fedora Silverblue can fix by itself but it is a blocker for this use case on the platform so it’s one that I would urge the Fedora Silverblue (or Fedora/Red Hat/IBM) teams to take up with Mozilla to come up with a solution that works given that Fedora Silverblue is seen as the future of Fedora/Red Hat/etc.
(Ideally, Mozilla shouldn’t make it so difficult to add custom certificate authorities. None of the other browsers do.)