???
If a static solution doesn't work, why should a temporary solution work?
No, the 2nd terminal gives:
curl: (56) Recv failure: Connection reset by peer
There are Political Restraints in place that forbid us to exposre a web server to the Internet WITHOUT going via a HAProxy server. We’re not just trying to get a certificacte this one time, we’re trying to set things up to get a number of certificates for a number of websites over the next several month and automatically renew them.
Hence, it needs to be set up on the HAProxy server, and we can’t use any “temporary work arounds” because our CISO/secuirty dept. wont allow it.
I'm still not sure whether we are on the same page. An error from curl isn't a big deal, as long as you can see the request arrive in nc.
It might be easier to do this instead of nc:
python -m SimpleHTTPServer 54321
and try the same curl.
Edit: and blah, I made errors earlier on. The curl needed to include :54321 in the URL. Too tired to be posting, apparently.
I don't say "You should skip your haproxy". You should skip the --standalone, because it's hard to debug.
PS: Your new 503 error says: Your haproxy works. But if you use standalone, there is (if certbot isn't running) no answering webserver. So debugging the way from your haproxy to your port 5* isn't possible.
OK - but the only problem with all that is that this was all working a few days ago until we had a crash (that took the backup of the haproxy server as well - luckily it was only the haproxy server and haproxy backup that went.
So I’ve been rebuilding the haproxy server over the last day and half (among other things) from installation notes from 2 years ago - so we had it working --standonly on the haproxy server then with that config, so we should be able to get it running now.
Obviously I’ve got a typo/misconfig somewhere, which we need to find.
That one gave the raw html code - so that one worked 
This simple haproxy.conf file gives the same error as I get with my more “complex one” 
If by web server the policy means 'a computer receiving HTTP connections', I'm afraid that you are breaking it by running certbot with --standalone, since it is doing just that. In this case you can NOT implement http-01 challenge on the haproxy computer, and the optimal solution conforming to your corp policy is to use dns challenge
If by web server the policy means 'a process receiving HTTP connections' then --standalone is acceptable as long as it is behind haproxy... but a permanent web server such as python -m httpserver exposing only the files necessary for the let's encrypt exchange is acceptable too.
1 Like
No need to throw the baby out with the bathwater. Proxying through to --standalone on an alternate port is a valid strategy that Certbot supports.
As OP said, it was working for them before.
That's just really bizarre. If you can replicate the issue on a second test environment, I'd be happy to login and take a look if you want.
Its OK, I found the problem, there was a typo 
Dry Run now working - thanks for your help, everyone
Cheers
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.