Lets Ecypt、Firefox、Peer 的憑證授權單位不被識別

Lets Ecypt、Firefox、Peer 的憑證授權單位不被識別

我最近將 TLS 終止從後端伺服器移回反向代理,並且遇到了這個非常具體的問題。

當連接到我的 nextcloud 網站時,firefox 會說SEC_ERROR_UNKNOWN_ISSUER.

有關錯誤的更多資訊(底部的證書資訊):

https://nextcloud.domain.com/

Peer’s Certificate issuer is not recognized.


HTTP Strict Transport Security: false

HTTP Public Key Pinning: false

奇怪的是,這個問題不會出現在任何其他瀏覽器上,只會出現在 Firefox 上(Firefox 95、Ubuntu 20.04、Windows 10 和 Android 12;無擴充)。僅在最初瀏覽該站點,然後關閉 Firefox,然後重新打開它並瀏覽到 nextcloud 上的任何 url 後,才會發生此錯誤。不幸的是,該錯誤並不完全是在第二次瀏覽時發生的,但無論是 Firefox 重新啟動後第二次、第三次還是第四次瀏覽,都會發生該錯誤。我可以透過在反向代理上重新啟動 nginx 來解決該錯誤。

需要明確的是,firefox 重啟似乎會觸發它;關閉選項卡並重新開啟不會產生錯誤。我也嘗試清除 Firefox 的網站資料並重新啟動,錯誤仍然發生。

奇怪的是,我在同一個反向代理上有幾個其他站點,使用 Lets 加密證書(不同的子網域),我無法在那裡複製錯誤。好像僅限於firefox+nextcloud+nginx。雖然重啟後端nginx/server並不影響。所以我想我的反向代理上應該缺少一個特定的配置。

我在這裡不知所措,唯一改變的是 TLS 被終止的地方和一個新的 Lets Encrypt 憑證。希望我遺漏了一些明顯的東西,這不是一個更大的問題。

完整的 nginx 配置(減去其他子域和 mime 類型):

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
# configuration file /etc/nginx/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.2 TLSv1.3;
        ssl_prefer_server_ciphers on;

        ##
        # Logging Settings
        ##

        ##
        # 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/sites-enabled/*;

        ##
        # Hardening
        ##
 
        add_header Allow "GET, POST, HEAD" always;
        add_header X-XSS-Protection "1; mode=block";
}


# configuration file /etc/nginx/snippets/ssl-params.conf:
ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers on;
ssl_ciphers "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH+aRSA+RC4 EECDH EDH+aRSA HIGH !RC4 !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS";
ssl_ecdh_curve secp384r1;
ssl_session_cache shared:SSL:10m;
ssl_session_tickets off;
ssl_stapling on;
ssl_stapling_verify on;
resolver 1.1.1.1 valid=300s;
resolver_timeout 5s;
# Disable preloading HSTS for now.  You can use the commented out header line that includes
# the "preload" directive if you understand the implications.
add_header Strict-Transport-Security "max-age=15552000; includeSubdomains; preload";
add_header X-Frame-Options "DENY" always;
add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "no-referrer" always;
add_header X-Download-Options "noopen" always;
add_header X-Permitted-Cross-Domain-Policies "none" always;
add_header X-Robots-Tag "none" always;
add_header X-XSS-Protection "1; mode=block" always;

ssl_dhparam /etc/ssl/certs/dhparam.pem;

# configuration file /etc/nginx/sites-enabled/nextcloud.domain.com:
server {
        listen 443 ssl http2;
        ssl_certificate /etc/letsencrypt/live/nextcloud.domain.com/fullchain.pem;
        ssl_certificate_key /etc/letsencrypt/live/nextcloud.domain.com/privkey.pem;
        include snippets/ssl-params.conf;
        server_name nextcloud.domain.com;
        location / {
                proxy_pass https://BACKENDIP;
                proxy_set_header X-Real-IP $remote_addr;
        }
}

# configuration file /etc/nginx/sites-enabled/reverseproxy.conf:
server {
        listen 80;
        server_name _;
        return 301 https://$host$request_uri;
}

透過 Firefox 來自伺服器憑證的一些資訊:

Subject Name
Common Name nextcloud.domain.com

Issuer Name
Country US
Organization Let's Encrypt
Common Name R3

Validity
Not Before Fri, 10 Dec 2021 19:29:21 GMT
Not After Thu, 10 Mar 2022 19:29:20 GMT

中級證書:

Subject Name
Country US
Organization Let's Encrypt
Common Name R3

Issuer Name
Country US
Organization Internet Security Research Group
Common Name ISRG Root X1

Validity
Not Before Fri, 04 Sep 2020 00:00:00 GMT
Not After Mon, 15 Sep 2025 16:00:00 GMT

根證書:

Subject Name
Country US
Organization Internet Security Research Group
Common Name ISRG Root X1

Issuer Name
Organization Digital Signature Trust Co.
Common Name DST Root CA X3

Validity
Not Before Wed, 20 Jan 2021 19:14:03 GMT
Not After Mon, 30 Sep 2024 18:14:03 GMT

代理或伺服器上沒有與任何內容相關的錯誤。 HTTP 請求顯示為代碼 200。

以下是我的兩台伺服器上的兩個憑證之間的比較,這兩個憑證都是透過 Lets Encrypt Certbot 頒發的,相隔幾分鐘:

這是 Firefox 的憑證有問題: 錯誤證書

這是 Firefox 接受的憑證: 良好的證書

一個稍微令人擔憂的問題是,當瀏覽到 Firefox 不信任的網站時,在 Chrome 中,我得到的根憑證不是由同一組織頒發的。

相關內容