diff options
| author |  Daenney <daenney@users.noreply.github.com> | 2023-03-04 18:24:02 +0100 |
|---|---|---|
| committer |  GitHub <noreply@github.com> | 2023-03-04 17:24:02 +0000 |
| commit | d2f6de01856917b19e1f1ba6028f7e05d60e674b (patch) | |
| tree | a8dd7a0718f67dc7248a5e2c9c98db20a6fb2741 /CONTRIBUTING.md | |
| parent | use updateattachment when updating to ensure cache is invalidated (#1587) (diff) | |
| download | gotosocial-d2f6de01856917b19e1f1ba6028f7e05d60e674b.tar.xz | |
[feature] Allow loading TLS certs from disk (#1586)
Currently, GtS only supports using the built-in LE client directly for
TLS. However, admins may still want to use GtS directly (so without a
reverse proxy) but with certificates provided through some other
mechanism. They may have some centralised way of provisioning these
things themselves, or simply prefer to use LE but with a different
challenge like DNS-01 which is not supported by autocert.
This adds support for loading a public/private keypair from disk instead
of using LE and reconfigures the server to use a TLS listener if we
succeed in doing so.
Additionally, being able to load TLS keypair from disk opens up the path
to using a custom CA for testing purposes avoinding the need for a
constellation of containers and something like Pebble or Step CA to
provide LE APIs.
Diffstat (limited to 'CONTRIBUTING.md')
| -rw-r--r-- | CONTRIBUTING.md | 15 |
1 files changed, 15 insertions, 0 deletions
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 02e9f60e8..c24e81221 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -29,6 +29,7 @@ These contribution guidelines were adapted from / inspired by those of Gitea (ht - [SQLite](#sqlite) - [Postgres](#postgres) - [CLI Tests](#cli-tests) + - [Federation](#federation) - [Updating Swagger docs](#updating-swagger-docs) - [CI/CD configuration](#cicd-configuration) - [Release Checklist](#release-checklist) @@ -418,6 +419,20 @@ In [./test/envparsing.sh](./test/envparsing.sh) there's a test for making sure t Although this test *is* part of the CI/CD testing process, you probably won't need to worry too much about running it yourself. That is, unless you're messing about with code inside the `main` package in `cmd/gotosocial`, or inside the `config` package in `internal/config`. +#### Federation + +By using the support for loading TLS files from disk it is possible to have two local instances with TLS to allow for (manually) testing federation. + +You'll need to set the following configuration options: +* `GTS_TLS_CERTIFICATE_CHAIN`: poiting to a PEM-encoded certificate chain including the public certificate +* `GTS_TLS_CERTIFICATE_KEY`: pointing to a PEM-encoded private key + +Additionally, for the Go HTTP client to recognise certificates issued by a custom CA as valid, you'll need to set one of: +* `SSL_CERT_FILE`: pointing to the public key of your custom CA +* `SSL_CERT_DIR`: a `:`-separated list of directories to load CA certificates from + +You'll additionally need functioning DNS for your two instance names which you can achieve through entries in `/etc/hosts` or by running a local DNS server like [dnsmasq](https://thekelleys.org.uk/dnsmasq/doc.html). + ### Updating Swagger docs GoToSocial uses [go-swagger](https://goswagger.io) to generate Swagger API documentation from code annotations. |