Sincronização da matriz por trás do proxy reverso gera erros de “impressão digital”

Question

Eu quero configurar uma instância de Sinapse por trás de um nginx para proxy reverso. Como o nginx é configurado com TLS para HTTPS, este post de blog um pouco desatualizado recomenda configurar a sinapse de matriz com o material TLS já usado no nginx vhost, já que este é o material TLS que outros servidores verão quando estiver falando com a minha instância.

Até agora eu consegui configurar o servidor para que ele seja executado por conta própria, e os usuários nesta instância podem conversar entre si. O principal problema é o servidor-2-servidor de comunicação, ou como o pessoal da matriz o chama de "federação".

Esta é a minha configuração de TLS na sinapse de matriz:

tls_certificate_path: "/var/lib/acme/live/matrix.simonszu.de/fullchain"

# PEM encoded private key for TLS
tls_private_key_path: "/etc/matrix-synapse/homeserver.tls.key"

# PEM dh parameters for ephemeral keys
tls_dh_params_path: "/etc/ssl/dhparams/matrix.simonszu.de_dhparams.pem"

# Don't bind to the https port
no_tls: True

O post acima menciona que você pode comentar completamente o tls_private_key_path , já que você definiu no_tls como True (já que todo material TLS é gerenciado pela instância nginx). Tenho notado que isso não funciona realmente, porque, nesse caso, a sinapse de matriz procurará um arquivo de chave em lugares obscuros. Não posso vincular o arquivo de chave associado ao certificado, porque o gerenciamento de chaves é feito pelo acmetool para obter certificados do Let's Encrypt e o processo de renovação automática falhará se qualquer outra permissão de arquivo do que o 0600 estiver definida como o arquivo de chave. Mas como o material do TLS é gerenciado pelo nginx de qualquer maneira, o synapse precisa desse certificado somente para a apresentação de impressão digital para outras instâncias de sinapse, e efetivamente ignora o key_path.

Eu me certifiquei de que essa instância de sinapse seja acessada por meio do navegador e que ela possa buscar as assinaturas manualmente. Mas, infelizmente, o aperto de mão inicial ao se comunicar com outras instâncias falha.

Eu tenho acesso a outro host com sua própria instância de sinapse (que não está atrás de um proxy reverso) e posso examinar seus arquivos de log durante o processo de handshake. Eu recebo os seguintes erros em seu arquivo de log: SynapseError: 401: No key for matrix.simonszu.de with id ['ed25519:a_LiWb'] .

O Google me levou a uma ferramenta chamada matrixtool, instalável via cpan App::MatrixTool , para que eu pudesse verificar a comunicação da federação via linha de comando. O resultado também foi uma dica que me levou à ideia de que ainda há algo errado com minha configuração de TLS:

$ matrixtool server-key matrix.simonszu.de
[INFO] Connected to 5.189.143.28:443
[FAIL] TLS fingerprint does not match any listed
[OK] Verified using origin=matrix.simonszu.de key_id=ed25519:a_LiWb
v2 keys from matrix.simonszu.de:

Key id ed25519:a_LiWb
  base64::VF2Cxq3wVEe8NIplwnHK+yKIhdBkgBmzqUfT1k0aMgg
[INFO] Matches cached key

Então, estou efetivamente ficando sem ideias. Durante toda a pesquisa percebi que não era o único com esse problema, mas a principal solução para outros usuários era desistir e criar uma instalação de sinapse de matriz sem proxies reversos. Então eu fui, e escrevi esta pergunta aqui, para deixar claro uma vez e todas as vezes: Como você configura corretamente a sinapse de matriz atrás de um proxy reverso habilitado para TLS?