caroot: cumulative cert update

This adds a note in all existing certs that they are explicitly trusted
for server auth, and also:

- Seven (7) added
- Nineteen (19) removed

(cherry picked from commit 446169e0b6f04b96960540784539c218f5a14c86)
(cherry picked from commit 3016c5c2bf68d8c6ebf303939f20092478e7a4ca)
(cherry picked from commit fac832b27105d926d9f8728d7147adb547b937d8)
(cherry picked from commit 76461921dac18b300489e326ba3df61d2809f364)

Git Hash: de140815c9a583e8eb702b39cd8f57ca81a05e3f
Git Author: kevans@FreeBSD.org

caroot: update CA bundle processor

Our current processor was identified as trusting cert not explicitly
marked for SERVER_AUTH, as well as certs that were tagged with
DISTRUST_AFTER.

Update the script to handle both scenarios. This patch was originally
authored by mandree@ for ports, and it was subsequently ported to base
caroot.

(cherry picked from commit c3510c941c0dddd09389915a9395e6f059088bab)

Git Hash: a12641eaecc3dab730b27149b7d48fb0a86d38c7
Git Author: kevans@FreeBSD.org

MFC r368555: caroot: update bundle

Summary:
- One (1) added
- Ten (10) removed

Unrevert r364793: revert r364792: caroot: switch to using echo+shell glob

This was reverted because the directory is empty and stable/11 FILES
infrastructure doesn't handle that very well. Neither directory is empty
anymore, so this is OBE.

MFC r365896: caroot: update base store

Count:
- Two (2) removed
- Three (3) added

MFC r365248: caroot: properly remove old distrusted roots

The proper procedure was not followed in r364943; all of these that were
deleted should have instead been moved over to the blacklist so that certctl
can DTRT.

Users must still `certctl rehash` after this, but this should generally be
done by one of mergemaster/etcupdate/freebsd-update/pkgbase already; note
that freebsd-update doesn't come into play for this particular update, as
these have not yet made it into a release.

Future work (after svn -> git) will likely change the script that updatecert
invokes to facilitate the process, rather than trusting that kevans or
whomever updates in the future will remember.

MFC r364943: carrot: update bundle

Stats:
- Seven (7) removed
- Four (4) added

Partial revert of r364792: caroot: switch to using echo+shell glob

On stable/11, I mistakenly only tested installation of trusted certs.
When the dir is empty, the glob remains unexpanded when it gets added to
FILES.

On stable/11 (but not 12 or head), this ends up being erroneous; it kind of
looks like the glob is being expanded to a single-word empty string rather
than leaving us with an empty FILES. Regardless, this isn't worth fixing on
stable/11, so back it out.

MFC r364600: caroot: switch to using echo+shell glob to enumerate certs

This solves an issue on stable/12 that causes certs to not get installed.
ls is apparently not in PATH during installworld, so TRUSTED_CERTS ends up
blank and nothing gets installed. We don't really require anything
ls-specific, though, so let's just simplify it.

MFC r353095, r355376: add root bundle

r353095:
caroot: commit initial bundle

Interested users can blacklist any/all of these with certctl(8), examples:

- mv /usr/share/certs/trusted/... /usr/share/certs/blacklisted/...; \
certctl rehash
- certctl blacklist /usr/share/certs/trusted/*; \
certctl rehash

Certs can be easily examined after installation with `certctl list`, and
certctl blacklist will accept the hashed filename as output by list or as
seen in /etc/ssl/certs

r355376:
caroot update to latest tip: one (1) addition, none (0) removed

Added:
- Entrust Root Certification Authority - G4

Relnotes: yes, please

MFC r357193: caroot: blacklisted: automatically pick up *.pem in the tree

This kind of automagica got picked up in trusted/ prior to the initial
commit, but never got applied over in blacklisted. Ideally no one will be
using blacklisted/ to store arbitrary certs that they don't intend to
blacklist, so we should just install anything that's in here rather than
force consumer to first copy cert into place and then modify the file
listing in the Makefile.

Wise man once say: "it is better to restrict too much, than not enough.
sometimes."

MFC r357084: caroot: use bsd.obj.mk, not bsd.prog.mk

This directory stages certdata into .OBJDIR and processes it, but does not
actually build a prog-shaped object; bsd.obj.mk provides the minimal support
that we actually need, an .OBJDIR and descent into subdirs. This is
admittedly the nittiest of nits.

MFC r352948-r352951, r353002, r353066, r353070: caroot infrastructure

Infrastructure only -- no plans in place currently to commit any certs to
these branches.

r352948:
[1/3] Initial infrastructure for SSL root bundle in base

This setup will add the trusted certificates from the Mozilla NSS bundle
to base.

This commit includes:
- CAROOT option to opt out of installation of certs
- mtree amendments for final destinations
- infrastructure to fetch/update certs, along with instructions

A follow-up commit will add a certctl(8) utility to give the user control
over trust specifics. Another follow-up commit will actually commit the
initial result of updatecerts.

This work was done primarily by allanjude@, with minor contributions by
myself.

r352949:
[2/3] Add certctl(8)

This is a simple utility to hash all trusted on the system into
/etc/ssl/certs. It also allows the user to blacklist certificates they do
not trust.

This work was done primarily by allanjude@, with minor contributions by
myself.

r352950:
[3/3] etcupdate and mergemaster support for certctl

This commit add support for certctl in mergemaster and etcupdate. Both will
either rehash or prompt for rehash as new certificates are
trusted/blacklisted.

This work was done primarily by allanjude@, with minor contributions by
myself.

r352951:
caroot: add @generated tags to extracted .pem

As is the current trend; while these files are manually curated, they are
still generated. If they end up in a review, it would be helpful to also
take the hint and hide them.

r353002:
Unbreak etcupdate(8) and mergemaster(8) after r352950

r352950 introduced improper case fall-through for shell scripts. Fix it with
a pipe.

r353066:
certctl(8): realpath the file before creating the symlink

Otherwise we end up creating broken relative symlinks in
/etc/ssl/blacklisted.

r353070:
certctl(8): let one blacklist based on hashed filenames

It seems reasonable to allow, for instance:

$ certctl list
# reviews output -- ah, yeah, I don't trust that one
$ certctl blacklist ce5e74ef.0
$ certctl rehash

We can unambiguously determine what cert "ce5e74ef.0" refers to, and we've
described it to them in `certctl list` output -- I see little sense in
forcing another level of filesystem inspection to determien what cert file
this physically corresponds to.

Relnotes: yes

Merge OpenSSL 1.0.2u.

Merge OpenSSL 1.0.2t.

Merge OpenSSL 1.0.2s.

Approved by: re (kib)

Merge OpenSSL 1.0.2r.

Merge OpenSSL 1.0.2q.

MFC: r337791

Merge OpenSSL 1.0.2p.

MFC: r331627

Merge OpenSSL 1.0.2o.

MFC: r329024

Remove c_rehash(1) to not confuse users.

MFC: r326662

Merge OpenSSL 1.0.2n.