Re: new certificate stuff
> Date: Sun, 3 Sep 2023 12:21:23 -0700 (PDT) > From: Paul Goyette > > If I migrate to this new world order (ie, I delete existing package > and clean out the /etc/openssl/certs directory), what happens to any > packages that currently depend on mozilla-rootcerts? Will they > somehow magically not need to install the mozilla-rootcerts package? Packages that merely depend on mozilla-rootcerts are unaffected. You don't need to delete mozilla-rootcerts. It can remain installed. The same applies to ca-certificates. After you delete /etc/openssl/certs and run postinstall: - Packages that look to /etc/openssl/certs for trust anchors will begin to see the base ones, not the mozilla-rootcerts package ones. - Packages that look to $LOCALBASE/share/mozilla-rootcerts for trust anchors will continue to see the mozilla-rootcerts package ones. We'll eventually fix most or all of the packages in the second group to stop looking to $LOCALBASE/share/mozilla-rootcerts and to instead look to /etc/openssl/certs on NetBSD, /etc/ssl/certs on FreeBSD, /etc/pki/whatever on Fedora, But that won't happen immediately -- not pkgsrc-2023Q3. (mozilla-rootcerts-openssl is a different story. Nothing should depend on this. I just fixed the one case in pkgsrc of such an incorrect dependency. The new postinstall item for certctl(8) should gracefully handle an existing mozilla-rootcerts-openssl install, though. If you want to let certctl(8) take over, you will have to deinstall mozilla-rootcerts-openssl.)
Re: new certificate stuff
I'm trying to make sure this will provide a seamless fresh install and upgrade path so that if you were already managing /etc/openssl/certs, it stays that way, but if you weren't, certctl(8) takes over and makes the Mozilla trust anchors available. And I'd like to get this into 10 ASAP. Sounds good. Just one last question: If I migrate to this new world order (ie, I delete existing package and clean out the /etc/openssl/certs directory), what happens to any packages that currently depend on mozilla-rootcerts? Will they somehow magically not need to install the mozilla-rootcerts package? ++--+--+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses:| | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com| | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | | & Network Engineer | | pgoyett...@gmail.com | ++--+--+
Re: new certificate stuff
> Date: Mon, 28 Aug 2023 10:41:32 +0200 > From: Manuel Bouyer > > Maybe postinstall should check the /etc/openssl/certs.conf existance, > and fail the 'fix opensslcerts' asking for it to be manually created; > as we do for e.g. uid/gid if some are missing ? I split it into two postinstall items: - opensslcertsconf: handles missing /etc/openssl/certs.conf, in case you neglect to apply etcupdate or equivalent to bring in new config files. If you appear to be managing /etc/openssl/certs manually already, this sets `manual' in certs.conf; otherwise it copies the default one from /usr/share/examples/certctl/certs.conf. - opensslcertsrehash: handles regenerating the /etc/openssl/certs cache from config. I also added a check operation so that this complains if and only if `certctl rehash' would create something different from what is currently in /etc/openssl/certs (or if it doesn't seem to be managed by certctl(8), but /etc/openssl/certs.conf doesn't set `manual'). Please let me know if you have any trouble with upgrades! I'm trying to make sure this will provide a seamless fresh install and upgrade path so that if you were already managing /etc/openssl/certs, it stays that way, but if you weren't, certctl(8) takes over and makes the Mozilla trust anchors available. And I'd like to get this into 10 ASAP.
Re: new certificate stuff
Taylor R Campbell writes: > The critical part I had missed is that certctl can claim _either_ a > directory it has already claimed, _or_ an empty directory, so it works > for new installations and to update pristine but old installations. Sorry, I should have said that out loud; I was thinking that. > Let me know if any of this seems wrong, or if the implementation seems > to behave differently from what I described. Sounds good. > Regarding etcupdate: I agree that interactive prompting is bad for > deployment. I don't actually use etcupdate myself, partly because it > is too interactive but mainly because it can't do three-way merges -- > instead, I use a bespoke script called etcmerge that does three-way > merges using the old and new etc.tgz. > > https://mumble.net/cgit/campbell/etcmerge > > (Maybe some day I will propose to import this into base, but it needs > a lot more polish and testing first, and some tweaks to the usage > model which currently has too many things going on at once.) You may also wish to look at etcmanage, which has a concept of marking things manually maintained and handling all sorts of cases. But it does not merge. So some logical merge of all of these would be good. > But while I agree with your criticism of etcupdate, it's what we have > in base and what we recommend in the guide. So that's what we have to > work with as a baseline to gauge the impact of changes like this on > update procedures; it's hard to meaningfully gauge if I have to guess > everything that anyone might try to do. Yes, it's the standard approach, but there are a number of well-known update workflows. > That said, you're right that it's better not to create things that > rely on the interactive prompt. Thanks for adjusting; I think we're in a good place now.
Re: new certificate stuff
> Date: Mon, 28 Aug 2023 08:42:58 -0400 > From: Greg Troxel > > Taylor R Campbell writes: > > > How is using /etc/openssl/certs/.certctl as the token different from > > using /etc/openssl/certs.conf as the token? > > Because normal updates merge etc in various ways, and if certs.conf > comes along with that (because it is in etc.tgz) then that is automatic > and not an admin action. > > > How does this satisfy the two criteria I set down in the previous > > message? Repeating here: > > > > (a) new installations get /etc/openssl/certs populated out of the box, > > that dir is empty and certctl can write to it and set the sentinel. > There is no problem populating an empty dir because that's not removing > admin config. OK, thanks, that's a good idea and I implemented it. (I also fixed an embarrassing mistake where I had added certs.conf to base rather than to etc!) The critical part I had missed is that certctl can claim _either_ a directory it has already claimed, _or_ an empty directory, so it works for new installations and to update pristine but old installations. The way it works in HEAD is now: 1. New installations get /etc/openssl/certs populated out of the box. 2. On updates to existing installations that have _empty_ /etc/openssl/certs, postinstall will take charge of it and populate it like a new installation. 3. On updates to existing installations (whether from 9.x to 10.0, or from 10.0 to 10.1) that have _populated_ /etc/openssl/certs, postinstall will fail and ask you to either set `manual' in /etc/openssl/certs.conf or move /etc/openssl/certs out of the way. This applies to anyone who is currently using mozilla-rootcerts, mozilla-rootcerts-openssl, or ca-certificates from pkgsrc, or anyone who has, like bouyer@, added any custom entries by hand. This will also apply to anyone who had updated to current and run postinstall in the time between 2023-08-26 and now, even if they hadn't otherwise populated /etc/openssl/certs, so I put a note in UPDATING about it. (Exception: If for some reason you had created the file /etc/openssl/certs/.certctl already, postinstall will quietly blow away your /etc/openssl/certs directory, of course.) 4. If you set `manual' in /etc/openssl/certs.conf, postinstall may print a message but will not touch /etc/openssl/certs and will not fail. Let me know if any of this seems wrong, or if the implementation seems to behave differently from what I described. I added automatic tests for the various cases of certctl, and I manually tested postinstall with: (a) nonexistent /etc/openssl/certs (create and populate) (b) empty /etc/openssl/certs (populate) (c) nonempty /etc/openssl/certs (fail) (c) nonempty /etc/openssl/certs + manual (leave alone and pass) (d) /etc/openssl/certs with .certctl (delete and recreate) Regarding etcupdate: I agree that interactive prompting is bad for deployment. I don't actually use etcupdate myself, partly because it is too interactive but mainly because it can't do three-way merges -- instead, I use a bespoke script called etcmerge that does three-way merges using the old and new etc.tgz. https://mumble.net/cgit/campbell/etcmerge (Maybe some day I will propose to import this into base, but it needs a lot more polish and testing first, and some tweaks to the usage model which currently has too many things going on at once.) But while I agree with your criticism of etcupdate, it's what we have in base and what we recommend in the guide. So that's what we have to work with as a baseline to gauge the impact of changes like this on update procedures; it's hard to meaningfully gauge if I have to guess everything that anyone might try to do. That said, you're right that it's better not to create things that rely on the interactive prompt.
Re: new certificate stuff
What about certctl.conf in the etc set defaulting to "manual" and sysinst (optionally?) changing it to automatic mode? Of course, then, updating to -10 wouldn't give you automatic mode.
Re: new certificate stuff
The other alternative is to decide that we are going to do unsafe things and to put it super loudly in the release notes that any sysadmin-configured trust anchors will be blown away. Compared to pkgdb, I expect that most admins both have backups, and have such certs elsewhere, and recovery is not too hard. I do expect a lot of people to have trouble and to complain. Doing it this way would be a eparture from longstanding practice that is so ingrained that we haven't ever talked about whether it is policy.
Re: new certificate stuff
Taylor R Campbell writes: > How is using /etc/openssl/certs/.certctl as the token different from > using /etc/openssl/certs.conf as the token? Because normal updates merge etc in various ways, and if certs.conf comes along with that (because it is in etc.tgz) then that is automatic and not an admin action. > How does this satisfy the two criteria I set down in the previous > message? Repeating here: > > (a) new installations get /etc/openssl/certs populated out of the box, that dir is empty and certctl can write to it and set the sentinel. There is no problem populating an empty dir because that's not removing admin config. > and > > (b) on _future_ updates (like 10.0 to 10.1, where both releases have > certctl(8) and a default certs.conf), /etc/openssl/certs gets > updated too (unless you set `manual' in /etc/openssl/certs.conf). Once there is a sentinel file, certctl works like it does now. So I don't see the concern here. > Please be specific either about what mechanism you mean and how it > meets these criteria, or about scenarios that you think the current > mechanism will inadequately address. The current one fails to address an update where etc is merged (as it should be), causing certs.conf to exist, in the case where the admin has configured trust anchors. I also don't see how the situation of having mozilla-rootcerts-openssl installed is handled, and what happens when it is later de-installed. > The status quo in HEAD (if pulled up to netbsd-10) will be: > > 1. New installations get /etc/openssl/certs populated out of the box. > > 2. Updates to existing installations that follow the long-standing >procedure of > >- update kernel >- unpack non-etc sets >- run etcupdate >- run postinstall > >will interactively prompt during etcupdate to install the new >/etc/openssl/certs.conf. That is one longstanding procedure among many in that there are various flavors of etcupate and private scripts that do the same thing. It is not ok for upgrades to need to be interactive in many situations, and hence etcupdate cannot be the one true path. And, prompting to install a new config file, which happens all the time, is not the same as asking if it's ok to overwrite something. >The file has comments explaining what it does and how to override >it -- here's the current content: Sure, once it's looked at. With pkgdb, there was the idea that people might have to do things. But it was a disaster in practice for many. (I realize this is easier to recover from.) > 3. If: >- you have /etc/openssl/certs.conf from 10.0, >- you haven't set it to manual, >- there are changes to mozilla-certdata from 10.0 to 10.1, and >- you update to 10.1, >then those changes will be reflected in /etc/openssl/certs on >postinstall (but etcupdate won't prompt anything about certs.conf >-- unless something has also changed in that, of course). sure that's fine > If you follow a different procedure for update, like naively unpacking > etc sets or running a bespoke etcupdate replacement, well, you should > expect to have to deal with the fallout yourself. I don't think that is at all reasonable. Yes, unpacking etc.tgz into etc is nuts, but taking a file that exists in the new set and not in /etc and silently putting it in /etc is not dismissible as bespoke; it's the right thing to do and IMHO it's a bug that etcupdate prompts itstead of just doing it. This is based on experience using NetBSD in large scale testbeds where more machines than people can think about get updated to new builds frequuently; this "change file in /etc to match etc.tgz, as long as the file in /etc either doesn't exist and hasn't existed, or has the same bits as it did when it was last put there from an install or automated update" procedure works extremely well. It's been available in pkgsrc since 2006. And, I don't even think "etcupdate asks if it's ok to install some new file you don't necesssarily understand the consequence of" avoids this concern. We do not have a history of adding new config files via this path that then overwrite admin config. Maybe there's some other way for certctl to recognize things that it didn't add, without a sentinel file.
Re: new certificate stuff
Taylor R Campbell writes: > Currently, if /etc/openssl/certs.conf doesn't exist, `certctl rehash' > (the crux of `postinstall fix opensslcerts') will print an error > message and then exit with status 0. This combination is a bug -- > need to think a bit about it, but probably better to exit nonzero than > to suppress the error message. sure, that's fine. > So if you unpack new _non-etc_ sets, `postinstall fix' won't > clobber your /etc/openssl/certs directory. ok > The etc.tgz set, however, will have /etc/openssl/certs.conf. So if > you naively unpack etc.tgz, `postinstall fix' will clobber your > /etc/openssl/certs directory. What I do is unpack etc.tgz and xetc.tgz to /usr/netbsd-etc and then use etcmanage, which does automatic updates which are safe. However, safe is not turing complete; it is "this file has newly appeared in the new etc and does not exist in the real etc so copy it in". This happens all the time with new rc.d and things like that. > That said, I think if you use etcupdate(8), it will interactively > prompt you before creating the new /etc/openssl/certs.conf. (Have > made a note to add this in my etcmerge(8) tool to do a three-way merge > for updating (x)etc sets too.) etcmanage won't prompt. It has a different design philosophy, which is that it is run non-interactively to allow administering large numbers of computers. The initial impetus was a testbed of 20 and later 100. So it does what can be done safely and just doesn't do the rest, which works out remarkably well. ANd the prompt is not this is installing a config file that will cause later steps to overwrite manual configuration it's just there's a new config file you don't have; install it? > I'm open to other suggestions about how to handle the transition from > manually maintained /etc/openssl/certs on (say) 9.x with no certs.conf > or certctl(8) to 10.0 with new default certs.conf and certctl(8), > provided that > > (a) new installations get /etc/openssl/certs populated out of the box, > > and > > (b) on _future_ updates (like 10.0 to 10.1, where both releases have > certctl(8) and a default certs.conf), /etc/openssl/certs gets > updated too (unless you set `manual' in /etc/openssl/certs.conf). I think the only issue is a one-time transition from sysadmin controls contents of /etc/openssl/certs to certctl controls contents and I can't think of anything safe other than sentinel file in /etc/openssl/certs declares it certctl managed certctl will auto-write the sentinel if it's sure there are no manual contents certctl will rm/replace if sentinel present certctl -f will rm/replace and write sentinel This works for (a) and it works for (b), with postinstall fix because there is a sentinel file, and it will also work if certs.conf gets updated via etcupdate/etmanage/etcmerge/whatever-sysadmin-uses.
Re: new certificate stuff
> Date: Mon, 28 Aug 2023 06:30:05 -0400 > From: Greg Troxel > > Maybe this is too much, but perhaps certctl should look for a .certctl > in /etc/openssl/certs and only if present rm/replace. Or really only > limit the rm; adding to an empty dir is fine. Basically a token that > says the dir is under the control of certctl. -f can override the > check and write the token. How is using /etc/openssl/certs/.certctl as the token different from using /etc/openssl/certs.conf as the token? How does this satisfy the two criteria I set down in the previous message? Repeating here: (a) new installations get /etc/openssl/certs populated out of the box, and (b) on _future_ updates (like 10.0 to 10.1, where both releases have certctl(8) and a default certs.conf), /etc/openssl/certs gets updated too (unless you set `manual' in /etc/openssl/certs.conf). Please be specific either about what mechanism you mean and how it meets these criteria, or about scenarios that you think the current mechanism will inadequately address. The status quo in HEAD (if pulled up to netbsd-10) will be: 1. New installations get /etc/openssl/certs populated out of the box. 2. Updates to existing installations that follow the long-standing procedure of - update kernel - unpack non-etc sets - run etcupdate - run postinstall will interactively prompt during etcupdate to install the new /etc/openssl/certs.conf. The file has comments explaining what it does and how to override it -- here's the current content: netbsd-certctl 20230816 # $NetBSD: certs.conf,v 1.1 2023/08/26 05:27:15 riastradh Exp $ # # Configuration file for certctl(8) to manage HTTPS root CA # certificates in /etc/openssl/certs. # path/usr/share/certs/mozilla/server # For manual control over /etc/openssl/certs, e.g. if you want to # install a separate CA bundle from pkgsrc, uncomment the next line: #manual If the user declines to install /etc/openssl/certs.conf in etcupdate, then postinstall will print a message about failing to open it. (postinstall should also fail with nonzero exit code in this case -- bug to be fixed.) 3. If: - you have /etc/openssl/certs.conf from 10.0, - you haven't set it to manual, - there are changes to mozilla-certdata from 10.0 to 10.1, and - you update to 10.1, then those changes will be reflected in /etc/openssl/certs on postinstall (but etcupdate won't prompt anything about certs.conf -- unless something has also changed in that, of course). 4. If you _don't_ have /etc/openssl/certs.conf from 10.0 (you deleted it or you never let etcupdate create it), and you update to 10.1, then it's the same deal as (2). If you follow a different procedure for update, like naively unpacking etc sets or running a bespoke etcupdate replacement, well, you should expect to have to deal with the fallout yourself.
Re: new certificate stuff
Manuel Bouyer writes: >> The etc.tgz set, however, will have /etc/openssl/certs.conf. So if >> you naively unpack etc.tgz, `postinstall fix' will clobber your >> /etc/openssl/certs directory. > > As it will clobber others /etc/ files, so that's fine. Maybe this is too much, but perhaps certctl should look for a .certctl in /etc/openssl/certs and only if present rm/replace. Or really only limit the rm; adding to an empty dir is fine. Basically a token that says the dir is under the control of certctl. -f can override the check and write the token. I know this sounds like extra work, but the lesson I took from the pkgdb change is that things like that this are at least 10x harder than you think. Also people will have to uninstall mozilla-rootcerts-openssl.
Re: new certificate stuff
On Sun, Aug 27, 2023 at 10:53:58PM +, Taylor R Campbell wrote: > > Date: Sat, 26 Aug 2023 19:15:01 +0200 > > From: Manuel Bouyer > > > > On Sat, Aug 26, 2023 at 04:48:59PM +, Taylor R Campbell wrote: > > > [...] > > > If you currently use security/mozilla-rootcerts or > > > security/ca-certificates (or security/mozilla-rootcerts-openssl) to > > > populate /etc/openssl/certs, and you want to continue to use it, you > > > will have to put the line `manual' in /etc/openssl/certs.conf before > > > you next run postinstall(8). > > > > Will postinstall remove any certificate in /etc/openssl/certs/ > > if there is no certs.conf ? I have server certificates here, in addition > > to some local (private) CA roots. > > Currently, if /etc/openssl/certs.conf doesn't exist, `certctl rehash' > (the crux of `postinstall fix opensslcerts') will print an error > message and then exit with status 0. This combination is a bug -- > need to think a bit about it, but probably better to exit nonzero than > to suppress the error message. Yes, it's fine to error out in this case > > So if you unpack new _non-etc_ sets, `postinstall fix' won't > clobber your /etc/openssl/certs directory. > > The etc.tgz set, however, will have /etc/openssl/certs.conf. So if > you naively unpack etc.tgz, `postinstall fix' will clobber your > /etc/openssl/certs directory. As it will clobber others /etc/ files, so that's fine. > > That said, I think if you use etcupdate(8), it will interactively > prompt you before creating the new /etc/openssl/certs.conf. (Have > made a note to add this in my etcmerge(8) tool to do a three-way merge > for updating (x)etc sets too.) > > I'm open to other suggestions about how to handle the transition from > manually maintained /etc/openssl/certs on (say) 9.x with no certs.conf > or certctl(8) to 10.0 with new default certs.conf and certctl(8), > provided that > > (a) new installations get /etc/openssl/certs populated out of the box, > > and > > (b) on _future_ updates (like 10.0 to 10.1, where both releases have > certctl(8) and a default certs.conf), /etc/openssl/certs gets > updated too (unless you set `manual' in /etc/openssl/certs.conf). Maybe postinstall should check the /etc/openssl/certs.conf existance, and fail the 'fix opensslcerts' asking for it to be manually created; as we do for e.g. uid/gid if some are missing ? -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: new certificate stuff
On Sun, Aug 27, 2023 at 10:53:58PM +, Taylor R Campbell wrote: > Currently, if /etc/openssl/certs.conf doesn't exist, `certctl rehash' > (the crux of `postinstall fix opensslcerts') will print an error > message and then exit with status 0. This combination is a bug -- > need to think a bit about it, but probably better to exit nonzero than > to suppress the error message. Sounds good to me. Make the error message point at some docs and ask the user to - deinstall mozilla-rootcerts - manually copy /etc/openssl/certs.conf over or - add a manual certs.conf and keep using their old certificate setup. and then re-run postinstall. > So if you unpack new _non-etc_ sets, `postinstall fix' won't > clobber your /etc/openssl/certs directory. This is good. Martin
Re: new certificate stuff
> Date: Sat, 26 Aug 2023 19:15:01 +0200 > From: Manuel Bouyer > > On Sat, Aug 26, 2023 at 04:48:59PM +, Taylor R Campbell wrote: > > [...] > > If you currently use security/mozilla-rootcerts or > > security/ca-certificates (or security/mozilla-rootcerts-openssl) to > > populate /etc/openssl/certs, and you want to continue to use it, you > > will have to put the line `manual' in /etc/openssl/certs.conf before > > you next run postinstall(8). > > Will postinstall remove any certificate in /etc/openssl/certs/ > if there is no certs.conf ? I have server certificates here, in addition > to some local (private) CA roots. Currently, if /etc/openssl/certs.conf doesn't exist, `certctl rehash' (the crux of `postinstall fix opensslcerts') will print an error message and then exit with status 0. This combination is a bug -- need to think a bit about it, but probably better to exit nonzero than to suppress the error message. So if you unpack new _non-etc_ sets, `postinstall fix' won't clobber your /etc/openssl/certs directory. The etc.tgz set, however, will have /etc/openssl/certs.conf. So if you naively unpack etc.tgz, `postinstall fix' will clobber your /etc/openssl/certs directory. That said, I think if you use etcupdate(8), it will interactively prompt you before creating the new /etc/openssl/certs.conf. (Have made a note to add this in my etcmerge(8) tool to do a three-way merge for updating (x)etc sets too.) I'm open to other suggestions about how to handle the transition from manually maintained /etc/openssl/certs on (say) 9.x with no certs.conf or certctl(8) to 10.0 with new default certs.conf and certctl(8), provided that (a) new installations get /etc/openssl/certs populated out of the box, and (b) on _future_ updates (like 10.0 to 10.1, where both releases have certctl(8) and a default certs.conf), /etc/openssl/certs gets updated too (unless you set `manual' in /etc/openssl/certs.conf).
Re: new certificate stuff
On Sat, Aug 26, 2023 at 04:48:59PM +, Taylor R Campbell wrote: > [...] > If you currently use security/mozilla-rootcerts or > security/ca-certificates (or security/mozilla-rootcerts-openssl) to > populate /etc/openssl/certs, and you want to continue to use it, you > will have to put the line `manual' in /etc/openssl/certs.conf before > you next run postinstall(8). Will postinstall remove any certificate in /etc/openssl/certs/ if there is no certs.conf ? I have server certificates here, in addition to some local (private) CA roots. -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: new certificate stuff
> Date: Sat, 26 Aug 2023 08:20:50 -0700 (PDT) > From: Paul Goyette > > OK, I tried to read and understand the thread, but not really sure I > succeeded with the understanding part. (In fact, i'm pretty sure I > failed that part, miserably.) This is about enabling TLS clients -- like ftp(1), pkg_add(1), -- connecting to a server to verify that the server owns the name you used to connect to it, according to a directory of certification authorities (CAs) curated and shipped by Mozilla. This is specifically about managing /etc/openssl/certs, the place where applications using OpenSSL will look by default for trusted CA certificates (or `trust anchors'). > I've got a simple set-up here, running postfix and pine for Email, and > of course f-fox for browsing. I've never done anything (at least, not > deliberately) with certificates; reading and writing Email just works, > as does most browsing. > > Will I need to do anything new (or differently) as a result of these > recent changes? Probably not. - If pine is just reading a local mbox or maildir, or talking to an imap server at localhost, it won't be affected. - I don't think Postfix will do any TLS validation unless you ask it to explicitly with smtp_tls_* or smtpd_tls_* options or similar, which you presumably haven't done. - Firefox uses its own internal trust anchors and is not affected by /etc/openssl/certs. If you currently use security/mozilla-rootcerts or security/ca-certificates (or security/mozilla-rootcerts-openssl) to populate /etc/openssl/certs, and you want to continue to use it, you will have to put the line `manual' in /etc/openssl/certs.conf before you next run postinstall(8).
new certificate stuff
OK, I tried to read and understand the thread, but not really sure I succeeded with the understanding part. (In fact, i'm pretty sure I failed that part, miserably.) I've got a simple set-up here, running postfix and pine for Email, and of course f-fox for browsing. I've never done anything (at least, not deliberately) with certificates; reading and writing Email just works, as does most browsing. Will I need to do anything new (or differently) as a result of these recent changes? ++--+--+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses:| | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com| | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | | & Network Engineer | | pgoyett...@gmail.com | ++--+--+
