-
Notifications
You must be signed in to change notification settings - Fork 61
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
HTTP challenge with DNS fallback #100
Comments
I'll see if Claude got it right :) Does that code work for you? Could you plase also elaborate a bit on what calls for this specific workflow? Usually it is either HTTP or DNS "for all", so I'd like to understand better in which scenario it is expected that even though DNS verification is necessary (such as for the wildcard), the system might need to retry on HTTP for non-wildcard names. |
The code does work for me, but the package name that Claude came up with is not right. I've got a branch going at https://github.com/oalders/Crypt-LE/tree/challenge-with-fallback The background is that I'm implementing a custom cert provisioner for cPanel. There will be many cases where one or more domains on the cert will contain wildcards. So, if a cert has wildcard and non-wildcard domains I can end up in a weird state where not all domain challenges will pass using HTTP, but if I switch to DNS there are cases where the wildcard domain needs a challenge TXT record on the same domain as a bare domain. (I think that was the case). For that case you could normally just create two TXT records on the same domain, but cPanel doesn't seem to have a way to do that with the Perl APIs. If you give it two records for the same domain the second will clobber the first. So, I was ending up with a mixed bag where HTTP might cover most cases and DNS might also cover most cases, but neither covered all cases. As far as I can tell this kind of HTTP => DNS fallback is similar to how cPanel has implemented its Let's Encrypt provisioning. I ended up using your work because of the EAB support (🙏🏻) and the out of the box ZeroSSL support was a nice touch as well. So, I thank you for your work and if this looks like something that you might be able to use, I'm happy to rework it to your standards. |
Found some notes:
|
In dealing with wildcard domains, it's handy to do the HTTP challenges first and then fall back to DNS for any names (ie wildcards) which failed the HTTP challenge. I could not find a way to do this with the current API, so I have been doing the following. I realize that this is bad for poking at the internals, but as a stopgap it does the trick. Am I missing something?
Please note: I can't really take credit for this. It was quite late at night and I had claude.ai generate most of it in order to rest my brain.
The text was updated successfully, but these errors were encountered: