search

colin-stubbs / dehydrated-bigip

F5 BIG-IP hook for dehydrated based Let's Encrypt interactions
GNU General Public License v3.0
10 stars 1 forks source link

admin cert doesn't replicate properly to HA unit #8

Open hildebrau opened 6 years ago

hildebrau commented 6 years ago

I deployed a new bigip admin management cert to both units of an HA pair of LTMs. The certs worked; however when I went back to synchronize my configuration, it barked about the primary units certificate file name not existing on the secondary unit's filesystem. I guess the /etc/httpd/conf.d/ssl.conf file gets cloned between the two units; so suddenly the secondary unit is pointed at the primary units SSL crt/key file names in /etc/httpd/conf/ssl.crt or .key.

I "worked around " this issue by doing a symbolic link from the existing cert to the other cert name. On secondary unit, I ran something like this: ln -s bigip2.crt bigip1.crt and ln -s bigip2.key bigip1.key.

Then the synchronize finished successfully and the cert still worked. I verified that the ssl.conf file points to bigip1 crt/key files on the HA unit.

What's the proper way to handle this with your scripts?

colin-stubbs commented 5 years ago

Hmmm... that's odd. The Apache certs should be entirely unique to each unique to each unit and not sync'ed. Trust may be based on them? I didn't think it was the core part of it but a change in cert on the HTTPS management service may complicate things if an explicit server cert (instead of root CA's) is actually used to validate what is being connected to. Will have to look into that at some point. If you get a chance to work it out please post what you find!

Sander-agfa commented 5 years ago

I also ran into this issue at some point. However, management certificates are not our main concern so I just try to avoid fushing mgmt certs for now. Will see if I can test this out further on a test F5 to reproduce and actually see what goes wrong.