Posso executar dois sites seguros diferentes usando a porta 443 no mesmo servidor?

Question

Digamos que eu queira dois sites seguros em execução na mesma máquina usando o servidor Apache:

 1. https://example.com
 2. https://example.ca

É possível usar a porta 443 para os dois sites acima?

    

Answer 1

Como já foi explicado, a conexão SSL é criada antes que qualquer dado real seja enviado pela conexão, portanto, o Apache não pode fornecer certificados SSL diferentes para cada um de seus sites virtuais, pois não tem ideia de qual nome do servidor está sendo solicitado. O que isto significa é que, independentemente do nome do servidor que é realmente solicitado (neste caso "mysite.com" ou "mysite.ca"), o Apache responderá com o certificado SSL padrão que foi configurado para usar. Isso pode ser declarado dentro do VirtualHost 443 "padrão" ou na configuração global do Apache.

O que isso significa do ponto de vista de usabilidade é que você pode absolutamente hospedar ambos os sites do mesmo host e IP do apache, mas os usuários receberão um aviso ao aceitar o certificado informando que o certificado é para o site errado. A única maneira de contornar isso seria ter dois endereços IP diferentes e configurar seus hosts virtuais para que cada um deles ouça em um endereço diferente. (Certifique-se de atualizar o DNS de acordo)

Após a troca do certificado, as regras normais do VirtualHost serão aplicadas e você poderá hospedar um conteúdo diferente em cada nome de servidor, se é isso que deseja fazer.

Estes exemplos são um pouco complicados, você vai querer consultar a documentação oficial do apache sobre os nomes dos parâmetros exatos para configurar hosts virtuais e configurar o ssl se você ainda não conhece o básico.

Exemplo: dois servidores em diferentes endereços IP com diferentes raízes de documentos, cada um apresentando o certificado correto

<VirtualHost 1.1.1.1:443>
ServerName mysite.com
DocumentRoot /var/www/comroot
SSLEngine On
// Configure certificate for mysite.com
</VirtualHost>

<VirtualHost 2.2.2.2:443>
ServerName mysite.ca
DocumentRoot /var/www/caroot
SSLEngine On
// Configure certificate for mysite.ca
</VirtualHost>

Exemplo: dois servidores no mesmo IP usando o certificado errado (configurado em outro lugar), mas ainda servindo conteúdo diferente com base no nome do servidor.

<VirtualHost *:443>
ServerName mysite.com
DocumentRoot /var/www/comroot
SSLEngine On
</VirtualHost>

<VirtualHost *:443>
ServerName mysite.ca
DocumentRoot /var/www/caroot
SSLEngine On
</VirtualHost>

    

Answer 2

Você pode executar vários sites SSL a partir de um único endereço IP usando alguns métodos, cada um com suas próprias desvantagens.

O primeiro método é ter um certificado SSL que cubra ambos os sites. A ideia aqui é ter um único certificado SSL que cubra todos os domínios que você deseja hospedar de um único endereço IP. Você pode fazer isso usando um certificado curinga que cubra os dois domínios ou use o Nome alternativo do assunto.

Certificados curinga seriam algo * .example.com, que abrangeriam www.example.com, mail.example.com e support.example.com. Há vários problemas com certificados curinga. Em primeiro lugar, cada nome de host precisa ter um domínio comum, por exemplo, com * .example.com, você pode ter www.example.com, mas não www.example.org. Em segundo lugar, não é possível ter mais de um subdomínio, ou seja, você pode ter www.example.com, mas não www.eu.example.com. Isso pode funcionar em versões anteriores do Firefox (< = 3.0), mas não funciona no 3.5 ou em qualquer versão do Internet Explorer. Em terceiro lugar, os certificados curinga são significativamente mais caros do que os certificados normais, se você quiser que ele seja assinado por uma CA raiz.

