Synapse should not require TLS certificate files

[spantaleev]

Testing with 0.99rc4, it seems like:

• regardless of the no_tls setting's value (False or True), Synapse would still try to load tls_certificate_path or tls_private_key_path (I'm not sure which one now, but it does try to read it and fails with an exception if it's missing or not a valid file)

• the comment in homeserver.yaml about no_tls seems backward ("Setting no_tls to False will do so (and avoid the need to give synapse a TLS private key).") I guess this should say True, rather than False

---

I wish to use Synapse with a reverse-proxy and this issue is a blocker for that. I'd rather not provide any certificate files to Synapse at all.

Now, looking at #2840, unless something changed, it seems like Synapse may really need to access the certificate file.

This leads to all sorts of pain, especially when automated renewal is involved.
Not only do we need to renew the certificate and reload the reverse-proxy (no downtime there), but we also need to restart Synapse at the same time (reloading doesn't seem possible as explained in #1180).

[richvdh]

this is a thing we should fix before 1.0

[spantaleev]

Is it just a problem of wishing to read some file, or does it actually use it for something?

If this is to be fixed for 1.0 (and not 0.99), how should we do the 0.99 transition? By supplying any certificate file (self-signed even) just to prevent parsing from breaking.. or by supplying a proper working certificate (the actual one used for reverse-proxying)?

[richvdh]

Is it just a problem of wishing to read some file, or does it actually use it for something?

It exposes it in a field in the s2s api which is no longer used.

If this is to be fixed for 1.0 (and not 0.99), how should we do the 0.99 transition?

Bear in mind that there is no need to change anything to use 0.99.

By supplying any certificate file (self-signed even) just to prevent parsing from breaking.. or by supplying a proper working certificate (the actual one used for reverse-proxying)?

any certificate should do

[spantaleev]

I'm trying to prepare matrix-docker-ansible-deploy for 0.99 (and 1.0).

Existing installations (that run from before v0.99) do have a self-signed certificate which can be left in place, so there's no need to do anything.

On the other hand, new installations would not have a self-signed certificate generated in /data, because 0.99's generate command doesn't do that anymore. So I do need to do something sensible in that case -- either make the playbook generate a self-signed certificate just so we can make 0.99 happy.. or pass along the real certificate into the container.

Thank you for your answers!

I now know that both solutions are feasible.
They do have pros and cons, so I'll figure out which one to choose, so we can migrate people over to Synapse 0.99.

[hawkowl]

I think that this still needs to be exposed for pre-0.99 Synapses, which will verify the TLS fingerprint? But for 1.0, it can def. be removed.

[richvdh]

meh. pre-0.99 Synapses will only check it when fetching the server keys, which is normally delegated via matrix.org, which is on 0.99, so doesn't care. We might as well make it optional for now.

[spantaleev]

I was about to generate a temporary self-signed certificate to make Synapse v0.99 happy, but it looks like once #4566 lands in 0.99rc5 (or 0.99 final), I'll be able to keep things simpler and use tls_certificate_path: /conf/dummy.tls.crt without doing anything extra.

Thanks!

[Joshndroid]

This seems to be the issue i was having when trying to set up a fresh server. the server would not begin to listen on the ports (unable to see python when running netstat) checking further it seems it was not able to find the tls and would error out. I tried changing the true to a false but that didn't seem to help me. Luckily i had a backup of my hyper-v instance i could restore.

Then when upgrading the previous instance I see that it tried to overwrite my homeserver.yaml with all the new tls changes, etc. At this time i kept mine, but i'm assuming this will be a requirement to be merged with my local homeserver.yaml in the future (ie v1) when it no longer breaks the server?

[richvdh]

fixed in #4618