From b66f149e6b30051821c51e7c86c54b32ca654bfb Mon Sep 17 00:00:00 2001 From: babolivier Date: Thu, 17 Jun 2021 17:57:10 +0000 Subject: deploy: 08c84693227de9571412fa18a7d82818a370c655 --- develop/MSC1711_certificates_FAQ.html | 32 ++++++-------------------------- 1 file changed, 6 insertions(+), 26 deletions(-) (limited to 'develop/MSC1711_certificates_FAQ.html') diff --git a/develop/MSC1711_certificates_FAQ.html b/develop/MSC1711_certificates_FAQ.html index 9750e816c5..6fa2436abd 100644 --- a/develop/MSC1711_certificates_FAQ.html +++ b/develop/MSC1711_certificates_FAQ.html @@ -274,15 +274,6 @@ valid certificate after this point will no longer be able to federate with

In this case, your server_name points to the host where your Synapse is running. There is no need to create a .well-known URI or an SRV record, but you will need to give Synapse a valid, signed, certificate.

-

The easiest way to do that is with Synapse's built-in ACME (Let's Encrypt) -support. Full details are in ACME.md but, in a nutshell:

-
    -
  1. Allow Synapse to listen on port 80 with authbind, or forward it from a -reverse proxy.
    2. -
  2. Enable acme support in homeserver.yaml.
    3. -
  3. Move your old certificates out of the way.
    4. -
  4. Restart Synapse.
    5. -

If you do have an SRV record currently

If you are using an SRV record, your matrix domain (server_name) may not point to the same host that your Synapse is running on (the 'target @@ -296,19 +287,9 @@ an SRV record which looks like:

In this situation, you have three choices for how to proceed:

Option 1: give Synapse a certificate for your matrix domain

Synapse 1.0 will expect your server to present a TLS certificate for your -server_name (example.com in the above example). You can achieve this by -doing one of the following:

- +server_name (example.com in the above example). You can achieve this by acquiring a +certificate for the server_name yourself (for example, using certbot), and giving it +and the key to Synapse via tls_certificate_path and tls_private_key_path.

Option 2: run Synapse behind a reverse proxy

If you have an existing reverse proxy set up with correct TLS certificates for your domain, you can simply route all traffic through the reverse proxy by @@ -327,10 +308,9 @@ with Synapse 0.34 and earlier.

  • Give Synapse a certificate corresponding to the target domain -(customer.example.net in the above example). You can either use Synapse's -built-in ACME support for this (via the domain parameter in -the acme section), or acquire a certificate yourself and give it to -Synapse via tls_certificate_path and tls_private_key_path.

    +(customer.example.net in the above example). You can do this by acquire a +certificate for the target domain and giving it to Synapse via tls_certificate_path +and tls_private_key_path.

  • Restart Synapse to ensure the new certificate is loaded.

    -- cgit 1.5.1