|
|
|
@@ -66,35 +66,6 @@ acme: |
|
|
|
# |
|
|
|
no_tls: {{ matrix_synapse_no_tls|to_json }} |
|
|
|
|
|
|
|
# List of allowed TLS fingerprints for this server to publish along |
|
|
|
# with the signing keys for this server. Other matrix servers that |
|
|
|
# make HTTPS requests to this server will check that the TLS |
|
|
|
# certificates returned by this server match one of the fingerprints. |
|
|
|
# |
|
|
|
# Synapse automatically adds the fingerprint of its own certificate |
|
|
|
# to the list. So if federation traffic is handled directly by synapse |
|
|
|
# then no modification to the list is required. |
|
|
|
# |
|
|
|
# If synapse is run behind a load balancer that handles the TLS then it |
|
|
|
# will be necessary to add the fingerprints of the certificates used by |
|
|
|
# the loadbalancers to this list if they are different to the one |
|
|
|
# synapse is using. |
|
|
|
# |
|
|
|
# Homeservers are permitted to cache the list of TLS fingerprints |
|
|
|
# returned in the key responses up to the "valid_until_ts" returned in |
|
|
|
# key. It may be necessary to publish the fingerprints of a new |
|
|
|
# certificate and wait until the "valid_until_ts" of the previous key |
|
|
|
# responses have passed before deploying it. |
|
|
|
# |
|
|
|
# You can calculate a fingerprint from a given TLS listener via: |
|
|
|
# openssl s_client -connect $host:$port < /dev/null 2> /dev/null | |
|
|
|
# openssl x509 -outform DER | openssl sha256 -binary | base64 | tr -d '=' |
|
|
|
# or by checking matrix.org/federationtester/api/report?server_name=$host |
|
|
|
# |
|
|
|
tls_fingerprints: [] |
|
|
|
# tls_fingerprints: [{"sha256": "<base64_encoded_sha256_fingerprint>"}] |
|
|
|
|
|
|
|
|
|
|
|
## Server ## |
|
|
|
|
|
|
|
# The domain name of the server, with optional explicit port. |
|
|
|
|