Configurare un Reverse-Proxy Apache per le richieste HTTPS

http apache reverse proxy ssl

  • 20 commenti
Dopo una richiesta di un nostro amico Marino su un recente post eccovi una piccola guida per configurare Apache come Reverse Proxy unico per i vostri server web interni tra cui potrebbe esserci anche Domino.

Avevo affrontato 6 anni fa l'argomento in salsa Windows , mentre oggi per questioni di casi d'uso lo rivediamo in salsa Linux.

La prima cosa da fare è quella di prepararvi sulla vostra distribuzione preferita di Linux (questo articolo è basato su Centos o RedHat) una macchina dedicata e con davvero poche risorse nella vostra VM virtuale (dipende da quanti accessi in realtà avete) che dedicherete al vostro reverse (io per esempio con 512MB di RAM e 5GB di disco sono + che sufficenti per aziende piccole)

Supponendo che il 192.168.100.1 sia l'IP dedicato alla vostra nuova macchina Linux che farà da reverse proxy, una volta collegati alla vostra console in SSH con i permessi di root, digiterete il comando per installare Apache dal repository
 
yum install httpd

Successivamente installerete i  moduli SSL di Apache per la gestione del certificato e la libreria OpenSSL per la generazione della chiave privata da distribuire al vostra certification authority
 
yum install mod_ssl openssl

Ora generate la chiave privata ed il CSR che vi servirà poi di ottenere un certificato SSL tramite il vostra Certification Authority (CA) (ne esistono molte, mi sono trovato sempre bene con  i certificati Comodo tramite NameCheap.com)
Il comando da lanciare, che genererà due file, uno chiamato dominopoint.key (chiave privata da non fornire a nessuno) e l'altro file  server.csr - La chiave privata è utilizzata per generare la Certificate Signing Request (CSR) - è il seguente:
 
openssl req -nodes -newkey rsa:2048 -keyout dominopoint.key -out server.csr

che genererà un output simile a questo:
 
Country Name (2 letter code) [AU]: IT
State or Province Name (full name) [Some-State]: Milano
Locality Name (eg, city) []: Monza
Organization Name (eg, company) [Internet Widgits Pty Ltd]: Dominopoint
Organizational Unit Name (eg, section) []: IT
Common Name (eg, YOUR name) []: mail.dominopoint.it
Email Address []:

Gli altri campi che vi verranno richiesti sono opzionali e potete lasciarli anche vuoti....

Alla fine, se tutto è stato fatto correttamente, dovrestre trovare all'interno del file server.csr un output simile a questo:.
 
-----BEGIN CERTIFICATE REQUEST-----
MIICvDCCAaQCAQAwdzELMAkGA1UEBhMCVVMxDTALBgNVBAgMBFV0YWgxDzANBgNV
BAcMBkxpbmRvbjEWMBQGA1UECgwNRGlnaUNlcnQgSW5jLjERMA8GA1UECwwIRGln
aUNlcnQxHTAbBgNVBAMMFGV4YW1wbGUuZGlnaWNlcnQuY29tMIIBIjANBgkqhkiG
9w0BAQEFAAOCAQ8AMIIBCgKCAQEA8+To7d+2kPWeBv/orU3LVbJwDrSQbeKamCmo
wp5bqDxIwV20zqRb7APUOKYoVEFFOEQs6T6gImnIolhbiH6m4zgZ/CPvWBOkZc+c
1Po2EmvBz+AD5sBdT5kzGQA6NbWyZGldxRthNLOs1efOhdnWFuhI162qmcflgpiI
WDuwq4C9f+YkeJhNn9dF5+owm8cOQmDrV8NNdiTqin8q3qYAHHJRW28glJUCZkTZ
wIaSR6crBQ8TbYNE0dc+Caa3DOIkz1EOsHWzTx+n0zKfqcbgXi4DJx+C1bjptYPR
BPZL8DAeWuA8ebudVT44yEp82G96/Ggcf7F33xMxe0yc+Xa6owIDAQABoAAwDQYJ
KoZIhvcNAQEFBQADggEBAB0kcrFccSmFDmxox0Ne01UIqSsDqHgL+XmHTXJwre6D
hJSZwbvEtOK0G3+dr4Fs11WuUNt5qcLsx5a8uk4G6AKHMzuhLsJ7XZjgmQXGECpY
Q4mC3yT3ZoCGpIXbw+iP3lmEEXgaQL0Tx5LFl/okKbKYwIqNiyKWOMj7ZR/wxWg/
ZDGRs55xuoeLDJ/ZRFf9bI+IaCUd1YrfYcHIl3G87Av+r49YVwqRDT0VDV7uLgqn
29XI1PpVUNCPQGn9p/eX6Qo7vpDaPybRtA2R7XLKjQaF9oXWeCUqy1hvJac9QFO2
97Ob1alpHPoZ7mWiEuJwjBPii6a9M9G30nUo39lBi1w=
-----END CERTIFICATE REQUEST-----


