The generated server certificate in Complement images has no Subject Alternative Name

[dkasak]

Description

When constructing a Complement Docker image for Synapse, we generate a server certificate which contains only a Common Name but no Subject Alternative Name (SAN). Dendrite doesn't like this, so refuses to communicate with such a Synapse.

I encountered this problem because I'm fiddling with trying to extend Complement to support spinning up federations composed of multiple different HS implementations. Synapse <-> Synapse and Dendrite <-> Dendrite work fine, but Synapse <-> Dendrite configurations currently fail to communicate due to this.

So to solve this, we need to include a SAN in there. Generating a certificate with SAN using openssl is a bit fiddly but doable, though it looks to be impossible to achieve using just the command-line arguments, so we'd need to bundle an openssl config file. Another option would be to generate the server certificate using something other than the openssl utility, e.g. using Python's cryptography package.

[richvdh]

Generating a certificate with SAN using openssl is a bit fiddly but doable,

You just have to generate a config file like this:

.include /etc/ssl/openssl.cnf

[SAN]
subjectAltName=DNS:<domain>

which is, as you say, fiddly, but very much doable.

It might be worth noting that the worker-mode complement image uses Caddy to generate the TLS cert. That solution feels overengineered to me, but perhaps I have Stockholm syndrome with the openssl cmdline.

[richvdh]

It might be worth noting that the worker-mode complement image uses Caddy to generate the TLS cert. That solution feels overengineered to me, but perhaps I have Stockholm syndrome with the openssl cmdline.

this is no longer true as of #12818 🎉