wordfence-cli on SLES 15 about wordfence-cli

[davidnuzik]

I can confirm #99 resolves this issue. I tested on a fresh SLES 15 Server install (which is indeed much like RHEL I described in my last message a few days ago - it does not have ca-certificates.crt rather it has ca-bundle.crt which is the same thing essentially just different filename. Both my RHEL 9.2 and SLES 15 environments work now with the binary built earlier from Pull 99.

Once this issue has a qa-ready dev-complete label later (PR merged, etc) I will do a quick check again and can then mark this case as qa-passed if the re-test goes well.

[akenion]

Thanks for reporting this. It looks like we will just need to document that running on SUSE requires installation of an additional package to provide the required CA certificate bundle. We'll get this added to the documentation.

[evilzenscientist]

@akenion awesome. I was trying to get round to a PR for the docs - but haven't got round to it.

[davidnuzik]

FYI similar situation with RHEL. (9.2 in my case)
OSError: Could not find a suitable TLS CA certificate bundle, invalid path: /etc/ssl/certs/ca-certificates.crt

At least with RHEL it looks like it's just a different naming convention. Rather than the CA cert bundle being at /etc/ssl/certs/ca-certficiates.crt it's at /etc/ssl/certs/ca-bundle.crt the content looks exactly the same the only difference being RHEL seems to label which certs belong to which company(ies). As far as I can tell, wordfence should just be looking for either ca-certificates.crt or ca-bundle.crt in the same path. Likely a library or something is to blame. Ideally either ca-bundle.crt or ca-certificates.crt should be acceptable with no intervention from the user / extra setup/install steps on most OOTB (out of the box) installs -- assuming they have ca-certificates package anyway which usually is the case.

Note that on my personal SUSE Tumbleweed daily driver (rolling release of openSUSE), it has /etc/ssl/certs/ca-certificates.crt perhaps the same is not true on regular cadence releases like SLES 15 (have not tested yet). Either that or my daily driver just already has ca-certificates installed since I have been using it for quite some time and also have steam on it so it has steamtricks and thus could just have the package just because of that.

Because this issue affects RHEL (and possibly other fedora OS'es) and possibly affects SLES as well, we may want to see if we can resolve this sooner rather than later if at all possible.

Alternatively, bit of a hacky solution and not sure if would have unintended consequences (probably not but can't be sure), if I just create a soft link ca-certificates.crt -> ca-bundle.crt then I can use wordfence on my RHEL setup.
(to do this you would execute the following as sudo / root: ln -s /etc/ssl/certs/ca-bundle.crt /etc/ssl/certs/ca-certificates.crt)

[davidnuzik]

@barmat @akenion @briandefiant (mentioned you all since you are assigned or created the PR) I'm going to mark this as dev-complete and validate and then mark as qa-passed. Any objections let me know and I can reopen the issue. This is on the basis that Brian's PR indeed does resolve this issue based on testing. Both SLES 15 and RHEL 9.2 are now working as expected out of the box :)

[davidnuzik]

v2.0.1-rc6 10/31/2023

SUMMARY:
QA validation PASSED.
I re-tested with v2.0.1.-rc6 (and rc5 prior) and observe no issues. The new build changes result in BOTH SLES15 and RHEL 9.2 working for me out of the box (uses ca-bundle.crt without issues).

VALIDATION STEPS

1. Smoke test SLES 15
2. Smoke test RHEL 9.2
   (Note plenty of prior testing against both, smoke test was to ensure latest rc is good to go and we are ready for release!)

NOTES:
None.