I have a mail server that I am using letsencrypt for the certs, it worked great for one domain but as soon as I added a second domain and upgraded the cert to work for both domains it broke my ability to send emails and just throws SMTP Error 454: Authentication Failed every time I try to send. It seemed to break after creating the new Server block for nginx for mail.domain 2 and after creating the new cert is when it broke.
If you have multiple domains on your mail server then either:
- You need to configure it with a single certificate that covers every domain, or
- You need to configure its SNI map so that it uses the appropriate certificate for each domain
The details of that are going to depend what your mailserver is and what domains and certificates you have.
454 also refers to a lot of different errors, it would help to have the exact error from the mail server's logs.
Hi there _az,
I used the command to re-generated the new cert for the new domain and that's when things broke.
sudo certbot certonly --webroot --agree-tos -d mail.domain1.com,mail.domain2.com --cert-name mail.domain1.com --email your-email-address -w /var/www/html
Hi @KyleBrown
please answer all of the following questions:
Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. https://crt.sh/?q=example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.
My domain is:
I ran this command:
It produced this output:
My web server is (include version):
The operating system my web server runs on is (include version):
My hosting provider, if applicable, is:
I can login to a root shell on my machine (yes or no, or I don't know):
I'm using a control panel to manage my site (no, or provide the name and version of the control panel):
The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot):
My domain is: 2e0epv.com & kylebrown.co.uk
I ran this command: mention that you used this to re-generated the new cert for the new domain
sudo certbot certonly --webroot --agree-tos -d mail.2e0epv.com,mail.kylebrown.co.uk --cert-name mail.2e0epv.com --kyle@kylebrown.co.uk -w /var/www/html
after running that that's when it broke the SMTP side.
It produced this output: Gave me the new cert.
My web server is (include version): N/A
The operating system my web server runs on is (include version): Ubuntu 20.04 LTS
My hosting provider, if applicable, is: Digital Ocean
I can log in to a root shell on my machine (yes or no, or I don't know): Yes
I'm using a control panel to manage my site (no, or provide the name and version of the control panel): No
The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot): certbot 0.40.0
nginx version: nginx/1.18.0 (Ubuntu)
You are asking for a cert with two names on it but provide only one webroot path...
Q1. Are they both being served from the same directory (/var/www/html) ?
Q2. Why do you need to use multiple names for a single email server ?
1 Like
Checking your first domain that's good - https://check-your-website.server-daten.de/?q=mail.2e0epv.com#connections - Grade B:
CN=mail.2e0epv.com
21.09.2020
20.12.2020
expires in 89 days mail.2e0epv.com, mail.kylebrown.co.uk - 2 entries
So the certificate creation has worked.
What says
certbot certificates
Your IMAP 993 port has the correct certificate. Your port 587 looks wrong. Is there the new certificate?
PS: Do you use mail.kylebrown.co.uk or kylebrown.co.uk to connect your domain? Same with your other domain? Without mail -> the certificate is wrong.
What do you recommend I do?
Both were mail.fqdn when they were created.
I don't understand your error.
I don't see the expected errors. Your configuration looks ok. Port 587 doesn't work with OpenSsl, but I don't know if you use that port.
The command
openssl s_client -starttls smtp -connect mail.kylebrown.co.uk:587
does not present any certificate:
CONNECTED(00000003)
3069317136:error:1408F10B:SSL routines:ssl3_get_record:wrong version number:../ssl/record/ssl3_record.c:332:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 246 bytes and written 340 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---
Have your mail server found and read the certificate (permission problem)?
Did you check the mail log when you restart your MTA / MSA?
1 Like
I do use 587 submission for sending mail. For the permission answer i went into /etc/letsencrypt/live then run ls - l. The output was this.
There is no certificate configured, so the error is expected.
What do I need to do. Nginx, Postfix and Dovecot are pointing to /etc/letsencrypt/live
I don't know, I don't use these mail servers. Check their documentation how to configure port 587.
Could this be something to do with the issue?
root@mail:/# cd /etc/letsencrypt/live/mail.2e0epv.com/
root@mail:/etc/letsencrypt/live/mail.2e0epv.com# ls -la
total 12
drwxr-xr-x 2 root root 4096 Sep 21 20:06 .
drwx------ 4 root root 4096 Sep 22 09:09 ..
-rw-r--r-- 1 root root 692 Sep 19 11:45 README
lrwxrwxrwx 1 root root 39 Sep 19 11:45 cert.pem -> ../../archive/mail.2e0epv.com/cert1.pem
lrwxrwxrwx 1 root root 40 Sep 21 20:06 chain.pem -> ../../archive/mail.2e0epv.com/chain2.pem
lrwxrwxrwx 1 root root 44 Sep 21 20:06 fullchain.pem -> ../../archive/mail.2e0epv.com/fullchain2.pem
lrwxrwxrwx 1 root root 42 Sep 21 20:06 privkey.pem -> ../../archive/mail.2e0epv.com/privkey2.pem
root@mail:/etc/letsencrypt/live/mail.2e0epv.com#
That is the normal file structure (linked to latest).
But I do also see a problem with the dates (not all Sep 21) and the files linked to are not all the same iteration (#2).
So yes, it would seem that the current linked live/cert.pem file is pointing to the previously issued cert (not to the latest one).
So if I can find the latest one and link it all will be good?
The latest should match the iteration #2.
look at the date/timestamp to confirm:
ls -lt /etc/letsencrypt/archive/mail.2e0epv.com/
Then, yes, you can just update the link to use the correct matching cert file.
Do not point to the /archive/ folder directly from any program - that will be hard to automate changes.
Always use the default /live/ location and files (which are merely links to the latest ones).