Differences

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

--- doc:appunti:linux:sa:letsencrypt [2019/02/27 15:29] – [Rinnovo dei certificati] niccolo
+++ doc:appunti:linux:sa:letsencrypt [2024/11/26 09:23] (current) – [Utilizzo dei certificati ProFTPD] 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 184: / 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 191: / 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, ad esempio [[https://ssl-tools.net/mailservers|ssl-tools.net]].
@@ Line 209: / 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 244: / 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**.
+===== Utilizzo dei certificati con ProFTPD =====
+Vedere **[[proftpd#supporto_tls|ProFTPD, supporto TLS]]**.
 ===== Verifica dei certificati POP/IMAP =====
@@ Line 267: / Line 322: @@
 /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)]]**