Bug 1847320

Summary:	Updating SSL/TLS Certificates requires haproxy service restart
Product:	Red Hat OpenStack	Reporter:	Srinivas Atmakuri <satmakur>
Component:	puppet-tripleo	Assignee:	OSP Team <rhos-maint>
Status:	CLOSED DUPLICATE	QA Contact:	David Rosenfeld <drosenfe>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	16.2 (Train)	CC:	bperkins, dciabrin, jjoyce, jschluet, lmiccini, mbultel, michele, migawa, rheslop, schhabdi, slinaber, tvignaud
Target Milestone:	---	Keywords:	Triaged
Target Release:	---
Hardware:	All
OS:	All
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2021-11-09 16:31:41 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Srinivas Atmakuri 2020-06-16 08:13:04 UTC

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.

Comment 7 Damien Ciabrini 2021-05-27 08:38:03 UTC

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.

Comment 8 Damien Ciabrini 2021-05-27 11:08:03 UTC

(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.

Comment 9 Roger Heslop 2021-09-10 19:14:00 UTC

The documentation has now been updated to reflect the need to manually run /usr/bin/certmonger-haproxy-refresh.sh

Comment 10 Damien Ciabrini 2021-11-09 16:31:41 UTC

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 ***

Comment 11 Red Hat Bugzilla 2023-09-15 01:29:54 UTC

The needinfo request[s] on this closed bug have been removed as they have been unresolved for 365 days