Add --no-verify flag

[andreasscherbaum]

It is possible that acme_tiny.py runs on a webserver which can't
connect to it's own loadbalancer from the inside. The --no-verify
will skip the local verification step.

[RonjaPonja]

See #107

[andreasscherbaum]

Is this still a "very uncommon case"?

[rspeed]

I agree with your comment on the other thread about it not being necessary to continue verifying it after the initial setup, but I also agree that this isn't a common enough issue to justify adding a new option. The best course of action would be to remove the verification step entirely and provide an external means to verify your server setup. This would solve your issue while also making acme-tiny easier to audit.

[andreasscherbaum]

This will remove ~10 lines of code - I like that plan.

[tzeejay]

Just used the fork to sign my cert. Why has this not been added to the master?

[andreasscherbaum]

@diafygi stated in #107 that this is an uncommon case :-(

[zatricky]

Awesome project btw. :)

I don't think the use-case for --no-verify is that uncommon. As mentioned in #122, the number of related issues/PRs is also climbing.

I'm not 100% sure which I'd prefer - but I'm leaning toward adding the flag. The two choices (excluding the choice of simply leaving it alone) are as follows:
a) remove the verify code
b) add the --no-verify flag
Pros of removing the verify code:

• Less code with similar end-result

Pros of adding the --no-verify flag:

• Magnitudes-quicker running/debug time with a bad config
• No unnecessary load on the ACME service

[jreusch]

hello
i'm a (nearly) completely happy user of acme-tiny :)
but i too ran into this problem, "fixed" it myself in the code and wanted to send you a pull request only to see that there are already three open for the exact same feature.
our setup is as follow:
firewall ---> imap/webserver
with the two servers beeing on different machines but in the same subnet.
now when letsencrypt wants to verify the certificate for the imap server, i simply redirect on the firewall the requests to port 80 of the webserver and i'm fine. but not when the webserver itself wants to do the same thing... i don't want to install a webserver on the other machine either (not to speak of an additional firewall in front of it...) so it would be cool to have this --no-verify flag :)

just in case you needed other cases where this problem occures, maybe it isn't that uncommon :)
thx!

[Krenair]

In Wikimedia's beta cluster, we have Varnish listening on HTTP and Nginx on HTTPS, with Varnish redirecting these HTTP acme-challenge requests to HTTPS.
But of course, until you have a valid certificate set up, Nginx will be serving a broken self-signed certificate, causing urllib to throw an exception unless you use a hack like https://gerrit.wikimedia.org/r/#/c/247587/3/modules/letsencrypt/files/acme_tiny.py

This would also be helpful in our case.

[frezbo]

@andreasscherbaum could you please do PR to my fork, https://github.com/frezbo/acme-tiny

[andreasscherbaum]

@frezbo Looks like you got it integrated already?

[frezbo]

@andreasscherbaum I forgot that I applied your patch previously, it has been a great help, i was getting errors when running script, thanks to you everything is resolved.

[Tronde]

Good evening,

I run in exactly the same issue described in #11. It could be resolved only trying the steps xxdesmus mentioned in comment- 162134072.

In my case internal and external DNS resolution is working just fine. I would like to see this PR merged.

Kind regards,
Tronde

[frezbo]

@Tronde check my fork of acme-tiny, i have merged the --no-verify option.

[Tronde]

@frezbo Thanks for your hint. I just started using your fork as well.

[diafygi]

Added --disable-check option in 4.0.0+