CentOS WordPress SSL 部署难点？

在 CentOS 上为 WordPress 配置 SSL，往往被当作“一键搞定”的任务，却隐藏着系统层、服务层以及安全策略层的多重坑，稍有不慎就会导致证书不生效、页面 404，甚至整站不可访问。

证书获取的常见误区

很多管理员直接把 Let’s Encrypt 的 .pem 文件拷贝过去，却忽略了 fullchain.pem 与 cert.pem 的区别。后者只包含服务器证书，缺失根链会让浏览器报“证书不受信任”。如果在 /etc/letsencrypt/live/yourdomain/ 里直接使用 cert.pem，往往只能在本地信任的机器上通过，外部访问则立刻被拦截。

Nginx 与 Apache 的 SSL 配置陷阱

CentOS 默认的 httpd 与 nginx 配置文件路径不同，且两者在 ssl_certificate 与 ssl_certificate_key 的指令位置上有细微差别。把证书路径写在了错误的 server 块，或者忘记在 listen 443 ssl; 前加上 ssl 参数，NGINX 会在启动时报错，却常被误认为是端口冲突。检查日志 /var/log/nginx/error.log 往往能发现“SSL: error:0B080074:…invalid certificate”。

SELinux 与防火墙的隐形拦截

CentOS 7 启用 SELinux 后，默认禁止 httpd 读取非标准路径下的证书文件。即便文件权限已设为 600，setenforce 0 前的访问仍会被阻断，导致 Nginx 启动成功，却在握手阶段返回 “403 Forbidden”。同理，firewalld 若未开放 443/tcp，外部请求直接被丢弃，浏览器只会显示“连接超时”。

自动续期脚本的细节

Let’s Encrypt 的 certbot 默认每 90 天生成一次新证书，配合 --renew-hook 可以在续期后自动重载 Nginx。但很多人忘记在 /etc/cron.d 中加入 0 0 * * * root certbot renew --quiet，或者在 hook 脚本里写成 systemctl reload nginx 而不是 systemctl reload php-fpm，导致新证书只在 Nginx 层生效，PHP 仍使用旧的 OpenSSL 库，出现“SSL handshake failed”。

• 确认 fullchain.pem 与 privkey.pem 配对无误。
• 在 Nginx 配置中加入 ssl_trusted_certificate 指向根链。
• 使用 semanage fcontext -a -t httpd_sys_content_t '/etc/letsencrypt(/.*)?' 让 SELinux 识别证书路径。
• 防火墙放行 443 端口：firewall-cmd --add-service=https --permanent && firewall-cmd --reload。
• 设置 certbot renew --post-hook "systemctl reload nginx" 确保每次续期后自动重载。

把这些细节逐项排查完后，WordPress 在 CentOS 上的 HTTPS 站点就不再是“看得见、摸不着”的概念，而是稳固可依赖的生产环境。