Aí vem uma pergunta provavelmente estranha e que provavelmente também foi feita de forma errada.
Tenho a seguinte estrutura/plano de rede...:
insira a descrição da imagem aqui
A ideia é que alguém que seja responsável/autorizado pela rede 1 e domínio1.com tenha seu próprio Rev. Proxy que ele gerencie e cuide dos certificados SSL. O mesmo se aplica à rede 2.
A questão é: isso é mesmo possível? Infelizmente, não estou muito familiarizado com SSL e proxies. Suspeito que o Rev. Proxy que detém os certificados SSL deve formar o frontend.? Se for esse o caso, provavelmente não funcionaria de qualquer maneira. Então a questão é se há outra maneira? Um tipo de NAT baseado em http/https? Parece um pouco estranho... Mas acho que a ideia é clara.
Se fosse basicamente possível, então a questão seria se a ordem HaProxy->Nginx é a correta? E se alguém pode me dar uma dica ou link sobre como configurar o proxy frontend corretamente.
Muito obrigado pelas suas respostas.
Atualização: Para aqueles que têm algo semelhante em mente, a configuração do haproxy:
# Automaticaly generated, dont edit manually.
# Generated on: 2024-10-07 20:55
global
maxconn 1000
stats socket /tmp/haproxy.socket level admin expose-fd listeners
uid 80
gid 80
nbthread 1
hard-stop-after 15m
chroot /tmp/haproxy_chroot
daemon
tune.ssl.default-dh-param 2048
server-state-file /tmp/haproxy_server_state
frontend Front
bind your_public_ip:80 name your_public_ip:80
bind your_public_ip:443 name your_public_ip:443
mode tcp
log global
timeout client 30000
tcp-request inspect-delay 5s
tcp-request content accept if { req_ssl_hello_type 1 }
acl app1 req_ssl_sni -m end domain1.de
acl app2 req_ssl_sni -m end domain2.de
use_backend Domain1_ipvANY if app1
use_backend Domain2_ipvANY if app2
backend Domain1_ipvANY
mode tcp
id 100
log global
timeout connect 30000
timeout server 30000
retries 3
load-server-state-from-file global
stick-table type binary len 32 size 30k expire 30m
acl clienthello req_ssl_hello_type 1
acl serverhello rep_ssl_hello_type 2
tcp-request inspect-delay 5s
tcp-request content accept if clienthello
tcp-response content accept if serverhello
stick on payload_lv(43,1) if clienthello
stick store-response payload_lv(43,1) if serverhello
server ProxyMan 192.168.7.1:8443 id 102 check inter 1000
backend Domain2_ipvANY
mode tcp
id 100
log global
timeout connect 30000
timeout server 30000
retries 3
load-server-state-from-file global
stick-table type binary len 32 size 30k expire 30m
acl clienthello req_ssl_hello_type 1
acl serverhello rep_ssl_hello_type 2
tcp-request inspect-delay 5s
tcp-request content accept if clienthello
tcp-response content accept if serverhello
stick on payload_lv(43,1) if clienthello
stick store-response payload_lv(43,1) if serverhello
server ProxyMan 192.168.8.1:8443 id 103 check inter 1000
É possível ter certificados para o mesmo domínio em vários estágios, o que é especialmente comum se o trânsito entre os vários estágios for por redes não confiáveis e, portanto, devem ser protegidas.
Um exemplo típico é uma rede de distribuição de conteúdo (CDN) como a Cloudflare, que encerra o TLS em seu site, mas encaminha o tráfego para o sistema do cliente em algum outro lugar na Internet que tenha seu próprio certificado para proteger a comunicação entre a Cloudflare e o servidor final.
Como cada um dos servidores/proxies precisa de um certificado e uma chave privada para isso e as chaves privadas não devem ser compartilhadas, isso geralmente significa que os proxies e servidores têm certificados diferentes. Da perspectiva do cliente público, apenas o proxy inicial precisa ter um certificado confiável para o cliente, ou seja, normalmente um certificado de uma CA pública como a Let's Encrypt. Cada outro estágio precisa apenas de um certificado confiável para o estágio anterior, que pode ser emitido por alguma CA interna não pública ou pode até ser autoassinado.
Note que você também pode usar roteamento baseado em domínio no proxy HA sem encerrar o TLS, roteando com base no nome do servidor que é visível no handshake TLS (desde que nenhum ECH esteja configurado). Como neste caso o proxy HA não encerra o TLS, ele também não precisa de certificados.