-
Notifications
You must be signed in to change notification settings - Fork 28
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
Another use case: http-01 with remote server #189
Comments
That sounds a bit like MDChallengeDns01 but for other challenge types as well. Except it would be optional. I think we are drifting towards a more general event interface, like In Apache internals, there are An An We send events synchronous. They are invoked just before/right after things happen. The should not block for long, else they block the Which events do you want for your use case? |
Yes, I realized that the external http-01 events are almost the same as the Dns-01 case when I woke up! I'll give this some more thought when I'm even more awake :-) To start with, I think Optional args would help for DNS too - for example, my DNS server uses TSIG keys, so being able to pass the filename for the key and server name to use would help... You'll see in my current handler that one of the challenges is config data - reserving a place in the There might be a case for an API to store/access config - but it needs to be simple enough for a script... One issue with passing data via args and environ variables is visiblity. E.g. the As I mentioned elsewhere, being able to deploy on renewal would be helpful - perhaps a Hope this helps - I'll give this some more thought later. |
This script is a preliminary version of a handler for the md_events discussed in issue icing#189. It has gone through some unit testing, but is not production qualified. Nothing about it should be considered stable. This version is to drive discussion of the mod_md interfaces. It should work as an MDMessageCmd and MDChallengeDns01 provider, as well as for the (hypothetical) MDChallengeHttp01 events. Feedback and testing is encouraged. To get started, run contrib/md_events/md_events -h for usage. Then contrib/md_events/md_events -I, which will do a default install. /etc/httpd/md_events.conf and /etc/httpd/md_events.d will be informative. You can play with it from the command line as installed: contrib/md_events/md_events -uroot installed example.net I have also provided a few dns-01 update scripts; md_events has an (untested) wrapper that should make them useful.
I pushed a commit with a VERY preliminary and rough version of md_events and some supporting files (for dns-01). Read the commit comment for details. This is not production ready - but hopefully is a good base for defining FWIW, I used the term "events" for the current MDMessageCmd interface from day 0... Out of time for now... |
I noticed one related issue in dns-01 handling. Often, it can take some time for a challenge to become visible to the validation servers. In any case, with other clients I've seen it take up to several minutes between when Obviously, a Waiting minimizes the chance of negative caching. A good value for the delay time is hard to estimate. It should be configurable. |
|
MDChallengeResponseDelay might be better. The validation server starts the challenge, mod_md responds.... The challenge is started - it's the response that's delayed. I don't have a problem with MDCAChallenges - while MDChallenges is better, not sure it's worth adding another alias that has to be documented/explained/tested... |
Also, the required delay depends on the challenge type. DNS can take time to propagate. tls-apln and mod_md internal http are instantly available. external http usually is visible when the script returns from the copy commend - but there might be a cache/CDN to update. .. So scope needs to be per-MDomain. Since mod_md can announce ability to respond to more than one challenge type, server can choose. So perhaps syntax is `MDChallengeResponseDelay http-01=[duration] tls-alpn=[duration] ... OTOH, it doesn't have to be TOO precise. Doesn't make sense for internal responses to wait 10s of minutes for getting the first certificate. But the slow ones have to work. Cert renewal happens every 60 days, so a coarse solution should suffice. |
I pushed a document (event_interface_notes.txt) that tried to collect the threads of this conversation. |
I've encountered another use case that
mod_md
needs help handling.Consider this situation (handled by the client I'm trying to retire...):
Remote server, a VPS with a vendor who doesn't support LE, needs a certificate; updating DNS is painful as the DNS provider has no supported API. Currently, I get/renew the certificates for the remote server from one of my local machines.
The remote server has a disk area that maps to /.well-known/acme-challenge.
The current client, running locally (not on the remote server), will call-out to a script, providing the token & key authorization. The script constructs a file (named by the token) containing the key authorization. It then uses scp to place the token on disk. Validation happens. The script is called to remove the token. Certificate issued.
For
mod_md
to support this, it needs a call-out likeMDMessageCmd
that provides an action (http-01-add
|http-01-remove
), domain, the token and the key authorization (could be the filename in$MD_STORE/challenges
) to be stored. It needs to be configured on a per MD basis. Your current handler is great for local certificates!Ideally, the
MDHttpProvider
directive is compatible withMDMessageCmd
- in fact, I want the same script to handle both types of events. (My message events handler already has the necessary configuration and deployment infrastructure.)When
MDHttpProvider
is not configured in a domain, your handler would continue to work.When it is configured, you will never see the GET (it goes to the remote server). But you do get the challenge (invoke and wait for the provider script), respond with the empty object. And when the status changes from "pending" to "valid" or "invalid", invoke the provider to de-provision.
Of course, I expect the
MDMessageCmd
handler to be called with 'installed' as usual - it knows how to get the certificate installed.It doesn't seem like a big change - the hardest parts are finding the right places to call out, and adding to your test system...
The text was updated successfully, but these errors were encountered: