Expired cert is used instead of new one

Help
1

OK, I've been struggling with this for days, but I'm a freakin' noob so answer might be obvious...

I formerly have generated a certificates for a mail subdomain mail.domain.ext using certbot with letsencrypt in an nginx container.

Then I changed later (weeks later) my reverse proxy container to a SWAG container (nginx + some extra security stuffs) and I issued new certificates with this time a wildcard with dns challenge with zerossl.

Everything worked perfectly with new certs (I have ~10 subdomains with webservers). :grinning:

BUT for some reason I discovered that the certificate used of mail.domain.ext:465 is still the old one which is now expired.

So basically :
openssl s_client -connect mail.domain.ext:443 -> everything ok, using wildcard up-to-date cert
openssl s_client -connect mail.domain.ext:465 -> old cert, expired. I use this port for SMTP (mail server).

Installing new wildcard certs doesn't fix the issue
I can't revoke old certs, I might somehow have lost it (I greped files for key pieces)

I thought certificate weren't related to ports ? How do I get rid of the old certificate ?
certbot certificates outputs nothing but the new wildcard certificates. Nothing in the archives.

Any help will do:)

2

Hi @bicycle, and welcome to the LE community forum :slight_smile:

They are not.

It likely only "exists" in the active memory of the system.
Try restarting the SMTP service [or the entire system].

5 Likes
3

Thanks,
I tried both already. Thought it might be a timezone issue or something but it didn't change the problem.

1 Like
4

How did you configure Dovecot?

Also, please provide the actual hostnames, so we can also test it. The questionnaire which somehow wasn't shown or you deleted mentions providing the domain name (hostname) is mandatory.

5 Likes
5

I read the questionnaire, but I was not very inclined to reveal my hostnames. Anyway the host are pinty.fr and another one theredshiftempire.com

I have made some progress :slight_smile:

How did you configure Dovecot?

