Differences

This shows you the differences between two versions of the page.

--- doc:appunti:linux:sa:letsencrypt [2018/01/12 16:09] – [Utilizzo dei certificati con Courier POP e IMAP] niccolo
+++ doc:appunti:linux:sa:letsencrypt [2022/04/01 09:41] (current) – [Certificati TLS come client] niccolo
@@ Line 76: / Line 76: @@
 ===== Rimozione di un nome di dominio dai Subject Alternative Names =====
-Pare che vi sia un bug al momento in cui si cerca di **togliere un nome di dominio** dall'elenco dei nomi alternativi **SAN** (Subject Alternative Names); alla successiva esecuzione di **certbot certonly** viene creata una nuova //lineage// di certificati in una cartella appositamente creata: **''/etc/letsencrypt/archive/<domain>-0001/''**, anche nella directory **''/etc/letsencrypt/live/''** venono creati i link simbolici sotto una nuova directory con il suffisso ''-0001''. Ovviamente i vari software (Apache, Postfix, ecc.) continueranno ad utilizzare la vecchia lineage di certificati.
+Se si desidera **togliere un nome di dominio** dall'elenco dei nomi alternativi **SAN** (Subject Alternative Names), si deve eseguire nuovamente il comando **certbot certonly** passando il nuovo elenco (ridotto) dei nomi e relative web root.
+C'è tuttavia un inconveniente (ancora con certbot v.0.31): alla successiva esecuzione di **certbot certonly** viene creata una nuova //lineage// di certificati in una cartella appositamente creata: **''/etc/letsencrypt/archive/<domain>-0001/''**, anche nella directory **''/etc/letsencrypt/live/''** venono creati i link simbolici sotto una nuova directory con il suffisso ''-0001''. Ovviamente i vari software (Apache, Postfix, ecc.) continueranno ad utilizzare la vecchia lineage di certificati.
 Vedere in proposito questo **[[https://community.letsencrypt.org/t/how-to-prevent-creation-of-etc-letsencrypt-live-domain-tld-0001-when-removing-domains-from-a-domain-tld-multidomain-certificate/8135/3|post]]** e questo **[[https://github.com/certbot/certbot/issues/2071|bug]]**.
@@ Line 101: / Line 103: @@
 Questo rende **impossibile il funzionamento** di **certbot** che si basa sul fatto di poter pubblicare temporaneamente il //challenge// sul dominio web (senza SSL).
-Conviene in questo caso creare una DocuemtnRoot ad-hoc, che effettui il redirect su hpps via PHP invece che con direttiva Apache. Questa stessa DocumentRoot sostanzialmente vuota può essere condivisa da diversi VirtualHost, anche con nomi a dominio diversi. La configurazione Apache diventa:
+La soluzione più elegante può essere quella di effettuare il redirect ad eccezione per la **.well-known** directory:
+<file>
+    RedirectMatch permanent ^/((?!\.well-known).*)$ https://mail.rigacci.org/$1
+</file>
+Una alternativa può essere quella di creare una DocuemtnRoot ad-hoc, che effettui il redirect su hpps via PHP invece che con direttiva Apache. Questa stessa DocumentRoot sostanzialmente vuota può essere condivisa da diversi VirtualHost, anche con nomi a dominio diversi. La configurazione Apache diventa:
 <file>
@@ Line 132: / Line 140: @@
 </code>
+===== Directory protetta da .htaccess =====
+Se un intero sito è protetto da una direttiva tipo **AuthType Basic** (ad esempio con una accoppiata di file **.htaccess** e **.htpasswd**), la procedura di **certbot fallisce** perché il server remoto non è in grado di accedere via HTTP alla sottodirectory **/.well-known/** creata appositamente (nella quale viene creato il challenge provvisorio).
+È quindi necessario escludere la sottodirectory **/.well-known/** dalla direttiva **AuthType Basic**, ad esempio creando un apposito file **.htaccess** che contiene:
+<file>
+AuthType None
+Require all granted
+</file>
 ===== Rinnovo dei certificati =====
@@ Line 144: / Line 160: @@
 si verifica e si rinnovano tutti i certificati contenuti in **''/etc/letsencrypt/live/''**. Eventualmente si aggiunge l'opzione **''%%-q%%''** per fare un cronjob che non genera messaggi inutili.
+Il pacchetto **Debian 9 Stretch** di **certbot** installa un cronjob **/etc/cron.d/certbot** che però non viene eseguito poiché è attiva la gestione dei processi di **systemd**. Infatti risulta registrato con //systemd// il **certbot.timer**, che provvede ad eseguire l'aggiornamento a intervalli regolari.
+Verificare che il timer sia abilitato e attivo:
+<code>
+systemctl enable certbot.timer
+systemctl start certbot.timer
+systemctl status certbot.timer
+</code>
+===== Reload di Apache =====
+Dopo aver esteso un certificato (e quindi anche dopo un rinnovo automatico?) è necessario notificare il demone apache almeno con un reload, ad esempio con **systemctl reload apache2.service**.
 ===== Utilizzo dei certificati con Exim4 =====
@@ Line 158: / Line 186: @@
 ===== Utilizzo dei certificati con Postfix =====
-Sembra che con i permessi predefiniti Postfix riesca a leggere i certificati direttamente dalla directory di Let's Encrypt, quindi è sufficiente mettere in **''/etc/postfix/main.cf''**:
+Con i permessi predefiniti Postfix riesce a leggere i certificati direttamente dalla directory di Let's Encrypt (provato con Debian versione da 9 a 11). Se il file certificato viene aggiornato è necessario fare un **reload** del demone.
+==== Certificati TLS come server ====
+Per offrire TLS ai clienti che si connettono è sufficiente mettere in **''/etc/postfix/main.cf''**:
 <file>
@@ Line 165: / Line 197: @@
 </file>
-Se il file certificato viene aggiornato è necessario fare un **reload** del demone.
-Conviene verificare il **livello di crittografia** offerto dal server e **disabilitare tutti i sistemi deboli o difettosi**. Esistono diversi servizi on-line che consentono di fare il check.
+Conviene verificare il **livello di crittografia** offerto dal server e **disabilitare tutti i sistemi deboli o difettosi**. Esistono diversi servizi on-line che consentono di fare il check, ad esempio [[https://ssl-tools.net/mailservers|ssl-tools.net]].
 Alcuni algoritmi di crittografia utilizzano i parametri di **Diffie-Hellman** e per avere una sicurezza accettabile richiedono più di 1024 bit. L'impostazione predefinita (almeno su Debian Jessie) è invece limitata a 1024 bit.
@@ Line 183: / Line 214: @@
 smtpd_tls_exclude_ciphers = aNULL, RC4
 </file>
+==== Certificati TLS come client ====
+Per utilizzare TLS quando si effettua il relay ad altri server è necessario mettere quanto segue in **''/etc/postfix/main.cf''**:
+<file>
+# Use TLS as a client, when the relaying server supports it.
+smtp_tls_security_level = may
+smtp_tls_cert_file = /etc/letsencrypt/live/supermail.texnet.it/fullchain.pem
+smtp_tls_key_file = /etc/letsencrypt/live/supermail.texnet.it/privkey.pem
+</file>
+Se si preferisce attivare TLS **solo verso alcuni host** è possibile usare la direttiva **smtp_tls_policy_maps** in questo modo:
+<file>
+# Use TLS as a client, only for some relay hosts.
+smtp_tls_security_level = none
+smtp_tls_cert_file = /etc/letsencrypt/live/supermail.texnet.it/fullchain.pem
+smtp_tls_key_file = /etc/letsencrypt/live/supermail.texnet.it/privkey.pem
+smtp_tls_policy_maps = hash:/etc/postfix/smtp_tls_policy_maps
+</file>
+Il file **/etc/postfix/smtp_tls_policy_maps** deve contenere l'elenco dei domini con una impostazione più restrittiva di **none**, ad esempio **may** oppure **encrypt** (il file deve essere compilato con **postmap**):
+<file>
+gmail.com      may
+rigacci.org    encrypt
+</file>
+Lato ricevente si può verificare che il trasporto sia avvenuto utilizzando crittografia TLS; negli header del messaggio deve risultare **ESMTPS** invece di **ESMTP**:
+<file>
+Received: from mail.mydomain.org (mail.mydomain.org [68.129.233.182])
+        by mail.rigacci.org (Postfix) with ESMTPS id 875378008E
+        for <niccolo@rigacci.org>; Thu, 31 Mar 2022 10:39:43 +0200 (CEST)
+</file>
+Queste sono acluni degli acronimi per i vari protocolli di trasporto email:
+^ ESMTP    | Extended Simple Mail Transfer Protocol (aggiunge security, authentication, etc. a SMTP)  |
+^ ESMTPS   | ESMTP con STARTTLS  |
+^ ESMTPSA  | ESMTP con STARTTLS e SMTP AUTH  |
 ===== Verifica del certificato SMTP con STARTTLS =====
@@ Line 218: / Line 292: @@
 Il file .pem viene indicato con la direttiva **TLS_CERTFILE** nei file **/etc/courier/imapd-ssl** e **/etc/courier/pop3d-ssl**.
+Attenzione ai permessi: il certificato non deve essere leggibile al mondo e con **Debian 10** bisogna che il file sia **leggibile all'utente courier**.
 ===== Verifica dei certificati POP/IMAP =====
@@ Line 233: / Line 309: @@
 OK - Certificate 'mail.markcommunication.com' will expire on Sat 12 Jun 2021 10:57:00 AM CEST.
 </code>
+===== Verifica dei certificati HTTPS =====
+La verifica del certificato SSL per il protocollo **HTTPS** può essere fatta con il plugin Nagios **check_http**:
+<code>
+/usr/lib/nagios/plugins/check_http --ssl -H 'www.rigacci.org' -I '176.9.39.130' -C 28
+</code>
+===== Certificato DST Root CA X3 scaduto =====
+Il **30 settembre 2021** è scaduto il certificato **ST Root CA X3**, si tratta di un certificato root utilizzato per cross-firmare molti certificati SSL rilasciati in passato da Let's Encrypt. I nuovi certificati sono invece firmati con il nuovo certitificato **ISRG Root X1**, che però potrebbe non essere riconosciuto dai client un po' datati.
+Anzitutto conviene confermare che il certificato in uso al **server** non sia scaduto e che sia firmato con il nuovo ISRG Root X1:
+<code>
+openssl x509 -text -noout -in /etc/letsencrypt/live/domain.tld/chain.pem
+</code>
+Dovrebbe risultare quanto segue:
+<code>
+...
+    Signature Algorithm: sha256WithRSAEncryption
+        Issuer: C = US, O = Internet Security Research Group, CN = ISRG Root X1
+        Validity
+            Not Before: Sep  4 00:00:00 2020 GMT
+            Not After : Sep 15 16:00:00 2025 GMT
+...
+</code>
+Sul **client** invece si verifica l'errore; ad esempio, utilizzando **wget** da una **Debian 10.3** per accedere una risorsa https, si ottiene qualcosa del genere:
+<code>
+ERRORE: il certificato di "www.rigacci.org" non è fidato.
+ERRORE: Il certificato di "www.rigacci.org" è scaduto.
+</code>
+Quindi su una **Debian 10** è stato necessario aggiornare il seguente pacchetto:
+<code>
+libgnutls30   3.6.7-4+deb10u2  =>  3.6.7-4+deb10u7
+</code>
+Su una **Debian 9** invece occorre il pacchetto che si trova attualmente in **stretch/updates**:
+<code>
+libgnutls30   3.5.8-5+deb9u5  =>  3.5.8-5+deb9u6
+</code>
+Con una **CentOS 7** invece è stato necessario aggiornare il pacchetto **ca-certificates**.
+Vedere **[[https://letsencrypt.org/docs/dst-root-ca-x3-expiration-september-2021/|DST Root CA X3 Expiration (September 2021)]]**