Números de porta para SSL

Temos um site existente com HTTP na porta 80 e HTTPS na porta 443. Estou adicionando um segundo site a isso agora, e pelo que entendi, não posso hospedar dois sites na mesma porta SSL.

Então, minha pergunta é: qual intervalo de número de porta é apropriado para eu usar como minha porta SSL no segundo site?

Comentários

  • Posso estar errado, mas acredito que uma certificação SSL válida exige estar na porta 443 e acredito que é por isso que a hospedagem compartilhada oferece um serviço dedicado Endereço IP ao adquirir um SSL. Mas … este não é meu campo, espero que outra pessoa geek possa confirmar.

Resposta

Na verdade, você PODE hospedar vários sites SSL na porta 443. O código a seguir em seu arquivo de configuração do apache resolverá o problema.

Caso contrário, você pode usar as portas que desejar. A desvantagem será é que os usuários terão que incluir o número da porta no URL (por exemplo, https://yourdomain.com:445/ )

## SSL (HTTPS) PORT 443 Listen 443 NameVirtualHost *:443 LoadModule ssl_module modules/mod_ssl.so SSLPassPhraseDialog builtin SSLSessionCache shmcb:/var/cache/mod_ssl/scache(512000) SSLSessionCacheTimeout 300 SSLMutex default SSLRandomSeed startup file:/dev/urandom 256 SSLRandomSeed connect builtin SSLCryptoDevice builtin <VirtualHost *:443> ServerName host1.com SSLEngine on SSLOptions +StrictRequire SSLProtocol -all +TLSv1 +SSLv3 SSLCipherSuite HIGH:MEDIUM:!aNULL:+SHA1:+MD5:+HIGH:+MEDIUM SSLCertificateFile /etc/httpd/ssl/host1.crt SSLCertificateKeyFile /etc/httpd/ssl/host1.key SSLVerifyClient none SSLProxyEngine off SetEnvIf User-Agent ".*MSIE.*" nokeepalive ssl-unclean-shutdown downgrade-1.0 force-response-1.0 CustomLog logs/ssl_request_log "%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b" DocumentRoot /var/www/host1/ <Directory "/var/www/host1/"> Options Indexes FollowSymLinks AllowOverride All Order Allow,deny Allow from all </Directory> </VirtualHost> <VirtualHost *:443> ServerName host2.com SSLEngine on SSLOptions +StrictRequire SSLProtocol -all +TLSv1 +SSLv3 SSLCipherSuite HIGH:MEDIUM:!aNULL:+SHA1:+MD5:+HIGH:+MEDIUM SSLCertificateFile /etc/httpd/ssl/host2.crt SSLCertificateKeyFile /etc/httpd/ssl/host2.key SSLVerifyClient none SSLProxyEngine off SetEnvIf User-Agent ".*MSIE.*" nokeepalive ssl-unclean-shutdown downgrade-1.0 force-response-1.0 CustomLog logs/ssl_request_log "%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b" DocumentRoot /var/www/host2/ <Directory "/var/www/host2/"> Options Indexes FollowSymLinks AllowOverride All Order Allow,deny Allow from all </Directory> </VirtualHost> 

Comentários

  • Obrigado, mas este é um site IIS. Alguma pista de como eu faria o mesmo?

Resposta

Quando você diz “segundo site” – você quer dizer um segundo nome de domínio? Por exemplo, você atualmente hospeda https://www.mycompany.com em um cluster e deseja hospedar https://www.yourcompany.com no mesmo cluster? Acho que o que você está procurando é” hospedagem virtual “: http://support.microsoft.com/kb/q190008

Você ainda precisará comprar um segundo certificado SSL, mas poderá hospedar os dois ao mesmo tempo Endereço IP nas portas padrão (o que, no mínimo, aumentará a confiança do usuário em seu site).

Comentários

  • Eu usei host nomes de cabeçalho e os dois sites estão no formato first.mycompany.com e second.mycompany.com. O problema é que em ” Identificação avançada de sites ” existem três colunas para HTTP (endereço IP, porta TCP e valor do cabeçalho do host) mas apenas dois para HTTPS (endereço IP e porta SSL), então não ‘ realmente parece ser possível pelo que posso ver.

Resposta

Tradicionalmente, você precisa de um endereço IP por ligação SSL. Não é possível adicionar um cabeçalho de host ao configurar as ligações. A razão para isso é porque o cabeçalho do host faz parte dos cabeçalhos HTTP enviados pelos navegadores e esses cabeçalhos são criptografados como parte do tráfego SSL. leia o cabeçalho do nome do host, o servidor deve primeiro descriptografar o tráfego, mas para isso ele precisa saber qual certificado usar. Para isso, ele precisaria do cabeçalho do host para que você entre em um círculo vicioso.

Uma solução seria o servidor tentar todos os certificados instalados e tentar descriptografar a solicitação. Embora isso possa funcionar com alguns certificados instalados, não funciona para servidores com décimos ou centenas de sites SSL. Isso tornaria o servidor drasticamente lento, pois o servidor teria que fazer isso para cada solicitação recebida.

A solução para isso é uma extensão do protocolo SSL chamada Indicação do nome do servidor (SNI) . Isso adiciona o nome do host ao protocolo SSL que permite ao servidor consulte o cabeçalho do host antes de descriptografar o tráfego SSL. Esta extensão não é compatível com nenhuma versão do IIS anterior ao IIS 8 (Windows 2012). No lado do cliente, o SNI é compatível com OS X 10.5.6 e Windows Vista ou superior . SNI não é compatível com o SChannel no Windows XP e, portanto, não é compatível com nenhuma versão do Internet Explorer (mesmo 8.0) no Windows XP.

Resposta

No IIS (como em outros servidores da web), existem três identificadores principais que identificam o seu site para solicitações de entrada:

  1. endereço IP
  2. TCP porta
  3. Cabeçalho do host

Se você estiver executando vários sites em um único servidor da web, pelo menos um dos três deve ser diferente para cada site. Em muitos ambientes, um servidor recebe apenas um único endereço IP, de forma que a porta TCP e o cabeçalho do host podem ser alterados. É possível executar um site https em uma porta diferente, você só precisa especificar a porta no URL, o que nem sempre é desejável (seria algo como https://www.foo.com:32000/index.html ). Na maioria das vezes, você deseja executar todos os seus sites na porta 80 (http) ou 443 (https) para obter URLs limpos. Isso deixa o cabeçalho do host como o único item que você deseja alterar.

No IIS, você pode ter vários sites na mesma combinação de IP / porta que usam SSL e cabeçalhos de host.A chave é que você precisa usar um certificado curinga ou um certificado SAN (Subject Alternative Names) que especifica vários nomes de host no próprio certificado. Você não pode definir as ligações de cabeçalho de host para cabeçalhos de host em um site SSL na IU do Gerenciador do IIS. Você deve fazer isso pela linha de comando ou editar manualmente o arquivo applicationHost.config no servidor.

Informações do Technet sobre como definir isso via linha de comando podem ser encontradas aqui .

Houve uma postagem no Fórum IIS com um problema semelhante a este também, que pode ser encontrado aqui .

Depois de executar o comando ou editar manualmente o arquivo de configuração, seu arquivo applicationHost.config pode ser semelhante a este:

<site name="first.mycompany.com"> ... <bindings> <binding protocol="http" bindingInformation="192.168.10.100:80:first.mycompany.com" /> <binding protocol="https" bindingInformation="192.168.10.100:443:first.mycompany.com" /> </bindings> ... </site> <site name="second.mycompany.com"> ... <bindings> <binding protocol="http" bindingInformation="192.168.10.100:80:second.mycompany.com" /> <binding protocol="https" bindingInformation="192.168.10.100:443:second.mycompany.com" /> </bindings> ... </site> 

Você verá as ligações no gerenciador do IIS. Espero que ajude.

* EDITAR * As informações acima pressupõem isso problema estava relacionado ao IIS7. Se for para o IIS6, há um procedimento diferente a seguir. Informações sobre isso podem ser encontradas aqui .

Resposta

considerando seu último comentário e depois de revisar as respostas de especialistas, posso recomendar duas soluções.

As melhores soluções são:

Compre um certificado SSL curinga que permitirá que você proteja sub .domain.com que está hospedado no mesmo IP (o certificado SSL requer IP dedicado).

Soluções alternativas:

Você pode comprar dois certificados SSL diferentes, um para cada site. Aqui você não pode hospedá-los no mesmo ip.

Deixe uma resposta

O seu endereço de email não será publicado. Campos obrigatórios marcados com *