tech-userlevel archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

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



Taylor R Campbell <riastradh%NetBSD.org@localhost> writes:

> 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.

That's totally fine.

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

heh, but as long as the man page says that doesn't upset me.

>>   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.

initial commit seems fine, but I think it should be present before
pullup to 10.  However, I may be an extreme outlier.

>> 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.

Totally straightforward, thanks.

> 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.)

That make sense and I'm all for keeping separable things sepearate.

>> 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.

I did not mean to change directory names or code at all.

I meant that it would good if the documentation said, at least the first
time it appears "configure certificates as trust anchors" rather than
"install CA certificates".   Certainly we don't want to confuse normal
people who are used to sloppy wording, but somebody who has read pkix
should be able to tie our wording to the spec in a way that is not
confusing or ambiguous.

This wording problem is not new to your proposed change.  As an example
of exising wording, mozilla-rootcerts-openssl says:

  This package configures the Mozilla rootcerts bundle CAs as trust
  anchors in OpenSSL, so that programs using OpenSSL will be able to use
  them to validate SSL certificates.

which I intended to be accurate for those that understand and clear
enough for those that are fuzzy on "install certificates".



Home | Main Index | Thread Index | Old Index