oiooiooioiioooiioiioiooo
Goto Top

Nginx TLSv1.2 (OUT), TLS alert, unknown CA (560)

Moin an alle,

wiedermal sitze ich vor einer Herausforderung welche mich überfordert und bekomme noch nicht einmal ansatzweise mal eine Lösung.

Ich habe mir mal einen Suse Server aufgesetzt:

Kernel: 5.3.18-lp152.69-default x86_64 bits: 64 Console: tty 0 Distro: openSUSE Leap 15.2

Um uns etwas fortzubilden haben wir uns bei der Maschine für nginx/1.16.1 entschieden

Wir haben auf dem Server vorerst zwei vhosts mit der Nachfolgende Konfig angelegt.

Seite 1: /etc/nginx/sites/seite1_de.conf
server {
        listen          111.11.111.11:80;
        listen          [::]:80;

        server_name     seite1.de www.seite1.de;

        return 301 https://seite1.de$request_uri;
}

server {
        listen          111.11.111.11:443 ssl;
        listen          [::]:443 ssl;

        server_name     seite1.de www.seite1.de;

        ssl_certificate /etc/nginx/ssl-certs/2021_wc.seite1_de.crt;
        ssl_trusted_certificate /etc/nginx/ssl-certs/2021_SectigoRSAExtendedValidationSecureServerCA.crt;
        ssl_certificate_key /etc/nginx/ssl-certs/2021_wc.seite1_de.key;

        root /srv/www/htdocs/shopware_seite1_de/public;
        index index.php index.html;

        allow 127.0.0.1;
        allow 222.11.111.11;
        allow 90.187.21.233;
        allow 111.11.111.11;
        allow 111.11.111.22;
        deny all;


        location /recovery/install {
                allow 222.11.111.11;
                allow 111.11.111.11;
                allow 111.11.111.22;
                deny all;
                index index.php;
                try_files $uri /recovery/install/index.php$is_args$args;
        }

        location /recovery/update/ {
                allow 222.11.111.11;
                allow 111.11.111.11;
                allow 111.11.111.22;
                deny all;
                location /recovery/update/assets {
                }
                if (!-e $request_filename){
                        rewrite . /recovery/update/index.php last;
                }
        }

        location / {
                try_files $uri /index.php$is_args$args;
        }

        location ~ \.php$ {
                fastcgi_split_path_info ^(.+\.php)(/.+)$;
                include fastcgi.conf;
                fastcgi_param HTTP_PROXY "";  
                fastcgi_buffers 8 16k;
                fastcgi_buffer_size 32k;
                client_max_body_size 24M;
                client_body_buffer_size 128k;
                fastcgi_pass localhost:9000;
                http2_push_preload on;
        }

        location /admin_status {
                stub_status on;
                allow ::1;
                allow 222.11.111.11/32;
                deny all;
        }

        access_log /srv/www/log/shopware_seite1_de-access.log;
        error_log /srv/www/log/shopware_seite1_de-error.log;

}

Die Seite wird ganz gewöhnlich aufgerufen auch mit dem Port 443 keine Probleme. Mit keinem Browser. Weder mit Firefox noch Cronium.

Nun zum Problem: bei dem Aufruf über curl hingegen haben wir folgende Ausgabe:

curl -vvv https://seite1.de
*   Trying 111.11.111.11:443...
* TCP_NODELAY set
* Connected to seite1.de (111.11.111.11) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (OUT), TLS alert, unknown CA (560):
* SSL certificate problem: unable to get local issuer certificate
* Closing connection 0
curl: (60) SSL certificate problem: unable to get local issuer certificate
More details here: https://curl.haxx.se/docs/sslcerts.html

curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.

Natürlich könnte man das auch ignorieren, nur denke ich mir, dass die Suchmaschinen-Spinnen damit nicht umgehen können.

Hat wer eine Idee, wo das Problem liegen könnte?

Viele Grüße

Ich

Content-ID: 665909

Url: https://administrator.de/contentid/665909

Ausgedruckt am: 21.11.2024 um 22:11 Uhr

tagol01
tagol01 20.04.2021 um 09:09:02 Uhr
Goto Top
hallo

deine zertifizierungs kette ist nicht vollstaendig.
OIOOIOOIOIIOOOIIOIIOIOOO
OIOOIOOIOIIOOOIIOIIOIOOO 20.04.2021 um 09:15:16 Uhr
Goto Top
vielen Dank für deine Antwort, was fehlt da noch?

Wir haben den Schlüssel, das Zertifikat und den ServerCA. Was fehlt uns noch?

Würde auch beim Aufruf mit einem Browser nicht auch zu Problemen führen, wenn die Kette unvollständig wäre?
OIOOIOOIOIIOOOIIOIIOIOOO
OIOOIOOIOIIOOOIIOIIOIOOO 20.04.2021 um 09:16:19 Uhr
Goto Top
wir haben auch die beiden Pakete nachinstalliert:

ca-certificates-cacert
ca-certificates-mozilla
SlainteMhath
SlainteMhath 20.04.2021 um 09:58:54 Uhr
Goto Top
Moin,

