Posso definire HTTP e HTTPS nello stesso VirtualHost in Apache conf?

13

Ho una definizione abbastanza grande di VirtualHost che non voglio duplicare solo perché il sito funzionerà anche su HTTPS.

Ecco cosa voglio fare:

<VirtualHost *>
    ServerName example.com

    <If port=443>
        SSLEngine on
        SSLCertificateFile ...
        SSLCertificateKeyFile ...
        SSLCertificateChainFile ...
    </If>

    (other config)

</VirtualHost>

C'è un modo per farlo?
Mi manca qualche altro metodo per non duplicare la configurazione?

apache-2.2 ssl virtualhost

— Jake
fonte

12

L'attuale versione stabile di Apache (2.2) non ha quella funzionalità, ma la 2.4 ha la direttiva IF .

Devi creare due VirtualHosts per ora, ma puoi impostare alcune cose attraverso variabili globali di ambiente o apache e usarle nella configurazione del tuo host virtuale (impostando ad esempio il documentroot). In questo modo, se vuoi cambiare, puoi farlo con una sola riga di modifica.

Ovviamente, puoi usare include per fare qualcosa del genere:

<VirtualHost *:80>
        include /etc/apache2/vhost.conf.d/site1
</VirtualHost>

<VirtualHost *:443>
        include /etc/apache2/vhost.conf.d/site1
        include /etc/apache2/vhost.conf.d/site1-ssl
</VirtualHost>

ps: SNI sarà mainstream anni prima dell'adattamento IPv6. Tutto il browser principale lo supporta già supponendo che tu sia su un sistema operativo supportato.

modifica: come notato la fooquency non puoi mettere SSLEngine su un blocco If, quindi la mia risposta è sbagliata.

— Tyrael
fonte

8

Tentare di inserire SSLEngine Onun <If>testamento SSLEngine not allowed here, quindi il caso d'uso suggerito all'inizio di questa risposta purtroppo non sembra essere possibile. Ciò sembra essere dovuto al fatto che all'interno di questa sezione di configurazione è possibile utilizzare solo le direttive che supportano il contesto della directory. (ref) ed SSLEngineè server config, virtual host (ref) , non directory.

— Fooquency,

3

No. Puoi spostare la maggior parte delle cose nella configurazione globale ed ereditarla in VirtualHost.

— Chris S
fonte

1

Purtroppo ho alcuni VirtualHosts, ognuno con una configurazione diversa e la maggior parte che ha bisogno di lavorare su HTTP e HTTPS.

— Jake,

1

Non utile quanto questa risposta è, è l'unica corretta. Passare a un server Web che non fa schifo. :)

— intgr

3

Questa è stata risposta in un'altra domanda. Usa un'istruzione Include. Ha funzionato benissimo per me:

Servire http (porta 80) e https (porta 443) sullo stesso VirtualHost

# Acme Co
<VirtualHost 192.168.56.101:80>
        Include /usr/local/apache2/conf/main-acme.conf
</VirtualHost>

###* SSL
<VirtualHost 192.168.56.101:443>
        Include /usr/local/apache2/conf/main-acme.conf
        SSLEngine On
</VirtualHost>

— Kevin Parker
fonte

2

Per gli host virtuali SSL, è necessario utilizzare una seconda porta ala

<VirtualHost *:443>
    ServerName abc.com
</VirtualHost>
<VirtualHost *:4443>
    Servername def.com
</VirtualHost>

oppure devi usare IP separati

<VirtualHost 192.168.0.1:443>
    ServerName abc.com
</VirtualHost>
<VirtualHost 192.168.0.2:443>
    Servername def.com
</VirtualHost>

C'è sicuramente un'ottima spiegazione nei documenti SSL di Apache http://httpd.apache.org/docs/2.0/ssl/ssl_faq.html

Cerca "Perché non posso utilizzare SSL con host virtuali basati su nome / non basati su IP?"

— Di Paul
fonte

2

Sii consapevole di ciò per il futuro, però: en.wikipedia.org/wiki/Server_Name_Indication

— mattdm

Ironia della sorte, quando SNI sarà ampiamente accettato per essere utilizzato in modo sicuro per la maggior parte dei siti di hosting virtuale, IPv6 sarà probabilmente abbastanza comune da renderlo irrilevante.

— jgoldschrafe,

4

@jgoldschrafe Ciao 2010, è il futuro parlare qui! Recenti caniuse mostrano che i browser non SNI sono <2% in tutto il mondo. Dal primo mondo è probabilmente molto meno. IPv4 ancora vivo e vegeto :)

— kubanczyk il

2

@kubanczyk Got me! :)

— jgoldschrafe l'

@jgoldschrafe Anche con IPv6 preferirei comunque SNI sull'assegnazione di blocchi di indirizzi a una singola macchina, poiché gli IP sono principalmente per il routing ed è più facile da gestire in questo modo.

— Bachsau,