Update procedure to configure TLS for LDAP

[asteflova]

What changes are you introducing?

I'm updating the procedure to configure TLS for LDAP authentication:

• Restarting httpd is not needed
• We can also simplify the instructions for uploading the LDAP certificate

Why are you introducing these changes? (Explanation, links to references, issues, etc.)

I noticed https://issues.redhat.com/browse/SAT-19821 and #2409 and thought "why not?"

Anything else to add? (Considerations, potential downsides, alternative solutions you have explored, etc.)

Checklists

A separate PR will probably be needed for some of the older branches due to conflicts but #2409 suggests that we should get the fixes there too.

• I am okay with my commits getting squashed when you merge this PR.
• I am familiar with the contributing guidelines.

Please cherry-pick my commits into:

• Foreman 3.13/Katello 4.15
• Foreman 3.12/Katello 4.14 (Satellite 6.16)
• Foreman 3.11/Katello 4.13 (orcharhino 6.11 on EL8 only)
• Foreman 3.10/Katello 4.12
• Foreman 3.9/Katello 4.11 (Satellite 6.15; orcharhino 6.8/6.9/6.10)
• Foreman 3.8/Katello 4.10
• Foreman 3.7/Katello 4.9 (Satellite 6.14)
• We do not accept PRs for Foreman older than 3.7.

[github-actions]

The PR preview for bf3daf6 is available at theforeman-foreman-documentation-preview-pr-3499.surge.sh

The following output files are affected by this PR:

• Configuring_User_Authentication/index-foreman-deb.html
• Configuring_User_Authentication/index-foreman-el.html
• Configuring_User_Authentication/index-katello.html
• Configuring_User_Authentication/index-orcharhino.html
• Configuring_User_Authentication/index-satellite.html

show diff

show diff as HTML

[ekohl]

Thanks for taking over. Again a great simplification.

[maximiliankolb]

style-wise it LGTM; though I am not sure if that would work on Foreman on Debian/Ubuntu. But it's an improvement, so let's get it in.

[ekohl]

though I am not sure if that would work on Foreman on Debian/Ubuntu

Good call. It would not, but the previous instructions also didn't work. The Debian equivalent is to place the file in /usr/local/share/ca-certificates and run update-ca-certificates.

[maximiliankolb]

Thanks Ewoud for providing the cmd/path. I will fix this in a follow-up PR so that it does not further block this PR. See #3500

[ekohl]

FYI, this now matches https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html/securing_networks/using-shared-system-certificates_securing-networks#adding-new-certificates_using-shared-system-certificates. Perhaps we should refer to it?

[asteflova]

FYI, this now matches https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html/securing_networks/using-shared-system-certificates_securing-networks#adding-new-certificates_using-shared-system-certificates. Perhaps we should refer to it?

I saw that section and didn't think it would add much value. But why not, let's add a link.

[asteflova]

I don't think we can replace the steps on our side with a link (update-ca-trust extract is not part of the RHEL docs) but in https://issues.redhat.com/browse/SAT-19820, Evgeni does recommend adding a link so that's what I did. Except that I'd rather not link to a specific section, only to the whole chapter/assembly (chapter links shouldn't change as much as section links).

[ekohl]

update-ca-trust extract is not part of the RHEL docs

Perhaps that's a RHEL docs bug. Technically it works if you don't pass one, but there's a difference. Quoting man update-ca-trust:

(absent/empty command)
Same as the extract command described below. (However, the command may print fewer warnings, as this command is being run during rpm package installation, where non-fatal status output is undesired.)

That makes me think users should pass the extract command.

[mjahoda]

Hi, we plan to revamp the Managing trusted system certificates chapter in the RHEL Security hardening (tracked in [1]). And we'll also reflect what is currently deprecated [2, 3]. Perhaps I could make a quick fix just to incorporate the missing argument.

[1] https://issues.redhat.com/browse/RHELDOCS-18440

[2] https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html/9.5_release_notes/deprecated-functionalities#deprecated-functionalities-security

[3] https://issues.redhat.com/browse/RHEL-54695

[asteflova]

Great, thanks a lot, Mirek! Looking at the RHEL RNs that you linked:

Using update-ca-trust without arguments is deprecated

which I believe confirms @ekohl's suspicion. If you do manage to apply the quick fix to update-ca-trust @mjahoda, I would appreciate it if you let me know because then I'd look into replacing the procedure steps on our side with a link to your guide.

However, for now, I think this PR is good enough to be merged. If anyone disagrees, please let me know.

[ekohl]

[3] https://issues.redhat.com/browse/RHEL-54695

This is how we (or at least, I) found out the hard way: voxpupuli/puppet-trusted_ca@b3416c5 & theforeman/puppet-foreman_proxy_content@53187d9 were the result of a very frustrating Friday when the change landed in CentOS Stream.

[ekohl]

And as I merged I just noticed I should have squashed.

563e291..ec409bd 3.11 -> 3.11
8c6432a..faf85d8 3.12 -> 3.12
0a15d58..f37aa74 3.13 -> 3.13

There's a merge conflict on 3.10 because 8069cf8 wasn't picked.

[asteflova]

I'll raise a follow-up PR to get the changes to 3.10 and below.

[mjahoda]

JFYI, the quick fix (the addition of "extract") is available in the published RHEL 8 and 9 docs: https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html/securing_networks/using-shared-system-certificates_securing-networks#adding-new-certificates_using-shared-system-certificates

[asteflova]

That was very fast @mjahoda, thanks! I created an issue to update the docs on our side: #3504