Just thought I'd share my experiences getting ACME Dreamhost DNS validation set up. It's working now, but wasn't entirely straightforward.
When configuring the Challenge Plugin within Datacentre > ACME, it wasn't at all clear what form the 'API Data' field should take. I initially guessed at:
to mirror the export lines for each plugin described in https://github.com/acmesh-official/acme.sh/wiki/dnsapi#how-to-use-dns-api . It turns out this was close, but should have been:
Playing around with the HE API it seems that for providers with more than one parameter, you put each on a separate line (rather than semi-colon separating etc.).
It would be really helpful if the docs at https://pve.proxmox.com/wiki/Certificate_Management#sysadmin_certs_acme_dns_challenge could describe the format and relationship to the acme.sh docs, as the only examples are for DNS API types with fields explicitly broken out.
This was compounded because there appears to be no check that the Dreamhost API call has actually worked. Even if the authentication fails it looks like the DNS record creation has succeeded in the logs. You don't see an error until later in the process, apparently immediately followed by a cleanup of the DNS record that seems to explain why there isn't one there any more. I only figured out what was going on by sitting at the DNS control panel in Dreamhost repeatedly refreshing to try to see the TXT record contents.
Finally, it's worth noting that the delay between the record being added to the API frontend and propagated to Dreamhost's DNS servers can sometimes be very long. With command line acme.sh, I observed a 15 minute delay on one occasion, requiring an explicit DNS refresh in the Dreamhost control panel to get things moving again. Command line acme.sh repeatedly sleeps and retries, so eventually succeeded. However, Proxmox's implementation has a single configurable fixed delay, defaulting to 30s. Most of the time that seems to be fine, but I'm expecting to see some renewal failures in the future. It would be nice if it could work like acme.sh.
With all that said, it's great to finally have proper certificates installed on the servers on my internal cluster, with automated renewal etc.. Minor tweaks would make this a really seamless process.
When configuring the Challenge Plugin within Datacentre > ACME, it wasn't at all clear what form the 'API Data' field should take. I initially guessed at:
Code:
DH_API_KEY="ABCDEFGHIJKLMNOP"to mirror the export lines for each plugin described in https://github.com/acmesh-official/acme.sh/wiki/dnsapi#how-to-use-dns-api . It turns out this was close, but should have been:
Code:
DH_API_KEY=ABCDEFGHIJKLMNOPPlaying around with the HE API it seems that for providers with more than one parameter, you put each on a separate line (rather than semi-colon separating etc.).
It would be really helpful if the docs at https://pve.proxmox.com/wiki/Certificate_Management#sysadmin_certs_acme_dns_challenge could describe the format and relationship to the acme.sh docs, as the only examples are for DNS API types with fields explicitly broken out.
This was compounded because there appears to be no check that the Dreamhost API call has actually worked. Even if the authentication fails it looks like the DNS record creation has succeeded in the logs. You don't see an error until later in the process, apparently immediately followed by a cleanup of the DNS record that seems to explain why there isn't one there any more. I only figured out what was going on by sitting at the DNS control panel in Dreamhost repeatedly refreshing to try to see the TXT record contents.
Finally, it's worth noting that the delay between the record being added to the API frontend and propagated to Dreamhost's DNS servers can sometimes be very long. With command line acme.sh, I observed a 15 minute delay on one occasion, requiring an explicit DNS refresh in the Dreamhost control panel to get things moving again. Command line acme.sh repeatedly sleeps and retries, so eventually succeeded. However, Proxmox's implementation has a single configurable fixed delay, defaulting to 30s. Most of the time that seems to be fine, but I'm expecting to see some renewal failures in the future. It would be nice if it could work like acme.sh.
With all that said, it's great to finally have proper certificates installed on the servers on my internal cluster, with automated renewal etc.. Minor tweaks would make this a really seamless process.
Last edited:
