我正在尝试在Ubuntu 18上续订nginx过期的certbot SSL。
certbot无法验证某些域(身份验证器:nginx)。
证书当局报告了以下问题:域:
mySite.co.uk类型:连接详细信息: 。 。 。 :获取
:
连接通过对等重置
我已经在http上运行了该网站:
server {
listen 80;
listen [::]:80;
server_name www.mysite.co.uk mysite.co.uk;
root /var/www/html;
}
... nginx.conf告诉它将其pid保留在/run/nginx.pid
中,我可以通过服务nginx start | Stop
,一切都很好:
curl -I http://www.mysite.co.uk/
HTTP/1.1 200 OK
我不清楚该>/。著名/acme-challenge/
应该可以正常工作 - 当然没有这样的文件夹中的/var/www/html
中的文件夹,但我确实读到certbot启动了自己的服务器(??)来管理身份验证,并且在续订时停止自己的验证是明智的。
因此,作为root,我确实:
cat /run/nginx.pid
> 124876
service nginx stop
lsof -i -P -n | grep LISTEN
> nothing on 80 or 443
cat /run/nginx.pid
> file doesn't exist
certbot certonly --nginx
我知道有一个 certbot续订
命令,但我每个人都得到了相同的结果,所以……无论如何。它正确地从现有conf拿起域名,提示我续订,并最终吐出上面的错误。我还看到添加了几行添加到nginx error.log
[notice] 125028#125028: signal process started
[error] 125028#125028: invalid PID number "" in "/run/nginx.pid"
。它也有一个新的pid。如果我尝试使用Service Nginx重新启动,则失败,因为它试图绑定到另一个(certbot的??)Nginx进程已经使用的端口。
无论始终,无论是通过“适当”的nginx还是这个certbot Zombie One,我的网站都很乐意将HTTP 200返回到外部请求中。我本人从未有过“通过同行”错误的“连接重置”。即使我手动创建一个/var/www/html/.well-nown/acme-challenge/test
文件,它始终可以很好地服务。
所以..全能的恶作剧正在发生什么?为什么Certbot启动无法看到的NGINX实例?为什么不阻止它?是否应该在/。著名/acme-challenge/
中创建某些内容?我的nginx实例有点干扰吗?应该发生什么?我在做什么错?
I'm trying to renew an expired certbot SSL for Nginx on Ubuntu 18. I'm getting... well, various weirdness, but the certbot error is:
Certbot failed to authenticate some domains (authenticator: nginx).
The Certificate Authority reported these problems: Domain:
mysite.co.uk Type: connection Detail: ...: Fetching
http://mysite.co.uk/.well-known/acme-challenge/rx6m9QMdK0h16ZOJYsq5sx_AZbxI4zWGvJ6o_kt3b-A:
Connection reset by peer
I've got the site running on HTTP:
server {
listen 80;
listen [::]:80;
server_name www.mysite.co.uk mysite.co.uk;
root /var/www/html;
}
...the nginx.conf is telling it to keep its PID in /run/nginx.pid
, I can start and stop it via service nginx start|stop
and everything's good:
curl -I http://www.mysite.co.uk/
HTTP/1.1 200 OK
I'm not clear how this /.well-known/acme-challenge/
thing is supposed to be working - there's certainly no such folder in /var/www/html
, but I did read that certbot starts it's own server (??) to manage authentication and it's wise to stop your own while renewing.
So, as root, I do:
cat /run/nginx.pid
> 124876
service nginx stop
lsof -i -P -n | grep LISTEN
> nothing on 80 or 443
cat /run/nginx.pid
> file doesn't exist
certbot certonly --nginx
I know there's a certbot renew
command but I'm getting the same results with each, so... anyway. It correctly picks up the domain name from the existing conf, prompts me to renew, and eventually spits out the error above. I also see a couple lines added to nginx error.log:
[notice] 125028#125028: signal process started
[error] 125028#125028: invalid PID number "" in "/run/nginx.pid"
Sure enough, nginx is started and is listening on 80 and 443. I didn't start it. It's also got a new PID. If I try service nginx restart, it fails because it's trying to bind to ports that this other (certbot's ??) Nginx process is already using.
At all times, whether via "proper" nginx or this certbot zombie one, my site is happily returning HTTP 200's to external requests. I've never got a "Connection reset by peer" error myself. Even when I manually created a /var/www/html/.well-known/acme-challenge/test
file it's always served it fine.
So.. what in the almighty shenannigans is going on? Why is certbot starting an nginx instance it can't see? Why doesn't it stop it? Is it supposed to be creating something in /.well-known/acme-challenge/
? Is my nginx instance somehow interfering? What should be happening? What am I doing wrong??
发布评论
评论(1)
好的,我仍然不了解certbot启动自己的nginx,不停止它,弄乱pids的怪异,所有这些...但是certbot现在可以看到我们的服务器并续订SSL证书。经过两天的宣誓盲人,它并没有被防火墙规则阻止……那是防火墙。
叹。
Ok, I still don't understand the weirdness with certbot starting its own nginx and not stopping it and mucking up PIDs and all that... but certbot can now see our server and renew the SSL certs. And after two days of IT swearing blind that it wasn't being blocked by a firewall rule... it was the firewall.
Sigh.