Ricollegatevi al  pannello web del vostro NameCheap.com di turno, copiate il contenuto del server.csr generato nell'apposita form del vostro pannello web.
Se tutto è stato fatto correttamente dovrete poi ricevere una mail entro le 24h contenente due file allegati come questi:

STAR_dominopoint_it.crt
e STAR_dominopoint_it.ca-bundle

Ipotizziamo ora che il nostro server Domino risponde ad un IP 192.168.50.1 (e non ha Internet Site attivati) eccovi la configurazione classica, per girare il traffico al vostro server Domino sfruttando il certificato SSL avendo così una configurazione HTTPS valida.

Apriamo quindi il file httpd.conf presente in Centos sotto la folder /etc/http.d/conf/ e nella sezione VirtualHost compiliamo i dati come di seguito:

 

<VirtualHost *:443>
ServerName mail.dominopoint.it
ProxyPass / http://192.168.50.1:80/
ProxyPassReverse / http://192.168.50.1:80/
LogLevel info
ErrorLog logs/ssl-proxy.log  
TransferLog logs/dominopoint_access_log_http.log
SSLEngine on
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_prefer_server_ciphers on;
ssl_ciphers "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH+aRSA+RC4 EECDH EDH+aRSA RC4 !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS";
SSLCertificateFile ssl/STAR_dominopoint_it.crt
SSLCertificateKeyFile ssl/dominopoint.key
SSLCertificateChainFile ssl/STAR_dominopoint_com.ca-bundle
ProxyPreserveHost On
</VirtualHost>



Facciamo partire Apache con il comando service httpd start ed ora tutte le richieste https://mail.dominopoint.it saranno passate all'IP interno

Vi ricordo se se volete passare l'IP reale al vostro Domino server, dovrete modificare la configurazione di Domino e Apache come indicato in questo post e per testare la vostra sicurezza SSL vi invito ad usare questo tool online

