Let's Encrypt on a Big-IP

Look in the hook.sh file it is here the tmsh commands inject the challenge into the datagroup. Maybe they need adjusting to the correct partitions?

Just retried with a new fresh pull from Gitlab. Still the same error.

I have the feeling that the datagroup doesn't get populated. When I look in the local traffic logs I can see the 404 logs, but never a 200, so this might be the issue. Maybe I'm missing something in the config file?

Well I fixed it by taking the latest from github.

Hey Inxgeek, yes I used the last dehydrated version. Pulled it from gitlab. So that version breaks stuff? Does anyone know of a working build?

Hi Jens

Have you updated dehydrated to the latest version, I think I was hit by this as well.

Hi,

I have the following issue at the moment. I managed to configure all the scripts, but I keep receiving the same error over and over again:

 + Signing domains...
 + Generating private key...
 + Generating signing request...
 + Requesting new certificate order from CA...
 + Received 1 authorizations URLs from the CA
 + Handling authorization for xxx
 + 1 pending challenge(s)
 + Deploying challenge tokens...
 + Responding to challenge for xxx authorization...
 + Cleaning challenge tokens...
 + Challenge validation has failed :(
ERROR: Challenge is invalid! (returned: invalid) (result: {
  "type": "http-01",
  "status": "invalid",
  "error": {
    "type": "urn:ietf:params:acme:error:unauthorized",
    "detail": "Invalid response from http://xxx/.well-known/acme-challenge/kesLdLYVVVQGsd7Rk2n81uSydmi_2_1j7O62gIf8ZIg [0.0.0.0]: 404",
    "status": 403
  },
  "url": "https://acme-v02.api.letsencrypt.org/acme/challenge/dEatI1F43o_YbrmzOedlPNjKW3EjQazpOAAwPEcFzSY/12616604520",
  "token": "kesLdLYVVVQGsd7Rk2n81uSydmi_2_1j7O62gIf8ZIg",
  "validationRecord": [
    {
      "url": "http://xxx/.well-known/acme-challenge/kesLdLYVVVQGsd7Rk2n81uSydmi_2_1j7O62gIf8ZIg",
      "hostname": "xxx",
      "port": "80",
      "addressesResolved": [
        "0.0.0.0"
      ],
      "addressUsed": "0.0.0.0"
    }
  ]

We are using a specific partition in our configuration, but this has been edited in all the scripts. So the correct datagroup is referenced in hook.sh. Anything I might be missing?

I have read that this can be due to the ACME version, but changing the default URL doesn't change anything. Both https://acme-v02.api.letsencrypt.org/directory and https://acme-v01.api.letsencrypt.org/directory give the same error.

I'm sure the datagroup is being check, this can be seen in the logs:

Rule /Default/Lets_Encrypt_ACME_iRule : Responding with 404 to ACME challenge YjMsNqw2uf5xbyqlB6uWF5jJcZqJ3azbPfksfUlxkzI

Thanks!

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}

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?

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.

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!