Feature #38240
openFeature request: reorganize and simplify TLS certificate utilization
Description
In short, the current use of TLS certificates is a mess and causes operational problems. Among other things:
- Certificate renewal is a major undertaking requiring running the foreman installer.
- Certificate renewal is hard to automate. In an age of 90-day or even 30-day certificates, this becomes a headache.
- katello-cert-check (and the foreman installer) reject some commercial certificate chains even though they are fully RFC compliant.
- The same certificate is, as far as I can tell, used by Apache, Java code and Ruby code, increasing the attack surface.
- On some ports, the TLS certificate does not validate correctly.
- It makes it hard to run foreman with a CNAME instead of the actual system host name (there are probably other issues involved with that problem, too).
More details:
Currently, the same TLS certificate is used in many different places and ways, for browser access and other purposes on port 443 with Apache, client-to-foreman communication (on port 8140 for puppet, 9090 for the SSH key for remote execution, and various other purposes), and smart proxy communication, too.
Some of this is done with Apache, some with Ruby code, some with Java.
Some of these uses do not validate the certificate chain (I was told this is due to certificate pinning). For instance, on port 9090, openssl reports
depth=0 C = US, ST = California, O = <redacted>, CN = <redacted>
verify error:num=20:unable to get local issuer certificate
verify return:1
All this presents a major management headache; renewing certificates requires a major chore, especially with today's commercial certificates moving to 90-day or even 30-day validity.
On top of that, not all commercial certificates are even accepted. For instance, RFC 5246 explicitly specifies that the certificate chain does not need to include the (self-signed) root certificate, but Foreman/Katello requires that. One example where this matters is when a certificate is obtained from Sectigo via the ACME protocol; the corresponding chain is cross-signed and, by its very nature, cannot not include root certificates.
There needs to be a way to simply and automatically renew certificates without running the foreman installer every time.
Solution suggestion (there may be other ways to solve this problem):
All HTTPS traffic on all ports should travel through a single front end server (reverse proxy). This front end server should be the only component terminating TLS, and allow replacing the certificate with a simple reload operation.
For certificate pinning, design a mechanism to distribute the new certificate automatically, or use a completely separate certificate (possibly one created by a CA built into Foreman).
No data to display