On Sun, Dec 18, 2016, at 11:24 PM, Amos Jeffries wrote: > On 19/12/2016 5:59 p.m., creditu wrote: > > > > On Sun, Dec 18, 2016, at 01:21 PM, Michael Pelletier wrote: > >> Check your file permissions on the key. > >> > >> On Dec 18, 2016 2:13 PM, creditu wrote: > >> > >>> I'm having trouble getting the sslpassword_program working for an > >>> encrypted key. Config looks like this: > >>> > >>> sslpassword_program /usr/local/bin/pass.sh > >>> https_port 10.10.10.1:443 accel vhost cert=/etc/squid/www.crt > >>> key=/etc/squid/private.key > >>> > >>> On start, cache log states "Ignoring https_port 10.10.10.1:443 due to > >>> SSL initialization failure." > >>> On stop, console states "Failed to acquire SSL private key > >>> '/etc/squid/private.key': error:0200100D:system library:fopen:Permission > >>> denied" > >>> > >>> Removing the passphrase from the private key, squid starts normally. > >>> Permissions on the encrypted and non-encrypted keys are the same. I > >>> also tried putting the pass.sh program in /bin. The pass.sh program > >>> looks like this: > >>> #!/bin/sh > >>> echo "testing" > >>> > >>> The hash of the private key modulus and the certificate modulus match as > >>> well. > >>> > >>> Am I missing something? This is on squid 3.1. > > If the ideas below don't help can you try an upgrade? there are a few > fixes in 3.2 and 3.3 related to that directive. > > >>> _______________________________________________ > > > > Checked the perms and they are identical as the private key that I > > stripped the password out of. They are also in the same directory. The > > one without a password works fine. > > The one without a password is being opened by OpenSSL directly. > > The one with pssword is being opened in Squid oeprating context, which > should be root, but may also be the low-privilege proxy user at the time > the script is run. > > So you need the key file to be readable by whichever of those privilege > contexts Squid is using at the time. (Sorry I can't be more precise, I'm > not sure myself which is used in 3.1). > > If you have SELinux or AppArmour they may also be interferring with the > priviledged access. > > The script itself needs either executable permissions set, or squid.conf > containing the full shell interpreter path as well as the script path. > ie. "sslpassword_program /bin/sh /usr/local/bin/pass.sh" > > > > Also tried encrypting with des3 > > versus aes128 and that didn't make a difference either. Gotta be > > missing something. > > > The error points to a perms problem, but not seeing > > how since everything is the same. > > The error message says fopen() command is not permitted for whichever > user account is trying to access the .key file. > It's not clear if that is fopen() of the .key file, or fopen() of the > pass.sh file before running it. > > The way you describe the issues below hint to me that it is the > permission to access the script which is breaking things. > > > Also, those old Squid had some issues with processing errno at the wrong > times. So there is a small but non-zero chance that the error is > actually something else. :-( > > > > Also, added a line in the > > sslpassword_program to touch a file to see if it got executed and it > > didn't create the file. Additionally, ran the stat command on the > > /usr/local/bin/pass.sh after squid started up > > FYI: That test only works if your filesystem has been configured to > record access times. Using such a setup with Squid will cause major > slowdown as cache related files and logs get accessed *a lot*. So is > typically disabled via fstab "noatime" settings if anyone with expertise > has tuned the proxy machine before you. > > > > and the access time never > > changes. It seems like the shell script may not being executed for some > > reason. I'm able to launch the shell script from the command line and > > it echos out the pass fine. > > This kind of implies the file permission problem is for Squid to open > the script "file" before running whats inside. > > Check /usr/local/bin/pass.sh ownership, executable rights, and > SELinux/AppArmour permissions (whichever is present on that achine). > > Amos > _______________________________________________ > squid-users mailing list > squid-users@xxxxxxxxxxxxxxxxxxxxx > http://lists.squid-cache.org/listinfo/squid-users Thanks. Worked down the list and the problem ended up being SELinux. Of course I would have sworn that it was not in enforcing mode. _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
