TLS handshaking: SSL_accept() failed: error:0A000412:SSL routines::sslv3 alert bad certificate: SSL alert number 42,

Help
1

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. crt.sh | 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:
mail.servicemouse.com
I ran this command:
tail -f /var/log/mail.log
It produced this output:
TLS handshaking: SSL_accept() failed: error:0A000412:SSL routines::sslv3 alert bad certificate: SSL alert number 42,
My web server is (include version):

The operating system my web server runs on is (include version):

My hosting provider, if applicable, is:
linode/akamai
I can login 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):
1.21.0

2

Hi@fugee,

Why do you believe this is an issue with getting a Let’s Encrypt certificate or using the certificate?

What service produced the shown error?

5 Likes
3

postfix

4

You need to provide more info. Specifically, what client is being used and what port is it connecting to when the failure happens?

But, I agree with Bruce ... I don't see this related to Let's Encrypt (yet). I tried connecting to all of your mail ports and they were either disabled or using a self-signed cert. I see you got a Let's Encrypt cert for your mail subdomain. You may just need to configure postfix to use it. A postfix forum is a better place for help with that.

4 Likes
5

Based on
openssl s_client -connect mail.servicemouse.com:587 -starttls smtp -crlf

It looks like you are currently using an self signed certificate, so you need to reconfigure your service to use your current certificate from Let's Encrypt. Just acquiring a certificate doesn't apply it to all relevant services, you still need to do that (either manually or using a script).

4 Likes
6

The log snippet might even be from an outgoing SMTP client connection instead of an incoming one. I'm not sure such an "sslv3 alert bad certificate" error would show for incoming connections. IMO we lack information/details.

7

When you say reconfigure my service do you mean postfix?

8

All services that use a certificate would need to be reconfigured to use the new certificate [after each certificate renewal].

If postfix is using a certificate, then it must be made aware of the newly renewed certificate.

Note: A certificate renewal is a replacement certificate.

2 Likes
9

mail.log isn't moving at all under tail -f

10

postfx only wants to know where fullchain.pem and privkey.pem are, the files are present in the same directory specified in main.cf under /etc/letsencrypt/live/...
cert.pem chain.pem fullchain.pem privkey.pem README

11

As @webprofusion pointed out the certificate is self signed, virtually nobody trusts a self signed certificate.
The presently being served certificate is shown here https://decoder.link/sslchecker/mail.servicemouse.com/587

12

If so, then it may only need to be restarted/reloaded to use the newly renewed certificate.
If not, then it needs to be told where the new certificate is located.

2 Likes
13

You can use the command sudo certbot certificates to show the certificates and their file names and location.

Here is an example of one of my test domains.

$ sudo certbot certificates --cert-name petrifiedhaggis.us.kg
Saving debug log to /var/log/letsencrypt/letsencrypt.log

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Found the following matching certs:
  Certificate Name: petrifiedhaggis.us.kg
    Serial Number: 4d6f4d74352a39f454384adddeb66d2b435
    Key Type: ECDSA
    Domains: petrifiedhaggis.us.kg *.petrifiedhaggis.us.kg
    Expiry Date: 2025-02-28 21:15:02+00:00 (VALID: 87 days)
    Certificate Path: /etc/letsencrypt/live/petrifiedhaggis.us.kg/fullchain.pem
    Private Key Path: /etc/letsencrypt/live/petrifiedhaggis.us.kg/privkey.pem
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
3 Likes
14

I created the certificate with the command `sudo certbot certonly --manual --preferred-challenges=dns

15

And how do you use the new cert once it has been renewed?

1 Like
16

I reboot the machine

17

Found the following matching certs:
Certificate Name: mail.servicemouse.com
Serial Number: 411b4cb22e198a6569dd1c4cf4b25bf1fa2
Key Type: RSA
Domains: mail.servicemouse.com
Expiry Date: 2025-03-03 14:16:41+00:00 (VALID: 89 days)
Certificate Path: /etc/letsencrypt/live/mail.servicemouse.com/fullchain.pem
Private Key Path: /etc/letsencrypt/live/mail.servicemouse.com/privkey.pem

18

That's overkill and not automated.
I think you could do better.

3 Likes
19

Yet here https://decoder.link/sslchecker/mail.servicemouse.com/587 is still showing a self-signed certificate being served.

I was expecting to see this certificate https://search.censys.io/certificates/198ebdc11327630daa1d9aa3e69d92826a67636912e90b014706eca0d7af4fbd

Edit

Or even possibly this certificate https://search.censys.io/certificates/69b88941d4588ab4d9f62c24069b79274a518678d15900108993ef8aa266d384

3 Likes
20

I assume an operating system command (that i don't know yet) would default to reloading certificates under /etc/ssl/certs where there's a postfix.pem (I don't know why) and a lot of other strange pem files How do I reload certs sourced from /etc/letsencrypt/live ?