Let's Encrypt on a Big-IP

We have a (separate) irule on the http VIP to do a 301 from http -> https. But what I'm seeing is that with the backend servers/nodes down (powered off) the irule for redirection, and the irule for lets encrypt challenge response isn't triggered. (Presumably irules don't get triggered for VIPs that are unhealthy/down) So seems like a chicken/egg dilemma.

@brad : the challenge irule is on the http virtual server.

Did you configure it to forward to the backend server? In my configuration, the http virtual server only respond to challenge and do a http redirect for all other uri.

With this configuration, even if the backend server is down, the challenge will work!

For some of our development systems (behind a ltm) we want to use lets encrypt. The challenge is that because these are development systems we shut them down each night and sometimes we may go days or weeks without starting them back up.

If the backend web servers are down, that means the VIP is down (due to failing health checks), and it appears that means the lets encrypt challenge/response irule won't work and certificates don't get renewed.

So is there some way to make the challenge/response irule still respond even if the VIP/backend servers are down?

Worst is it possible to make a health check that always makes the VIP healthy so that the irule will trigger regardless of what's happening on the backend?

Makes sense, I'll go through Github the next time.

Actually, I've created issues for my todo list now. Anyone who wants to work on them should fork the repo and submit a pull request referencing the issue once you think you've got something to address them. Feel free to add more.

Thanks! Have you got a github account? Do you know how to create isdues a submit pull requests? More than happy to accept contributions that way and there's still quite a few things in the todo list :-)

You're welcome Colin :-)

It is a fantastic project you have put together here, I'm just trying to help out.

Thanks @lnxgeek... you've prompted me to finally get around to committing what I had locally, new version in new file here, a couple of other minor changes to it: https://github.com/colin-stubbs/dehydrated-bigip/blob/master/dehydrated-bigip-common

Hi Colin

Just re-tested your fine upload function and the skip chunks problem has been fixed. However you make one retraction too much when you run the curl command.

When you iterate over the file you have this calculation for the end range number: BYTES_END=$((${BYTES_START} + ${TMP_FILESIZE} - 1))

but then when you fire off the curl command you do it again:

OUT=$(/bin/bash -c "${CURL} -s --insecure -X POST --data-binary '@${TMP_FILE}' --user '${BIGIP_USERNAME}:${BIGIP_PASSWORD}' -H 'Content-Type: application/octet-stream' -H 'Content-Range: ${BYTES_START}-$((${BYTES_END} - 1))/${FILESIZE}' 'https://${BIGIP_DEVICE}/mgmt/shared/file-transfer/uploads/${2}'")

This causes the rest API to go mad:

[SEVERE][18286][17 Jul 2018 14:25:29 UTC][8100/shared/file-transfer/uploads FileTransferWorker]     Transfer failed for /var/config/rest/downloads/file.txt with java.lang.IllegalStateException: Chunk byte count 499713 in Content-Range header different from received buffer length 499712
    at com.f5.rest.common.RestFileReceiver.writeFileChunk(RestFileReceiver.java:350)
    at com.f5.rest.common.RestFileReceiver.handleFileChunkWrite(RestFileReceiver.java:286)
    at com.f5.rest.common.RestFileReceiver$1.run(RestFileReceiver.java:222)
    at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:473)
    at java.util.concurrent.FutureTask.run(FutureTask.java:262)
    at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178)
    at      java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
    at java.lang.Thread.run(Thread.java:745)

If I change it to this instead it works:

OUT=$(/bin/bash -c "${CURL} -s --insecure -X POST --data-binary '@${TMP_FILE}' --user '${BIGIP_USERNAME}:${BIGIP_PASSWORD}' -H 'Content-Type: application/octet-stream' -H 'Content-Range: ${BYTES_START}-$((${BYTES_END}))/${FILESIZE}' 'https://${BIGIP_DEVICE}/mgmt/shared/file-transfer/uploads/${2}'")

Hi everyone!

I've just updated my dehydrated script to the latest version (release 0.6.2) along with the updated "config" and "hook.sh" file - everything seems to play perfectly.

Both the "config" and "hook.sh" file has some new settings in them but I just moved over the configuration from the old files and put it into the same places in the new ones.

I didn't make any changes to the version of ACME so I'm running it with v2.