-
Notifications
You must be signed in to change notification settings - Fork 1
Certs renewed locally; but not pushing to LTMs #9
Comments
So, I just did a cat on /etc/dehydrated/certs/blahconfigservice.domain.com/cert.pem I couldn't "debug" why it couldn't automate that step since the script just sees the cert is already renewed, so it doesn't seem to attempt to update the LTM. I'll have to catch it on the fly. Are there execution logs saved somewhere from these cronjobs? |
Execurtion logs are saved in /var/log/dehydrated-bigip*.log Actually checking the cert uploaded on the F5 in that hook might be a good idea, so you can always use this hook and then only re-upload if the cert is not properly installed on the F5. |
The latest commit in #10 fixes this. |
@Sander-agfa : I just cloned this project from your repo, so I believe I have all of your latest commits. I'm still having an issue where the /etc/dehydrated/certs/ has updated certs (from March 6th), but my F5 is refusing the updates. The REST call to upload the cert to /var/config/rest/downloads/ on the F5 works. The file gets there. Then the next step to install it runs via something like this: /usr/bin/curl -sk --connect-timeout 5 -m 120 -H Content-Type: application/json --user 'user:password' https://f5host.name.com/mgmt/tm/sys/crypto/cert -X POST -d '{ "command": "install", "name": "/Common/example.domain.com.crt", "from-local-file": "/var/config/rest/downloads/example.domain.com.crt" }' The F5 responds with: It's like we need to use a "modify" command instead of an "install" command. I didn't quite understand what you changed and whether it should fix this problem or not. Perhaps I'm in a unique state where the cert was downloaded successfully with the older branch and then your branch can't kick it in gear properly? Thank you! |
@Sander-agfa As mentioned previously, I cloned your master version. I've been trying to debug it. I added I set the dehydrated-bigip-hookscript to use lexicon and to use dehydrated-bigip-redeploy-traffic-certificate. I didn't see any updated documentation about this new script of yours; but I assumed some things here. I then ran this: It ended with this (after I removed some sed escape back slashes that I mentioned in a comment in your code diffs):
It looks like my current cert has no serial number or certReference/link. It just returns 2 and exits. How do you envision this working when this doesn't exist yet? What would make it exist? Thank you! |
Hello @hildebrau, thanks for the feedback. |
@hildebrau just another thought: What version of LTM are you running? Maybe this is a difference in API between versions. |
I'm currently running BIG-IP 11.6.2 Build 1.0.507 Hotfix HF1. I've had a terrible time finding appropriate documentation for the iControl REST API that these scripts are utilizing. I'm obviously interested in getting to the bottom of this. Preferably before my cert expires again in early April. ;) |
We're running BIG-IP 12.1.3.7 so that might explain the difference. As for finding API documentation: I also had no luck ;) |
The v12 version of BIG-IP updates the certs without issue as long as the key is the same, don't have a v11 unit here to test this against. What might be a fix for you is renaming the certificates with a timestamp. Perhaps consider setting it to 1 to try if this works and circumvents the issue? |
I added timestamp setting and ran the hook script again but no noticable change in behavior. The cert query from the F5 returns json, but no mention of the certlink. Unless that's the URL to the cert? Is it looking for a thumbnail/serial or what? |
The certlink in v12 is indeed a link to the certificate, so it can get the serial number. |
@hildebrau, as I don't have access to a v11 system, can you provide some output from yours?
|
Sorry for the delay. I still have bash debugs enabled, and I added a "echo skipping" in front of the "return 2" line that you requested that I comment out. Here is the entire obfuscated output. Sorry for the length.
|
Interesting, line 381 refers to Timestamp / Bigip device variable not being set. |
I noticed my certs are showing new expiration dates on our F5 LTM. These two obfuscated certs show "Nov 29, 2018" as the expiration on the LTM. What am I missing? The script originally placed the certs on there just fine; but it doesn't seem to be able to update them.
I manually ran the dehydrated cronjob command:
As you can see, it thinks the certs are valid until Jan 29, 2019; so it has nothing to do. Somewhere along the line it forgot to update the LTM. I have until 11/29 before this blows up on me.
Please point me in the right direction. I'll keep digging as time permits and will update this ticket if I make any progress.
Thank you!
The text was updated successfully, but these errors were encountered: