Let's Encrypt on a Big-IP

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 :-)

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.

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

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?

@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!

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.

If you are redirecting from http to https, I hope there is no pool assigned to the http virtual server!

With such config, this va doesn’t change status when https pool member is down!

There actually was but I removed it and the VIP still shows as green so that may have solved my problem. Let me double check though.

I got this to work fine with the ACME v2 staging environment. When I changed the URL for the production environment I got prompted that the cert is still valid for longer than 30 days. Using the --force flag ignores that message but I get two new messages stating "01070317:3: profile /Common/auto_domains.com's key and certificate do not match" after + Creating fullchain.pem... The messages concludes with +Done!. but the cert that is in use is still the staging one. I had do delete the ssl profile and ssl key and recreate with the production url. Has anyone run into this? Is this because the key name is the same regardless of staging or production?

Please help, I have all the files in /shared/letsencrypt directory. wrapper.sh runs, the new cert+key pair is imported and visible in System››Certificate Management : Traffic Certificate Management : SSL Certificate List

But automatic reconfiguration of Client SSL profile with new certificate and key do not work, there is an error in var/log/letsencrypt.log:

The requested key (xyz.

key

It seems like the script can not find new certificate and key. I use version 14.1.0 (and I have not configured it in previous versions, so not sure if the issue relates to version).

Update (self-answer): BigIP ver. 14.1 saves the newly generated cert and key without the .crt and .key extensions. That's why the running script generates mentioned error message. Lnxgeek's scripts works well in 13.1, where you can see both files with their extensions in the running-config.

It is easy to make hook.sk work by omitting the extensions in the script:

Before:

cert=${name}.crt
key=${name}.key

After:

cert=${name}
key=${name}