我最近尝试更新我的 letsencrypt ssl 证书,但更新后,每当我尝试连接到我的网站时,服务器都会返回 400 个响应。我尝试了所有我能想到的方法。我附上了我的 Nginx 错误日志文件的副本,级别设置为调试,以及我的服务器配置文件。任何帮助都非常感谢。
我在我的服务器上使用 Django、Nginx 和 Gunicorn。
我运行了命令certbot renew
来更新证书。
完成后,我只收到了 400 条回复。
此外,当我尝试连接到该站点时,收到 Django 错误输出:
Invalid HTTP_HOST header: 'testing.com,testing.com'. The domain name provided is not valid according to RFC 1034/1035.
Report at /
Invalid HTTP_HOST header: 'testing.com,testing.com'. The domain name provided is not valid according to RFC 1034/1035.
这可能与重复的 URL 有关,但我也不确定是否如此。
下面是我在 sites-available 中的 nginx 配置文件。
server { # redirection logic
listen 80; # port to listen on
return 301 https://$host$request_uri*;
}
server {
listen 443 ssl; # listen for HTTPS
server_name testing.com www.testing.com; # server name to use
ssl_certificate /etc/letsencrypt/live/testing.com/fullchain.pem; # ssl certs
ssl_certificate_key /etc/letsencrypt/live/dt-testing.com/privkey.pem;
location = /favicon.ico { access_log off; log_not_found off; } # site icon to use
location /static/ { # location of static files
root /websites/DT/path/;
}
location / {
proxy_set_header Host $host;
include proxy_params;
proxy_pass http://unix:/websites/DT/run/gunicorn.sock; # connector to gunicorn
#error_page 405 =200 $uri;
}
rewrite_log on;
error_log /var/log/nginx/error_log debug;
}
这是我的 nginx 调试日志输出。
"GET / HTTP/1.0
Host: testing.com
Host: testing.com
X-Real-IP: 185.252.151.5
X-Forwarded-For: 185.252.151.5
X-Forwarded-Proto: https
Connection: close
User-Agent: Mozilla/5.0 (Linux; Android 7.1.1; Nexus 6P Build/NOF27C) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.81 Mobile Safari/537.36
Accept-Language: en-us,en-gb,en;q=0.7,*;q=0.3
Accept-Charset: utf-8,ISO-8859-1;q=0.7,*;q=0.7
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Encoding: x-gzip, gzip, deflate
"
2019/04/06 00:02:56 [debug] 11579#11579: *12 http cleanup add: 000055DF21463240
2019/04/06 00:02:56 [debug] 11579#11579: *12 get rr peer, try: 1
2019/04/06 00:02:56 [debug] 11579#11579: *12 stream socket 15
2019/04/06 00:02:56 [debug] 11579#11579: *12 epoll add connection: fd:15 ev:80002005
2019/04/06 00:02:56 [debug] 11579#11579: *12 connect to unix:/websites/DT/run/gunicorn.sock, fd:15 #13
2019/04/06 00:02:56 [debug] 11579#11579: *12 connected
2019/04/06 00:02:56 [debug] 11579#11579: *12 http upstream connect: 0
2019/04/06 00:02:56 [debug] 11579#11579: *12 posix_memalign: 000055DF2142F410:128 @16
2019/04/06 00:02:56 [debug] 11579#11579: *12 http upstream send request
2019/04/06 00:02:56 [debug] 11579#11579: *12 http upstream send request body
2019/04/06 00:02:56 [debug] 11579#11579: *12 chain writer buf fl:1 s:524
2019/04/06 00:02:56 [debug] 11579#11579: *12 chain writer in: 000055DF214F97D0
2019/04/06 00:02:56 [debug] 11579#11579: *12 writev: 524 of 524
2019/04/06 00:02:56 [debug] 11579#11579: *12 chain writer out: 0000000000000000
2019/04/06 00:02:56 [debug] 11579#11579: *12 event timer add: 15: 60000:4664042409
2019/04/06 00:02:56 [debug] 11579#11579: *12 http finalize request: -4, "/?" a:1, c:2
2019/04/06 00:02:56 [debug] 11579#11579: *12 http request count:2 blk:0
2019/04/06 00:02:56 [debug] 11579#11579: *12 http run request: "/?"
2019/04/06 00:02:56 [debug] 11579#11579: *12 http upstream check client, write event:1, "/"
2019/04/06 00:02:56 [debug] 11579#11579: *12 http upstream request: "/?"
2019/04/06 00:02:56 [debug] 11579#11579: *12 http upstream dummy handler
2019/04/06 00:02:57 [debug] 11579#11579: *12 http upstream request: "/?"
2019/04/06 00:02:57 [debug] 11579#11579: *12 http upstream process header
2019/04/06 00:02:57 [debug] 11579#11579: *12 malloc: 000055DF21502980:4096
2019/04/06 00:02:57 [debug] 11579#11579: *12 recv: eof:1, avail:1
2019/04/06 00:02:57 [debug] 11579#11579: *12 recv: fd:15 160 of 4096
2019/04/06 00:02:57 [debug] 11579#11579: *12 http proxy status 400 "400 Bad Request"
2019/04/06 00:02:57 [debug] 11579#11579: *12 http proxy header: "Server: gunicorn/19.9.0"
2019/04/06 00:02:57 [debug] 11579#11579: *12 http proxy header: "Date: Sat, 06 Apr 2019 00:02:57 GMT"
2019/04/06 00:02:57 [debug] 11579#11579: *12 http proxy header: "Connection: close"
2019/04/06 00:02:57 [debug] 11579#11579: *12 http proxy header: "Content-Type: text/html"
2019/04/06 00:02:57 [debug] 11579#11579: *12 http proxy header done
2019/04/06 00:02:57 [debug] 11579#11579: *12 xslt filter header
2019/04/06 00:02:57 [debug] 11579#11579: *12 HTTP/1.1 400 Bad Request
Server: nginx/1.15.5 (Ubuntu)
Date: Sat, 06 Apr 2019 00:02:57 GMT
Content-Type: text/html
Transfer-Encoding: chunked
Connection: keep-alive
编辑:此时,我认为我在某处重复了 URL。我还提供了我的 nginx.conf 文件,希望在其中重复了某些内容。
user www-data;
worker_processes auto;
pid /run/nginx.pid;
include /etc/nginx/modules-enabled/*.conf;
events {
worker_connections 768;
# multi_accept on;
}
http {
##
# Basic Settings
##
sendfile on;
tcp_nopush on;
tcp_nodelay on;
keepalive_timeout 65;
types_hash_max_size 2048;
# server_tokens off;
# server_names_hash_bucket_size 64;
# server_name_in_redirect off;
include /etc/nginx/mime.types;
default_type application/octet-stream;
##
# SSL Settings
##
ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3; # Dropping SSLv3, ref: POODLE
ssl_prefer_server_ciphers on;
##
# Logging Settings
##
access_log /var/log/nginx/access.log;
error_log /var/log/nginx/error.log;
##
# Gzip Settings
##
gzip on;
# gzip_vary on;
# gzip_proxied any;
# gzip_comp_level 6;
# gzip_buffers 16 8k;
# gzip_http_version 1.1;
# gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;
##
# Virtual Host Configs
##
#include /etc/nginx/conf.d/*.conf;
include /etc/nginx/sites-enabled/*;
}
#mail {
# # See sample authentication script at:
# # http://wiki.nginx.org/ImapAuthenticateWithApachePhpScript
#
# # auth_http localhost/auth.php;
# # pop3_capabilities "TOP" "USER";
# # imap_capabilities "IMAP4rev1" "UIDPLUS";
#
# server {
# listen localhost:110;
# protocol pop3;
# proxy on;
# }
#
# server {
# listen localhost:143;
# protocol imap;
# proxy on;
# }
#}
答案1
这个问题似乎与 SSL 没有直接关系,但更像是你使用了有问题的 HTTP 客户端,该客户端发送了多个 HTTPHost
字段。这完全是错误的,完全违反了 HTTP 标准:
GET / HTTP/1.0
Host: testing.com
Host: testing.com
...
这些多个Host
字段被连接在一起并提供给 Web 应用程序,该应用程序正确地抱怨标头毫无意义:
无效的 HTTP_HOST 标头:“dt-testing.com,dt-testing.com”。根据 RFC 1034/1035,提供的域名无效。
这可能会导致400 Bad Request
。
要修复此问题,您需要修复损坏的 HTTP 客户端。我不知道这是什么客户端,但由于没有现代客户端会使用HTTP/1.0
(至少所有客户端都会使用HTTP/1.1
),也没有现代客户端会接受压缩x-gzip
(请参阅Accept-Encoding
字段),我认为这是一些自制的客户端,而不是它在User-Agent
字段中声称的客户端。