Set SNI to the server_name, not whatever was in the SRV record

[richvdh]

Fixes #3843

[WGH-]

Are you sure this's the right behaviour?

I think SRV records are more like MX records.

Just out of curiousity, I checked how subject and SANs of certificates for MX hosts relate to hostnames. It seems that certificats are never issued for main hostname, but rather for MX hostnames. For example, gmail.com:

$ host -t MX gmail.com
gmail.com mail is handled by 30 alt3.gmail-smtp-in.l.google.com.
gmail.com mail is handled by 40 alt4.gmail-smtp-in.l.google.com.
gmail.com mail is handled by 10 alt1.gmail-smtp-in.l.google.com.
gmail.com mail is handled by 5 gmail-smtp-in.l.google.com.
gmail.com mail is handled by 20 alt2.gmail-smtp-in.l.google.com.

and their certificates are issued for corresponding hostnames, not for the original gmail.com domain:

gmail-smtp-in.l.google.com.
 Subject: CN=mx.google.com,O=Google LLC,L=Mountain View,ST=California,C=US
 DNSNames:
  mx.google.com
  alt1.aspmx.l.google.com
  alt1.gmail-smtp-in.l.google.com
  alt1.gmr-smtp-in.l.google.com
  alt2.aspmx.l.google.com
  alt2.gmail-smtp-in.l.google.com
  alt2.gmr-smtp-in.l.google.com
  alt3.aspmx.l.google.com
  alt3.gmail-smtp-in.l.google.com
  alt3.gmr-smtp-in.l.google.com
  alt4.aspmx.l.google.com
  alt4.gmail-smtp-in.l.google.com
  alt4.gmr-smtp-in.l.google.com
  aspmx.l.google.com
  aspmx2.googlemail.com
  aspmx3.googlemail.com
  aspmx4.googlemail.com
  aspmx5.googlemail.com
  gmail-smtp-in.l.google.com
  gmr-mx.google.com
  gmr-smtp-in.l.google.com

Additionally, as a third-party domain owner, you won't be able to delegate mail handling to Google without having them a certificate for your main domain in possesion.

I checked a couple of other mail servers - namely, yandex.ru, mail.ru, yahoo.com, hotmail.com, wikipedia.org, xmpp.org, protonmail.com, aol.com - and only mail.ru has certificate for the main domain on its MX server (and even then a few alternative domains, like inbox.ru, still point to the same MX server, which doesn't have a certificate for them).

Here is the program I tested it with: https://gist.github.com/WGH-/d7f90fab9e2385f348aaba3bae4896a8

[WGH-]

XMPP servers, on the other hand, usually have certificates for the main (originating) domain.

[erikjohnston]

Note that this is discussed at length in MSC1708 and MSC1711.

[WGH-]

Thanks, having carefully read the discussion and the FAQ (https://github.com/matrix-org/synapse/blob/master/docs/MSC1711_certificates_FAQ.md), I came to conclusion that .well-known mechanism is superior to SRV records, and I should just forget about them.

[nemhods]

Running into a similar problem here. We're using Let's Encrypt with HTTP-01 challenge (through traefik), and in our case, example.com and matrix.example.com are on different IPs.

The server on matrix.example.com cannot fetch a valid Let's encrypt certificate using the HTTP-01 challenge, since example.com does not point to it's IP.

Probably going to move to .well-known too, however i really dislike the fact that this creates another dependency (if the webserver on example.com is down, no one will find my matrix server). DNS, and thus SRV records, would be distributed and less failure prone.