Ubuntu环境下Squid使用sslcrtvalidator_program实现OCSP证书验证失败问题排查

先别急，咱们一步步拆解这个问题，从配置细节、权限、Squid的运行逻辑几个方向来排查：

1. 先确认Squid是否支持sslcrtvalidator_program #

不是所有Squid版本都支持这个指令，尤其是Ubuntu默认打包的版本可能需要特定编译选项。你可以先运行这个命令查看Squid的编译参数：

squid -v

看看输出里有没有包含与SSL证书验证相关的选项（比如--enable-ssl、--enable-ssl-crtd），如果没有的话，可能需要重新编译Squid或者安装带完整SSL支持的版本。

2. 检查脚本的权限和可执行性 #

你的验证脚本没被调用，首先要排除权限问题：

• 给脚本加上可执行权限：

  chmod +x /opt/my-squid/cert-validator.sh
  

• 确认Squid的运行用户（通常是proxy用户）对脚本有执行权限，同时对日志输出路径有写入权限。比如/tmp虽然是全局可写，但有些系统会有安全限制，你可以把日志路径改成Squid的日志目录试试，修改脚本内容：

  #!/bin/bash
  cat >> /var/log/squid/debug.log
  

  然后给这个日志文件赋予proxy用户的权限：

  touch /var/log/squid/debug.log
  chown proxy:proxy /var/log/squid/debug.log
  

• 手动测试脚本是否能正常工作：

  echo "test content" | /opt/my-squid/cert-validator.sh
  

  看看日志文件里有没有写入内容，确保脚本本身没问题。

3. 简化sslcrtvalidator_program的配置 #

你当前的配置加了cache=0 ttl=1参数，先试试去掉这些参数，用最基础的配置测试：

sslcrtvalidator_program /opt/my-squid/cert-validator.sh

有时候参数格式不对或者取值不合理会导致Squid无法正确调用脚本，先排除参数的干扰。

4. 调高Squid日志级别，获取详细错误信息 #

你说日志只显示“连接失败”，这是因为默认日志级别不够详细。在squid.conf里添加调试选项：

debug_options ALL,1 28,9

这里28是专门针对SSL证书验证的调试类别，9是最高日志级别。重启Squid后，查看/var/log/squid/cache.log，里面会有关于调用验证脚本的详细错误信息——比如找不到脚本、权限不足、脚本执行返回错误码等等，这能帮你精准定位问题。

5. 确保cache_peer配置触发证书验证 #

Squid只会在需要验证后端服务器证书的时候才会调用sslcrtvalidator_program，所以要确认你的cache_peer配置里开启了证书验证：
在你的cache_peer行里加上tls-verify=yes，修改后应该是：

cache_peer nginx parent 443 0 no-query originserver tls tls-verify=yes tls-cafile=/opt/my-squid/certs/ServerCA-chain.pem sslcert=/opt/my-squid/certs/proxy-client.pem name=myAccel

这个选项会强制Squid验证后端服务器的证书，进而触发外部验证脚本的调用。

6. 检查脚本的shebang是否正确 #

确保脚本开头的#!/bin/bash在你的Ubuntu系统里是有效的，有些系统bash路径可能是/usr/bin/bash，或者更通用的写法是：

#!/usr/bin/env bash

这样可以避免路径不一致的问题。

按照上面的步骤逐一排查，应该能找到脚本没被调用的原因。

备注：内容来源于stack exchange，提问作者Rosso