on 12-Dec-2015 04:02
Problem this snippet solves:
It is now possible to make use of Let's Encrypt certificates and maintain them on the Big-IP.
Code :
http://wiki.lnxgeek.org/doku.php/howtos:let_s_encrypt_-_how_to_issue_certificates_from_a_bigip
Just tried this and am having a strange problem. On my dev F5 it works without any issues. However, on my prod F5 I get an error.
During the deploy_cert stage when it tries to install the key/cert it gives the error
01070712:3: file (/opt/letsencrypt/certs/somedomain/privkey.pem) expected to exist.
privkey.pem is a symlink to privkey-{timestamp}.key. Testing the install command in the cli with the real file works. Using the symlink gives the above error. Are there permissions settings somewhere I'm missing which would result in the above error?
dev V11.6.0
prod V11.6.1
Having some issues deploying this on a 12.1 VE. Does anyone have a more thorough walk through of the deployment process to get this working?
The hook.sh in the zip file I downloaded from wiki.lnxgeek.org includes the following lines:
scp ${BASEDIR}/certs/$domain/privkey.pem root@9.0.0.4:/etc/ssl/letsencrypt/${domain}.key
scp ${BASEDIR}/certs/$domain/fullchain.pem root@9.0.0.4:/etc/ssl/letsencrypt/${domain}.crt
You may want to comment these out
Also in hook.sh, those not in the US may want to change the date format in the certificate name as it appears in the GUI, from
now=$(date +%Y-%d-%m)
to
now=$(date +%Y-%m-%d)
I'm having the same problem as Delta Force
./letsencrypt.sh -c
INFO: Using main config file /letsencrypt/config
ERROR: Problem connecting to server (curl returned with 60)
I can ping acme-v01.api.letsencrypt.org from the the same shell. I'm running 11.6.0 Any ideas?
Googling the error gives:
CURLE_SSL_CACERT (60) Peer certificate cannot be authenticated with known CA certificates.
How does it look if you run: curl -v https://acme-v01.api.letsencrypt.org
from the Bigip?
This is my output from the BIGIP
curl -v https://acme-v01.api.letsencrypt.org
* About to connect() to acme-v01.api.letsencrypt.org port 443 (0)
* Trying 104.123.211.71... connected
* Connected to acme-v01.api.letsencrypt.org (104.123.211.71) port 443 (0)
* successfully set certificate verify locations:
* CAfile: /etc/pki/tls/certs/ca-bundle.crt
CApath: none
* SSLv3, TLS handshake, Client hello (1):
} [data not shown]
* SSLv3, TLS handshake, Server hello (2):
{ [data not shown]
* SSLv3, TLS handshake, CERT (11):
{ [data not shown]
* SSLv3, TLS alert, Server hello (2):
} [data not shown]
* SSL certificate problem, verify that the CA cert is OK. Details:
error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
* Closing connection 0
curl: (60) SSL certificate problem, verify that the CA cert is OK. Details:
error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
More details here: http://curl.haxx.se/docs/sslcerts.html
curl performs SSL certificate verification by default, using a "bundle"
of Certificate Authority (CA) public keys (CA certs). If the default
bundle file isn't adequate, you can specify an alternate file
using the --cacert option.
If this HTTPS server uses a certificate signed by a CA represented in
the bundle, the certificate verification probably failed due to a
problem with the certificate (it might be expired, or the name might
not match the domain name in the URL).
If you'd like to turn off curl's verification of the certificate, use
the -k (or --insecure) option.
Updated my BIGIP to 11.6.1. That seems to have resolved the SSL issue. I ran the script again and now it alerted me that the LICENSE pdf was outdated so I updated it to the lates version and tried to run the script again.
./letsencrypt.sh -c
: No such file or directory
Running ls lets me know the file is there.
letsencrypt ls -a -l
total 59
drwxr-xr-x 3 root root 1024 Feb 14 11:33 .
drwxr-xr-x 28 root root 1024 Feb 14 11:18 ..
drwxr-xr-x 2 root root 1024 Feb 14 11:24 .acme-challenges
-rwxr-xr-x 1 root root 3529 Feb 10 14:14 config
-rwxr-xr-x 1 root root 32 Feb 14 11:21 domains.txt
-rwxr-xr-x 1 root root 3429 Jan 11 16:10 hook.sh
-rwxr-xr-x 1 root root 37807 Feb 14 11:29 letsencrypt.sh
-rwxr-xr-x 1 root root 390 May 29 2016 wrapper.sh
What is wrong here?
Most welcome 🙂
I just tested the latest version of the script (which now is called dehydrated) from Lukas and it works nicely. Remember to update WELLKNOWN variable and update the hook.sh file which has some minor changes to it.
Could you update the installation instructions to include the use of dehydrated or is it just required to replace the letsencrypt.sh file with the new dehydrated file? Could you also please explain what needs to be updated with regards to WELLKNOWN and hook.sh?
I changed also to dehydrated. My changes. uncommented WELLKNOWN in the config file. I also used the hook.sh from dehydrated and pasted the commands from the hook.sh of lnxgeek into the new hook.sh file. It is very obvious with commands you will need.
(for some reasons i cannot add the hook.sh i made here)
Hi all,
beyond the article, do you have a step by step tutorial for implementing this within F5 BIG IP?
How the flow works? F5 is passing the challenge to one specific web server to do the challenge/response or F5 itself is the one that carry this out?
Does this script distribute the new certificate (request or renew) to all the web servers in my farm?
It has any support to automatically configure IIS/Apache or other webservers or it only gets the certificate and is up to the administrator to configure the certificate on each web server?
Has this script any limitations in terms of webserver´s platforms or is independent?
Thanks in advance!
This is what you need to do to get it running:
The certificates lives on the F5, this is the point with this script implementation. So there is no distribution of the certificates unless you put it into the hook script. The best way of using SSL/TLS is to have it handled in front of the web servers by the F5 and run cleartext against the servers. The script is completely independent of any device, server, service type you put the F5 in front. The dependency is tight to the F5.
Hope this helps.
Dear lnxgeek116, Thanks very much for your response! I will give it a try and see how it works. Thanks!
I have just updated the solution with OCSP stapling.
After too many hours digging around getting OCSP to work properly on the BigIP I've made a small change to the hook script making it possible to get OCSP stapling working. For now it is only v.13 compatible but it should be a minor hack to get it working on other versions.
I noticed this runs from a cron job. During firmware upgrades do cron jobs get retained? Or if we implemented this would we need to take care when upgrading our firmware to re-create the cron jobs? Anyone know?
I finally got some time to finetune this script. I have added a section where I create an iScript which runs the wrapper script once a week.
This should defeat the need for cronjobs and survive upgrades and even synchronize between cluster members. What's not to like! 🙂
Let me know if you have any problems with it.
Hi,
it seems the link changes. I found the documentation on this URL:
http://wiki.lnxgeek.org/doku.php/howtos:let_s_encrypt_-_how_to_issue_certificates_from_a_bigip
Thank you lnxgeek for this solution. it is very helpful!
I had some difficulties to understand how to what to do with all these files, so I here is a little installation guide:
chmod 755 hook.sh wrapper.sh send_mail dehydrated create-profiles.sh
mkdir /var/www/dehydrated
./dehydrated --register --accept-terms
./dehydrated -c
Where can I get the 11.4 hook.sh & dehydrated scripts? I get error: + Done! + Creating fullchain.pem... Syntax Error: "default" unknown property
Looks like 11.4 using older syntax: ltm profile client-ssl /Common/clientssl { ca-file none cert /Common/default.crt cert-lifespan 30 cert-lookup-by-ipaddr-port disabled chain none client-cert-ca none crl-file none handshake-timeout 10 key /Common/default.key
}
while newer versions indeed using the "default" statement: app-service none cert /Common/default.crt cert-key-chain { default { cert /Common/default.crt key /Common/default.key } } chain none inherit-certkeychain true key /Common/default.key passphrase none }
I guess this script was written in newer version and does not exist for version 11.4
try to edit the following command in tmsh and find what is not working and change the hook script.
modify ltm profile client-ssl ${profile} cert-key-chain replace-all-with { default { key $key cert $cert } }
if you frequently add subdomains you can save yourself a little effort by building your domains list dynamically (this assumes that your vips are named for the fqdn so , shop.example.com, etc):
tmsh -q -c "cd /;list ltm virtual recursive" | awk 'BEGIN {RS="\n}"} !/\ none/ {print}'| grep ^ltm | awk '{print "/" $3}' | grep "domain$" | cut -d'/' -f3 | xargs
Hello,
If anyone have this error :
./dehydrated -c
INFO: Using main config file .. config
: No such file or directory
In my case, this is hook file with bad encoding of end of line because file are created on Windows.
Hoping someone might have come across this before or can point me in the right direction? I'm currently using VE of BIG-IP running 11.6.1 Build 0.0.317 Final. I have everything in place just like the article explains but I'm getting following messages.
01070712:3: file (/home/admin/dehydrated/shared/letsencrypt/certs/qa.pdaa.penton.com/privkey.pem) expected to exist.
01070712:3:file(/home/admin/dehydrated/shared/letsencrypt/certs/qa.pdaa.penton.com/fullchain.pem) expected to exist.
010717e3:3: Client SSL profile must have RSA certificate/key pair.
Vince, you need to move the script out of "/home" as this filesystem is very small and not intended to be used like this. Use /shared instead and then make sure backup handles this as well.
I haven't seen your errors before but can you verify that the files are in order and exist?
Thanks for the quick response and for the work you put into this, great stuff. As for the privky and fullchain they do they do exist under the certs directory. I even went through the process of manually adding them to the f5 and re-running dehydrated as test but saw the same result. I’ll move the entire directory out of home as you suggest and try again.