Subject Alternative Name é um método de usar uma extensão para certificados X509 que lista nomes de host alternativos válidos para esse certificado. Envolve adicionar um campo "subjectAltName" ao certificado que lista cada host adicional que você deseja que seja coberto pelo certificado. Isso deve funcionar na maioria dos navegadores; certamente, todo navegador mainstream moderno. A desvantagem desse método é que você deve listar todos os domínios no servidor que usará o SSL. Você pode não querer esta informação publicamente disponível. Você provavelmente não deseja que domínios não relacionados sejam listados no mesmo certificado. Também pode ser difícil adicionar domínios adicionais em uma data posterior ao seu certificado.

A segunda abordagem é usar algo chamado SNI (Server Name Indication), que é uma extensão no TLS que resolve o problema do ovo e da galinha de não saber qual certificado enviar ao cliente porque o cliente não enviou o Host: cabeçalho ainda. Como parte da negociação do TLS, o cliente envia o nome do host necessário como uma das opções. A única desvantagem disso é o suporte a clientes e servidores. O suporte em navegadores tende a ser melhor que em servidores. O Firefox suporta desde 2.0. O Internet Explorer suporta de 7 em diante, mas apenas no Vista ou posterior. O Chrome só suporta no Vista ou posterior também. Opera 8 e Safari 8.2.1 têm suporte. Outros navegadores podem não suportar isso.

O maior problema que impede a adoção é o suporte ao servidor. Até muito recentemente, nenhum dos dois principais servidores da Web o apoiava. O Apache ganhou suporte a SNI a partir de 2.2.12, que foi lançado em julho de 2009. Até agora, o IIS não suporta SNI em nenhuma versão. nginx, lighttpd e Cherokee suportam SNI.

De agora em diante, o SNI é o melhor método para resolver a hospedagem virtual baseada em nome do HTTPS, mas o suporte pode ser irregular por um ano ou dois ainda. Se você precisar fazer hospedagem virtual HTTPS sem problemas em um futuro próximo, a hospedagem virtual baseada em IP é a única opção.

    

Answer 3

Somente se os sites estiverem em seus próprios IPs.

A conectividade SSL acontece antes que o cliente solicite um site, portanto, quando a conexão SSL é configurada, o servidor não tem idéia do que o cliente solicitará.

Por exemplo, se você estiver apresentando o certificado SSL .com, o que deixaria os clientes pedindo o .ca infeliz.

A solução é configurar um segundo IP para o .ca e ter uma instância separada do servidor da Web escutando esse IP com o certificado SSL do .ca.

    

Answer 4

Sim, desde que você atribua vários IPs à máquina. Um para cada certificado / domínio SSL. Geralmente, você precisará de um IP exclusivo para cada servidor SSL. Windows, Linux, BSD & Todos os Solaris suportam vários IPs em uma única NIC ou você pode adicionar NIC's extras ou NICs com várias portas. É muito comum atribuir de 10 a 20 IPs por máquina / NIC em um ambiente de serviço da Web.

Outras opções de SSL que não funcionam com seus critérios.

Certificados SSL curinga podem hospedar muitos subdomínios desde que o domínio de segundo nível seja o mesmo, normalmente usado para hospedagem virtual em massa.

Certificados SSL compartilhados podem ser usados em várias máquinas para o mesmo domínio, normalmente usado para failover e balanceamento de carga.

    

Answer 5

Boas respostas, no entanto, usando um servidor HTTP para hospedar ambos os sites tem um SPOF - ou seja, uma vez que a instância do servidor apache. Se esse servidor apache ficar inativo, os dois sites não poderão ser acessados. Como cerca de uma placa ethernet de porta dupla? ou, melhor ainda, usando a virtualização. Sou um grande fã de virtualização como o xen ou o openVZ. No entanto, você precisará gastar algum dinheiro em hardware embora.

    

Answer 6

queridos usuários gentilmente usam haproxy na frente do seu apache2 nesse caso você será capaz de encaminhar um domínio diferente no mesmo servidor apache na porta ssl diferente, mas você precisa configurar o site diferente no site habilitado com portas como 443 e 8443 você pode copiar após o primeiro site ssl e alterar dentro de apenas porta e alias de domínio, você encontrará ajuda sobre a ativação do apache2 ssl e também precisará selecionar o arquivo hosts com 2 ips como 127.0.1.1 web-ssl1 127.0.2.1 web-ssl2