Servir http (puerto 80) y https (puerto 443) en el mismo VirtualHost


29

Necesito configurar mi VirtualHost en Apache para servir tanto en http como en https (usando puertos estándar)

Si habilito el motor SSL (como se indica a continuación): aparece un error cuando estoy en el puerto 80.

La razón es que algunas partes del sitio deben ser SSL pero otras no. ¿Cómo puedo servir tanto http + https en el sitio?

Aquí está mi archivo de 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>

Respuestas:


44

No puede hacer esto en un host virtual, porque Apache necesita saber cuál va a hablar SSL y cuál no (nota al margen: nginx no tiene este problema, puede decirle qué directivas de escucha se relacionan con SSL; Una de las muchas razones por las que me encanta).

La forma en que administro esto en Apache es poner toda mi configuración no relacionada con SSL en un archivo separado, y luego tener los dos vhosts configurados uno al lado del otro, cada uno incluyendo el archivo de configuración específico del sitio dentro de la stanza 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 un problema en Apache vHost, pero hace el trabajo sin tener que repetir la configuración.

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>

Eso es realmente extraño, ¡pero existe!
user77376

1
Esto funcionó tan bien como cabría esperar de tal error, ¡casi, pero no del todo! Descubrí que Apache 2.4.10 establece la variable de entorno SERVER_PORT en 443 en lugar de usar el puerto en el que entró la solicitud (80 o 443 dependiendo). <IMAGINARY_PARAGRAPH_BREAK> Lástima, ya que esperaba poder usar esto, ya que realmente quería mantener un archivo por host virtual. <IMAGINARY_PARAGRAPH_BREAK> Además, necesitará una directiva ServerName dentro de <VirtualHost> superior; de lo contrario, engullirá las solicitudes por error. Configúrelo en ServerName badhost.bad o algo así.
Daniel Beardsmore

1
@DanielBeardsmore: Acabo de probar esto con 2.4.18 de las colecciones de RH Software, y eso parece deberse al valor predeterminado de UseCanonicalPhysicalPort Off. Si lo activa, parece que utiliza el puerto real. (Curiosamente, tuve que dejarlo SSLEngine Onen mi vhost doblemente usado y obtuve el puerto 80 por defecto.)
Ulrich Schwarz

1
@DanielBeardsmore: FWIW, %{HTTPS}también se configurará correctamente, pero %{REQUEST_SCHEME}no (siempre http). Sin UseCanonicalRequestSchemeembargo, me sentiría tonto al presentar una solicitud de función para una directiva.
Ulrich Schwarz
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.