On Thu, Feb 13, 2020 at 08:21:27PM +0100, Wolfgang Schweer wrote: > On Wed, Feb 12, 2020 at 08:20:08PM +0100, Wolfgang Schweer wrote: > > On Wed, Feb 12, 2020 at 07:09:21PM +0000, Mike Gabriel wrote: > > > The simpleness of the fetch-ldap-cert version you propose is > > > tempting. But this version will only work against TJENERs that have > > > a Debian-Edu_rootCA.crt exported via www.intern. > > Considering... > > [Mike] > > > This assures that Debian-Edu_rootCA is available in the system-wide CA > > bundle in /etc/ssl/certs/ca-certificates.crt. > > > This issue relates to #926388 (let Firefox trust > > /etc/ssl/certs/ca-certificates.crt) > > ...let's me think, that this bug is only fixable for Debian Edu 10 and > higher anyway. Some more thoughts: My proposed script could be added as fetch-rootca-cert because that's what it's all about. The fetch-ldap-cert script would be kept in bullseye (and retired in bullseye+1 aka bookworm). fetch-rootca- could then go into buster-pu, I guess. Also, the firefox-esr policies file (already in the master branch) should be shipped for buster-pu. The policies file makes shure that FF-ESR shows the green padlock also in case a user changes the password using gosa-desktop (which is the recommended way to do that). It is actually quite bad to be warned about a certificate issue and an insecure connection just in this case. Reason for the gosa-desktop issue: On first call, a new FF profile is created on the fly. IMO the additional profile issue can't be solved with the p11-kit-trust.so method, which is now deprecated in favour of the pocicies one, see e.g.: https://wiki.mozilla.org/CA/AddRootToFirefox I've tested an appropiately updated d-e-config package both on a buster 10.3 main server and on a buster 10.3 roaming workstation (w/ your fixes present for that one). Works ok in both cases, green padlocks in all cases mentioned above. Wolfgang
Attachment:
signature.asc
Description: PGP signature