User Tools

Site Tools


doc:appunti:linux:sa:letsencrypt

Differences

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

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
Last revisionBoth sides next revision
doc:appunti:linux:sa:letsencrypt [2021/11/17 09:51] – [Verifica dei certificati HTTPS] niccolodoc:appunti:linux:sa:letsencrypt [2022/04/01 07:41] – [Utilizzo dei certificati con Postfix] niccolo
Line 76: Line 76:
 ===== Rimozione di un nome di dominio dai Subject Alternative Names ===== ===== 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]]**. 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 ===== ===== 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> <file>
Line 191: Line 197:
 </file> </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]]. 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 smtpd_tls_exclude_ciphers = aNULL, RC4
 </file> </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>
 +
 +^ 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 ===== ===== Verifica del certificato SMTP con STARTTLS =====
  
Line 274: Line 320:
 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. 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.
  
-Ad esempio, utilizzando **wget** da una **Debian 10.3** per accedere una risorsa https, si ottiene un errore del genere:+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> <code>
Line 287: Line 351:
 </code> </code>
  
-Su una **Debian 9** invece:+Su una **Debian 9** invece occorre il pacchetto che si trova attualmente in **stretch/updates**:
  
 <code> <code>
doc/appunti/linux/sa/letsencrypt.txt · Last modified: 2022/04/01 07:41 by niccolo