|
|
@@ -14,9 +14,9 @@ up and will work provided you set the ``server_name`` to match your
|
|
|
machine's public DNS hostname, and provide Synapse with a TLS certificate
|
|
|
which is valid for your ``server_name``.
|
|
|
|
|
|
-Once you have completed the steps necessary to federate, you should be able to
|
|
|
-join a room via federation. (A good place to start is ``#synapse:matrix.org`` - a
|
|
|
-room for Synapse admins.)
|
|
|
+Once federation has been configured, you should be able to join a room over
|
|
|
+federation. A good place to start is ``#synapse:matrix.org`` - a room for
|
|
|
+Synapse admins.
|
|
|
|
|
|
|
|
|
## Delegation
|
|
|
@@ -98,6 +98,77 @@ _matrix._tcp.<server_name>``. In our example, we would expect this:
|
|
|
Note that the target of a SRV record cannot be an alias (CNAME record): it has to point
|
|
|
directly to the server hosting the synapse instance.
|
|
|
|
|
|
+### Delegation FAQ
|
|
|
+#### When do I need a SRV record or .well-known URI?
|
|
|
+
|
|
|
+If your homeserver listens on the default federation port (8448), and your
|
|
|
+`server_name` points to the host that your homeserver runs on, you do not need an SRV
|
|
|
+record or `.well-known/matrix/server` URI.
|
|
|
+
|
|
|
+For instance, if you registered `example.com` and pointed its DNS A record at a
|
|
|
+fresh server, you could install Synapse on that host,
|
|
|
+giving it a `server_name` of `example.com`, and once [ACME](acme.md) support is enabled,
|
|
|
+it would automatically generate a valid TLS certificate for you via Let's Encrypt
|
|
|
+and no SRV record or .well-known URI would be needed.
|
|
|
+
|
|
|
+This is the common case, although you can add an SRV record or
|
|
|
+`.well-known/matrix/server` URI for completeness if you wish.
|
|
|
+
|
|
|
+**However**, if your server does not listen on port 8448, or if your `server_name`
|
|
|
+does not point to the host that your homeserver runs on, you will need to let
|
|
|
+other servers know how to find it. The way to do this is via .well-known or an
|
|
|
+SRV record.
|
|
|
+
|
|
|
+#### I have created a .well-known URI. Do I still need an SRV record?
|
|
|
+
|
|
|
+As of Synapse 0.99, Synapse will first check for the existence of a .well-known
|
|
|
+URI and follow any delegation it suggests. It will only then check for the
|
|
|
+existence of an SRV record.
|
|
|
+
|
|
|
+That means that the SRV record will often be redundant. However, you should
|
|
|
+remember that there may still be older versions of Synapse in the federation
|
|
|
+which do not understand .well-known URIs, so if you removed your SRV record
|
|
|
+you would no longer be able to federate with them.
|
|
|
+
|
|
|
+It is therefore best to leave the SRV record in place for now. Synapse 0.34 and
|
|
|
+earlier will follow the SRV record (and not care about the invalid
|
|
|
+certificate). Synapse 0.99 and later will follow the .well-known URI, with the
|
|
|
+correct certificate chain.
|
|
|
+
|
|
|
+#### Can I manage my own certificates rather than having Synapse renew certificates itself?
|
|
|
+
|
|
|
+Yes, you are welcome to manage your certificates yourself. Synapse will only
|
|
|
+attempt to obtain certificates from Let's Encrypt if you configure it to do
|
|
|
+so.The only requirement is that there is a valid TLS cert present for
|
|
|
+federation end points.
|
|
|
+
|
|
|
+#### Do you still recommend against using a reverse proxy on the federation port?
|
|
|
+
|
|
|
+We no longer actively recommend against using a reverse proxy. Many admins will
|
|
|
+find it easier to direct federation traffic to a reverse proxy and manage their
|
|
|
+own TLS certificates, and this is a supported configuration.
|
|
|
+
|
|
|
+See [reverse_proxy.rst](reverse_proxy.rst) for information on setting up a
|
|
|
+reverse proxy.
|
|
|
+
|
|
|
+#### Do I still need to give my TLS certificates to Synapse if I am using a reverse proxy?
|
|
|
+
|
|
|
+Practically speaking, this is no longer necessary.
|
|
|
+
|
|
|
+If you are using a reverse proxy for all of your TLS traffic, then you can set
|
|
|
+`no_tls: True` in the Synapse config. In that case, the only reason Synapse
|
|
|
+needs the certificate is to populate a legacy `tls_fingerprints` field in the
|
|
|
+federation API. This is ignored by Synapse 0.99.0 and later, and the only time
|
|
|
+pre-0.99 Synapses will check it is when attempting to fetch the server keys -
|
|
|
+and generally this is delegated via `matrix.org`, which will be running a modern
|
|
|
+version of Synapse.
|
|
|
+
|
|
|
+#### Do I need the same certificate for the client and federation port?
|
|
|
+
|
|
|
+No. There is nothing stopping you from using different certificates,
|
|
|
+particularly if you are using a reverse proxy. However, Synapse will use the
|
|
|
+same certificate on any ports where TLS is configured.
|
|
|
+
|
|
|
## Troubleshooting
|
|
|
|
|
|
You can use the [federation tester](
|
Neil Johnson