… que he tenido que poner en marcha algo más rápido de lo que tenía pensado.
Etiqueta: qpsmtpd
Certificados Let’s Encrypt en máquinas secundarias …
.. que sólo los consumen pero no los crean.
qpsmtpd y los complementos …
… y mi primera incursión en la ampliación del programa.
qpsmtpd como frontal para mi correo …
… con muchas ideas para realizar si funciona correctamente.
Aplicando certificados Let’s Encrypt en el sistema
Ya hemos usado un cliente para el proyecto Let’s Encrypt y hemos habilitado su renovación automática así que ahora lo que toca es emplearlo en los diferentes servicios del sistema.
Los que voy a comentar en esta entrada son:
- Servidor web
- Servidor SMTP
- Servidor IMAP/POP3
- Servidor XMPP
Servidor web Apache
Para declarar los certificados en el servidor Apache necesitamos añadir varias directivas a su configuración. Tal y como lo he organizado dispongo de tres juegos de certificados, uno por cada dominio principal, por lo que voy a crear tres archivos de configuración de manera que me sea más sencillo cargarlos en cada servidor virtual.
Sólo anoto aquí el ejemplo de uno de ellos
SSLEngine on SSLCipherSuite HIGH SSLProtocol all -SSLv2 SSLHonorCipherOrder on SSLCertificateFile /etc/letsencrypt.sh/certs/taquiones.net/fullchain.pem SSLCertificateKeyFile /etc/letsencrypt.sh/certs/taquiones.net/privkey.pem
Guardado como
/etc/apache2/conf.d/taquiones-ssl.conf
y cargado empleando la directiva
Include /etc/apache2/conf.d/taquiones-ssl.conf
. Las referencias sobre las otras opciones de SSL las he sacado, entre otras fuentes, de StackOverflow. Ahora, tras recargar la configuración podemos probar la nueva configuración gracias a la ayuda de SSL Labs.
Recepción de correo (servidor XMPP)
Para la recepción del correo estoy empleando qpsmtpd como frontal de exim4 y dado que es el encargado de identificar a los usuarios precisa de acceso a los certificados para las conexiones seguras.
El complemento TLS del programa no está escrito con mucho cariño, menos aún documentado, y me ha costado encontrar la forma de que funcione. Ya que qpsmtpd funciona con un usuario sin privilegios administrativos no tiene acceso a los archivos de los certificados; me he visto obligado a proporcionarle una copia de los mismos en su directorio de configuración
/etc/qpsmtpd/ssl
root@spin:/etc/qpsmtpd/ssl# ls -ltra total 20 -rw------- 1 qpsmtpd qpsmtpd 3875 abr 11 07:55 server.crt -rw------- 1 qpsmtpd qpsmtpd 3243 abr 11 07:55 private.key -rw------- 1 qpsmtpd qpsmtpd 3875 abr 11 08:01 ca.crt drwxr-xr-x 2 root root 4096 abr 11 08:21 . drwxr-xr-x 3 root root 4096 abr 11 08:56 ..
Para después indicar dónde están en la configuración (
/etc/qpsmtpd/plugins
):
# Habilitar conexiones seguras tls /etc/qpsmtpd/ssl/server.crt /etc/qpsmtpd/ssl/private.key /etc/qpsmtpd/ssl/ca.crt
Ahora sólo resta solucionar el detalle de que cada vez que se renueve un certificado se vuelvan a copiar los contenidos en su directorio particular. Para eso he modificado la función deploy_cert() en el script
/etc/letsencrypt.sh/hook.sh:
# y luego según el caso afinamos más case $DOMAIN in taquiones.net) # Detenemos el servidor smtp systemctl stop qpsmtpd # Copiamos los certificados para él QPSMTPD=/etc/qpsmtpd/ssl cp $KEYFILE $QPSMTPD/privkey.pem cp $CERTFILE $QPSMTPD/server.crt cp $FULLCHAINFILE $QPSMTPD/ca.crt # Reiniciar servidores de correo, mensajería ... echo "Reiniciando servidores de correo y mensajería ..." >&2 systemctl start qpsmtpd systemctl restart dovecot systemctl restart prosody ;; esac
Servidor IMAP/POP3 (dovecot)
Este ha sido el más sencillo de configurar. Para habilitar las conexiones seguras de los protocolos de acceso a los buzones de correo basta con añadir unas estrofas a su archivo de configuración en
/etc/dovecot/dovecot.conf
:
ssl_ca = </etc/letsencrypt.sh/certs/taquiones.net/fullchain.pem ssl_cert = </etc/letsencrypt.sh/certs/taquiones.net/fullchain.pem ssl_key = </etc/letsencrypt.sh/certs/taquiones.net/privkey.pem
Servidor XMPP (prosody)
Con este programa nos encontramos con el mismo problema que con qpsmtpd: funciona con una cuenta de usuario normal y no tiene acceso a los certificados. He tenido que implementar la misma técnica y copiar los certificados a un directorio privado
/etc/prosody/certs/
e indicarle que los tomase de allí
-- These are the SSL/TLS-related settings. If you don't want -- to use SSL/TLS, you may comment or remove this ssl = { key = "/etc/prosody/certs/taquiones.net.key"; certificate = "/etc/prosody/certs/taquiones.net.cert"; }
Resumiendo
El programa letsencrypt.sh conserva los certificados bajo permisos muy restrictivos y a menos que el servicio funcione como apache (arranque como root, lea los certificados y luego cambie al usuario normal) será necesario efectuar una copia tras la renovación (o la creación inicial) para que los servidores funcionen. En el resto no he encontrado más problemas.