Implement TLS client authentication

[M1cha]

What is the purpose of this change? What does it change?

Add support for authenticating clients using a CA certificate.

Was the change discussed in an issue or in the forum before?

Closes #73

Checklist

• I have enabled maintainer edits for this PR
• I have added tests for all changes in this PR
• I have added documentation for the changes (in the manual)
• There's a new file in changelog/unreleased/ that describes the changes for our users (template here)
• I have run gofmt on the code in all commits
• All commit messages are formatted in the same style as the other commits in the repo
• I'm done, this Pull Request is ready for review

[MichaelEischer]

Shouldn't the rest-server also extract the username from the client certificate similar to #191? Or is the idea to only use the client certificate to allow access to the rest-server and then require an additional htpasswd verification (I'm not particularly sure how useful that is)?

[M1cha]

@MichaelEischer IMO, what you request should be optional. I use TLS with my own CA to prevent anyone inside my home network from using the rest server. I need neither htaccess nor TLS username verification though since I'm the only user.

[smiller255]

I tested this branch at 517d9cbcad3a52965f73d36fe0fd8cc61e8f1300 and it works just fine and as expected.

Notes:

• The added documentation states that the new option can be used with --tls-ca but the implemented option uses --tls-cacert
• To use client side tls for authentication without a htpasswd file it is currently required to start the server with the --no-auth flag, because without it the server complains about the missing htpasswd file. The --no-auth flag should actually disable both authentication options wile using --tls-cacert should work even if there is no htpasswd file.

@M1cha If you are still interested to work on this feature, I would offer to test this further and help with documentation or unit tests.

[M1cha]

I updated the PR from my personal fork.

@smiller255

* The added documentation states that the new option can be used with `--tls-ca` but the implemented option uses `--tls-cacert`

Good catch, fixed.

* To use client side tls for authentication without a htpasswd file it is currently required to start the server with the` --no-auth` flag, because without it the server complains about the missing htpasswd file. The` --no-auth` flag should actually disable both authentication options wile using `--tls-cacert` should work even if there is no htpasswd file.

That sounds reasonable. I didn't implement that in my push, yet though.

@M1cha If you are still interested to work on this feature, I would offer to test this further and help with documentation or unit tests.

I've been using the code in this PR for my main backup since I've opened the PR. Unfortunately it looks like the maintainers of rest-server are very inactive.

[JasonYao]

FWIW, this PR when rebased with git pull --rebase origin basically works as-is for enabling mTLS for rest-server, with an example at github.com/jasonyao/rest-server

For reference, I'm able to spin up rest-server with the command:

# Builds the server
CGO_ENABLED=0 go build -o rest-server ./cmd/rest-server

# (In separate terminal window 1) Manually running to test that this works as expected
# (Ctrl + C to stop the server)
rest-server \
  --path /foo/bar/path/to/repositories \
  --append-only \
  --private-repos \
  --prometheus \
  --listen ":10000" \
  --tls --tls-min-ver "1.3" \
  --tls-cacert /foo/bar/path/to/all_allowed_clients.combined.public.pem

Where the all_allowed_clients.combined.public.pem can be generated by cating all of the public .crt files together for each of the clients that you want

One note for anybody following, if your client cert is signed by a root or intermediate, you'll need to also include whatever root/intermediate cert that was used to sign the client as well, e.g.

cat intermediate.public.crt \
  client_a.public.crt \
  client_b_signed_by_intermediate.public.crt > all_allowed_clients.combined.public.pem

Note that from testing, you just need the immediate signing cert for your client- in this example, intermediate.public.crt was signed by a root.crt, but there wasn't a need to include that here to authenticate client_b