|
|
|
|
|
|
by e12e
2114 days ago
|
|
|
Ok, thank you for the details and managing expectations. This still seems to warrant some experimentation. In my case I'm mostly interested in delegating a domain/sub-domain somewhere I can easily update (be that run my own dns, host it somewhere with an api) - while having my main domains on a more boring/static dns infrastructure - yet still easily get certs for things like imap.example.com - which would not run a web server. And also split cert renewal to vps/container isolated from things like smtp/imap that need the certs. |
|
|
Well, depending on the OS, you could start up a web server during the LE verification process and then bring it down once that's done. You'd only have to run in on port 80 for probably less than a minute.
But yes, you could this mechanism to have "_acme-challenge.imap.example.com" (which is what the ACME protocol uses) be a CNAME to point to something.auth.example.com that is more dynamic. Or even a completely different domain like foo.bar.example.ORG.
In your example.com zone file you'd put NS and A(AAA) records to point to the DNS server that handles the queries for the auth sub-domain.
> And also split cert renewal to vps/container isolated from things like smtp/imap that need the certs.
It's easier to run the ACME client on the host in question, and I'm not sure what it gains you to have it run somewhere else. That being said, there are ACME clients with a bit of a focus on being run 'remotely' from where the certs actually live:
* https://github.com/srvrco/getssl
This is probably for shared-hosting scenarios where cron is not accessible.
IMHO though, if you have access to the CLI on the host running the TLS service, it's best to run things there.