Route53 DNS Cert Renewal Failing

[jplandry908]

When renewing certificates that use Route53 (at least on docker), certbot is unable to locate the credentials.

File "/opt/venv/lib/python3.12/site-packages/certbot_dns_route53/_internal/dns_[route53.py](http://route53.py/)", line 82, in perform
    raise errors.PluginError("\n".join([str(e), INSTRUCTIONS]))
certbot.errors.PluginError: Unable to locate credentials

With the little help of AI ...

This is a known issue with how certbot-dns-route53 works. Unlike other certbot DNS plugins that accept credentials via a config file, the Route53 plugin uses boto3 under the hood, which has its own credential lookup chain and ignores whatever CertMate passes to certbot directly.

Let me check exactly how CertMate tries to pass Route53 credentials:

Investigated credential retrieval mechanism and configuration storage integrityInvestigated credential retrieval mechanism and configuration storage integrityThe code is doing the right thing — it sets AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY as environment variables before running certbot. So the error means the credentials coming out of settings.json are empty or masked when the renewal job runs.

Let me check the masking issue:

Check how dns_config is retrieved during renewalCheck how dns_config is retrieved during renewalFound the real problem. The renew_certificate method runs certbot renew with no environment variables set at all — it just calls certbot directly with no AWS credentials injected. The prepare_environment / AWS env var logic only exists in create_certificate. So renewals always fail for Route53 regardless of what's in settings.

The workaround is to pass the credentials as Docker environment variables, which will be present in the container's environment when certbot renew runs:

In your docker-compose.yml, add these under environment:
yaml environment:

  - AWS_ACCESS_KEY_ID=your_access_key_here
  - AWS_SECRET_ACCESS_KEY=your_secret_key_here
  - AWS_DEFAULT_REGION=us-east-1

Adding these environment variables fixed the issue, so I assume that the AI reasoning is correct. The environment variables must not be getting passed during renewal which is causing it to fail.

[jensaops]

I have been looking at this as well, also with some help from AI. This bug seems to affect DNS providers differently. When using AWS the environment variables work as you say, but with other DNS providers that save credentials in settings.json files are written to a hardcoded path 'letsencrypt/config/xxxx.ini' and then deleted in the 'finally' block after certbot runs. The renewal conf written by certbot stores this path. On the next 'certbot renew', the credentials file no longer exists, causing renewal to fail.

1. Credentials file providers - certbot renew fails immediately because the credentials file path in the renewal conf points to a deleted file. DNS challenge cannot authenticate.

2. Environment variable providers (AWS Route53) - prepare_environment() injects AWS_ACCESS_KEY_ID etc. into process_env during creation but renew_certificate() passes no env= to shell_executor.run(). Renewal only works by accident if the credentials are also set as Docker environment variables - credentials stored only in settings.json are never injected during renewal.