Ich habe meine TLS-Terminierung vor Kurzem vom Backend-Server zurück auf meinen Reverse-Proxy verschoben und bin auf dieses sehr spezifische Problem gestoßen.
Beim Verbinden mit meiner Nextcloud-Site sagt Firefox SEC_ERROR_UNKNOWN_ISSUER:
Weitere Informationen zum Fehler (Zertifikatsinformationen unten):
https://nextcloud.domain.com/
Peer’s Certificate issuer is not recognized.
HTTP Strict Transport Security: false
HTTP Public Key Pinning: false
Das Seltsame ist, dass dieses Problem bei keinem anderen Browser auftritt, nur bei Firefox (Firefox 95, Ubuntu 20.04, Windows 10 und Android 12; keine Erweiterungen). Es tritt nur auf, wenn man zunächst zur Site navigiert, dann Firefox schließt, sie dann wieder öffnet und zu einer beliebigen URL auf Nextcloud navigiert und der Fehler auftritt. Leider ist es nicht genau so, dass der Fehler beim zweiten Browsen auftritt, aber er tritt auf, egal ob es das zweite, dritte oder vierte Browsen nach einem Firefox-Neustart ist. Ich kann den Fehler beheben, indem ich nginx auf meinem Reverse-Proxy neu starte.
Um es klarzustellen: Es scheint, dass der Neustart von Firefox den Fehler auslöst; das Schließen und erneute Öffnen des Tabs führt nicht zu dem Fehler. Ich habe auch versucht, die Site-Daten von Firefox zu löschen und neu zu starten, der Fehler tritt immer noch auf.
Das Seltsame daran ist, dass ich ein paar andere Sites auf demselben Reverse-Proxy habe, die Lets-Encrypt-Zertifikate verwenden (andere Subdomäne), und ich kann den Fehler dort nicht reproduzieren. Er scheint auf Firefox+NextCloud+Nginx beschränkt zu sein. Ein Neustart des Backends Nginx/Server hat jedoch keine Auswirkungen. Ich nehme also an, dass es eine bestimmte Konfiguration geben muss, die mir auf meinem Reverse-Proxy fehlt.
Ich bin hier ratlos, das einzige, was sich geändert hat, ist, wo das TLS beendet wird und ein neues Lets Encrypt-Zertifikat. Hoffentlich übersehe ich etwas Offensichtliches und das ist kein größeres Problem.
Vollständige Nginx-Konfiguration (abzüglich anderer Subdomänen und MIME-Typen):
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;
}
Einige Informationen vom Serverzertifikat über 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
Zwischenzertifikat:
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
Stammzertifikat:
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
Keine Fehler auf dem Proxy oder Server, die mit irgendetwas in Zusammenhang stehen. Die HTTP-Anforderung wird als Code 200 angezeigt.
Hier ist ein Vergleich zwischen zwei Zertifikaten auf zwei meiner Server, die beide im Abstand von wenigen Minuten über Lets Encrypt Certbot ausgestellt wurden:
Dies ist das Zertifikat, mit dem Firefox ein Problem hat:
Dies ist das von Firefox akzeptierte Zertifikat:
Ein etwas beunruhigendes Problem besteht darin, dass ich beim Aufrufen einer Site, der Firefox nicht vertraut, in Chrome ein Stammzertifikat erhalte, das NICHT von derselben Organisation ausgestellt wurde.