20 Commenti:

  • #1 emanuele 12/11/2018 6:02:13 PM

    Se invece dovessi inserire un servizio diverso su un'altra porta (esempio 446 ) come devo configurare?

    Ho provato a editare il file così ma non sembra funzionare

    <VirtualHost *:443 *:446>

    ....

    ProxyPreserveHost On

    ProxyPass /portale 127.0.0.0.1:80/portale"

    ProxyPassReverse /portale 127.0.0.1:80/portale"

    ProxyPass / 127.0.0.180/

    ProxyPassReverse / 127.0.0.1:80/

    ho tolto gli http causa spam

  • #2 davide 10/12/2018 5:25:11 PM

    una domanda stupida da neofita.... se apro il sitoweb di destinazione con il protocollo https, resta di fatto che il certificato debba essere installato anche sul server di destinazione giusto?

  • #3 Daniele Grillo 02/05/2015 12:17:31 PM

    @mircot: si hai ragione corretto errore mio allora.

    con la direttiva ProxyPreserveHost On preserva l'hostname ...quindi passando col ProxyPass l'IP , dovrebbe andare senza problemi senza toccare i DNS.

    Eppure ho avuto problemi vado a memoria

    P.S. Anche io uso NGINX :-D da poco è molto più efficiente.

  • #4 mircot 02/05/2015 9:35:50 AM

    con gli internet site non mi pare serva nessuna modifica particolare.

    la direttiva ProxyPreserveHost On passa a domino il nome host richiesto e quindi viene scelto l'internet site corretto.

    l'unica condizione è fare un virtualhost (e quindi un servername) per ogni internet site di domino.

    ultimamente sto usando nginx come reverse proxy puro.

    lo trovo più semplice da configurare e parecchio più veloce a parità di caratteristiche della macchina virtuale.

    ciao! :-)

  • #5 marino 01/27/2015 3:26:05 PM

    @Giovanni: Presumo riguardi sempre PODDLE o heartbleed.. In pratica o segui da stefano benassi; oppure temporanemente, almeno su Chrome abbassi il livello di SSL accettato.

  • #6 daniele 01/27/2015 1:54:43 PM

    @Giovanni: non so di cosa stai parlando..potresti essere più chiaro?

  • #7 Giovanni D’Alessandro 01/27/2015 12:11:26 PM

    Salve,

    mi sapete dire quali sono le soluzioni al problema con le richieste HTTPS , che si sta verificando con le ultime versioni di Chrome e Firefox ??

    grazie

  • #8 marino 01/26/2015 3:18:25 PM

    OK credo stavamo dicendo la stessa cosa :)

    La macchina "sacrificale" con apache, avrà:

    <VirtualHost app1.miosito.net:443>

    ServerName app1.miosito.net

    ProxyPass / app1.miosito.net:80/

    ProxyPassReverse / app1.miosito.net :80/

    segue.....

    </VirtualHost>

    E nel file di host o meglio nei dns associato a app1.miosito.net l'ip 192.168.50.1

  • #9 Daniele Grillo 01/26/2015 1:33:33 PM

    ....facciamo un esempio pratico Marino...

    Hai i DNS pubblici esterni tipo *app1.dominopoint.it* e *app2.dominopoint.it* che puntano all'IP pubblico 89.40.45.670

    Il tuo firewall Natta le richieste TCP 80 e 443 dall'IP 89.40.45.670 verso il tuo Reverse proxy apache 192.168.1.100

    Il tuo Reverse proxy Apache ha 2 virtual host configurati che fowarda le richieste verso *app1.dominopoint.it* e *app2.dominopoint.it* che il reverse stesso deve essere in grado di risolvere come 192.168.50.1

    Per poter fare questa risoluzione o il reverse proxy ha nei proprio DNS interni la possibilità di risolvere questo (quindi lo gestisci dal DNS interno) oppure nel file host della macchina (è come /windows/system32/drivers/etc/host in ambiente Windows) fai un mapping locale andando a scrivere:

    *app1.dominopoint.it app2.dominopoint.it 192.168.50.1*

    In questo modo Domino (192.168.50.1) che adotta gli Internet Site riceve la richiesta dal reverse proxy sull'HostName corretto che è stato rigirato dal reverse proxy.

    P.S. Magari esiste un altro modo + automatico e più brillante per fare questo...ma al momento mi sfugge

  • #10 marino 01/26/2015 12:33:07 PM

    Quindi, forse concludendo, basterebbe che il dns o file di host, che usa il servente domino, abbia mappato app1.miosito.net e app2.miosito.net all'ip locale del server domino stesso.. Questo intendevi prima?

  • #11 Daniele Grillo 01/26/2015 11:29:06 AM

    @Marino... si il ragionamento che fai funziona fino al reverse proxy... cioè DNS pubblici arrivano ad Apache in 443/80 (Nat su Firewall solitamente) ... Il problema è nel quando Apache GIRA a Domino ...se la gira con IP e Domino ha gli Internet Site configurati allora viene servito il Default HTTP Internet site..ecco perchè per ovviare al problema Apache dovrebbe a sua volta avere i DNS risolvibili su Domino dei singoli Internet Site configurati

  • #12 marino 01/26/2015 10:57:27 AM

    Parlo da conoscitore di httpd. Io pensavo: a livello di dns, vengono ruotati app1.miosito.net e app2.miosito.net all'httpd reverse proxy.

    In questo vi sono i virtualhost app1.miosito.net e app2.miosito.net praticamente configurati come da tuo template, ed ognuno ruota al server domino direttamente ad ip.

    Questo, se ha gli internet sites attivi, riesce a rispondere alla richiesta visto che la url passante è app1.miosito.net e app2.miosito.net ?

    @Stefano, sorry, mio errore, ma ancora sono febbricitante... E in ogni caso grazie e interessante la questione... Per chi ha versioni più vecchie, intendo 8.5.x c'è ben poco da fare vedo.

  • #13 Daniele Grillo 01/26/2015 10:10:24 AM

    Marino se devi fare in modo che la richiesta venga girata per esempio a *www.dominopoint.it* e non all'IP perchè hai attivato gli internet site, devi gestire la cosa a livello di risoluzione DNS in modo che Apache possa risolvere *www.dominopoint.it* con l'IP.

    La pratica più semplice è quella di modificare il file */etc/hosts* non so se esistono altre strade più inteligenti, al momento non mi vengono in mente ...

  • #14 Stefano Benassi 01/26/2015 9:52:03 AM

    Sono Stefano ma ve bene lo stesso... ;-)

  • #15 marino 01/26/2015 9:22:23 AM

    Grazie daniele, gentilissimo come sempre. Se avrai voglia, di ampliare questo howto, con la funzionalità degli internet sites attivati su domino sarà un piacere leggerlo.. Anche se, a mia logica, non dovrebbe essere niente di trascendentale... Ma ragiono come conoscitore di httpd apache.. forse mi sfugge qualcosa.

  • #16 Stefano Benassi 01/25/2015 7:47:50 PM

    Ciao Marino. Per implementare il TLS 1.0 (Domino non supporta versioni superiori), è sufficiente:

    - installare la release 9.0.1 FP2 IF3 o superiore

    - inserire nel notes.ini la variabile DISABLE_SSLV3=1

    Riavvii l'http e, a questo punto, l'unica connessione possibile è tramite il TLS 1.0. Consiglio anche di disabilitare certi algoritmi di cifratura particolarmente deboli abilitati di default su Domino.

    Per quanto concerne i certificati, il mio consiglio è quello di utilizzare la nuova utility "KyrTool" resa disponibile da IBM ({ Link } con questa ho creato un certificato *.nomezienda.com per Apache che poi ho esportato in un keyring file per Domino e in un file .pfx per IIS senza problemi.

  • #17 marino 01/25/2015 9:54:21 AM

    P.S. sarà forse la febbre che ancora aleggia, ma nelle direttive apache, non manca il riferimento al server 192.168.100.1 ??

    Se avrai voglia, se vuoi ampliarlo anche con gli internet sites, che li davvero nasce, almeno a me, sempre il mal di testa in questi casi... tipo applicazione1.dominopoint.it che risponde su apache, deve essere richiamato su applicazione1.dominopoint.it sul server domino... e cosi via... se poi cè un modo per fare uno *.dominopoint.it che fa proxyreverse al server domino e il server domino risponde in base all'internet site richiamato tipo app1.dominopoint.it o app2.dominopoint.it ancora meglio...

  • #18 marino 01/25/2015 9:29:24 AM

    Eccolo, che sentitamente ringrazio.. L'influenza mi ha un po' abbattuto questi giorni, e non la raccomando a nessuno.... Molto interessante.. Avrei da porti una domanda perchè ho sentito pareri discordanti sull'argomento e mi piacerebbe da te, o da chiunque ne è al corrente parlarne... Ammesso che il server domino funzioni da solo in SSL, per evitare SSLv3, che sta diventando deprecato in quasi in ogni browser, come si fa, con un certificato di terzi alla mano (esempio quelli che tu citi) a fare una ssl di livello superiore tipo TSL 1.0/1.1/1.2 ??

    Ho letto questo documento:

    { Link }

    Ma non fa menzione assolutamente al livello di TLS e si parla di SSL. Sapresti/sapreste illuminarmi anche in tal senso???

  • #19 Daniele Grillo 01/16/2015 4:15:57 PM

    Grazie Michele, l'argomento è interessante ed anche io sono anni che lo implemento, ma visto che mi è stato espressamente richiesto ne ho parlato.

    Sarebbe poi il caso di parlare anche di altre questioni come alcuni casi sulle XPages , rewrite degli URL o delle risposte o l'utilizzo del modulo Page Speed per l'accelerazione del rendering :-)

    https://developers.google.com/speed/pagespeed/module

    Se avessi molto più tempo da dedicare a Dominopoint, pubblicherei un'enciclopedia di roba :-D

  • #20 Michele 01/16/2015 3:01:17 PM

    Daniele,

    complimenti per gli utilissimi articoli degli ultimi giorni, sono cose che qui abbiamo in produzione da molto,

    ma ritengo che siano utilissime a chi non avesse già implementato il reverse proxy, ed é bene che se ne parli.

Commenta articolo
 

Questo spazio web è stato creato da per un uso pubblico e gratuito. Qualsiasi tipo di collaborazione sarà ben accetta.
Per maggiori informazioni, scrivete a info@dominopoint.it

About Dominopoint
Social
Dominopoint social presence: