Hi guys,
You got so close but not quite.
Rohit;
* check your running Squid to see what user account it is using. You
should not need to configure the effective user explicitly (unless it is
that 'nobody' account - best prevent that account from playing with cert
creation).
* Remove the ssl_db directory you have that was not working and create
one fresh with write permissions to the Squid user *and* group. Note
that is the top level ssl_db directory only.
* run restorecon on the new directory. This is needed for the create to
work properly when SELinux is present.
* then run the ssl_crtd command _as the Squid user account_ ("su squid"
or "sudo -i -u squid").
* run restorecon *again* on the formatted directory structure. This is
needed for the normal Squid uses to work properly when SELinux is present.
That should be all that is needed to use this helper.
As for upgrades, yes it would be a good idea regardless of this issue.
3.5.20 was July 2016 release[1] and its best not to be more than a month
or two behind with ssl-bump things. Eliezers packages[2] should be okay
if you want to avoid compiling.
[1] <http://www.squid-cache.org/Versions/v3/3.5/>
[2] <https://wiki.squid-cache.org/KnowledgeBase/RedHat> this page was
badly out of date sorry, now updated.
Amos
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users
