Hi @bicycle, and welcome to the LE community forum 
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
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
Using this online tool https://crt.sh/ you can see a list of issued certificates
Using this online tool SSL Server Test (Powered by Qualys SSL Labs) both sites seem to be using same certificate
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.
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.