Re: [PATCH] HTTPS/TLS CA certificates in base

[Taylor R Campbell <riastradh%NetBSD.org@localhost>]

> Date: Sun, 20 Aug 2023 10:38:01 -0400
> From: Greg Troxel <gdt%lexort.com@localhost>
> 
> I'd like to see three things handled (which might be already):
> 
> 1)
> 
>   a way for a user to install a CA cert (as a trust anchor -- I think it
>   would be good for docs to use pkix terminology) that is not part of
>   the mozilla root set, such that as updates/etc. happen, the trust
>   anchor set remains
>     union of
>       user-configured
>       mozilla set, if opted into, minus those excluded
> 
> This is just code and I don't care if the user has to put the cert in
> /etc/openssl/manual-trust-anchors or someplace like that to be available
> for unioning, which would make certctl be able to just write /certs.
> I am guessing your patch already handles this somehow, but I wanted to
> comment quickly before reading this since I have ranted so much.

This is exactly what you get if you populate a directory
/usr/local/mycerts with the .pem certificates you want and then add
the line

path /usr/local/mycerts

to /etc/openssl/certs.conf, alongside the line

path /usr/share/certs/mozilla/server

which is already in it.

The only restriction is that the base names must be distinct across
all the paths specified.

> 2) On installation, either
> 
>   a yes/no question "do you want to configure the Mozilla root
>   certificate set as trusted"?

I understand the sentiment, but our installer is already a nightmare
of impenetrable questions, trapping you into making obscure technical
decisions on the spot whose consequences are not obvious and it's
unclear whether you can change your mind later or how.

We need to reduce these questions in sysinst, not add more questions
especially when they have obviously sensible default answers which
most users don't even know to contemplate changing.  (`What the heck
is a BIOS disk geometry?')

The rare users who know they want custom trust anchors will know to
look for how to change them, or build custom images with custom
certs.conf.  We don't need to impose a prompt on everyone just to
satisfy those users.

> or
> 
>   a "trust mozilla root certificate set" as a yes/no option in
>   configuration where you turn on sshd/ntpd, and I don't really care how
>   it defaults.

An unobtrusive optional item in the sysinst utility and/or config menu
would be fine by me, along with a note in afterboot(8).  (I feel like
the config menu ought to have a reference to afterboot(8) so you know
how to go back and reconsider the config later.)  But I don't think
the initial commit needs to block on this.

> 3) If a user wants to configure (as an example)
>    The US DOD root (a "real CA" not in the mozilla set)
>    a personal CA that they created
>    Let's Encrypt, and 8 other specific CAs from mozilla
>    
> then that should be supported somehow in the certctl config file.  I
> suspect you've enabled that, and it's just omitting the "use the mozilla
> set" and adding lines for "use this" and "use that".

Create a directory of .pem files or symlinks to them and put it in a
`path' line instead of `path /usr/share/certs/mozilla/server' in
certs.conf.

Or, create three directories and add three `path' lines.

> A) I think it's fine to only have "postinstall fix" run certctl in the
> DESTDIR=/ case and not at all urgent to address.   This is sort of like
> how we do'n build locate/man db etc. in images but only on real systems.
> 
> (Alternatively we could run certctl rehash at boot if certctl=YES,
> default YES and skip it from postinstall.  I have not thought through
> pros and cons.)

I considered that, but postinstall(8) is better because it doesn't add
more reasons that /etc must be writable at boot-time.

That said, we can change the mechanism afterward if we decide there's
a better way.

> B) There is talk of enforcing validation, but we already enforce
> validation with an empty list.  I think the only change is installing a
> bunch of CAs as trust anchors (in a manageable way), and there is no
> change to validation.  If I'm confused on this point please tell me.

The patch I attached only adds the certificates, certctl(8), and
automatic tests.  It does not change whether any applications use
/etc/openssl/certs or require validation.

Currently, as of February, ftp(1) has validation enabled by default,
with a default-off option `sslnoverify' to disable validation.  That
means it just doesn't work out of the box right now on real-world web
sites.

I don't know offhand whether pkg_add(1) has validation enabled or
disabled by default, but we should enable it after this goes in.
(That's aside from signing packages, which we should also do, but my
plan for that is not ready yet.)

> C) The openssl nomenclature /etc/openssl/certs is confusing because it
> blurs what is a certificate and what certificates are trust anchors; it
> really (I think) means the latters.  I realize that few understand this
> naming distinction, but a CA cert is just a cert whose private key can
> sign other certs, and you may or may not care, unless it is a trust
> anchor or reachable from one.

I agree the nomenclature is confusing.

However, the path /etc/openssl/certs is baked into applications
already.  Changing it would require patching OpenSSL (again),
coordinating with pkgsrc, and dealing with who knows what other
existing applications.  And it's overridden in OpenSSL by the
SSL_CERT_DIR environment variable, which would presumably be even
riskier to rename.

So I'm not proposing to tug at that thread.  I'm only proposing to
populate the directory out of the box.