Servir http (porta 80) e https (porta 443) no mesmo VirtualHost


29

Preciso configurar meu VirtualHost no Apache para servir em http e https (usando portas padrão)

Se eu ativar o mecanismo SSL (conforme abaixo) - recebo um erro quando estiver na porta 80.

O motivo é que partes do site precisam ser SSL, mas outras não. Como posso fornecer os dois http + https no site?

Aqui está o meu arquivo host virtual ....

NameVirtualHost *

<VirtualHost *>
        ServerAdmin webmaster@localhost
        ServerName mysite.co.uk
        DocumentRoot /var/www/mysite/public
        <Directory />
                Options FollowSymLinks
                AllowOverride None
        </Directory>
        <Directory /var/www/mysite/public>
                Options Indexes FollowSymLinks MultiViews
                AllowOverride All
                Order allow,deny
                allow from all
        </Directory>

        ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/
        <Directory "/usr/lib/cgi-bin">
                AllowOverride None
                Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch
                Order allow,deny
                Allow from all
        </Directory>

        ErrorLog /var/log/apache2/error.log

        # Possible values include: debug, info, notice, warn, error, crit,
        # alert, emerg.
        LogLevel warn

        CustomLog /var/log/apache2/access.log combined
        ServerSignature On

    Alias /doc/ "/usr/share/doc/"
    <Directory "/usr/share/doc/">
        Options Indexes MultiViews FollowSymLinks
        AllowOverride None
        Order deny,allow
        Deny from all
        Allow from 127.0.0.0/255.0.0.0 ::1/128
    </Directory>

     #SSL STUFF...
      SSLEngine on
      SSLCertificateFile /etc/apache2/crts/mysite.crt
      SSLCertificateKeyFile /etc/apache2/crts/mysite.key
      SSLCertificateChainFile /etc/apache2/crts/DigiCertCA.crt


</VirtualHost>

Respostas:


44

Você não pode fazer isso em um host virtual, porque o Apache precisa saber quem fala sobre SSL e qual não é (nota de rodapé: nginx não tem esse problema, você pode dizer quais diretivas de escuta estão relacionadas ao SSL; uma das muitas razões pelas quais eu amo isso).

A maneira como gerencio isso no Apache é colocar todas as minhas configurações não relacionadas a SSL em um arquivo separado e, em seguida, ter os dois vhosts configurados um ao lado do outro, cada um incluindo o arquivo de configuração específico do site dentro da estrofe do vhost, como este :

<VirtualHost 192.0.2.12:80>
    Include /etc/apache2/sites/example.com
</VirtualHost>

<VirtualHost 192.0.2.12:443>
    SSLEngine On
    # etc
    Include /etc/apache2/sites/example.com
</VirtualHost>

7

Parece um problema no Apache vHost, mas faz o trabalho sem precisar repetir a configuração.

SSLCertificateFile /srv/.ssl/self/server.crt
SSLCertificateKeyFile /srv/.ssl/self/server.pem

# REQUIRED
<VirtualHost *:80>
    DocumentRoot /srv/www/badhost
</VirtualHost>

<VirtualHost *:80 *:443>
    SSLEngine On
    ServerName example.com
    ServerAlias www.example.com
    DocumentRoot /srv/www/example.www
</VirtualHost>

Isso é realmente estranho, mas existe!
user77376

1
Isso funcionou tão bem quanto você poderia esperar de tal kludge - quase, mas não exatamente! Descobri que o Apache 2.4.10 define a variável de ambiente SERVER_PORT para 443 em vez de usar a porta na qual a solicitação veio (80 ou 443, dependendo). <IMAGINARY_PARAGRAPH_BREAK> Pena, como eu esperava poder usar isso, pois eu realmente queria manter um arquivo por host virtual. <IMAGINARY_PARAGRAPH_BREAK> Além disso, você precisará de uma diretiva ServerName dentro da parte superior do <VirtualHost>, caso contrário, ele absorverá as solicitações por engano. Defina-o como ServerName badhost.bad ou algo assim.
Daniel Beardsmore

1
@DanielBeardsmore: Acabei de testar isso com a 2.4.18 das coleções do RH Software, e isso parece dever-se ao padrão de UseCanonicalPhysicalPort Off. Se você ativá-lo, parece que a porta real é usada. (Curiosamente, eu tive que deixar de fora o SSLEngine Onem meu vhost duplamente utilizado e tem a porta 80 como o padrão.)
Ulrich Schwarz

1
@DanielBeardsmore: FWIW, %{HTTPS}também será definido corretamente, mas %{REQUEST_SCHEME}não é (sempre http). Eu me sentiria bobo ao fazer um pedido de recurso para uma UseCanonicalRequestSchemediretiva, no entanto.
Ulrich Schwarz
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.