Nginx 的 SSL 证书和 HTTPS 重定向错误

2 年 ago

宇, 华

3 minutes

引言

Nginx是一款受欢迎的Web服务器，可以在互联网上托管许多大型和高流量的网站。在安装Nginx后，您的网站默认接受HTTP流量的请求。这对于您的网站来说并不是最安全的选择。因此，您可以选择将HTTP流量重定向到HTTPS，这是用于加密流量并通过TLS/SSL证书进行验证的选项。即使有类似Let’s Encrypt或Cerbot的资源可以帮助自动化获取证书和协助重定向到HTTPS的过程，但您的Nginx Web服务器仍然可能出现错误。

本指南中的示例在Ubuntu 22.04服务器上经过测试，但适用于大多数Nginx安装。这些错误大多可以在Nginx的标准配置文件范围内解决，尽管目录和路径可能略有不同。

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

检查您的 Nginx 错误日志。

本教程中提供的错误和解决方案是常见情况，但并不是穷尽所有可能。由于语法错误打破了Nginx识别为有效语句的结构，以下错误只是指导Nginx如何做出响应的准则。往往一个错误会引发其他错误，并且一个错误可能是更大或独立问题的症状。您的具体情况和设置可能会有所不同。

请注意，您始终可以参考Nginx错误日志来查看正在运行的列表。

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

验证服务器块中的重定向指令

如果您的网站在HTTP与HTTPS之间的重定向存在问题，可能是您在配置文件中设置的指令有问题。特别是，listen 指令应该指向适当的端口，即443端口，表示加密的HTTPS流量。为了提供背景，如果您为Nginx网络服务器设置了服务器域块，则您的配置可能遵循以下结构：

/etc/nginx/sites-available/example.com 可在此处找到 example.com 的配置文件。

server {
        listen 80;
        listen [::]:80;

        root /var/www/example.com/html;
        index index.html index.htm index.nginx-debian.html;

        server_name example.com www.example.com;

        location / {
                try_files $uri $uri/ =404;
        }
}

这个文件的内容提供了几个指令的详细信息，但最需要注意的是listen指令。目前，此指令只允许端口80的传入请求，这是Nginx的默认端口。该端口仅用于HTTP流量，而不是HTTPS。为了允许HTTP流量重定向到HTTPS，您需要更新listen指令，将端口443包括其中。

你可以通过从证书授权机构（CA），例如Let’s Encrypt获得一个TLS/SSL证书，来高效地实现这一点。为你的网站获得证书有助于使web服务器能够启用加密的HTTPS。

此外，通过名为Certbot的软件客户端，Nginx可以完全自动化地获得和安装该证书，该客户端还有一个用于Nginx的插件。您可以允许Certbot自动配置Nginx的配置文件，将所有HTTP流量重定向到HTTPS，并禁止直接的HTTP流量。如果您喜欢，您也可以手动完成此操作，其原理是相同的。请通过我们的”How To Secure Nginx with Let’s Encrypt”教程了解更多信息。对于本教程，我们已经通过Let’s Encrypt获得了一个证书，并将配置文件更新为如下：

/etc/nginx/sites-available/example.com 可供选择的一个选项如下：

server {

        root /var/www/example.com/html;
        index index.html index.htm index.nginx-debian.html;

        server_name example.com www.example.com;

        location / {
                try_files $uri $uri/ =404;
        }

    listen [::]:443 ssl ipv6only=on; # managed by Certbot
    listen 443 ssl; # managed by Certbot
    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem; # managed by Certbot
    include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot


}

server {
        if ($host = www.example.com) {
                return 301 https://$host$request_uri;
        } # managed by Certbot


        if ($host = example.com) {
                return 301 https://$host$request_uri;
        } # managed by Certbot


        listen 80;
        listen [::]:80;

        server_name example.com www.example.com;
        return 404; # managed by Certbot
}

如果你将这个服务器域名块与第一个示例进行比较，你可以评估因Certbot自动设置SSL证书所进行的更改。更重要的是，listen指令现在指向443端口，这意味着允许HTTPS连接。通过Let’s Encrypt由Certbot生成的证书和密钥也与你的服务器块关联起来。

此外，Certbot重组了您的服务器块，将所有HTTP流量重定向到HTTPS。现在您有了一个额外的服务器块，它处理在端口80上的原始监听指令。这个新的服务器块通过对$host变量进行条件检查来捕获所有访问您的域名的流量。这是通过条件if指令语句执行的。这些指令将检查变量是否与您的域名匹配，然后Nginx使用301重定向将请求发送到该网站的HTTPS版本。此外，作为一种安全措施，任何成功绕过条件重定向的流量都将被捕获为404错误。

如果问题仍然存在，您可能需要检查防火墙设置并根据需求进行调整。

调整您的防火墙设置

如果你设置了TLS/SSL证书后，仍然无法正常响应，那么可能是你的防火墙设置有问题。正如前面所提到的，如果你按照Let’s Encrypt教程进行了设置，HTTP和HTTPS的重定向已经自动在配置文件中设置为监听指令。因此，错误的一个可能原因是你的防火墙禁止了443端口上的HTTPS流量。

要检查当前防火墙上哪些端口是打开的，您可以运行以下命令。请记住，本教程使用的是简易防火墙UFW，因此根据您的发行版可能有所不同。

sudo ufw status

Status: active

To                         Action      From
--                         ------      ----
OpenSSH                    ALLOW       Anywhere
Nginx HTTP                 ALLOW       Anywhere
OpenSSH (v6)               ALLOW       Anywhere (v6)
Nginx HTTP (v6)            ALLOW       Anywhere (v6)

如果您的输出与以下类似的列表相符，那么这意味着您的防火墙当前只允许接受HTTP请求。要调整这些设置，您需要添加允许通过端口443进行TLS/SSL加密流量的Nginx HTTPS配置文件。要执行此操作，请运行以下命令：

sudo ufw allow ‘Nginx HTTPS’

如果你收到了“规则已添加”的输出，则说明你成功将此个人资料添加至你的列表中。你可以通过检查状态来确认。

sudo ufw status

Status: active

To                         Action      From
--                         ------      ----
OpenSSH                    ALLOW       Anywhere
Nginx HTTP                 ALLOW       Anywhere
Nginx HTTPS                ALLOW       Anywhere
OpenSSH (v6)               ALLOW       Anywhere (v6)
Nginx HTTP (v6)            ALLOW       Anywhere (v6)
Nginx HTTPS (v6)           ALLOW       Anywhere (v6)

Note

注意：有一个名为Nginx Full的Nginx配置文件可用，它打开HTTP和HTTPS端口连接。如果你想清理列表，可以使用sudo ufw delete allow ‘Nginx HTTP’和sudo ufw delete allow ‘Nginx HTTPS’命令删除这两个规则，然后添加以下规则：sudo ufw allow ‘Nginx Full’

你的防火墙现在可以接受来自HTTP和HTTPS流量的连接。

现在Nginx的HTTP和HTTPS配置文件都已列出，端口443已开放，并且请求将重定向到HTTPS。

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

将HTTP重定向到HTTPS意味着您允许进行加密的流量连接，并且通常需要TLS/SSL证书进行验证。然而，在浏览器层面仍有可能出现错误信息。请记住，这些错误信息并不意味着您的Nginx服务器出现问题，而是证书本身存在问题。

例如，如果您使用的是自签名的SSL证书，这个证书未经由像Let’s Encrypt这样的证书机构（CA）验证。因此，当您在浏览器中访问https://example.com时，可能会弹出一个信息提示，警告访问者该网站不安全。

在这种情况下，有一个错误提示是“您的连接不是私密的”，并且显示了一个特定的错误，即NET::ERR_CERT_AUTHORITY_INVALID。如果您点击高级选项，尽管证书不安全，仍然可以绕过此错误。

高级选项详细说明了example.com无法被充分识别。尽管这可能不是真实的，因为您设置了自签名的SSL证书，但是来访者会对您的网站产生这样的感知。

尽管您可以通过选择“继续访问…”选项继续访问您的网站，但在访问您的网站时收到此类安全和隐私提示会给用户带来糟糕的体验。您应该使用由 CA（证书颁发机构）验证的证书。您可以阅读我们的教程《如何使用 Let’s Encrypt 保护 Nginx》来设置这个。

然而，即使你通过Let’s Encrypt设置了TLS/SSL证书，仍有可能收到以下消息。

这个消息与原始的“您的连接不是私密的”消息不同，因为网络错误显示为NET::ERR_CERT_DATE_INVALID，意味着您当前的SSL/TLS证书已经过期。需要注意的是，Let’s Encrypt证书只持续有效90天。如果在安装Let’s Encrypt时使用了certbot软件包，系统将安排每天两次检查即将过期的证书，且每次检查将提前30天进行。

您可以通过以下方式查看定时器的状态:
您可以使用以下方法检查定时器的状态:
您可以通过以下途径查看定时器的状态:
您可以查询定时器的状态使用以下方式:

sudo systemctl status snap.certbot.renew.service

输出将确认您的证书续订处于活动状态。

然而，如果您的证书过期并且希望强制更新，您可以使用以下命令。如果您要为不同的域名更新证书，这也是很有用的。

certbot certonly –force-renew -d example.com

即使certbot软件包带有/etc/cron.d下的证书更新脚本，但还有其他选项。例如，您可以在Certbot中设置renew_hook选项，以便在更新后运行其他任务。要做到这一点，您需要将renew_hook添加到Certbot更新配置文件中。首先用您选择的文本编辑器打开该文件。

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

一旦你进入文件，将钩子添加到最后一行，重新加载面向网络的服务，以便设置可以使用更新的证书。

/etc/letsencrypt/renewal/example.com.conf 的中文意思是：“example.com 的续订配置文件。”

renew_hook = systemctl reload your_service

完成后，您可以保存并关闭文件。如果您正在使用nano，按下CTRL + X，Y，然后按ENTER键。

无论您在设置证书续订流程时选择什么，您总可以通过以下命令确认Certbot正在按预期运行续订流程。

sudo certbot renew –dry-run

最后，使用sudo nginx -t检查是否有语法错误，然后使用sudo systemctl restart nginx重新启动Nginx以确保您的更改生效。完成所有操作后，打开您的Web浏览器，访问https://example.com以确认重定向是否正常工作。

结论是

在本教程中，您学习了如何解决Nginx Web服务器重定向的常见错误，特别是从HTTP到HTTPS的重定向。其中一些解决方案包括验证配置文件是否正确设置以监听适当的端口，打开防火墙以接收这些连接，并处理有关未经验证或已过期的SSL/TLS证书的安全错误消息。如果您对学习更多关于Nginx的内容感兴趣，您可以查看我们的社区页面或开始学习如何在Ubuntu 22.04上安装Nginx。