Expired cert is used instead of new one

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

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

1 Like

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

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.

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

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

2 Likes

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

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

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 ?

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

5 Likes

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

2 Likes

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

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

What good would revoking do?

5 Likes

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

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

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

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

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

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

I meant "standard" in a way that I just put the defafult mailcow proxy.conf for maping physical 465 to a specific virtual port.
465 proxying is standard according to the mailcow documentation if you choose to use smtps protocol, behind a proxy (which I do).
https://docs.mailcow.email/prerequisite/prerequisite-system/#firewall-ports
Have a nice day.