Trying to renew my certificates with no success

Hi, folks. I have a webmail service (made with iRedMail) and I'm trying to renew my certificates and this is the reponse I've been getting:

If you try the URL https://mail.olimppi.us, you'll see that the certificate has already expired.

My DNS is in CloudFlare:

If you try to check the DNS, they are working and propagating well: mail.olimppi.us | mta-sts.olimppi.us

I have mta-sts and mail (A records) set for olimppi.us. In reality the hostname (and domain) I'm using for the mail service is 'mail.olimppi.us'. And I'm trying to renew them with no success.

This is what I have in Nginx:

server {
    #listen 80 default_server;
    listen 443 ssl http2 default_server;
    listen [::]:443 ssl http2 default_server;
    #server_name _;
    server_name mail.olimppi.us;

    root /var/www/html;
    index index.php index.html;

    include /etc/nginx/templates/misc.tmpl;
    include /etc/nginx/templates/ssl.tmpl;
    include /etc/nginx/templates/iredadmin.tmpl;
    include /etc/nginx/templates/roundcube.tmpl;
    include /etc/nginx/templates/sogo.tmpl;
    include /etc/nginx/templates/netdata.tmpl;
    include /etc/nginx/templates/php-catchall.tmpl;
    include /etc/nginx/templates/stub_status.tmpl;

    #ssl_certificate /etc/letsencrypt/live/mail.olimppi.us/fullchain.pem; # managed by Certbot
    #ssl_certificate_key /etc/letsencrypt/live/mail.olimppi.us/privkey.pem; # managed by Certbot
}

server {
    #listen 80;
    listen 443 ssl http2;
    listen [::]:443 ssl http2;

    server_name mta-sts.olimppi.us;
    root /var/www/mta-sts.olimppi.us;

    # TLS session cache (type:name:size)
    ssl_session_cache shared:mta-sts.olimppi.us:10m;
    ssl_certificate /etc/letsencrypt/live/mta-sts.olimppi.us/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/mta-sts.olimppi.us/privkey.pem; # managed by Certbot
    include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot

    location ^~ /.well-known/mta-sts.txt {
        try_files $uri @mta-sts;
    }
}

My mta-sts.txt is in /home/ubuntu/mta-sts.olimppi.us/.well-known/ (but also created symbolic link to /var/www/mta-sts.olimppi.us/ and I set the due permissions according to https://admin42day.com/server/ServerRedMailSwitch/) and its content is:

version: STSv1
mode: enforce *
mx: mail.olimppi.us
max_age: 604800

And the content of the TXT record (named _mta-sts) was 'v=STSv1; id=20220806213642Z'. And I solved to change it to 'v=STSv1; id=20230806213642Z' in order to see how it goes, but with no success.

That being said, I can't renew either 'mta-sts' or 'mail' A records for olimppi.us.

What is happening? What am I doing wrong?

My domain is: mail.olimppi.us

I ran this command: sudo certbot renew --cert-name mail.olimppi.us --dry-run

It produced this output: Attempting to renew cert (mail.olimppi.us) from /etc/letsencrypt/renewal/mail.olimppi.us.conf produced an unexpected error: Some challenges have failed.. Skipping. All renewal attempts failed. The following certs could not be renewed: /etc/letsencrypt/live/mail.olimppi.us/fullchain.pem (failure)

My web server is (include version): nginx/1.18.0 (Ubuntu)

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

My hosting provider, if applicable, is: Oracle Cloud Infrastructure

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): certbot 0.40.0

The first block shown has no certificate.

Where is the HTTP Server block?
Please show the entire config:
nginx -T

2 Likes

