From 7cadc4c918c207a574ea15bd1e3793d8a48b7beb Mon Sep 17 00:00:00 2001 From: Richard van der Hoff Date: Thu, 7 Feb 2019 19:29:20 +0000 Subject: cleanups --- docs/MSC1711_certificates_FAQ.md | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/docs/MSC1711_certificates_FAQ.md b/docs/MSC1711_certificates_FAQ.md index 579c5dffce..0a781d00e3 100644 --- a/docs/MSC1711_certificates_FAQ.md +++ b/docs/MSC1711_certificates_FAQ.md @@ -112,7 +112,7 @@ _matrix._tcp.example.com. IN SRV 10 5 8000 customer.example.net. In this situation, you have three choices for how to proceed: -#### Option 1: give Synapse (or a reverse-proxy) a certificate for your matrix domain +#### 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 @@ -123,8 +123,7 @@ doing one of the following: and `tls_private_key_path`, or: * Use Synapse's [ACME support](./ACME.md), and forward port 80 on the - `server_name` domain to your Synapse instance, or: - + `server_name` domain to your Synapse instance. ### Option 2: run Synapse behind a reverse proxy @@ -133,7 +132,6 @@ your domain, you can simply route all traffic through the reverse proxy by updating the SRV record appropriately (or removing it, if the proxy listens on 8448). - #### Option 3: add a .well-known file to delegate your matrix traffic This will allow you to keep Synapse on a separate domain, without having to -- cgit 1.4.1