Apache: reescreva a porta 80 e 443 - configuração múltipla de vhosts SSL

1

CONFIGURAÇÃO:

  • vários domínios SSL são configurados em um único IP, usando vhosts com números de porta diferentes (nos quais o Apache atende)
  • Apache 2.2.8 no Windows 2003 (sem comentários sobre este pls)
  • muitos usuários do Windows XP, por isso o SNI ainda não é uma opção

Pode haver razões por que é errado usar essa abordagem, mas funciona por enquanto.

configuração vhosts:

# secure domain 1
<VirtualHost IP:443>
  SSL stuff specifying certificate etc.
  ServerName domain1.org
</VirtualHost>

# secure domain 2
<VirtualHost IP:81>
  SSL stuff for domain2.org
  ServerName domain2.org
</VirtualHost>

OBJETIVO: Algumas pastas dentro do docroot domain2.org precisam ser seguras. Eu usei um arquivo .htaccess para reescrever o URL para https na porta 81:

RewriteEngine On
RewriteCond %{SERVER_PORT} !^81$
RewriteRule (.*) https://%{HTTP_HOST}:81%{REQUEST_URI} [R]

Suponha que eu coloque o .htaccess na pasta ' secfolder '. Ao acessar http://domain2.org/secfolder , isso é reescrito com êxito para link : //domain2.org: 81 / secfolder.

PROBLEMA: Ao acessar https://domain2.org/secfolder (sem porta 81), o certificado do primeiro vhost (domain1.org) é usado e o navegador reclama que o site é inseguro porque o certificado não é válido para domain2.org.

Eu achei que RewriteCond %{SERVER_PORT} !^81$ também reescreveria https://domain2.org para https://domain2.org:81 , mas não . Parece que o arquivo .htaccess não está sendo usado neste caso.

Neste ponto, não tenho certeza de como aplicar um RewriteRule a https://domain2.org . Eu tentei criar um vhost adicional para domain2 na porta 443 antes daquele para domain1.org, mas o Apache parece se engasgar com isso. Espero que alguém tenha uma ideia de como abordar isso. TIA.

Editar: Houve uma resposta que foi eliminada, mas dizia:
"Você não pode se conectar ao servidor sem primeiro verificar o certificado e porque o certificado é para o domínio errado, você não pode redirecionar." A incompatibilidade de certificados é realmente o fim da linha? Nenhum redirecionamento forçado / reescrita de url é possível depois disso?

    
por Benjamin Jung 01.05.2010 / 00:48

2 respostas

2

Lembre-se de que, quando você faz uma conexão HTTPS com o link (que é realmente uma conexão com link ), a ordem é aproximadamente

  1. O navegador abre a conexão com o IP on porta 443
  2. O Apache procura um VirtualHost que corresponda ao IP da combinação: 443
  3. Neste caso, encontra o VirtualHost para domain1.org
  4. O Apache envia o certificado SSL associado a esse VirtualHost (ou seja, o certificado para domain1.org)
  5. [O restante da negociação do SSL]
  6. O navegador envia seus cabeçalhos de solicitação HTTP, incluindo o cabeçalho Host: dizendo ao Apache que domínio ele pensa está falando com.
  7. Se aplicável, o processamento mod_rewrite dos cabeçalhos de solicitação HTTP acontece aqui.

i.e. quando o Apache decide qual certificado enviar, ele ainda não recebeu as informações que o mod_rewrite usaria para fazer o redirecionamento.

Para contornar isso, você precisaria de um único certificado válido para os dois domínios. Pode ser um certificado curinga (se a situação for domain1.example.com e domain2.example.com, obtenha um certificado para *. Example.com ) ou tente obter um certificado SSL certificado com um Assunto de "domínio1.org", mas um Nome alternativo do assunto de "domínio2.org".

Em ambos os casos, você precisaria fazer o redirecionamento nos arquivos de configuração principais do Apache - se estiver em um arquivo .htaccess no DocumentRoot do domínio2.org, então os pedidos que usam o VirtualHost do domínio1.org irão para um diretório DocumentRoot diferente, e nunca mais veremos o arquivo.

    
por 01.05.2010 / 01:25
0

Você tem um certificado curinga de algum tipo ou está tentando hospedar domínios diferentes com certificados SSL diferentes no mesmo IP?

Se não for um caractere curinga, você não poderá fazê-lo, porque você só pode usar um único certificado SSL por endereço IP, independentemente da porta em que está ...

    
por 01.05.2010 / 00:52