Documentation/Configuration for OVH?

zimboog

Hi,

I stumbled onto this great app which seem perfect for what I need (generate automatically a new cert every 3 months from letsencrypt for my piholes) and much simpler (at least for me) than certbot/letsencrypt cli stuff.
Would the above actually not be the intent of that tool, let me know as I may be wrong 🙂

Assuming i'm with the right tool and right place, I cannot seem to figure out how to configure it to use OVH, who is my provider for domains.
I have it setup and working using certifytheweb and following that tutorial: https://docs.certifytheweb.com/docs/dns/providers/ovh/

Wondering if someone would be kind enough to help me convert this for cert warden assuming it is compatible?

Thanks a lot for your time!
Cheers

gregtwallace

Yes, OVH is supported.

See: https://www.certwarden.com/docs/user_interface/providers/dns01_go_acme_le_go/
And: https://go-acme.github.io/lego/dns/ovh/index.html

If you work through the "Getting Started" section of the Cert Warden docs you should be good.

zimboog

Thank you!

I have followed the process as close as I could but on the part where I should create a cert, and "place an order" this is where it is failing and gets me an error in the logs. I am unsure what it means or what I should do at this point sadly.

12/7/2024, 9:58:37 PM, info, orders/fulfilling_do.go:100, orders: fulfilling worker 2: order 3 done
12/7/2024, 9:58:37 PM, error, orders/fulfilling_do.go:99, orders: fulfilling worker 2: fulfill auths error: ovh: could not find zone for domain "[redacted].net": [fqdn=acme-challenge.[redacted].net.] unexpected response for 'net.' [question='net. IN SOA', code=SERVFAIL]
12/7/2024, 9:58:37 PM, error, challenges/solver.go:72, challenges: deprovision failed (ovh: unknown record ID for 'acme-challenge.[redacted].net.')
12/7/2024, 9:58:36 PM, info, orders/fulfilling_do.go:24, orders: fulfilling worker 2: ordering order id 3 (certificate name: agh_cert_[redacted], subject: [redacted])

[redacted] = my domain name.net

Any idea or hints or could point me to some documentation that I could read for that?

My use case, if that helps:

I use the generated cert to add into my adguardhome instance (similar to pihole). currently i have to copy/paste the cert file every 3 months manually (I generate it from a windows machine with certifytheweb) and hoping that my Pi could do it himself with cert warden 🙂

gregtwallace

I also use AGH, great app.

As for your error, it sounds like something specific to DNS / OVH. Cert Warden is unable to set the needed DNS record on your domain. Are you using the same OVH credentials you were using with a previous ACME Client (i.e., do you know the credentials actually work for the specific domain)?

zimboog

gregtwallace For the credentials, I created, following the links, an "app key" which I created with my account being logged in. So they should be ok. Same process I did with certify but just a new set. I'll see if I can find a different way to login.

gregtwallace

Given the specific error, I'd speculate your credential does not have sufficient permissions to create/delete DNS records on the domain you're trying to get a certificate for.

zimboog

I think the issue is likely related to this part of the configuration that I do not think i'm getting right: https://www.certwarden.com/docs/user_interface/providers/#domains

I do not find the "aliases" part in the UI at all. I have created the _acme-challenge.[domain].net. part as a CNAME on my provider's website and that's it. But i'm really unsure on the certwarden configuration part. All I have entered everytime i'm asked to input a "domain" in certwarden is my [domain].net and that is it.

gregtwallace

Domain Aliases are a feature that was just added in today's release, so if you didn't update in the last hours you would not see it. That said, unless you're using a domain alias, you don't need to worry about that section.

Domain alias would be if you have realdomain.com and otherdomain.com and you want to provide API credentials for otherdomain.com even though you're getting certificates for realdomain.com (thus Cert Warden doesn't have credentials for realdomain.com but can get certificates for it).

Your provider should be for your domain [domain].net or wildcard * if you want. The token/credentials you specify on the provider need to be able to create and delete DNS records on [domain].net. If you manually created CNAME records in your DNS provider's console, remove them, they aren't needed.

What is your certificate Subject? Do you have any Subject Alternate Names ?

zimboog

gregtwallace

The credentials have GET/PUT/POST/DELETE rights on the domain, so yes they should have full access (the other app i just tested again with same credentials creation type works)

I removed the cname. Thank you for the explanation the alias stuff, definitely not needed for me, so easier 🙂.

My certificate subject is [domain].net is that correct?
No alternate names configured.

gregtwallace

Is your firewall blocking DNS queries to servers that aren't your AGH server? Disable your dns blocking firewall rules and test again.

zimboog

gregtwallace

I saw in the configuration file example some dns servers entries where it was 1.1.1.1 etc. I changed them all to be my dns server m. Would that not work around that? I do block everything and prefer to keep that under control. Or does cert warden use hardcoded dns servers ?

gregtwallace

The suggestion is temporary based on looking through some code. I don’t maintain the lego acme code, I just pull it into my project, so its exact working isn’t familiar to me.

If that temporary suggestion fixes it I can review further to see if it’s something I can work around. Alternatively in the meantime if that fixes it you could make a firewall rule specifically to allow just your certain warden device to make dns calls.

zimboog

gregtwallace Reading through all my firewall logs, i saw nothing blocked. Plus, the pi that has certwarden running has a rule already to allow it to do dns out (since its my adguard with upstreams). I anyway gave it a try and fully paused the whole firewall + adguard and no difference. It was indeed worth a try.

gregtwallace

Was it the same exact error in the logs?

zimboog

gregtwallace Yes, was exactly the same.