Description of problem: When following the procedure in https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/16.0/html/advanced_overcloud_customization/sect-enabling_ssltls_on_the_overcloud#updating_ssl_tls_certificates to update the overcloud SSL certs, the new certificate is pushed through but haproxy is still using the old certs. Although restarting the haproxy containers seems to resolve this. [WORK-AROUND] ~~ $ sudo pcs resource restart haproxy-bundle ~~ Version-Release number of selected component (if applicable): Red Hat OpenStack Platform - 16 (RHOSP-16) How reproducible: Always Steps to Reproduce: 1. Deploy overcloud with SSL 2. Attempt to update SSL certificate by re-deploying with the updated template 3. Actual results: Haproxy is still using the old cert Expected results: Haproxy uses the new cert Additional info: This issue is also observed for RHOSP-13. A backport of the fix may be needed.
This to me looks like a documentation bug more than a code issue. When we use freeipa/certmonger with TLS everywhere, certmonger keeps track of the certificate and any time a certificate is renewed, haproxy is notified and reloads its config to parse the new certificate. This is already happening without interrupting haproxy. This bz seems to relate to manually managed certificates? For that case, any manual change of those certificate would require haproxy to be notified. I think detecting change in externally managed certificates is not a trivial thing, so the best way to deal with the situation would be to manually run the same script as certmonger whenever such certificates are renewed.
(In reply to Damien Ciabrini from comment #7) > I think detecting change in externally managed certificates is not a trivial > thing, so the best way to deal with the situation would be to manually run > the same script as certmonger whenever such certificates are renewed. To be a bit more specific, the scripts used by certmongers are only available when TLS everywhere is enabled, and this script doesn't reload manually managed certificates automatically. So automating the reload of certificate not managed by certmonger in haproxy is still a gap. Right now, the workaround is to force a restart of the haproxy bundle as specified in the original bug description.
The documentation has now been updated to reflect the need to manually run /usr/bin/certmonger-haproxy-refresh.sh
I believe this bug is now fixed with https://bugzilla.redhat.com/show_bug.cgi?id=1935621, which makes sure that both certmonger-managed certificates and user-managed certificates can be injected automatically in the haproxy container without restarting it. I deployed latest OSP16.2 with an external overcloud_endpoint.pem, and this file gets automatically injected on stack update. *** This bug has been marked as a duplicate of bug 1935621 ***
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 365 days