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
