Nginx Reverse Proxy Multi-file configuration

Yes; certbot hasn't been configured to add those required TXT entries for you.
So it will start the process and either time out waiting or fail when proceeding because LE can't find them in your DNS zone.
These failures will be logged every time the cron job runs and the cert is nearing expiry.
Each time it tries a new pending authorization will be created.
That will continue until there are too many pending authorizations and it will start logging that new error.
This will be happening while the cert is still active (between day 60 and day 90).
And you won't realize it (unless you look at the LE logs or configure it to send you an email on any failure) until the cert actually expires.
Then you will be like: Why did my cert expire? I set the cron job to renew it!
And that is what I'm trying to avoid (yeah, all of that).

So there are three choices to overcome this upcoming lack of automated renewal situation:

  1. Perpetually renew the cert manually each time before it expires (less than 90 days from last issuance). [You can remove the cron job to run certbot renew and have it send you an email instead]
  2. Use a DNS Service Provider (DSP) that allows for API updates to your DNS zone and automate the DNS updates within certbot.
    [if your current DNS provider doesn't support API updates, another DSP can be easily delegated to - more on that later, if needed]
  3. Don't use wildcard certs (which require DNS-01 authentication) - switch to HTTP-01 authentication or TLS-ALPN-01 authentication.

So far what I did was creating a post at Dynu.com to see if anyone there can provide any help with item 02. Meanwhile I'll also try to find how to do that.

Thanks again

1 Like

So your current DSP is DYNU.
See: API | Dynu
You only need to do Authentication API Key step #1 (Obtain API Key).
Then provide those credentials to certbot.

EDIT: I've never used DYNU with certbot and I can't find an explicit plugin for it:
User Guide โ€” Certbot 1.19.0.dev0 documentation (eff.org)
But it might be RFC 2136 compliant and that plugin might work (or one of the others).
I'll try searching here and online to see if anyone has a confirmed working plugin.

Ok. I have got the API key already

1 Like

According to this page: DNS providers who easily integrate with Let's Encrypt DNS validation - Issuance Tech - Let's Encrypt Community Support (letsencrypt.org)
You might have to switch ACME clients to get DYNU API plugin support.
From certbot to acme.sh :frowning:

Still looking...

I would try using the RFC2136 plugin:
Welcome to certbot-dns-rfc2136โ€™s documentation! โ€” certbot-dns-rfc2136 0 documentation

If that fails, the path of least resistance is installing acme.sh.
[not about to write a new plugin :frowning: ]

This looks promising...
certbot-dns-dynu ยท PyPI

I need to get some shut eye...

All good, mate. You have spent a great deal of your time helping me. Have a good one

1 Like

Hey, mate

Hoping you're resting now but when you have a moment later on:

sudo certbot renew --dry-run \                                                                                         ~
--authenticator certbot-dns-dynu:dns-dynu  \
        --certbot-dns-dynu:dns-dynu-credentials ~/.dynu-credentials.ini \

[sudo] password for eddie:
Saving debug log to /var/log/letsencrypt/letsencrypt.log

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Processing /etc/letsencrypt/renewal/eddienetworks.ddnsfree.com.conf
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Plugin legacy name certbot-dns-dynu:dns-dynu may be removed in a future version. Please use dns-dynu instead.
Simulating renewal of an existing certificate for *.eddienetworks.ddnsfree.com and eddienetworks.ddnsfree.com
Unsafe permissions on credentials configuration file: /home/eddie/.dynu-credentials.ini
Unsafe permissions on credentials configuration file: /home/eddie/.dynu-credentials.ini
Waiting 60 seconds for DNS changes to propagate

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Congratulations, all simulated renewals succeeded:
  /etc/letsencrypt/live/eddienetworks.ddnsfree.com/fullchain.pem (success)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

If there is nothing else pending, I will use this as my new cron job (without the dry-run flag).

Thanks

1 Like

That is awesome!
Did you run it without the --dry-run?
Please show:
certbot certificates

Hi @rg305

Here are the results of the commands:

-> sudo certbot renew \                                                                                                   ~
--authenticator certbot-dns-dynu:dns-dynu  \
        --certbot-dns-dynu:dns-dynu-credentials ~/.dynu-credentials.ini \

[sudo] password for eddie:
Saving debug log to /var/log/letsencrypt/letsencrypt.log

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Processing /etc/letsencrypt/renewal/eddienetworks.ddnsfree.com.conf
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Certificate not yet due for renewal

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
The following certificates are not due for renewal yet:
  /etc/letsencrypt/live/eddienetworks.ddnsfree.com/fullchain.pem expires on 2021-11-13 (skipped)
No renewals were attempted.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
sudo certbot certificates                                                                                            ~
Saving debug log to /var/log/letsencrypt/letsencrypt.log

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Found the following certs:
  Certificate Name: eddienetworks.ddnsfree.com
    Serial Number: 47ea975a5fc8b1f254c7a6eebbe93cd9ebf
    Key Type: RSA
    Domains: *.eddienetworks.ddnsfree.com eddienetworks.ddnsfree.com
    Expiry Date: 2021-11-13 09:30:18+00:00 (VALID: 87 days)
    Certificate Path: /etc/letsencrypt/live/eddienetworks.ddnsfree.com/fullchain.pem
    Private Key Path: /etc/letsencrypt/live/eddienetworks.ddnsfree.com/privkey.pem
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

One last file check.
Let's have a look at this file to confirm the settings for the next renewal:

And you might want to address this concern:

Ok, for the first bit:

cat /etc/letsencrypt/renewal/eddienetworks.ddnsfree.com.conf                                           /etc/nginx/http.d
# renew_before_expiry = 30 days
version = 1.16.0
archive_dir = /etc/letsencrypt/archive/eddienetworks.ddnsfree.com
cert = /etc/letsencrypt/live/eddienetworks.ddnsfree.com/cert.pem
privkey = /etc/letsencrypt/live/eddienetworks.ddnsfree.com/privkey.pem
chain = /etc/letsencrypt/live/eddienetworks.ddnsfree.com/chain.pem
fullchain = /etc/letsencrypt/live/eddienetworks.ddnsfree.com/fullchain.pem

# Options used in the renewal process
[renewalparams]
account = 2491055be5418d2dd416c418ca2124e3
authenticator = manual
server = https://acme-v02.api.letsencrypt.org/directory
pref_challs = dns-01,

For the second one, I tried to find some information about ownership and permissions but was unlucky.
So far the owner is myself with 644 permissions.

I was expecting to see a bit more in the renewal config file.
We'll have to see how it does in 60 days :crossed_fingers:

What shows?:
ls -la /home/eddie/.dynu-credentials.ini

ls -la /home/eddie/.dynu-credentials.ini                                                               
-rw-r--r--    1 eddie    eddie           72 Aug 17 20:15 /home/eddie/.dynu-credentials.ini

hmm...

  • It might be complaining about that first "w" - not very likely.
    Try 444 instead of 644.

  • If not, then it's likely that last "r".
    Try 640 instead of 644.

Yeah, I'm thinking it's the last "r" that allows too much access to that file.
certbot runs as root so it should have all the access it needs to that file.

Hi,

640 did the trick.

Mate, thank you very much. I've been in a couple of forums and never seen anyone as helpful as you. If you don't mind, is that ok if I link this conversation in the video I used as reference?

2 Likes

Glad to hear things worked out :slight_smile:

Yes, of course; This is a public forum and it is geared towards helping as many people as possible, anything that can help the Internet community at large with encryption is a very welcomed step.

Cheers from Miami :beers:

#FreeCuba

1 Like

All the best @rg305

2 Likes

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