Acme.sh with inwx dns validation

[TheRojam]

Hello
i am atm integrating letsencrypt as my cert provider for my turris.

Feature: Automated SSL Certificate Management with ACME.sh
As a system administrator
I want to automate SSL certificate management using ACME.sh
So that I can maintain valid SSL certificates for my domains

Background:
Given I have installed ACME.sh on my OpenWrt system
And I have configured my domain with INWX as DNS provider
And I have set the key size to “ecc-384”
And my DNS records are automatically updating via INWX DynDNS

Scenario: Certificate Issuance Fails Due to Incorrect Renewal Settings
Given I have the following configuration in LuCI:
| Setting | Value |
| Key Type | ECC |
| Key Size | 384 bits |
| DNS Provider | INWX |
| Challenge Type | dns-01 |
| Auto Renewal | never |
When I attempt to issue a new certificate using ACME.sh
Then the system should indicate a configuration error
And display “Renewal setting must be configured for automatic certificate management”
And suggest the following remediation steps:
| Step | Action |
| 1 | Change renewal setting from ‘never’ to ‘auto’ |
| 2 | Verify INWX DNS API credentials |
| 3 | Ensure DNS challenge validation is enabled |
But the certificate issuance process should not proceed

[kai]

I must admit that I find your description confusing. Issuing a certificate fails but you don’t get the error message(s) you expect? What are the messages (if any) you see in the log?

What I can say: I’m using acme.sh on my TO without issues (with dns.he.net as DNS provider). However, I’ve installed it directly using SSH without any integration into OpenWRT/Foris/LUCI (instead, certificates get created via CLI and the update process gets triggered via cron). I don’t see why a similar configuration should not work with INWX.

[Vienna]

Hi,

I do read that you use www.inwx.de as DynDNS. So you try to get a certificate and validation fails. If you search in the forum, you might find that in some cases sentinel blocks the requests and there are soultions that deal with this issue. But if you are using “plain” OpenWRT you might be wrong here…

Greetz,
Vienna

[AreYouLoco]

@Vienna DNS validation doesnt need any open ports. So Sentinel wont block it. With DNS validation you make a proof that you own domain by TXT record in your DNS zone. And get a cert like that.

[Vienna]

Dynamic firewall blocks Let's Encrypt renewals

And why not just use DNS validation? opkg update opkg install acme acme-dnsapi luci-app-acme /etc/config/acme config acme option state_dir '/etc/acme' option account_email 'name.surname@example.com' option debug '0' config cert 'main' option keylength 'ec-256' list domains 'router.example.com' # subjectName list domains 'srv1.example.com' # subjectAltName list domains 'srv2.example.com' # subjectAltName option enabled '…

since he is using it as certificate authority…

Let's Encrypt servers are blocked since Turris OS 7.1

A certbot instance inside a LXC container cannot renew certificates (with the webroot method) since the update to TOS 7.1. Let’s Encrypt try to contact my http server (running in the same container) for the webroot challenge, from the server outbound2p.letsencrypt.org (23.178.112.215) or outbound2l.letsencrypt.org (23.178.112.211), but the router firewall contains this in the set dynfw_4 (“IPv4 addresses blocked by Turris Sentinel”): 23.178.112.101, 23.178.112.103, 23.178.112.211, 23.178.112…

since I do understand the acme instance needs counterproof, but maybe I am wrong.