Question

在服务器上安装了Nginx。我们的加密功能在www.domain.com上运行良好，但无法使用static.domain.com

使用PuTTY，当我输入： sudo letsencrypt certonly -a webroot --webroot-path=/var/www/site/domain -d static.domain.com -d domain.com -d www.domain.com

我有以下问题：

Failed authorization procedure. static.domain.com (http-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from http://static.domain.com/.well-known/acme-challenge/c6zngeBwPq42KLXT2ovW-bVPOQ0OHuJ7Fw_FbfL8XfY: "<html>
<head><title>403 Forbidden</title></head>
<body bgcolor="white">
<center><h1>403 Forbidden</h1></center>
<hr><center>"

IMPORTANT NOTES:
 - The following errors were reported by the server:

   Domain: static.domain.com
   Type:   unauthorized
   Detail: Invalid response from
   http://static.domain.com/.well-known/acme-challenge/c6zngeBwPq42KLXT2ovW-bVPOQ0OHuJ7Fw_FbfL8XfY:
   "<html>
   <head><title>403 Forbidden</title></head>
   <body bgcolor="white">
   <center><h1>403 Forbidden</h1></center>
   <hr><center>"

   To fix these errors, please make sure that your domain name was
   entered correctly and the DNS A record(s) for that domain
   contain(s) the right IP address.

有人知道会出现什么问题吗？

Answer 1

当我第一次尝试在我的网站上安装证书时，我从certbot收到了相同的错误消息。

在Web服务器上检查原因

我使用的是apache2，而不是nginx。我在/var/log/apache2/error.log的日志中查看了与我网站上的 403 Forbidden 事件相关的apache2错误消息，然后发现：

[Sun Aug 26 14:16:24.239964 2018] [core:error] [pid 12345] (13)Permission denied: [client 12.34.56.78:1234] AH00035: access to /.well-known/acme-challenge/5PShRrf3tR3wmaDw1LOKXhDOt9QwyX3EVZ13JklRJHs denied (filesystem path '/var/lib/letsencrypt/http_challenges') because search permissions are missing on a component of the path

权限和访问问题

我搜索了此错误消息，发现apache2由于权限不正确而无法读取上述目录（例如/var/lib/letsencrypt/http_challenges），例如：

$ sudo ls -la /var/lib/letsencrypt/
total 16
drwxr-x---  4 root root 4096 Aug 26 14:31 .
drwxr-xr-x 72 root root 4096 Aug 18 00:48 ..
drwxr-x--- 27 root root 4096 Aug 26 14:26 backups
drwxr-xr-x  2 root root 4096 Aug 26 14:27 http_challenges

因此，根据上一行带有表示许可权.的{{1}}文件夹的点（letsencrypt），除root用户外，没有人可以读取其内容。要纠正权限，我只是做了：

解决方案

rwxr-x---

将上面的$ sudo chmod o+rx /var/lib/letsencrypt命令输出更改为：

$ ls

现在，上面带有{.1}目录的点（。）的行表示$ ls -la /var/lib/letsencrypt/ total 16 drwxr-xr-x 4 root root 4096 Aug 26 14:31 . drwxr-xr-x 72 root root 4096 Aug 18 00:48 .. drwxr-x--- 27 root root 4096 Aug 26 14:26 backups drwxr-xr-x 2 root root 4096 Aug 26 14:27 http_challenges，因此“其他用户”（例如用户 www-data （适用于apache2）现在可以读取并进入letsencrypt目录。

然后certbot按预期工作。

Answer 2

我猜你的子域名有另一个webroot，如果需要，只需要指定webroot。在您的示例中，您拥有both static.domain.com和domain.com相同的webroot。

来自https://certbot.eff.org/docs/using.html

如果您一次获得许多域的证书，那么该插件   需要知道每个域的文件的来源，哪些可以   可能是每个域的单独目录。请求时   多个域的证书，每个域将使用最多   最近指定了--webroot-path

certbot certonly --webroot -w /var/www/example/ -d www.example.com -d example.com -w /var/www/other -d other.example.net -d another.other.example.net

Answer 3

我遇到了一个解决方案，因为它不是解决方案（不是自动的），但它有效。

您可以使用DNS质询证明您的域名所有权，通过The Certbot;

sudo certbot -d domain.com --manual --preferred-challenges dns certonly

Answer 4

我必须删除我域的AAAA记录，因为certbot更喜欢IPV6。我的虚拟主机提供商DNS具有www和@（域根）的默认AAAA记录。

仔细检查了/var/log/letsencrypt/letsencrypt.log-在显示“ addressUsed”的位置之后，我看到它正在使用IPV6地址。就我而言，我在www上没有任何网站。或由IPV6地址提供服务的域的根目录，因此我删除了AAAA记录，并立即解决了我的问题。由于dns传播并记录了ttl，其他人可能需要更长的时间才能看到浮雕。

即使您希望通过IPV4进行连接，certbot仍可以尝试使用IPV6地址与您建立连接，这就是我的问题所在。

我建议删除日志，以便在继续执行命令之前只有新条目-sudo rm /var/log/letsencrypt/legsencrypt.log-查找“ addressUsed”并确认它是IPV4地址而不是IPV6地址。如果它是IPV6地址，则可以将该网关处的地址转发到主机，并验证您是否也在监听IPV6，或者删除DNS中的AAAA记录，以便letencrypt将改为使用IPV4地址连接到您。

Answer 5

在您的服务器块中，添加：

# for LetsEncrypt
location ~ /.well-known {
  allow all;
}

Answer 6

万一仍有人遇到此问题，可以尝试以下操作，它对我有用：

location ^~ /.well-known/acme-challenge/ {
default_type "text/plain";
alias /home/nginx/domains/domain.com/public/acme-challenge/;
}

Answer 7

就我而言，我拒绝通过

访问与安全相关的文件（/.htaccess，/.htpasswd等）

location ~ /\. {
  deny all;
}

我更改为

location ~ /\.ht {
  deny all;
}

Answer 8

我不想重复不必要的事情，但是似乎有很多不同的情况会导致403证书更新。对我来说，这与更改的nginx配置有关，因为Wordpress / url重写。使用 Virtualmin btw。

上面的评论中有一个链接指向Github上的问题。 One guy explains brilliantly how the location matches in nginx work and gives a solution for the 403。不过，可能还有其他问题导致了这一点。

因此，对我来说，解决方案是为/.well-known/添加位置匹配。

location ^~ /.well-known/ {
    #limit_req            [tighter per-ip settings here]; ## kicked this one out
    access_log           off;
    log_not_found        off;
    #root                 /var/www/html; ## kicked this one out
    autoindex            off;
    index                index.html; # "no-such-file.txt",if expected protos don't need it
    try_files            $uri $uri/ =404;
}

我根本不是nginx专家，所以我鼓励您阅读这篇文章并检查适合您情况的参数。

我们禁止加密未经授权的403

8 个答案:

在Web服务器上检查原因

权限和访问问题

解决方案