stunnel + HAProxy + Pergunta do Apache, vários certificados de site

Question

Atualmente, estou usando o esquema a seguir para atender ao conteúdo estático y dinâmico.

Eu compilei o stunnel com o patch de suporte X-Forwarded-For.

Internet (http) - > haproxy (frontend1) - > Apache Farm

Internet (https) - > stunnel - > haproxy (frontend2) - > Apache Farm

Stunnel está configurado para usar o certificado de xxxx.com. É possível adicionar suporte ao stunnel para servir com outros certificados?

cert = /etc/stunnel/group.cert
key = /etc/stunnel/private.key
verify = 0
debug = local0.debug
CAfile = /etc/stunnel/group.cert
chroot = /var/run/stunnel4/chroot
setuid = stunnel4
setgid = stunnel4
failover = prio
xforwardedfor = yes
TIMEOUTclose=0
socket=l:TCP_NODELAY=1
socket=r:TCP_NODELAY=1

[https]
accept = 443
connect = HAPROXYHOST:FRONTEND2PORT

Eu sei que posso executar outra instância stunnel que se liga a outro endereço IP, mas não temos um endereço público infinito se decidirmos hospedar mais sites, eu sei que é possível configurar o Apache para servir certificados diferentes por VirtualHost, é possível fazer isso com este esquema? Ou talvez mudar de stunnel para o Apache mod_proxy ou outra solução.

Muito obrigado.

    

Answer 1

A exibição de certificados diferentes na mesma porta no mesmo endereço depende do suporte à Indicação do nome do servidor TLS, que não é suportado pelo stunnel.

Usando o Apache como seu proxy, você obterá o suporte do lado do servidor que precisa, no entanto, tenha em mente que o suporte do lado do cliente (Windows XP) para Indicação de Nome do Servidor ainda não é onipresente.

Uma alternativa a considerar, se estiver na sua faixa de preço, é um certificado que apresenta os nomes alternativos do assunto.

    

Answer 2

Em geral, ao trabalhar com SSL / TLS e vários sites no único IP, você tem duas opções.

O primeiro é fazer com que o cliente envie o nome do host em que está interessado com a solicitação inicial. Isto é o que link oferece, mas isso não é suportado por todos os clientes (veja a página da Wikipedia para a lista do que e não funciona para isso). Com o SNI, o nome do host está disponível no início da negociação segura, para que o servidor possa escolher o certificado correto para responder.

Se você não for capaz de usar o SNI, então você tem um pequeno problema. O cliente aparece e diz "Ei, eu quero fazer SSL", mas você não sabe qual o nome do host que eles querem, então você não pode escolher o certificado certo. Tudo o que você sabe é o endereço IP. Então, para fazer isso, você precisa garantir que o certificado retornado seja válido para todos os diferentes vhosts nesse IP.

Este último não é necessariamente tão ruim quanto parece pela primeira vez. Uma opção é obter um certificado curinga, por exemplo, * .mysite.com. Enquanto você estiver servindo www.mysite.com e images.mysite.com (ou seja, ambos dentro do mesmo espaço curinga), tudo bem. A outra opção é usar subjectAltName no seu certificado. Com essa opção, seu certificado é válido para vários sites. Dessa forma, quando você enviar o único certificado de volta ao cliente, ele será válido para qualquer um dos hosts que eles desejarem. Muitas CAs suportam esta última opção, e geralmente é a única opção para o EVA certs (você geralmente não pode obter caracteres curingas), e você normalmente só ligaria sua CA toda vez que você quisesse adicionar uma nova vhost para esse IP, e eles cobrarão uma pequena taxa e emitirão um novo certificado com o nome extra nele.