Fortunatamente qualcuno ha pensato anche a chi con Internet ci si diverte solo:
StartSSL offre certificati
GRATUITI sia per la mail che per ssl (e non solo). Certo, i certificati gratuiti hanno qualche limitazione, ma non eccessiva (dovuta, principalmente, al basso grado di affidabilità della verifica che viene effettuata). Le limitazioni NON intaccano la sicurezza del certificato che, anzi, è superiore a quella di altri ben più costosi (2048 o 4096 bit di modulo RSA).
Se poi si vuole un certificato che non riporti "Organization=Persona Not Validated", basta pagare circa 50$ una tantum ed inviare un paio di foto di documenti. Il bello è che non sono 50$ per certificato o per anno! Finché i certificati sono per la persona identificata, rimangono gratuiti! Infatti StartSSL si fa pagare solo il lavoro di verifica, che non è più necessario per gli ulteriori certificati.
Aggiornamento 07/01/2010: la certificazione di livello 2 con StartSSL permette di emettere certificati per 350 giorni dal momento della verifica. I certificati hanno durata di 2 anni, quindi, se non avete bisogno di ulteriori certificati, potete validarvi una volta ogni (circa) 3 anni... Piccola nota a margine: viene effettuata anche una verifica del numero di telefono e/o dell'indirizzo (rispettivamente con bolletta+telefonata o lettera con istruzioni da seguire), quindi fate in modo di avere i documenti con l'indirizzo aggiornato e magari anche una bolletta. Altra possibilità per ottenere certificati gratuitamente è partecipare alla Web of Trust, contattando un "notaio" vicino a voi.
Un altro provider gratuito di certificati è CAcert, ma non è incluso tra gli enti certificatori 'ufficiali', quindi l'utente deve prima installare il loro certificato per poter verificare il vostro...
Ovviamente, sul mio hosting personale ho già installato il certificato per https://csshl.org/ . Prossimamente studierò se/come gestire il multi-dominio.
Aggiornamento 07/09/2010: Ho fatto qualche prova per la gestione del multi-dominio.
Il problema è che la mia linea ha a disposizione un solo indirizzo IP.
Quindi per poter avere in https anche www.openalarm.info non posso usare IP-based-vhost (deve essere tutto su un unico IP), non posso mettere tutti i domini nel certificato di csshl.org, ma devo usare port-based-vhost. Peccato che questo richieda anche l'indicazione della porta, che non sarà più quella standard (443) ma, nel mio caso, la 444 (ocio ad espandere: le porte "sicure", cioè al di sotto della 1024, sarebbero tutte "riservate" per determinati servizi... la 445, per esempio, viene usata per le condivisioni Windows e quindi non è disponibile come porta per https!).
Ma dover aggiungere il numero di porta dopo l'indirizzo è brutto. Ed espone ad errori: che succede se un domani voglio spostare i vari server https sulle porte 44300-44399? Tutti gli utenti devono esserne informati, devono aggiornare i bookmark e comunque continuano a vedere un 'brutto' indirizzo. Come me (ma qualche anno prima...) l'ha pensata qualcun altro, tanto che è stato creato un apposito RFC, il 2782, che prevede di fornire il numero di porta tramite il DNS! Banale, una volta che ci si sia pensato. Sono oramai passati parecchi anni, e molti programmi (jabber, SIP, vari LDAP tra cui Active Directory, Kerberos...) lo usano tranquillamente. Eccezione notevole: i browser, malgrado sia dal 1999 che sarebbe disponibile una patch almeno per Firefox!
Attualmente www.openalarm.info dovrebbe essere ben configurato:
$ dig @ns3.eu.editdns.net -tsrv _https._tcp.openalarm.info
; <<>> DiG 9.6.2-P2 <<>> @ns3.eu.editdns.net -tsrv _https._tcp.openalarm.info
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5866
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available
;; QUESTION SECTION:
;_https._tcp.openalarm.info. IN SRV
;; ANSWER SECTION:
_https._tcp.openalarm.info. 600 IN SRV 1 0 444 openalarm.info.
;; Query time: 31 msec
;; SERVER: 95.172.4.250#53(95.172.4.250)
;; WHEN: Tue Sep 7 14:05:27 2010
;; MSG SIZE rcvd: 78
peccato che manchi il supporto nei browser...
E visto che i browser non si danno una mossa, c'è chi pensa di modificare opportunamente i server: da Apache 2.2.12 (non ancora disponibile in Debian Lenny, ma non mi stupisco troppo: Drupal è ancora alla versione 6.6 contro la 6.19!) è disponibile SNI. Peccato che questo richieda sia un certo supporto da parte del browser (che comunque secondo questo articolo è già piuttosto diffuso, anche se manca in IE7 su WinXP), sia il supporto da parte del server...
Aggiornamento 29/11/2010: è possibile usare GnuTLS invece di SSL per avere SNI anche in Lenny. Ora, infatti, potete accedere a https://www.openalarm.info senza problemi (basta che usiate un browser che supporta SNI, ovviamente). I problemi li ho avuti io per capire cosa modificare nella configurazione!
Intanto, va installato il pacchetto libapache2-mod-gnutls.
Poi tutte le direttive SSL* vanno tolte.
Va poi inserito, per ogni sito:
GnuTLSEnable on
GnuTLSExportCertificates on
GnuTLSCacheTimeout 300
GnuTLSCertificateFile /var/www/clients/client1/web2/ssl/openalarm.info.crt
GnuTLSKeyFile /var/www/clients/client1/web2/ssl/openalarm.info.key
GnuTLSPriorities NORMAL:!DHE-RSA:!DHE-DSS:!AES-256-CBC:%COMPAT
Inoltre va disabilitato mod_ssl (con a2dismod ssl), attivato mod_gnutls (con a2enmod gnutls), e sostituiti i vari <IfModule mod_ssl.c> con <IfModule gnutls_module>. Poi riavviate (/etc/init.d/apache2 restart) il server e... NON FUNZIONANO PIÙ I SITI IN SSL!
Paura, eh? Ovviamente manca qualcosa... Mi ci è voluto un po' per capire cosa, ma alla fine ci sono arrivato. Se siete più svegli di me (facile! 
) allora potete saltare il prossimo paragrafo...
A dire il vero un piccolo glitch c'è: non vengono riconosciuti tutti i siti in ServerName/ServerAlias (anche se dovrebbe funzionare...). Problema abbastanza piccolo ma condiviso, anche se per il momento non ho trovato una soluzione. Alcuni dicono di utilizzare l'IP del server invece di *, ma io non ho notato la minima differenza. È molto probabile che questo sia dovuto al fatto che la versione di Apache inclusa in Lenny (la 2.2.9) non supporta ancora ufficialmente SNI... Per questo, talvolta, mi sono ritrovato sulla pagina di csshl.org malgrado stessi accedendo ad openalarm.info...
Documentazione (in inglese) se ne trova, anche se "distillare" le info utili può non essere banale. OutOfOrder ha una documentazione piuttosto esaustiva, con esempi. Peccato che non mi abbia aiutato "sufficientemente".
Mi sono quindi deciso ad installare Apache 2.2.16 di Squeeze (unstable) e tornare a mod_ssl...
Ho quindi sostituito 'lenny' con 'unstable' in /etc/apt/sources.list, alla linea:
deb ftp://ftp.it.debian.org/debian/ lenny contrib main non-free
e lanciato un bel apt-get update.
A quento punto, ho provveduto ad aggiornare solo Apache e le sue dipendenze con apt-get install apache2.
A questo punto ho ripristinato il sources.lst, rimosso libapache2-mod-gnutls e sistemato /etc/apache2/ports.conf aggiungendo NameVirtualHost *:443 dopo Listen 443. Un bel restart di Apache e funziona tutto!
Per chi usa ISPConfig, c'è anche un bel tutorial su come modificare i template per il supporto a GnuTLS... Ma a questo punto è piuttosto inutile... anche se almeno indica come modificare il template (/usr/local/ispconfig/server/conf/vhost.conf.master) per sistemare le "cosine" che servono per il name-based-vhost su SSL:
- eliminare "Listen 443" e "NameVirtualHost *:443" dalle configurazioni dei singoli siti (vanno messe in ports.conf, e si evitano gli errori "NameVirtualHost ... has no hosts") -- forse questo non serve e l'ho trovato nei miei file per qualche vecchia prova, ma meglio verificare
- aggiungere
SSLOptions StrictRequire subito dopo SSLEngine on
- aggiungere SSLRequireSSL all'interno delle due sezioni Directory
Se volete gestire un sito che sia completamente valido sia come http che come https, dovete fornire localmente tutti i contenuti (immagini e script), altrimenti l'utente riceverà un avviso (pagina non completamente criptata). Su OpenAlarm il bannerino di EditDns e lo script di tracking per le pagine erano esterni, quindi avreste ricevuto un warning. Mentre il bannerino non è stato un problema (è bastato "servirlo" da locale), per lo script questo non è possibile (JavaScript può comunicare solo col dominio da cui proviene lo script, per motivi di sicurezza): è necessario che il fornitore dello script preveda l'accesso tramite https. Quindi è bene che un sito https sia pensato appositamente e venga ben controllato.
