Not 100% sure I understand your question, but I’ll try to answer a few different ways:
Caddy may use the URL described later in your post to solve the HTTP challenge, if used – you don’t need to configure this though. It will just handle it.
That’s the only real “URL” that the server needs to respond to when it comes to TLS certificates.
This sounds like it’s referring to on-demand TLS, which has to be explicitly enabled with an ‘ask’ endpoint to allow or disallow certificate issuance decisions at runtime. This is not the normal mode of execution.
Normally, you configure the hostnames in your config file and at load-time, Caddy will start managing certs for those domains. No “URL to the domain” is needed. Caddy just goes ahead.
Regardless of whether On-Demand TLS mode is enabled, if Caddy is using the HTTP-01 challenge (defined by the ACME spec), then yes, the CA will make an HTTP request to an endpoint like that.
Once there is a certificate, Caddy can complete TLS handshakes with clients and serve HTTP routes normally according to your configuration, since the HTTP will be able to be decrypted and parsed by the server.
So some background, I was just thinking if it was theoretically possible to use caddy to just handle the fetching and renewals of the certificates (storing it in say redis).
Meaning I would still use say nginx, and only allow requests to be forwarded to caddy on the HTTP-01 challenge URL, all other requests would go through nginx fully. I would then need another URL to go to caddy to start the creation process or update cert.
Yes it is possible. But why not just replace Nginx with Caddy? Much simpler, you’d be running less software. Plus, you’d be getting the full benefits of Caddy, including support for the ACME TLS-ALPN challenge (which would not be possible if you put Nginx in front of Caddy), having a memory-safe server (Nginx is written in C, it’s not immune to memory safety bugs, like Heartbleed; Caddy is written in Go, those kinds of bugs are not possible).