Entenda a configuração do SSL

Question

Objetivos:

• Se o usuário suportar SNI e clicar em myurl1.server.com (https) ou myurl2.server.com (https), ele corresponderá ao vhost correto. (os últimos 2 vhosts)
• Se o usuário não suportar SNI e clicar em myurl1.server.com (https) ou myurl2.server.com (https), ele será capturado pelo vhost de fallback (o primeiro na porta 443). Ele contém o certificado da SAN e atingirá o servidor novamente para fazer a correspondência. Desta vez, ele irá acertar os últimos 2 vhosts.
• Se o usuário inserir um URL desconhecido com http ou https, ele será capturado no primeiro vhost que exibir uma página de erro.

Eu testei todos os 3 gols e está funcionando bem.

Perguntas:

• Quando o usuário está atingindo o SAN vhost (https), que faz uma nova solicitação para si mesmo. Como o Apache sabe que ele corresponderá aos últimos 2 vhosts (443) quando o proxypass no SAN vhost estiver usando http (80)
• Quando o usuário está acessando o vhost da SAN, não consigo ver nenhuma solicitação no log de acesso da SAN. As solicitações aparecem apenas nos últimos 2 vhosts mesmo que passem pelo SAN vhost. No entanto, posso ver algumas solicitações de bots no log de acesso da SAN.

O código contém apenas as partes importantes.

NameVirtualHost *:80
NameVirtualHost *:443

<VirtualHost *:80>
  show error page
</VirtualHost>

<VirtualHost *:443>
  SSLCertificateFile san.crt
  CustomLog san-access.log 
  ProxyPass / http://my-local-url-server/
  ProxyPassReverse / http://my-local-url-server/
</VirtualHost>

<VirtualHost *:443>
  ServerName myurl1.server.com
  SSLCertificateFile myurl1.crt
  CustomLog myurl1-access.log 
  ProxyPass / http://mybackend1/
  ProxyPassReverse / http://mybackend1/
</VirtualHost>

<VirtualHost *:443>
  ServerName myurl2.server.com
  SSLCertificateFile myurl2.crt
  CustomLog myurl2-access.log 
  ProxyPass / http://mybackend2/
  ProxyPassReverse / http://mybackend2/
</VirtualHost>

    

Answer 1

A confusão aqui é entre negociação SSL e manipulação de vache do apache. Isso é o que acontece:

Se um usuário se conectar sem suportar o SNI, o Apache não poderá saber a primeira que vhost o usuário deseja, já que o nome do host está oculto na criptografia SSL. Assim, o apache usará o primeiro certificado SSL encontrado para a negociação SSL. Depois que o cliente aceitar esse certificado e terminar a negociação, o Apache poderá descriptografá-lo e tratá-lo como se o cliente tivesse recebido o SNI desde o início.

Portanto, nunca há qualquer solicitação HTTP para o servidor SAN - há apenas uma negociação SSL que usa o certificado do servidor SAN antes de descobrir qual vhost usar para a solicitação HTTP. O Apache registra apenas as solicitações HTTP, não as negociações SSL.