Actually the mail server is a mailcow instance (with it's own nginx, and acme container), that I'm running behind a main nginx reverse proxy.

I figured out that the certificate weren't renewed by mailcow's acme container because for some reason, I think it won't follow the 80 to 443 redirection.

this is what the mailcow acme container outputs:

mailcowdockerized-acme-mailcow-1  | Found domains: mail.pinty.fr, autodiscover.theredshiftempire.com, autodiscover.pinty.fr, autoconfig.pinty.fr, autoconfig.theredshiftempire.com
mailcowdockerized-acme-mailcow-1  | Getting directory...
mailcowdockerized-acme-mailcow-1  | Directory found!
mailcowdockerized-acme-mailcow-1  | Registering account...
mailcowdockerized-acme-mailcow-1  | Already registered! Account ID: https://acme-v02.api.letsencrypt.org/acme/acct/XXXXXX
mailcowdockerized-acme-mailcow-1  | Creating new order...
mailcowdockerized-acme-mailcow-1  | Order created!
mailcowdockerized-acme-mailcow-1  | Verifying autoconfig.pinty.fr...
mailcowdockerized-acme-mailcow-1  | Traceback (most recent call last):
mailcowdockerized-acme-mailcow-1  |   File "/usr/bin/acme-tiny", line 8, in <module>
mailcowdockerized-acme-mailcow-1  |     sys.exit(main())
mailcowdockerized-acme-mailcow-1  |   File "/usr/lib/python3.10/site-packages/acme_tiny.py", line 195, in main
mailcowdockerized-acme-mailcow-1  |     signed_crt = get_crt(args.account_key, args.csr, args.acme_dir, log=LOGGER, CA=args.ca, disable_check=args.disable_check, directory_url=args.directory_url, contact=args.contact, check_port=args.check_port)
mailcowdockerized-acme-mailcow-1  |   File "/usr/lib/python3.10/site-packages/acme_tiny.py", line 153, in get_crt
mailcowdockerized-acme-mailcow-1  |     raise ValueError("Challenge did not pass for {0}: {1}".format(domain, authorization))
mailcowdockerized-acme-mailcow-1  | ValueError: Challenge did not pass for autoconfig.pinty.fr: {'identifier': {'type': 'dns', 'value': 'autoconfig.pinty.fr'}, 'status': 'invalid', 'expires': '2022-12-02T21:16:07Z', 'challenges': [{'type': 'http-01', 'status': 'invalid', 'error': {'type': 'urn:ietf:params:acme:error:connection', 'detail': '82.123.53.27: Fetching http://autoconfig.pinty.fr/.well-known/acme-challenge/AbgvaxbdLlGZwMVrA3EFh6XdArwg3I0fTXW8z5PL664: Connection refused', 'status': 400}, 'url': 'https://acme-v02.api.letsencrypt.org/acme/chall-v3/180472630947/ADAyuw', 'token': 'AbgvaxbdLlGZwMVrA3EFh6XdArwg3I0fTXW8z5PL664', 'validationRecord': [{'url': 'http://autoconfig.pinty.fr/.well-known/acme-challenge/AbgvaxbdLlGZwMVrA3EFh6XdArwg3I0fTXW8z5PL664', 'hostname': 'autoconfig.pinty.fr', 'port': '80', 'addressesResolved': ['82.123.53.27'], 'addressUsed': '82.123.53.27'}], 'validated': '2022-11-25T21:24:15Z'}]}
mailcowdockerized-acme-mailcow-1  | Fri Nov 25 22:24:18 CET 2022 - Failed to obtain certificate /var/lib/acme/mail.pinty.fr/cert.pem for domains 'mail.pinty.fr autoconfig.pinty.fr autoconfig.theredshiftempire.com autodiscover.pinty.fr autodiscover.theredshiftempire.com'
mailcowdockerized-acme-mailcow-1  | OK
mailcowdockerized-acme-mailcow-1  | Fri Nov 25 22:24:18 CET 2022 - Some errors occurred, retrying in 30 minutes...
mailcowdockerized-acme-mailcow-1  | OK

If I try
curl https://autoconfig.pinty.fr
I get a server response. But if I try:
curl http://autoconfig.pinty.fr
It gives a connection refused

But I checked in a browser that the redirection is functionnal, and acme challenge should follow de http to https redirection, so I have no clue why it doesn't renew. I suspect a misconfiguration in my Nginx main reverse proxy, but it's pretty standard.

6

So you're using Certbot and a mailcow-specific ACME client to get almost the same certificates?

Can't you configure mailcow to use the certs from Certbot?

5 Likes
7

Why? See Certificate Transparency is going to make the public anyway.

2 Likes
8

Using this online tool https://crt.sh/ you can see a list of issued certificates

  1. crt.sh | pinty.fr
  2. crt.sh | theredshiftempire.com

Using this online tool SSL Server Test (Powered by Qualys SSL Labs) both sites seem to be using same certificate

  1. SSL Server Test: pinty.fr (Powered by Qualys SSL Labs)
  2. SSL Server Test: theredshiftempire.com (Powered by Qualys SSL Labs)
2 Likes
9

Yes they are. It's not much a privacy issue.
I run different services on seperate domains, hosted on the same physical host.

1 Like
10

That would be the smart solution. But since it worked without any further configuration at the beginning I did'nt bother much.

But I litteraly don't know how to do that. Maybe I can use mailcow's acme container to revoke certificate so the default would be the certbot wildcard ?

11

Am I missing something?
The 2 curl requests look identical to me.
Yet you get 2 different responses, is what I read.

5 Likes
12

sorry typo (edited).
connection refused with http but ok with https.

2 Likes
13

Yes, looks like a typo. The HTTPS request works but an HTTP request fails (below).

The redirect is not functional. Browsers (like chrome) sometimes check both http and https and use https if it works.

You need to fix port 80 (http). Try Let's Debug to test

curl -I https://autoconfig.pinty.fr
HTTP/2 200
server: nginx
date: Fri, 25 Nov 2022 22:52:54 GMT

curl -I http://autoconfig.pinty.fr
curl: (7) Failed to connect to autoconfig.pinty.fr port 80 after 81 ms: Connection refused
4 Likes
14

I'm not familiar with mailcow, so I don't know either.

What good would revoking do?

5 Likes
15

Thanks, I think this might be the easiest way. But I double checked everything in my SWAG config. Requests from 80 should be redirected, not refused.

I will search further.

Am I right to assume that certbot follows 301 redirection (if redirection properly working) ?

2 Likes
16

Well, technically, it is the Let's Encrypt Server which makes the http challenge. But, yes, it will follow redirects to http or https URLs

5 Likes
17

I was hoping revoking the letsencrypt certificate would automatically make the wildcard be the one that is used.

18

It would not. It just marks that cert as revoked. If your server is still referencing it then you'll just be sending out a revoked cert

5 Likes
19

Of course I double checked everything in my SWAG (nginx) config for redirection to work.

Except that GODAMMMMMMMM SWAG docker-compose port 80 mapping that was commented out.
Sorry to have waste your time ! And thanks a lot all of you for your kind help.
:slight_smile: :slight_smile: :slight_smile: :slight_smile: :slight_smile: :slight_smile:

4 Likes
20

There isn't anything standard about proxying port 465.
You need to follow that connection.

Was this addressed?:

I suppose it was ...
That must mean that both systems are requesting their own certs.

4 Likes