You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jun 10, 2020. It is now read-only.
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?
The text was updated successfully, but these errors were encountered:
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!
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.
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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?
The text was updated successfully, but these errors were encountered: