Nella parte precedente dell’articolo abbiamo visto come creare un virtual host Apache utilizzando il moduli mod_proxy, mod_rewrite e mod_ssl per creare un reverse-proxy https riscrivendo l’URL OWA di Exchange 2007. Se lasciassimo la configurazione cosi’, gli utenti, per raggiungere l’applicazione attraverso il reverse-proxy, dovrebbero digitare https://webmail.dominio.it, ma saranno pero’ condizionati alla scrittura del prefisso https://.
Con un po’ di pazienza e qualche altra riga di codice, potremmo semplificare ulteriormente.
Ecco come fare:

Questo virtual host si limita soltanto a redirigere permanentemente cio’ che arriva sulla porta 80 del reverse-proxy (http://webmail.dominio.it) sulla porta 443 (https://webmail.dominio.it) senza apportare nessuna modifica. Non e’ sicuramente fondamentale ai fini del risultato ricercato, ma si tratta di una piccola “finezza” che permettera’ agli utenti di raggiungere l’applicazione OWA semplicemente digitando webmail.dominio.it.

In questo articolo, vedremo come esporre su internet OWA (Outlook Web Access) in modo sicuro traslando l’URL http con indirizzo privato in un URL https con indirizzo pubblico utilizzando alcune funzionalita’ messe a disposizione da Apache tramite i moduli mod_proxy mod_rewrite e mod_ssl.

Il modulo mod_proxy permette di effettuare relay e caching di richieste provenienti da vari host verso altri host mantenendo questi logicamente separati.
E’ praticamente uno step intermedio fra i client e il server remoto, in modo da non consentire il passaggio diretto delle informazioni, ma sia il proxy a gestire la comunicazione fra le parti.
Puo’ essere utilizzato in modalita’ FORWARD e REVERSE, proprio come se fosse un imbuto.
Nel primo caso il proxy raccoglie le richieste dei client da tutta una LAN e le redirige verso internet (forward), il secondo caso e’ esattamente opposto, il proxy raccoglie le richieste da internet e le redirige su un server della LAN (reverse).

Il modulo mod_rewrite permette di riscrivere un URL in un altro senza che l’utente ne sia a conoscenza. L’associazione avviene al “volo” tramite regole definite nel file di configurazione e/o virtualhosts oppure nel file .htaccess. Questo tipo di riscrittura apre a numerose possibilita’ per “ripulire” un URL e renderlo quindi piu’ semplice per l’utente.
Molti avranno sperimentato che, in particolar modo, con l’uso di CMS (Content Management System) il server produce URL simili a:

sicuramente non semplice da digitare, ma utilizzando la riscrittura la si puo’ rendere:

decisamente meglio, vero?

Il modulo mod_ssl è il modulo per la gestione del protocollo HTTPS in Apache, basato su OpenSSL capace di supportare i protocolli Secure Sockets Layer (SSL v2/v3) e Transport Layer Security (TLS v1), un tempo sviluppato come “patch” del codice sorgente, oggi modulo cardine della sicurezza.

Non resta che unire queste funzionalita’ in due virtualhost di Apache per ottentere il risultato desiderato.
Dato per assunto che abbiate installato Apache con i moduli richiesti su un server Linux questa e’ la configurazione da fare:

Nella configurazione appena vista deve essere inserito l’indirizzo IP privato del vostro server reverse proxy (nell’esempio 172.18.27.7) su cui sara’ effettuato il NAT (se utilizzate questa tecnica), altrimenti se utilizzate una rete disaccoppiata (server con un indirizzo privato ed un indirizzo pubblico) sara’ necessario creare due virtual host (identici) con gli indirizzi IP (Publico e Privato) del vostro server reverse proxy, “aa.bb.cc.dd” deve essere sostituito con quello del vostro server Exchange e il certificato di crittografia deve essere esportato dal server Exchange 2007 e convertito in formato Apache (per informazioni Esportare un certificato SSL da IIS per utilizzarlo in Apache).

Nella prossima parte dell’articolo ci occuperemo di creare il virtual host http che sara’ rediretto sul virtual host https appena visto.

In alcuni casi, puo’ essere necessario utilizzare lo stesso certificato SSL su un server Microsoft IIS e su un server Apache.
E’ possibile esportare un certificato SSL da IIS per utilizzarlo in ambiente Apache.
Ecco come fare:

1. Sul server Windows con IIS aprire una Microsoft Management Console (mmc.exe), aggiungere lo snap-in Certificates e selezionare Account Computer e Local Computer.

2. Cercare il certificato che si intende esportare e selezionando All Tasks > Export, avendo cura di esportare anche la chiave privata, inserendo una password alla richiesta.

3. Prendere il file formato pfx appena generato e spostarlo su una macchina Unix/Linux in cui e’ installato OpenSSL e digitare:

4. Il file formato PKCS12 non e’ altro che la concatenazione del certificato e della chiave privata che dovrete separare in due file con estensione .crt (certificato) e .key (chiave privata).

5. Per eliminare la password inserita durante l’esportazione (utile in ambienti di produzione in cui Apache deve avviarsi in modalita’ non assistita) digitare:

I file cosi’ ottenuti sono perfettamente compatibili in ambiente Apache.

In questi giorni ho deciso di pubblicare un mio sito web e su suggerimento di un mio carissimo amico ho deciso di optare per un nuovo CMS: Silverstripe.
Così come mi aveva anticipato il mio suggeritore, Silverstripe è meno potente del più diffuso Joomla, ma per coloro che non hanno esigenze particolari e necessitano di modificare\implementare CSS in maniera più semplice è sicuramente la scelta più azzeccata.
Scrivo questo post perchè ho “litigato” un pò con la messa a punto della configurazione del web server e spero che la mia esperienza possa tornarvi utile per farvi risparmiare un pò di tempo. Per le istruzioni dell’installazione di Silverstripe indicherò in seguito i riferimenti ufficiali.

La configurazione che ho adottato per il web server è la seguente:

• Centos 4.4 – Installazione minimal aggiornata con yum
• Apache 2.2
• Php 5.2
• MySql 5.0.5

Di seguito la procedura che ho utilizzato per l’installazione.

Ho installato il sistema operativo in configurazione minimal e successivamente ho utilizzato Yum per l’aggiornamento utilizzando l’opzione –enablerepo per scaricare gli aggiornamenti dai repository di Centos:

yum –enablerepo=centosplus update

Al termine dell’update ho proceduto al download dei sorgenti e degli RPM che Silverstripe richiede come requisiti:

httpd-2.2.8.tar.gz
php-5.2.6.tar.gz
MySQL-client-community-5.0.51a-0.rhel4.i386.rpm
MySQL-devel-community-5.0.51a-0.rhel4.i386.rpm
MySQL-server-community-5.0.51a-0.rhel4.i386.rpm
MySQL-shared-compat-5.0.51a-0.rhel4.i386.rpm

Prima di procedere alla compilazione dei pacchetti appena citati, ho installato gli strumenti che mi permattano la compilazione stessa:

yum install libgcc libgc-c++ ncurses-devel xml2

…e poi ho compilato….

tar zxvf httpd-2.2.8.tar.gz
cd httpd-2.2.8
./configure –prefix=/usr/local/apache2.2 –enable-modules=most
make
make install

tar zxvf php-5.2.6.tar.gz
cd php-5.2.6
./configure –prefix=/usr/local/php5.2 –with-apxs2=/usr/local/apache2.2/bin/apxs –with-config-file-path=/usr/local/apache2.2/php5.2 –with-mysql –with-gd –with-zlib –with-jpeg-dir –with-png-dir –with-openssl –with-tiff-dir –with-mysqli
make
make install

E’ possibile che durante la compilazione si verifichino degli errori dovuti alla mancanza di alcuni pacchetti nel sistema operativo, ma in quel caso gli errori sono estremamente comprensibili e Yum si conferma una gran bella invenzione.

Ora è la volta di MySql, ma qui ho utilizzato gli RPM scaricati da MySql e ho proceduto come di seguito…

rpm -iUh MySQL-client-community-5.0.51a-0.rhel4.i386.rpm MySQL-devel-community-5.0.51a-0.rhel4.i386.rpm MySQL-server-community-5.0.51a-0.rhel4.i386.rpm MySQL-shared-compat-5.0.51a-0.rhel4.i386.rpm

Una volta installato e startato il servizio del nostro DB ho configurato l’accesso con la seguente istruzione:

mysqladmin -u root password “password”

per testare che l’operazione sia andata a buon fine accedo al DB…

mysql -u root -p
“password”

Se riuscite ad entrare in MySQL vuol dire che la configurazione è andata a buon fine.

Ora non vi resta che scaricare Silverstripe.
Un consiglio che mi sento di suggerirvi, frutto del lavoro di alcune notti, è quello di scaricare silverstripe-v2.2.2-rc3.tar.gz invece della silverstripe-v2.2.1.tar.gz. Quest’ultima anche se definita stabile, ha diversi bug nei files di configurazione che impediscono una installazione in ambiente in cui non sono utilizzate le installazioni di default e navigando non si trovano molte soluzioni ai problemi che ho riscontrato.

Per “attivare” il nostro cms procediamo come segue:

tar zxvf silverstripe-v2.2.2-rc3.tar.gz
mv silverstripe-v2.2.2-rc3 silverstripe
cp silverstripe /usr/local/apache2.2/htdocs

e (come anticipato ad inizio post) seguire il tutorial sul sito di silverstripe il quale è estremamente chiaro ed esauriente.

In linea di massima tuttodovrebbe funzionare correttamente, ma in ogni caso sono qui per ricevere\dare consigli sulla ottimizzazione della configurazione, del resto come disse uno famoso (forse il mio compagno di banco??) “nessuno nasce imparato!”.