Re: certificati let's encrypt in tomcat
Il 23/03/21 15:58, Piviul ha scritto:
Grazie mille Paolo, ho ancora molta confusione; prima di capire cosa
vuole tomcat mi piacerebbe allora capire cosa mi restituisce
letsencrypt. Letsencrypt come dicevo genera 4 files: privkey.pem,
fullchain.pem, chain.pem e cert.pem. Accompagnati a questi 4 files c'è
il seguente README:
This directory contains your keys and certificates.
`privkey.pem` : the private key for your certificate.
`fullchain.pem`: the certificate file used in most server software.
`chain.pem` : used for OCSP stapling in Nginx >=1.3.7.
`cert.pem` : will break many server configurations, and should
not be used
without reading further documentation (see link below).
WARNING: DO NOT MOVE OR RENAME THESE FILES!
Certbot expects these files to remain in this location in order
to function properly!
We recommend not moving these files. For more information, see the
Certbot
User Guide at
https://certbot.eff.org/docs/using.html#where-are-my-certificates.
Secondo te quindi fullchain.pem è un certificato che contiene anche la
catena dei certificati?
Esatto, fullchain.pem contiene certificato + catena, che in sostanza
corrisponda a
$ cat cert.pem chain.pem > fullchain.pem
quindi puoi inserire in una configurazione le seguenti pseudo-direttive
(da riscrivere in base al server utilizzato):
> Certificato: fullchain.pem
> Chiave privata: privkey.pem
oppure
> Certificato: cert.pem
> Catena CA; chain.pem
> Chiave privata: privkey.pem
Inoltre ora tomcat sono riuscito a farlo funzionare con un certificato
autofirmato. Il certificato l'ho generato con un tool di tomcat che si
chiama keytool. Questo è il comando lanciato:
$ keytool -keysize 2048 -genkey -validity 1825 -keyalg RSA -alias
tomcat -keystore .keystore
Non conosco keystore e keytool, ho cercato un po' di info sulla manpage
e da quello che ho visto il keystore è un db di materiale crittografico
gestibile con keytool (man di keytool):
> The keytool command is a key and certificate management utility. It
enables users to administer their own
> public/private key pairs and associated certificates for use in
self-authentication (where the user
> authenticates himself or herself to other users and services) or data
integrity and authentication services,
> using digital signatures. The keytool command also enables users to
cache the public keys (in the form of
> certificates) of their communicating peers.
Il comando genkeypair (genkey è il vecchio nome che è meglio evitare di
usare, vedi man) genera chiave privata e chiave pubblica e da questa
genera un certificato autofirmato.
Una volta lanciato quel comando mi chiede una password e una serie di
informazione che poi compaiono nel certificato stesso (tipo nome,
cognome, azienda provincai, stato...).
Queste sono le informazioni che poi verranno inserite nel certificato
Poi ho copiato il file .keystore generato nella directory di tomcat e
ho dovuto mettere i riferimenti del file .keystore generato e la
password utilizzata nel file server.xml di tomcat:
<?xml version="1.0" encoding="UTF-8"?>
[...]
<!-- Define an SSL Coyote HTTP/1.1 Connector on port 8443 -->
<Connector
protocol="org.apache.coyote.http11.Http11NioProtocol"
port="8443" maxThreads="200"
scheme="https" secure="true" SSLEnabled="true"
keystoreFile="/etc/tomcat9/.keystore"
keystorePass="password utilizzata nella generazione del certificato"
clientAuth="false" sslProtocol="TLS"/>
Secondo te quindi il file .keystore contiene certificato e catena?
Qual'è il senso, secondo te, che io e tomcat condividiamo una stessa
password affinché tomcat possa utilizzare il certificato? Per caso sai
indirizzarmi su come si possa, con keytool, trasformare il certificato
letsencrypt in un certificato valido per tomcat?
keystore.db contiene il certificato, catena (in questo caso una sola CA,
la quella locale) e la chiave privata, in un formato tutto suo, che
dovrebbe poter contenere tutti i certificati necessari a java.
Le password sulle chiavi pubbliche che devono essere utilizzate da un
servizio secondo me sono sostanzialmente inutili se non dannose, perché,
come noti, poi devi comunque metterle in chiaro da qualche parte sul
sistema oppure essere presente ad ogni riavvio o crash per poterla
inserire ed fare ripartire il servizio...
Però se java lo richiede c'è poco da fare, potresti solo vedere se è
possibile generare un keystore senza password.
Ho visto che keytool ha una serie di parametri per generare i csr per la
richiesta di certificati a CA esterne (certreq) e per la loro
importazione dopo averli ricevuti (importcert), ma questo non si adatta
bene alla filosofia di let's encrypt, che punta tutto sull'automazione
del processo e il rinnovo ogni 3 mesi.
La soluzione più semplice è quella che ti hanno già suggerito, ovvero un
reverse proxy con nginx o apache che faccia da frontend TLS.
Alternativamente puoi vedere se le direttive citate in [1] possono
essere utilizzate con symlink ai file di certbot, di certo non è
pensabile di ricordarsi di copiare a mano i certificati ogni 90 giorni.
[1]
https://medium.com/@raupach/how-to-install-lets-encrypt-with-tomcat-3db8a469e3d2
Grazie mille
Piviul
--
Mandi.
Paolo
Reply to: