I’m not sure I’ll be able to fully answer your question, so I’ll let @matt chime in when he has a chance, but I can hopefully explain a couple things regardless.
The ask option is typically used as “hey backend, does x.example.com belong to an existing customer?”
It’s essentially a way to avoid abuse, because if you didn’t configure ask, someone could make HTTPS requests to your server for domains you don’t care about and make your server issue certificates for them, and they could have your server issue an unlimited amount of certificates, maybe eventually exhausting your server’s disk space (after millions of certificates).
Obviously that’s no good, so you can limit which ones are allowed with an ask callback to prevent unwanted domains from being issued a certificate.
Your suggestion of “should check if the domain has a valid cert” wouldn’t work, because it’s a chicken and egg problem; you wouldn’t have a valid cert yet if Caddy is asking! Also your other suggestion “should only check that the subdomain is pointing to my Caddy server” wouldn’t make sense either, because Caddy would only be asking if it got an HTTPS request for that domain; the domain already has the right DNS if it reached Caddy!
I don’t know enough about the app you’re setting up, so I’m not sure what to suggest your approach should be, but essentially you would probably store a list of all the domains you want to allow to have certificates in your database, and if a request comes in with a query of ?domain=x.example.com, you could check if your DB contains x.example.com in the list. If so, return status 200. If not, return any 400 (or any 4xx/5xx code, whatever makes sense to you).
That said, I think on_demand isn’t what you’re actually looking to use, since you seem to want a wildcard certificate. I think (@matt correct me if I’m wrong) you just need to remove on_demand from your config entirely and it might fetch a wildcard certificate instead.
But to get wildcard certs, you MUST use the DNS challenge which it doesn’t seem you’re doing right now. See this post for an explanation of how to set that up:
The DNS records requirement is something set by Let’s Encrypt. It must be used because using the HTTP or ALPN challenges (i.e. make a request over HTTP, or make a request over HTTPS with some metadata) isn’t enough to know whether the program requesting a wildcard cert belongs to someone who has access to the entire domain and not just individual subdomains. Let’s Encrypt needs to verify that you control the domain and not that you just have a server pointed to by one of the DNS entries.
Here’s where wildcard cert support is described in the docs: