Nginx SSL 证书和 HTTPS 重定向错误

介绍

Nginx是一个流行的网页服务器,可以在互联网上托管许多大型和高流量网站。安装 Nginx后,您的网站默认接受HTTP流量请求,这不是您网站的最安全的选择。出于这个原因,您可以选择将您的HTTP流量重定向到HTTPS,这是用于加密流量,并通过TLS/SSL证书(https://andsky.com/tech/tutorials/openssl-essentials-working-with-ssl-certificates-private-keys-and-csrs)进行验证。即使有资源如Let's EncryptCerbot来帮助自动化获得证书并协助重定向到HTTPS过程,仍有可能发生在您的 Nginx网页服务器上。

本指南中的示例在Ubuntu 22.04 服务器上进行了测试,但应该适用于大多数 Nginx 安装程序. 这些错误大部分都可以在 Nginx 标准化配置文件的范围内解决,尽管目录和路径可能略有不同。

在本教程中,您将了解在为您的 Nginx 服务器设置 TLS/SSL 证书和 HTTPS 重定向连接时可能出现的常见错误,您还将学习如何识别这些重定向错误的可能原因并修复它们。

检查您的 Nginx 错误日志

在本教程中提出的错误和解决方案是常见的案例,但不是完整的。由于语法错误的性质破坏了 Nginx 承认的有效陈述的结构,以下错误只是 Nginx 如何响应的指南。

请注意,您可以始终参阅 Nginx 错误日志以查看运行列表:

1sudo cat /var/log/nginx/error.log

验证您的服务器封锁的重定向指令

如果您的网站没有从 HTTP 重定向到 HTTPS 出现问题,则可能存在您在配置文件中设置的指令问题,具体而言,倾听指令应该指向适当的端口,在这种情况下,443,这意味着加密的 HTTPS 流量。

 1[label /etc/nginx/sites-available/example.com]
 2server {
 3        listen 80;
 4        listen [::]:80;
 5
 6        root /var/www/example.com/html;
 7        index index.html index.htm index.nginx-debian.html;
 8
 9        server_name example.com www.example.com;
10
11        location / {
12                try_files $uri $uri/ =404;
13        }
14}

此文件的内容提供了有关多个指令的详细信息,但最重要的是要注意的是倾听。 目前,此指令只允许对端口80的输入请求,这对于 Nginx 是默认的。

您可以有效地做到这一点的一种方法是从证书授权机构(CA)获得一个 TLS/SSL证书,例如 Let's Encrypt。

此外,通过一个名为Certbot的软件客户端,您可以允许Certbot自动配置您的Nginx配置文件以将所有HTTP流量重定向到HTTPS,并禁止直接的HTTP流量。如果您喜欢,您也可以手动完成此操作,并且适用相同的原则。 了解更多关于如何使用我们的教程在 How To Secure Nginx with Let's Encrypt上完成此操作。 对于本教程的目的,我们通过Let's Encrypt获得了一份证书,并更新了配置文件如下:

 1[label /etc/nginx/sites-available/example.com]
 2server {
 3
 4        root /var/www/example.com/html;
 5        index index.html index.htm index.nginx-debian.html;
 6
 7        server_name example.com www.example.com;
 8
 9        location / {
10                try_files $uri $uri/ =404;
11        }
12
13    listen [::]:443 ssl ipv6only=on; # managed by Certbot
14    listen 443 ssl; # managed by Certbot
15    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem; # managed by Certbot
16    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem; # managed by Certbot
17    include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
18    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot
19
20}
21
22server {
23        if ($host = www.example.com) {
24                return 301 https://$host$request_uri;
25        } # managed by Certbot
26
27        if ($host = example.com) {
28                return 301 https://$host$request_uri;
29        } # managed by Certbot
30
31        listen 80;
32        listen [::]:80;
33
34        server_name example.com www.example.com;
35        return 404; # managed by Certbot
36}

如果你将这个服务器域块与第一个例子进行比较,你可以评估由于Certbot管理的自动步骤来设置SSL证书所做的更改,更重要的是,倾听指令现在指向端口443,这意味着允许HTTPS连接。

此外,Certbot 重组您的服务器块,将所有 HTTP 流量重定向到 HTTPS. 您现在有一个额外的服务器块,该服务器块处理您的原始倾听指令在端口 80。 这个新的服务器块通过对 $host变量进行条件检查来捕捉到所有流量到您的域。 这是用条件if` 指令声明执行的。 这些指令检查变量是否匹配您的域,然后 Nginx 使用 301 重定向来发送请求到网站的 HTTPS 版本。 此外,作为一个故障安全,任何能够通过条件重定向的流量都将被捕获为 404 错误。

但是,如果您仍然遇到问题,您可能需要检查防火墙设置并在需要时调整它们。

调整您的防火墙设置

如果您的 Web 浏览器在设置 TLS/SSL 证书后也不会响应,那么您可能会遇到防火墙设置的问题,正如上一节所提到的,如果您遵循 Let’s Encrypt 教程,将 HTTP 和 HTTPS 重定向自动设置为配置文件中的倾听指令。

要检查目前在您的防火墙上打开的哪个端口的状态,您可以运行以下命令. 请记住,本教程使用的是不复杂的防火墙,因此这可能因您的分布而有所不同:

1sudo ufw status
1Status: active
2
3To Action From
4--                         ------      ----
5OpenSSH ALLOW Anywhere
6Nginx HTTP ALLOW Anywhere
7OpenSSH (v6)               ALLOW Anywhere (v6)
8Nginx HTTP (v6)            ALLOW Anywhere (v6)

如果您的输出反映了类似以下列表,那么这意味着您的防火墙目前只开放接受来自 HTTP 的请求. 为了调整这些设置,您想要添加Nginx HTTPS配置文件,允许通过端口443进行 TLS/SSL 加密流量。

1sudo ufw allow 'Nginx HTTPS'

如果您收到「規則添加」的輸出,那麼您已成功地將此個人資料添加到您的列表中。

1sudo ufw status
 1Status: active
 2
 3To Action From
 4--                         ------      ----
 5OpenSSH ALLOW Anywhere
 6Nginx HTTP ALLOW Anywhere
 7Nginx HTTPS ALLOW Anywhere
 8OpenSSH (v6)               ALLOW Anywhere (v6)
 9Nginx HTTP (v6)            ALLOW Anywhere (v6)
10Nginx HTTPS (v6)           ALLOW Anywhere (v6)

<$>[注] **注:**有一个名为Nginx Full的 Nginx 配置文件,可以打开 HTTP 和 HTTPS 端口连接。如果您想清理列表,您可以删除两个规则,包括sudo ufw delete allow ‘Nginx HTTP’sudo ufw delete allow ‘Nginx HTTPS’,并添加以下规则:

1sudo ufw allow 'Nginx Full'

您的防火墙随后准备接受来自 HTTP 和 HTTPS 流量的连接。

现在 Nginx HTTP 和 HTTPS 配置文件都列出了,端口 443 打开,请求将重定向到 HTTPS。

使用 TLS/SSL 证书安全设置您的重定向

重定向 HTTP 到 HTTPS 意味着您正在允许加密的流量连接,这通常是通过 TLS/SSL 证书进行验证的。然而,在浏览器级别仍有可能出现错误消息。

例如,如果您使用的是 自签名的SSL证书,这不会被证书管理局(CA)验证,例如使用Let's Encrypt. 因此,当您浏览到您的浏览器时,在https://example.com页面上,可能会出现一个消息提示,以警告访问者该网站不安全:

Nginx self-signed cert warning

在这种情况下,有一个错误,读取 您的连接不是私密的,并且有一个特定错误,表示 NET::ERR_CERT_AUTHORITY_INVALID

Nginx self-signed override

Advanced选项详细说明example.com无法充分识别,尽管这可能不是真的,因为您设置了自签名SSL证书的Web服务器,但这就是访问您的网站的任何人所感知的。

虽然您可以通过按 ** 继续到...** 选项继续访问您的网站,但在访问您的网站时收到此类安全和隐私消息是一种糟糕的用户体验,您将希望使用由 CA 验证的证书。

但是,即使您有通过 Let’s Encrypt 设置的 TLS/SSL 证书,也可以收到以下消息:

Nginx expired certificate

此消息与原来的 ** 您的连接不是私密 ** 消息不同,因为网络错误表示 NET::ERR_CERT_DATE_INVALID,这意味着您的当前 SSL/TLS 证书已过期。

您可以通过以下方式检查计时器的状态:

1sudo systemctl status snap.certbot.renew.service

输出将确认您的证书更新活动。

但是,如果您的证书已过期,并且您想要强制更新,您可以使用以下命令这样做。

1certbot certonly –force-renew -d example.com

儘管「certbot」套件配備了「/etc/cron.d」的證書更新脚本,但還有其他選項。例如,您可以使用 Certbot 設定「renew_hook」選項,以便在更新後執行其他任務。要做到這一點,您需要將「renew_hook」添加到 Certbot 更新設定檔案。開始使用您偏好的文本編輯器開啟檔案:

1sudo nano /etc/letsencrypt/renewal/example.com.conf

一旦你在文件中,添加链接到最后一行,以重新加载面向网络的服务,以便它们可以设置使用更新证书:

1[label /etc/letsencrypt/renewal/example.com.conf]
2renew_hook = systemctl reload your_service

一旦完成,您可以保存并关闭文件. 如果您使用nano,请按CTRL + X,Y,然后按ENTER

无论您在设置证书更新流程时选择什么,您可以随时通过以下命令确认certbot正在按照预期运行更新流程:

1sudo certbot renew --dry-run

最后,检查任何语法错误与 sudo nginx -t,然后重新启动 Nginx 与 sudo systemctl 重新启动 nginx 以确保您的更改被执行. 完成所有这些后,导航到您的网页浏览器在 https://example.com 确认重定向工作正确。

结论

在本教程中,您了解了如何解决 Nginx 网页服务器重定向的常见错误,特别是从 HTTP 到 HTTPS. 其中一些解决方案包括验证您的配置文件是否正确设置以倾听适当的端口,打开防火墙以接收这些连接,以及如何处理您可能接收的安全错误消息,涉及未验证或过期的 SSL/TLS 证书。 如果您有兴趣了解更多关于 Nginx 的信息,您可以查看我们的 标记社区页面,或跳入学习(如何在 Ubuntu 22.04 上安装 Nginx)(https://andsky.com/tech/tutorials/how-to-install-nginx-on-ubuntu-22-04)。

Published At
Categories with 技术
Tagged with
comments powered by Disqus