Introduce the HTTP01 challenge

[davidknezic]

This pull request adds a new provider called HTTP to the list, allowing you to use this Rancher Letsencrypt integration with yet unsupported DNS providers or where you don't have API access to your DNS records. Fixes #28.

The only thing that needs to be considered is that you'll have to redirect all traffic to http://your-domain:80/.well-known/acme-challenge to your rancher-letsencrypt service, in order for it to be able to serve the challenge files. This can be done using the built-in Rancher load balancer.

If you want to test this, there are a couple of steps necessary:

1. Make sure you have a working Go environment
2. Clone the branch
3. make build
4. remove the -debugarg from Dockerfile.dev
5. make image
6. Use that image and make sure you set PROVIDER=HTTP

Or, if you trust me, use my image davidknezic/rancher-letsencrypt:dev-a13546f.

I don't consider this ready to merge, this is what's still missing:

• fix formatting with gofmt
• testing (seems to work for everyone in Introduce the simple HTTP challenge #28 and here)
• feedback @janeczku
• extend the docs/README

[FKSI]

👍

[franciscocpg]

Just what I need.

[janeczku]

I guess we don't need this

[davidknezic]

Yes, agree!

[janeczku]

Thanks for submitting the PR @davidknezic. Do you think it's feasible to make it so that it waits until traffic for the domains is forwarded to the container before trying to issue the certificate?

[DanielDent]

Looking forward to seeing this merged. I just pushed out https://github.com/danieldent/rancher-lets-encrypt which does something very similar (along with some auto discovery).

Re "Do you think it's feasible to make it so that it waits until traffic for the domains is forwarded to the container before trying to issue the certificate?", one simple implementation idea:

I implemented that functionality by publishing something at /.well-known/acme-challenge/, verifying that what I published is what I get when I request that HTTP url, and then doing the standard ACME HTTP protocol after that succeeds.

[davidknezic]

I implemented that functionality by publishing something at /.well-known/acme-challenge/, verifying that what I published is what I get when I request that HTTP url, and then doing the standard ACME HTTP protocol after that succeeds.

@DanielDent Sounds like a great approach to me!

[janeczku]

@davidknezic this pr seems to be working for people (#28 (comment)). Do you want to update this before i merge it or is it good to go as it is?

[l-e-e-o]

@davidknezic @janeczku Anything new? I would love to see this merged.

[l-e-e-o]

@janeczku @davidknezic It has been two months now. Is there anything I can do to help? I think lots of people want this feature as it would resolve the DNS provider issues.

[janeczku]

@darkblinded i think whats still missing is some check to make sure that queries to the domain are forwarded to this service before requesting the certificate. Though we could probably merge this now and add that in later.

[davidknezic]

Hi @darkblinded @janeczku I've just removed the obsolete line of code and extended the README. Since this seems to work pretty well for a couple of people (including me) I absolutely agree with you on merging this pr. It would be great for us too, to be able to switch to the official catalog version instead of my custom build.

The access check can be a nice addition for a future pr.

[janeczku]

Thanks everyone!