http-01 challenge methods

[mdschweda]

Would you consider to support more update methods for http-01 challenges analogous to DNS Update Method? The assumption that the local file system or IIS instance is related to the domain of the current certificate request is pretty limiting.

Proposal:

• Add an option HTTP Update Method under Challenge Type: http-01
• Support at least (Update HTTP manually), (Use Custom Script) and Local file system

[webprofusion-chrisc]

Hi, yes indeed. This has been on the to-do list for a while but surprisingly it hasn't been requested very often.

What scenario are you specifically hoping to cater for?

The http challenge targets I can think of include (including your suggestions):

• manual ( let the user create the required file anywhere, then resume request)
• custom script (option to run as specified credentials. In the future the context can be linux as well as windows.)
• Local file system (it already does this if you specify the web root, so you can use with IIS, apache, nginx etc)
• Remote file system (UNC, network credentials copy over SMB)
• SFTP/SSH
• Webhook?

All of these are very similar to the Deployment Tasks that are already in v5. I'm wondering if the current challenge(s) (http or DNS) could optionally be passed into a Validation Task (basically a deployment task that runs at the validation stage), that way we can re-use a bunch of stuff. Each domain in a cert order gets it's own challenge to complete, so there's batching to think about.

[webprofusion-chrisc]

This has greater relevance for the next phase of Certify, which is where you host the backend as a centralised certificate service (linux/windows) handling certificate renewal/validation and you just connect the GUI to that service. This work is currently in progress.

[mdschweda]

What scenario are you specifically hoping to cater for?

We have an inhomogeneous infrastructure of many websites and applications with several domains where the domain registrar won't let me update DNS entries programmatically. Currently, I am working around that limitation by mapping an Azure file share over SMB and deploying several small, isolated solutions for serving that static content under */.well-known/acme-challenge/*. I'd rather have this logic centralized on the Certify host.

next phase of Certify [..] as a centralised certificate service

That sounds great. Even though there are turnkey solutions for Kubernetes, I use Certify to renew certificates for pods so that everything SSL is under one umbrella with as few moving parts as possible.