MFC r365756: certctl: fix unprivileged mode

The first issue was lack of quoting around INSTALLFLAGS, which set it
incorrectly and produced an error on -M.

The second issue was that we weren't actually doing the install in
unprivileged mode, making it effectively useless. This was designed to pass
through the proper metalog/unpriv flags to install(1), so just let it
happen.

MFC r365500: certctl: fix hashed link generation with duplicate subjects

Currently, certctl rehash will just keep clobbering .0 rather than
incrementing the suffix upon encountering a duplicate. Do this, and do it
for blacklisted certs as well.

This also improves the situation with the blacklist to be a little less
flakey, comparing cert fingerprints for all certs with a matching subject
hash in the blacklist to determine if the cert we're looking at can be
installed.

Future work needs to completely revamp the blacklist to align more with how
it's described in PR 246614. In particular, /etc/ssl/blacklisted should go
away to avoid potential confusion -- OpenSSL will not read it, it's
basically certctl internal.

PR: 246614

MFC r361397, r361655, r361683: certctl(8) unprivileged & HISTORY correction

r361397:
Add an unprivileged mode where calls to install are passed appropriate
flags. For ease of integration, use the same flags as install:

-U unprivileged mode
-D <destdir> Specify DESTDIR (overrides the environment)
-M <metalog> Full path to METALOG file

r361655:
certctl.8: Correct the HISTORY section.

certctl was merged to stable/12 after 12.1 was branched.

r361683:
certctl: fix test syntax

test doesn't understand &&, but it does understand -a.

PR: 246190

MFC r361022-r361023, r361148: certctl(8) fixes

r361022: certctl(8): don't completely nuke $CERTDESTDIR

It's been reported/noted that a well-timed `certctl rehash` will completely
obliterate $CERTDESTDIR, which may get used by ports or system
administrators. While we can't guarantee the certctl semantics when other
non-certctl-controlled bits live here, we should make some amount of effort
to play nice.

Pruning all existing links, which we'll subsequently rebuild as needed, is
sufficient for our needs. This can still be destructive, but it's perhaps
less likely to cause issues.

I also note that we should probably be pruning /etc/ssl/blacklisted upon
rehash as well.

r361023: certctl: follow-up to r361022, prune blacklist as well

Otherwise, removals from the blacklist may not get processed as they should.

While we're here, restructure these to not bother with mkdir(1) if we've
already tested them to exist.

r361148: certctl: don't fall over flat with relative DESTDIR

Up until now, all of our DESTDIR use has been with absolute paths. It turned
out that the cd in/out dance we do here breaks us down later on, as the
relative path no longer resolves.

Convert EXTENSIONS to an ERE that we'll use to grep ls -1 of the dir we're
inspecting, rather than cd'ing into it and globbing it up.

MFC r358091: certctl(8): switch to install(1) to fix DESTDIR support

"Oops" - ln(1) is fine and dandy, but when you're using DESTDIR...it's not-
the path will almost certainly be invalid once the root you've just
installed to is relocated, perhaps to /.

Switch to install(1) using `-l rs` to calculate the relative symlink between
the two, which should work just fine in all cases.

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

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

No objection from: secteam
Differential Revision: https://reviews.freebsd.org/D16857