We are trying to get dovecot mailserver running under SSL using the certbot cert for the site: mail.privustech.com
We have a composite LE cert that includes four https vhosts plus the mail vhost. All five sites get an “A” from Qualys.
The mail server has its own vhost mail.privustech.com and comprises dovecot and postfix on the host server (hostnamelavarre) as well as the vhost at /srv/www/htdocs/mailprivustech. The vhost is accessible by wwwrun:www and readable at https://mail.privustech.com
So we now try to obtain a standalone cert for the mail server. https://www.howtoforge.com/community/threads/letsencrypt-on-mail-server.73695/ certbot certonly --webroot -w /srv/www/htdocs/mailprivustech -d mail.privustech.com
We use the staging version for testing: certbot certonly --staging --webroot -w /srv/www/htdocs/mailprivustech -d mail.privustech.com
It fails with
**The client lacks sufficient authorization**,
although certbot has root privileges: -rwxr-xr-x 1 root root 384 Jan 12 08:54 /usr/bin/certbot
and the webroot is world-readable by wwwrun:www
We also tried --webroot-path/srv/www/htdocs, /srv/www, and /var/www.
/etc/apache2/listen.conf includes listen 80 and listen 443. listen 993 is commented out, since if apache listens on 993 then dovecot fails.
You've misinterpreted this part of the FAQ and maybe we should update it to be clearer on this point.
In this case "email encryption" refers to S/MIME encryption (between one end-user's e-mail client and another's). It doesn't refer to TLS encryption used by an e-mail server to protect connections to that server, as with STARTTLS in SMTP, or IMAPS, or SMTPS protocols. Let's Encrypt's ordinary certificates are fine for these uses and you don't need a separate certificate or a special kind of certificate to protect TLS sessions used for the delivery or retrieval of e-mails.
By contrast, S/MIME allows an e-mail author to encrypt the body of a message inside his or her e-mail client so that it can only be decrypted later inside the e-mail client of the intended recipient. This requires a different kind of certificate that Let's Encrypt doesn't issue, but this is probably not your intended application here.
schoen is correct. If you already have a certificate including the FQDN mail.privustech.com, and clients use that hostname for their SMTP and IMAP clients, you can use that certificate in Postfix and Dovecot.
We specify in /etc/dovecot/conf.d/10-ssl.conf to use ssl and give the path to the cert and key.
The default for 10-ssl.conf is to include a “from/less than” symbol (<) before the path.
The two lines pointing to the cert and key are: ssl_cert = </etc/certbot/live/privustech.com/fullchain.pem ssl_key = </etc/certbot/live/privustech.com/privkey.pem
I’ve checked the targets of these links (…/…/archive/privustech.com/fullchain4.pem, …/…/archive/privustech.com/fullchain4.pem) and they are valid, plus as reported, Qualys gives us “A” grades on all the sites.
However, including the ‘<’ symbol prevents dovecot starting, removing it lets dovecot start but it then throws an error: No peer certificate available No client certificate CA names sent
The “client” is the localhost CLI issuing openssl and besides, CA certs are not required unless we require client certification, which we expressly do not (# ssl_verify_client_cert= is commented out)
So to what do peer certificate and client certificate CA names refer, and what is with the ‘<’ symbol?
Maybe dovecot prints the error to stderr when it fails to start? Check your syslog or systemctl status -l dovecot
My guess would be the user dovecot is running as doesn’t have permission to access the certificate files, or maybe the process doesn’t have the necessary SELinux or AppArmor permission.
Hi! Not sure if I understand you right, but are you linking the same file (fullchain4.pem) twice? I also use let’s encrypt with my dovecot-setup on a debian-system and my 10-ssl.conf looks like:
Tracer hi, thank you.
My paths look like yours except for the < symbol. dovecot does not run
for me with the symbol there.
The multiple links are because that’s what certbot created, but to
check I changed to directly referencing the fullchain4.pem and
privkey4.pem with no success. @osirius: The exact error message is:
lavarre dovecot: imap-login: Fatal: Can’t load ssl_cert: There is no
valid PEM certificat
e. (You probably forgot ‘<’ from
ssl_cert=</etc/certbot/live/privustech.com/fullchain.pem)
Details below.
I’ve started with a fresh install and all these are repeatable…
Thanks again, Andy