修复伪静态Rewrite规则导致SSL证书无法更新实录

前几天发现以前一个部署了Nextcloud并开启了HTTPS的网站证书过期失效了。仔细检查后确认了是伪静态导致自动更新无法访问证书的验证文件。虽然这次问题是针对Nextcloud的，但无论是什么网站程序，原理都是一样的。这里写篇文章记录一下，之后再遇到类似问题也可以参考一下。

问题详情

部署的机器是Oneinstack集成环境，SSL证书（HTTPS证书）是使用acme.sh（Oneinstack自带）自动部署的Let's Encrypt免费证书。按照以前遇到过的自动证书失效问题，本来是想运行一下acme.sh手动更新证书，但是出现了报错（如下图，无关信息已隐藏）。

出错提示是域名验证失败，看来问题并不是因为acme.sh没有自动执行才导致的。一番排查后，发现是Let’s Encrypt用于验证的HTTP(S)地址无法访问。

这里需要说明一下的是，LNMP和Oneinstack这两个集成环境自动部署、续期SSL证书都是通过acme.sh实现的，而acme.sh部署SSL证书时，验证这一步又有两种方式：文件式验证和域名解析式验证。前者是在你的网站根目录下创建一个“.well-known”文件夹以及相关的文件，给Let’s Encrypt访问；后者则是直接在域名的DNS解析中增加一现临时的TXT记录进行验证。正常情况下Oneinstack使用的是文件式验证（LNMP环境两种方式都支持，取决于设置，这里不细说）。简单的说，如果这个“.well-known”文件夹都无法直接通过HTTP/HTTPS网址直接访问，那么肯定是无法通过Let’s Encrypt的域名验证，进而不能更新证书了。

原因解析

不过为什么NextCloud这个站点无法访问“.well-known”这个文件夹中的内容？看一看Nginx配置中伪静态部分，答案就非常清晰了。

打开NextCloud站点用的Nginx配置，当前的Rewrite规则（伪静态）是基于Oneinstack提供的NextCloud规则修改而来的，和官方给的类似。里面都有这么一行规则

这一行的作用就是就是把所有的二级目录重定向（转发）到根目录下的“index.php”文件上。再通俗一点说，就是外部（比如浏览器）访问的地址是“www.网址.com/.well-known/123”，但是经过Rewrite规则作用后，服务器内部实际访问的可能是“www.网址.com/index.php?p=.well-known/123”，所以就会显示一个NextCloud的页面而不是“.well-known”文件夹中的真实内容了。

解决方法

确定问题所在之后就可以对症下药了，让NextCloud不转发“.well-known”文件夹的路径，或者说忽略即可。

事实上，这个NextCloud的这个.well-known问题已经有人在社区上问过了。原贴地址见下：https://help.nextcloud.com/t/how-to-exclude-well-known-folder-when-upgrade/5974/10

个人觉得比较有意思的一点是，NextCloud官方似乎是知道这件事，但是并没有排除这个文件夹，也许是开发人员出于安全因素的考虑，认为这个问题应该交证书提供方由解决吧。

具体的解决办法呢，其实很简单了。修改这个NextCloud站点的Nginx配置文件，在“location / {”这一段前加入如下内容即可：

#忽略Let’s Encrypt的文件夹
location ^~ /.well-known/acme-challenge/ {
  allow all;
  access_log off;
}

这一小段的作用就是对于根目录下“.well-known”文件夹的访问直接放行，而不按照默认规则转发到index.php上。其中“^~”表示这行（路径）不是正则表达式。

最后重新运行acme.sh脚本更新证书，完美解决。