der Rechner auf dem du curl aufrust, kennt nicht alle CAs aus der Validierungskette deines Server-Zertifikates.
Abhllfe: Fehlende Zertifikate auf dem Rechner installieren, der CURL aufruft

Wenn FF, Chrome und Edge die Seite ohne Fehlermeldung öffnen sollte am TLS vom Webserver alles passen.

lg,
Slainte
tagol01
Lösung tagol01 20.04.2021 um 10:00:36 Uhr
Goto Top
OIOOIOOIOIIOOOIIOIIOIOOO
OIOOIOOIOIIOOOIIOIIOIOOO 20.04.2021 um 10:26:58 Uhr
Goto Top
Zitat von @SlainteMhath:
der Rechner auf dem du curl aufrust, kennt nicht alle CAs aus der Validierungskette deines Server-Zertifikates.
Abhllfe: Fehlende Zertifikate auf dem Rechner installieren, der CURL aufruft

Wenn FF, Chrome und Edge die Seite ohne Fehlermeldung öffnen sollte am TLS vom Webserver alles passen.

Den Aufruf machen wir auch local am Server. Da bekommen wir das gleiche Ergebnis. des weterem, wird das Zertifikat auch auf anderen Servern (httpd) eingesetzt, dort haben wir jedoch keine Probleme.

Zitat von @tagol01:

bei nginx muss man die kette manuel schliessen:

siehe:

https://ldeds.de/?q=nginx%20zertifikate%20kette
Vielen Dank, für deine Hilfe -.- so viele Fehler beim Tippen habe ich jedoch nicht gehabt :p



Auf diese Seite waren wir auch und konnten leider nicht sofort erkennen was man an welche Stelle und wofür gesetzt werden soll.

Ich versuche jetzt mal aufzuschlüsseln, so wie ich es verstanden habe:

cat domain.tld.crt sub-ca.cer > domain-bundle.crt

domain.tld.crt = Zertifikat, welches wir von Zertifizierungstelle erhalten haben (2021_wc.seite1_de.crt)
sub-ca.cer = Die Requestdatei welche wir selbst generiert haben
domain-bundle.crt = Ergebnis für das Zertifikat für NGINX

Erst also das eigentliche Zertifikat für die Domäne (domain.tld) – dann die Zwischenzertifizierungsstelle (sub-ca). Die Stammzertifizierungsstelle (Root-CA) wird meistens nicht benötigt.

Was ist ein "sub-ca"? Sagt mir bitte nicht Zwischenzertifizierungsstelle face-smile Wie und wo bekomme ich diese?

Manchmal muss man aber doch auch das Root-CA mit in Kette mit aufnehmen (z.B. bei Zertifikate einer eigenen CA) – dann wäre es:
cat domain.tld.crt sub-ca.cer root-ca.cer > domain-bundle.crt

an diese Stelle bin ich raus

Erst also das eigentliche Zertifikat für die Domäne (domain.tld) – dann die Zwischenzertifizierungsstelle (sub-ca) und am Schluss die Stammzertifizierungsstelle (root-ca).

Wenn man die Zertifikate von Windows-Systemen bekommt, sollte man alle vorher mit
openssl x509 -inform der -in certificate.cer -out certificate.pem

Dieser Schritt ist bei uns nicht nötig, da wir mit Linux arbeiten.

umwandeln und dann eben mit
cat domain.tld.pem sub-ca.pem root-ca.pem > domain-bundle.crt

weiterverarbeiten.

In der Nginx-Config jetzt enfach das bundle.crt in der Zeile

ssl_certificate /etc/nginx/ssl/domain-bundle.crt;

angeben und nginx dann neustarten.

face-confused
tagol01
tagol01 20.04.2021 um 10:32:02 Uhr
Goto Top
welches zert hast du? bzw. vom welchem anbieter?
OIOOIOOIOIIOOOIIOIIOIOOO
OIOOIOOIOIIOOOIIOIIOIOOO 20.04.2021 aktualisiert um 10:39:26 Uhr
Goto Top
wildcard über sslplus bezogen von certum
OIOOIOOIOIIOOOIIOIIOIOOO
OIOOIOOIOIIOOOIIOIIOIOOO 20.04.2021 aktualisiert um 10:52:15 Uhr
Goto Top
cat 2021_wc.seite1_de.crt 2021_SectigoRSAExtendedValidationSecureServerCA.crt > ca-bundle.crt

in die vhost eingetragen und überfüssige entfernen oder auskommentieren:

#ssl_certificate /etc/nginx/ssl-certs/2021_wc.seite1_de.crt;
#ssl_trusted_certificate /etc/nginx/ssl-certs/2021_SectigoRSAExtendedValidationSecureServerCA.crt;
ssl_certificate /etc/nginx/ssl-certs/2021_bundle.crt;
ssl_certificate_key /etc/nginx/ssl-certs/2021_wc.seite1_de.key;

systemctl restart nginx

Firtisch!

Danke dir tagol.de face-smile