Durante l’ultima workweek Mozilla a Orlando ho assistito a una breve presentazione di Let’s Encrypt da parte di Eric Rescorla (:ekr). Mi ero ripromesso di fare qualche prova al ritorno e, complice il passaggio da dedicato+debian+apache a vps+ubuntu+nginx, mi sono finalmente deciso a farlo.

Che cos’è “Let’s Encrypt”: un’autorità di certificazione indipendente e aperta che permette al proprietario di un sito web di ottenere gratuitamente dei certificati. Per ulteriori dettagli consiglio la lettura del post inaugurale del blog.

Veniamo al dunque: come ottenere un certificato per il dominio che ospita questo blog e configurare nginx per utilizzarlo.

Per prima cosa bisogna clonare il repository (non esiste ancora un pacchetto per Ubuntu):

git clone https://github.com/letsencrypt/letsencrypt
cd letsencrypt

Come spiegato nella documentazione: letsencrypt-auto è un wrapper che si occupa di installare le dipendenze e creare un ambiente virtuale per Python, e il plugin per nginx è ancora altamente sperimentale (al contrario di Apache).

Nel mio caso voglio:

• ottenere solamente il certificato senza modificare alcuna configurazione;
• utilizzare il webserver “standalone” per recuperare il certificato. Siccome il plugin occupa la porta 80 o la 443, potrebbe essere necessario bloccare temporaneamente il server nginx.

Questo è il contenuto del file di configurazione per evitare una linea di comando infinita (modificare l’indirizzo email)

# Use a 4096 bit RSA key instead of 2048
rsa-key-size = 4096
email = YOUREMAIL@EXAMPLE.COM

# Standalone authenticator on port 443
authenticator = standalone
standalone-supported-challenges = tls-sni-01

E questo il comando da lanciare (modificare il dominio e il percorso al file di configurazione)

./letsencrypt-auto certonly --config /root/cli.ini -d EXAMPLE.COM

La prima volta verrà chiesto di accettare le condizioni di servizio. Dopo pochi istanti il certificato verrà salvato in una sottocartella di /etc/letsencrypt/live/.

A questo punto bisogna aggiornare la configurazione del dominio in nginx. Personalmente ho utilizzato il generatore messo a disposizione da Mozilla, modificando

    ssl_dhparam /etc/nginx/dhparam.pem;
    ssl_certificate /etc/letsencrypt/live/www.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/www.example.com/privkey.pem;

E rimuovendo la linea ssl_session_tickets off; (non compatibile con la mia versione di nginx).

Per utilizzare questa configurazione, la prima volta bisogna generare una chiave Diffie-Hellman:

cd /etc/nginx
openssl dhparam -out dhparam.pem 2048

Se riuscite a leggere questo post, significa che non è esploso nulla.

Normalmente utilizzo Debian stable e Apache su tutte le mie VM. In questi giorni sto facendo qualche prova in locale con Ubuntu Server LTS (14.04) e NGINX, giusto per capire come funzionano le cose.

La prova è semplice: prendi una VM con risorse limitate (1 core, 2GB di RAM), installaci sopra WordPress (per la precisione un backup di questo blog), e prova a vedere come gira.

$ siege -c 100 -r 10 -b http://localvm/blog

Transactions:               2000 hits
Availability:             100.00 %
Elapsed time:               3.24 secs
Data transferred:          14.23 MB
Response time:              0.16 secs
Transaction rate:         617.28 trans/sec
Throughput:             4.39 MB/sec
Concurrency:               96.03
Successful transactions:        2000
Failed transactions:               0
Longest transaction:            0.69
Shortest transaction:           0.00

Poi mi è venuto in mente di provare a disattivare WP Super Cache.

$ siege -c 100 -r 10 -b http://localvm/blog

Transactions:               2000 hits
Availability:             100.00 %
Elapsed time:             138.59 secs
Data transferred:          14.15 MB
Response time:              6.61 secs
Transaction rate:          14.43 trans/sec
Throughput:             0.10 MB/sec
Concurrency:               95.39
Successful transactions:        2000
Failed transactions:               0
Longest transaction:           14.90
Shortest transaction:           0.00

Mentre nel primo caso il load era intorno a 0.2, nel secondo ha raggiunto piuttosto rapidamente 5. Morale della favola: utilizzate un plugin per la cache, c’è l’imbarazzo della scelta.