In the first block, I confess that the certificates are commented. Anyways, this is not the issue, because even if I comment it out, the command for renewing does not work. As for the command ```nginx -t`` you asked me to run, the output is:

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

... Which means that nginx has no syntax issue.

Moreover, just to show you and give you a better picture of the thing:

ubuntu@mail:~$ sudo certbot renew --cert-name mail.olimppi.us
Saving debug log to /var/log/letsencrypt/letsencrypt.log

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Processing /etc/letsencrypt/renewal/mail.olimppi.us.conf
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Cert is due for renewal, auto-renewing...
Plugins selected: Authenticator nginx, Installer nginx
Renewing an existing certificate
Performing the following challenges:
http-01 challenge for mail.olimppi.us
Waiting for verification...
Challenge failed for domain mail.olimppi.us
http-01 challenge for mail.olimppi.us
Cleaning up challenges
Attempting to renew cert (mail.olimppi.us) from /etc/letsencrypt/renewal/mail.olimppi.us.conf produced an unexpected error: Some challenges have failed.. Skipping.
All renewal attempts failed. The following certs could not be renewed:
  /etc/letsencrypt/live/mail.olimppi.us/fullchain.pem (failure)

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

All renewal attempts failed. The following certs could not be renewed:
  /etc/letsencrypt/live/mail.olimppi.us/fullchain.pem (failure)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1 renew failure(s), 0 parse failure(s)

IMPORTANT NOTES:
 - The following errors were reported by the server:

   Domain: mail.olimppi.us
   Type:   unauthorized
   Detail: 150.230.69.171: Invalid response from
   https://mail.olimppi.us/.well-known/acme-challenge/yzWMDPaOcnfcsjgv_zkaw5qaueG7SCh6LpLdohhWLeY:
   404

   To fix these errors, please make sure that your domain name was
   entered correctly and the DNS A/AAAA record(s) for that domain
   contain(s) the right IP address.

Besides that, I can't show my whole Nginx configuration here (via 'nginx -T' command), as it'd be another additional security risk for me. If at all it's already a risk itself showing a part of my conf here. Anyways, I suspect that this can be either an issue from Cloudflare or from Oracle (subnet or network things). I'm still trying to investigate that. But it's a bit strange and suspicious. Now when I try to run the command sudo certbot renew --cert-name mail.olimppi.us --dry-run, the output is:

Another instance of Certbot is already running.

This online tool make DNS queries like Let's Encrypt.

https://unboundtest.com/

"Use this server to make DNS queries against an Unbound instance and get logs. The Unbound instance is configured very similarly to Let's Encrypt's production servers, and is started fresh for each query so there are no caching effects. If you are having trouble diagnosing a DNS problem reported by Let's Encrypt, this may help you debug it. Common problems include: invalid DNSSEC records, failure to implement DNS 0x20 (mixed case), timeouts, and flaky servers.

Once you've made a query, you'll get a URL you can share. Note that URLs are currently only persisted in memory, so they are likely to disappear after a few hours or days when the server is restarted. Source code on GitHub. View the Unbound config."

1 Like

Nice. This is the result I got:

Query results for A mail.olimppi.us

Response:
;; opcode: QUERY, status: NOERROR, id: 54216
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;mail.olimppi.us.	IN	 A

;; ANSWER SECTION:
mail.olimppi.us.	0	IN	A	150.230.69.171

----- Unbound logs -----
Feb 01 19:10:27 unbound[131719:0] notice: init module 0: validator
Feb 01 19:10:27 unbound[131719:0] notice: init module 1: iterator
Feb 01 19:10:27 unbound[131719:0] info: start of service (unbound 1.16.3).
Feb 01 19:10:28 unbound[131719:0] info: 127.0.0.1 mail.olimppi.us. A IN
Feb 01 19:10:28 unbound[131719:0] info: resolving mail.olimppi.us. A IN
Feb 01 19:10:28 unbound[131719:0] info: priming . IN NS
Feb 01 19:10:28 unbound[131719:0] info: response for . NS IN
Feb 01 19:10:28 unbound[131719:0] info: reply from <.> 198.97.190.53#53
Feb 01 19:10:28 unbound[131719:0] info: query response was ANSWER
Feb 01 19:10:28 unbound[131719:0] info: priming successful for . NS IN
Feb 01 19:10:28 unbound[131719:0] info: response for mail.olimppi.us. A IN
Feb 01 19:10:28 unbound[131719:0] info: reply from <.> 192.58.128.30#53
Feb 01 19:10:28 unbound[131719:0] info: query response was REFERRAL
Feb 01 19:10:28 unbound[131719:0] info: response for mail.olimppi.us. A IN
Feb 01 19:10:28 unbound[131719:0] info: reply from <us.> 37.209.194.15#53
Feb 01 19:10:28 unbound[131719:0] info: query response was REFERRAL
Feb 01 19:10:28 unbound[131719:0] info: resolving mona.ns.cloudflare.com. AAAA IN
Feb 01 19:10:28 unbound[131719:0] info: resolving sergi.ns.cloudflare.com. A IN
Feb 01 19:10:28 unbound[131719:0] info: resolving sergi.ns.cloudflare.com. AAAA IN
Feb 01 19:10:28 unbound[131719:0] info: resolving mona.ns.cloudflare.com. A IN
Feb 01 19:10:28 unbound[131719:0] info: response for mona.ns.cloudflare.com. AAAA IN
Feb 01 19:10:28 unbound[131719:0] info: reply from <.> 2001:500:a8::e#53
Feb 01 19:10:28 unbound[131719:0] info: query response was REFERRAL
Feb 01 19:10:28 unbound[131719:0] info: response for sergi.ns.cloudflare.com. A IN
Feb 01 19:10:28 unbound[131719:0] info: reply from <.> 2001:dc3::35#53
Feb 01 19:10:28 unbound[131719:0] info: query response was REFERRAL
Feb 01 19:10:28 unbound[131719:0] info: response for mona.ns.cloudflare.com. A IN
Feb 01 19:10:28 unbound[131719:0] info: reply from <.> 192.203.230.10#53
Feb 01 19:10:28 unbound[131719:0] info: query response was REFERRAL
Feb 01 19:10:28 unbound[131719:0] info: response for sergi.ns.cloudflare.com. AAAA IN
Feb 01 19:10:28 unbound[131719:0] info: reply from <.> 192.203.230.10#53
Feb 01 19:10:28 unbound[131719:0] info: query response was REFERRAL
Feb 01 19:10:28 unbound[131719:0] info: response for sergi.ns.cloudflare.com. A IN
Feb 01 19:10:28 unbound[131719:0] info: reply from <com.> 192.12.94.30#53
Feb 01 19:10:28 unbound[131719:0] info: query response was REFERRAL
Feb 01 19:10:28 unbound[131719:0] info: response for mona.ns.cloudflare.com. AAAA IN
Feb 01 19:10:28 unbound[131719:0] info: reply from <com.> 192.55.83.30#53
Feb 01 19:10:28 unbound[131719:0] info: query response was REFERRAL
Feb 01 19:10:28 unbound[131719:0] info: response for sergi.ns.cloudflare.com. A IN
Feb 01 19:10:28 unbound[131719:0] info: reply from <cloudflare.com.> 2400:cb00:2049:1::a29f:937#53
Feb 01 19:10:28 unbound[131719:0] info: query response was ANSWER
Feb 01 19:10:28 unbound[131719:0] info: response for sergi.ns.cloudflare.com. AAAA IN
Feb 01 19:10:28 unbound[131719:0] info: reply from <com.> 192.31.80.30#53
Feb 01 19:10:28 unbound[131719:0] info: query response was REFERRAL
Feb 01 19:10:28 unbound[131719:0] info: response for mona.ns.cloudflare.com. AAAA IN
Feb 01 19:10:28 unbound[131719:0] info: reply from <cloudflare.com.> 162.159.4.8#53
Feb 01 19:10:28 unbound[131719:0] info: query response was ANSWER
Feb 01 19:10:28 unbound[131719:0] info: response for sergi.ns.cloudflare.com. AAAA IN
Feb 01 19:10:28 unbound[131719:0] info: reply from <cloudflare.com.> 162.159.2.9#53
Feb 01 19:10:28 unbound[131719:0] info: query response was ANSWER
Feb 01 19:10:28 unbound[131719:0] info: response for sergi.ns.cloudflare.com. A IN
Feb 01 19:10:28 unbound[131719:0] info: reply from <cloudflare.com.> 162.159.9.55#53
Feb 01 19:10:28 unbound[131719:0] info: query response was ANSWER
Feb 01 19:10:28 unbound[131719:0] info: response for mona.ns.cloudflare.com. AAAA IN
Feb 01 19:10:28 unbound[131719:0] info: reply from <cloudflare.com.> 162.159.4.8#53
Feb 01 19:10:28 unbound[131719:0] info: query response was ANSWER
Feb 01 19:10:28 unbound[131719:0] info: response for sergi.ns.cloudflare.com. AAAA IN
Feb 01 19:10:28 unbound[131719:0] info: reply from <cloudflare.com.> 162.159.5.6#53
Feb 01 19:10:28 unbound[131719:0] info: query response was ANSWER
Feb 01 19:10:28 unbound[131719:0] info: response for mail.olimppi.us. A IN
Feb 01 19:10:28 unbound[131719:0] info: reply from <olimppi.us.> 108.162.195.68#53
Feb 01 19:10:28 unbound[131719:0] info: query response was ANSWER
Feb 01 19:10:28 unbound[131719:0] info: prime trust anchor
Feb 01 19:10:28 unbound[131719:0] info: generate keytag query _ta-4f66. NULL IN
Feb 01 19:10:28 unbound[131719:0] info: resolving . DNSKEY IN
Feb 01 19:10:28 unbound[131719:0] info: resolving _ta-4f66. NULL IN
Feb 01 19:10:28 unbound[131719:0] info: response for mona.ns.cloudflare.com. AAAA IN
Feb 01 19:10:28 unbound[131719:0] info: reply from <cloudflare.com.> 162.159.8.55#53
Feb 01 19:10:28 unbound[131719:0] info: query response was ANSWER
Feb 01 19:10:28 unbound[131719:0] info: response for sergi.ns.cloudflare.com. AAAA IN
Feb 01 19:10:28 unbound[131719:0] info: reply from <cloudflare.com.> 162.159.3.11#53
Feb 01 19:10:28 unbound[131719:0] info: query response was ANSWER
Feb 01 19:10:28 unbound[131719:0] info: response for . DNSKEY IN
Feb 01 19:10:28 unbound[131719:0] info: reply from <.> 192.58.128.30#53
Feb 01 19:10:28 unbound[131719:0] info: query response was ANSWER
Feb 01 19:10:28 unbound[131719:0] info: validate keys with anchor(DS): sec_status_secure
Feb 01 19:10:28 unbound[131719:0] info: Successfully primed trust anchor . DNSKEY IN
Feb 01 19:10:28 unbound[131719:0] info: validated DS us. DS IN
Feb 01 19:10:28 unbound[131719:0] info: resolving us. DNSKEY IN
Feb 01 19:10:28 unbound[131719:0] info: response for _ta-4f66. NULL IN
Feb 01 19:10:28 unbound[131719:0] info: reply from <.> 2001:503:ba3e::2:30#53
Feb 01 19:10:28 unbound[131719:0] info: query response was NXDOMAIN ANSWER
Feb 01 19:10:28 unbound[131719:0] info: response for mona.ns.cloudflare.com. A IN
Feb 01 19:10:28 unbound[131719:0] info: reply from <com.> 2001:502:8cc::30#53
Feb 01 19:10:28 unbound[131719:0] info: query response was REFERRAL
Feb 01 19:10:28 unbound[131719:0] info: response for mona.ns.cloudflare.com. A IN
Feb 01 19:10:28 unbound[131719:0] info: reply from <cloudflare.com.> 162.159.1.33#53
Feb 01 19:10:28 unbound[131719:0] info: query response was ANSWER
Feb 01 19:10:28 unbound[131719:0] info: response for mona.ns.cloudflare.com. A IN
Feb 01 19:10:28 unbound[131719:0] info: reply from <cloudflare.com.> 162.159.0.33#53
Feb 01 19:10:28 unbound[131719:0] info: query response was ANSWER
Feb 01 19:10:28 unbound[131719:0] info: response for us. DNSKEY IN
Feb 01 19:10:28 unbound[131719:0] info: reply from <us.> 2001:dcd:2::15#53
Feb 01 19:10:28 unbound[131719:0] info: query response was ANSWER
Feb 01 19:10:28 unbound[131719:0] info: validated DNSKEY us. DNSKEY IN
Feb 01 19:10:28 unbound[131719:0] info: NSEC3s for the referral proved no DS.
Feb 01 19:10:28 unbound[131719:0] info: Verified that unsigned response is INSECURE
1 Like

With Let's Debug I am seeing these results https://letsdebug.net/mail.olimppi.us/1358527

From my location I get these results that are inconsistent with those from Let's Debug above.

$ curl -Ii http://mail.olimppi.us/.well-known/acme-challenge/sometestfile
HTTP/1.1 404 Not Found
Server: nginx
Date: Wed, 01 Feb 2023 19:21:14 GMT
Content-Type: text/html
Content-Length: 146
Connection: keep-alive
$ nmap -Pn mail.olimppi.us
Host discovery disabled (-Pn). All addresses will be marked 'up' and scan times will be slower.
Starting Nmap 7.91 ( https://nmap.org ) at 2023-02-01 11:21 PST
Nmap scan report for mail.olimppi.us (150.230.69.171)
Host is up (0.20s latency).
Not shown: 992 filtered ports
PORT    STATE SERVICE
22/tcp  open  ssh
80/tcp  open  http
110/tcp open  pop3
143/tcp open  imap
443/tcp open  https
587/tcp open  submission
993/tcp open  imaps
995/tcp open  pop3s

Nmap done: 1 IP address (1 host up) scanned in 10.21 seconds
1 Like

Looks like they might have fixed something. I just got 3 Let's Debug "OK" results in a row

2 Likes

Thanks @MikeMcQ :slight_smile:

Then you need to stop that other instance.

Then that block isn't being used.
[without a certificate, it is rendered useless]
Thus, my request to see the entire config.
If you don't/can't share it, then you will have to go through it.
[or have someone you trust go through it - your problem is in there (somewhere)]

Logic, for one, is never a syntax issue.

2 Likes

As I said, and you said: it really seems like there were no certificates at all, but the certificates were really there (unless one or both of them had been corrupted somehow). I still think that this is not the matter. Now I simply deleted the certificate for mail.olimppi.us by using the command sudo certbot delete --cert-name mail.olimppi.us. Now I'm trying to install it again, but guess what:

And as you can see, once again, it's there:

Or it's an issue in the server (instance) from my side (Oracle), because I think it's not an issue from Cloudflare, or it's simply an issue in some point of the Nginx configuration file, which I think it's not the problem, because this code has remained untouched since last year.

Probably because I was messing with that. But what does that mean exactly?

You can only install certs that exist.

That deleted the cert you now intend on installing.

3 Likes

You're right. My bad. The right command is sudo certbot --nginx, not sudo certbot install. How awkward I am, lol! Now I got to reaccess the website via HTTPS. Now I'm facing another issue: it's not recognizing the password any more. Maybe it can be Postfix or Dovecot problem, once I rebooted the instance recently. Or not...

And I'm facing this problem, too:

I've got solve that issue here. It was a network problem. Probably because a port (465) was forgotten to be configured. Thanks

2 Likes

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.