Das Problem, mit dem alles begann

Stellen Sie sich vor: Ich hatte gerade ein SSL-Zertifikat auf meiner Website shadynagy.com installiert. Aus meiner Sicht sah alles großartig aus – das Zertifikat war gültig, von Sectigo ausgestellt und hatte noch reichlich Zeit bis zum Ablauf (265 Tage!). Aber als ich einen schnellen SSL-Test auf WhyNoPadlock.com durchführte, wurde ich mit einigen enttäuschenden roten Kreuzchen konfrontiert:

❌ Force HTTPS: Erzwingt nicht die Verwendung von SSL
❌ Invalid Intermediate: Fehlendes Zwischenzertifikat (Bundle)

Mir sank das Herz. Was nützt ein SSL-Zertifikat, wenn es nicht richtig funktioniert? Meine Besucher könnten Sicherheitswarnungen sehen, Suchmaschinen könnten mich niedriger einstufen, und am schlimmsten – meine Website könnte unprofessionell wirken.

Aber hier ist die gute Nachricht: Ich habe alles behoben, und ich zeige Ihnen genau, wie ich es Schritt für Schritt gemacht habe.

Verstehen, was schiefgelaufen ist

Bevor wir uns in die Lösungen stürzen, sollten wir verstehen, was diese Fehler tatsächlich bedeuten:

Problem Nr. 1: Fehlendes Zwischenzertifikat

Was ist ein Zwischenzertifikat?

Stellen Sie sich SSL-Zertifikate wie eine Vertrauenskette vor:

• Ihr Browser vertraut bestimmten Root-Zertifizierungsstellen (wie Sectigo)
• Diese Behörden stellen Zwischenzertifikate an Unterbehörden aus
• Diese Unterbehörden stellen das Zertifikat Ihrer Website aus

Ihre Website muss SOWOHL Ihr Zertifikat ALS AUCH das Zwischenzertifikat an Browser senden. Ohne das Zwischenzertifikat kann der Browser die Vertrauenskette nicht überprüfen.

Auswirkungen in der Praxis:

• Einige Browser zeigen Sicherheitswarnungen an
• Mobile Geräte können häufig keine Verbindung herstellen
• Ihre Website wirkt für Besucher unsicher

Problem Nr. 2: Keine HTTP-zu-HTTPS-Weiterleitung

Was bedeutet das?

Wenn jemand http://shadynagy.com (ohne das ‘s’) eingibt, sollte er automatisch zu https://shadynagy.com weitergeleitet werden. Ohne diese Weiterleitung:

• Können Besucher über unsicheres HTTP auf Ihre Website zugreifen
• Sehen Suchmaschinen doppelten Inhalt (HTTP- und HTTPS-Versionen)
• Verlieren Sie die SEO-Vorteile von HTTPS

Lösung Nr. 1: Behebung des fehlenden Zwischenzertifikats

Schritt 1: Die Grundursache verstehen

Ich stellte fest, dass meine nginx-Konfiguration die falsche Direktive verwendete. Das hatte ich:

# ❌ FALSCHE KONFIGURATION
ssl_certificate /etc/nginx/ssl/shadynagy.com.crt;
ssl_trusted_certificate /etc/nginx/ssl/shadynagy.com.ca-bundle;

Das Problem: ssl_trusted_certificate ist für OCSP-Stapling (eine Performance-Funktion) gedacht, NICHT zum Senden der Zertifikatskette an Browser!

Schritt 2: Erstellen des vollständigen Kettenzertifikats

Die Lösung besteht darin, ein Fullchain-Zertifikat zu erstellen, das Ihr Zertifikat mit dem Zwischenzertifikat kombiniert.

Befehl:

cat /etc/nginx/ssl/shadynagy.com.crt /etc/nginx/ssl/shadynagy.com.ca-bundle > /etc/nginx/ssl/shadynagy.com-fullchain.crt

Was dies bewirkt:

• cat - Verkettet (kombiniert) Dateien
• Erste Datei: Das Zertifikat Ihrer Website
• Zweite Datei: Das CA-Bundle des Zwischenzertifikats
• > - Gibt in eine neue Datei namens “fullchain” aus

Beispielerklärung: Stellen Sie sich vor, Sie haben zwei Puzzleteile:

1. Ihr Zertifikat (Teil A)
2. Das Zwischenzertifikat (Teil B)

Sie kleben sie zusammen, um ein vollständiges Puzzle zu erstellen, das Browser verstehen können.

Schritt 3: Aktualisieren der Nginx-Konfiguration

Öffnen Sie Ihre SSL-Konfigurationsdatei:

nano /etc/nginx/conf.d/shadynagy.com-ssl.conf

Aktualisieren Sie auf Folgendes:

server {
    listen 443 ssl http2;  # Port 443 mit SSL und HTTP/2
    
    # ✅ KORREKT - Verwenden Sie das Fullchain-Zertifikat
    ssl_certificate /etc/nginx/ssl/shadynagy.com-fullchain.crt;
    ssl_certificate_key /etc/nginx/ssl/shadynagy.com.key;
    
    # Optional: Für OCSP-Stapling behalten (Performance-Boost)
    ssl_trusted_certificate /etc/nginx/ssl/shadynagy.com.ca-bundle;
    
    root /var/www/shady-nagy.com/html;
    index index.html index.htm;
    server_name shadynagy.com www.shadynagy.com;
    
    access_log /var/log/nginx/nginx.vhost.access.log;
    error_log /var/log/nginx/nginx.vhost.error.log;
    
    location / {
        try_files $uri $uri/ =404;
    }
}

Wichtige Änderungen erklärt:

1. listen 443 ssl http2;

   • 443 = HTTPS-Port
   • ssl = SSL aktivieren
   • http2 = HTTP/2 für bessere Performance aktivieren
   • Dies ersetzt die veraltete Direktive ssl on;

2. ssl_certificate verweist jetzt auf Fullchain statt nur auf Ihr Zertifikat

3. ssl_trusted_certificate wird für OCSP-Stapling beibehalten (optional, aber empfohlen)

Schritt 4: Änderungen testen und anwenden

Konfiguration testen:

nginx -t

Erwartete Ausgabe:

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

Wenn Sie Fehler sehen, überprüfen Sie Ihre Dateipfade und Syntax doppelt!

Änderungen anwenden:

systemctl reload nginx

Warum reload statt restart?

• reload wendet Änderungen an, ohne Verbindungen zu unterbrechen
• restart würde Ihre Website kurzzeitig offline nehmen

✅ Vorteile dieser Behebung

• ✅ Alle Browser können Ihr SSL-Zertifikat überprüfen
• ✅ Keine “Ungültiges Zertifikat”-Warnungen mehr
• ✅ Mobile Geräte verbinden sich ordnungsgemäß
• ✅ Besseres Vertrauen und SEO-Rankings
• ✅ Professionelles Erscheinungsbild

Lösung Nr. 2: HTTPS-Weiterleitungen erzwingen

Die Untersuchungsreise

Zuerst überprüfte ich meine HTTP-Konfiguration:

cat /etc/nginx/conf.d/shadynagy.com.conf

Ich fand Folgendes:

# ❌ DEFEKTE KONFIGURATION
server {
    listen 80;
    root /var/www/shady-nagy.com/html;
    server_name shadynagy.com www.shadynagy.com;
    
    location / {
        try_files $uri $uri/ =404;
    }
    
    return 301 https://$server_name$request_uri;  # Wird nie erreicht!
}

Das Problem: Nginx liest Konfigurationen von oben nach unten. Wenn eine Anfrage einging:

1. Wurde der location /-Block gefunden
2. Wurde die Anfrage verarbeitet
3. Wurde die Weiterleitungszeile NIE erreicht

Es ist, als würde man ein Umleitungsschild NACH der Straße aufstellen!

Schritt 1: Erstellen der korrekten Weiterleitungskonfiguration

Die Lösung:

# ✅ KORREKTE KONFIGURATION
server {
    listen 80;
    listen [::]:80;  # Auch auf IPv6 lauschen
    server_name shadynagy.com www.shadynagy.com;
    
    # ALLEN HTTP-Traffic zu HTTPS weiterleiten
    return 301 https://$host$request_uri;
}

Was jeder Teil bewirkt:

• listen 80; - Auf HTTP-Anfragen lauschen (Port 80)
• listen [::]:80; - Auch auf IPv6-HTTP-Anfragen lauschen
• server_name - Für welche Domains dies gilt
• return 301 - Eine permanente Weiterleitung senden (Statuscode 301)
• $host - Die Domain, die der Benutzer eingegeben hat (behält www vs. nicht-www bei)
• $request_uri - Der angeforderte Pfad (z. B. /about oder /contact)

Beispiel in Aktion:

Wenn jemand besucht: http://www.shadynagy.com/how-i-fixed-ssl-certificate-issues-on-my-website-a-complete-guide
Wird weitergeleitet zu: https://www.shadynagy.com/how-i-fixed-ssl-certificate-issues-on-my-website-a-complete-guide

Schritt 2: Anwenden und Testen

Konfiguration testen:

nginx -t

Nginx neu laden:

systemctl reload nginx

Weiterleitung testen:

curl -I http://shadynagy.com

Erwartete Ausgabe:

HTTP/1.1 301 Moved Permanently
Location: https://shadynagy.com/

Perfekt! Aber warten Sie mal…

Die Wendung: Die Firewall blockierte Port 80!

Als ich in meinem Browser testete, funktionierte es immer noch nicht! Nach einigen Untersuchungen:

firewall-cmd --list-all

Ausgabe:

services: https

Fällt Ihnen auf, was fehlt? HTTP (Port 80)!

Die Weiterleitung war perfekt konfiguriert, aber meine Firewall blockierte eingehenden HTTP-Traffic. Es ist, als würde man eine Haustür einbauen, aber eine Mauer davor errichten!

Schritt 3: Öffnen der Firewall

HTTP-Dienst hinzufügen:

firewall-cmd --permanent --add-service=http

Firewall neu laden:

firewall-cmd --reload

Überprüfen, ob es funktioniert hat:

firewall-cmd --list-all

Jetzt sollten Sie sehen:

services: http https

✅ Vorteile dieser Behebung

• ✅ Alle Besucher verwenden automatisch HTTPS
• ✅ Keine Probleme mit doppeltem Inhalt für SEO
• ✅ Bessere Sicherheit für Ihre Besucher
• ✅ Verbesserte Suchmaschinen-Rankings
• ✅ Grünes Vorhängeschloss in Browsern
• ✅ Schafft Vertrauen bei Besuchern

Vollständige Diagnosebefehle

Hier sind alle Befehle, die ich während der Fehlerbehebung verwendet habe:

Nginx-Konfiguration überprüfen

# Alle Serverblöcke finden, die auf Port 80 lauschen
grep -r "listen 80" /etc/nginx/

# Nginx-Konfigurationssyntax testen
nginx -t

# Vollständige Nginx-Konfiguration anzeigen
nginx -T

# Bestimmten Serverblock anzeigen
nginx -T 2>/dev/null | grep -A 15 "server_name shadynagy.com"

Nginx-Status überprüfen

# Läuft nginx?
systemctl status nginx

# Nginx neu laden (Änderungen ohne Ausfallzeit anwenden)
systemctl reload nginx

# Nginx neu starten (kurze Ausfallzeit)
systemctl restart nginx

# Fehlerprotokolle überprüfen
tail -20 /var/log/nginx/error.log

HTTP-zu-HTTPS-Weiterleitung testen

# Weiterleitung testen (umgeht Browser-Cache)
curl -I http://shadynagy.com

# Allen Weiterleitungen folgen
curl -IL http://shadynagy.com

Port-Status überprüfen

# Lauscht nginx auf Port 80?
ss -tlnp | grep :80

# Lauscht nginx auf Port 443?
ss -tlnp | grep :443

Firewall überprüfen

# Alle Firewall-Regeln auflisten
firewall-cmd --list-all

# HTTP permanent hinzufügen
firewall-cmd --permanent --add-service=http

# HTTPS permanent hinzufügen
firewall-cmd --permanent --add-service=https

# Änderungen anwenden
firewall-cmd --reload

Endgültige Konfigurationsdateien

HTTP-Konfiguration (Port 80)

Datei: /etc/nginx/conf.d/shadynagy.com.conf

server {
    listen 80;
    listen [::]:80;
    server_name shadynagy.com www.shadynagy.com;
    
    return 301 https://$host$request_uri;
}

HTTPS-Konfiguration (Port 443)

Datei: /etc/nginx/conf.d/shadynagy.com-ssl.conf

server {
    listen 443 ssl http2;
    
    ssl_certificate /etc/nginx/ssl/shadynagy.com-fullchain.crt;
    ssl_certificate_key /etc/nginx/ssl/shadynagy.com.key;
    ssl_trusted_certificate /etc/nginx/ssl/shadynagy.com.ca-bundle;
    
    root /var/www/shady-nagy.com/html;
    index index.html index.htm index.nginx-debian.html;
    server_name shadynagy.com www.shadynagy.com;
    
    access_log /var/log/nginx/nginx.vhost.access.log;
    error_log /var/log/nginx/nginx.vhost.error.log;
    
    location / {
        add_header Cache-Control "no-cache, no-store, must-revalidate";
        add_header Pragma "no-cache";
        add_header Expires 0;
        try_files $uri $uri/ =404;
    }
}

Die Ergebnisse: Alles behoben! ✅

Nach Implementierung aller Korrekturen zeigte mein SSL-Test auf WhyNoPadlock.com:

✅ SSL Connection - Bestanden
✅ Valid Certificate - SSL-Zertifikat ist korrekt installiert
✅ Force HTTPS - Webserver erzwingt die Verwendung von SSL
✅ Domain Matching - Zertifikat stimmt mit Domainnamen überein
✅ Signature - Verwendet sha256WithRSAEncryption
✅ Expiration Date - Zertifikat ist aktuell (läuft ab am 2026-11-03)
✅ Mixed Content - Kein gemischter Inhalt

Perfekte Punktzahl!

Fragen und Antworten

F1: Warum benötige ich ein Zwischenzertifikat?

A: Das Zwischenzertifikat erstellt eine Vertrauenskette von Ihrer Website zu einer vertrauenswürdigen Root-Autorität. Ohne es:

• Können Browser nicht überprüfen, ob Ihr Zertifikat legitim ist
• Sehen Besucher beängstigende Sicherheitswarnungen
• Können mobile Geräte häufig keine Verbindung herstellen
• Wirkt Ihre Website unprofessionell und unsicher

Stellen Sie es sich so vor: Wenn sich jemand als “John, Freund von Sarah” vorstellt, vertrauen Sie ihm vielleicht nicht. Aber wenn Sarah Ihre beste Freundin ist und sie für John bürgt, vertrauen Sie ihm. Das Zwischenzertifikat ist Sarah, die für das Zertifikat Ihrer Website bürgt.

F2: Was ist der Unterschied zwischen ssl_certificate und ssl_trusted_certificate in nginx?

A: Großartige Frage!

• ssl_certificate: Dies sendet nginx an Browser, um die Identität Ihrer Website zu beweisen. Es sollte Ihr Zertifikat UND das Zwischenzertifikat (Fullchain) enthalten.

• ssl_trusted_certificate: Dies wird für OCSP-Stapling verwendet, eine Performance-Funktion. Nginx verwendet dies, um den Zertifikatssperrstatus im Namen von Clients zu überprüfen. Es wird nicht an Browser gesendet.

Analogie:

• ssl_certificate = Ihr Ausweis, den Sie Leuten zeigen
• ssl_trusted_certificate = Ihre persönliche Kopie der Regeln, auf die Sie für sich selbst Bezug nehmen

F3: Warum $host statt $server_name in Weiterleitungen verwenden?

A:

• $host: Die exakte Domain, die der Benutzer in seinem Browser eingegeben hat (z. B. www.shadynagy.com oder shadynagy.com)
• $server_name: Der erste server_name in Ihrer Konfiguration

Beispielszenario:

• Ihre Konfiguration hat: server_name shadynagy.com www.shadynagy.com;
• Benutzer besucht: http://www.shadynagy.com

Mit $server_name: Leitet zu https://shadynagy.com weiter (entfernt das www)
Mit $host: Leitet zu https://www.shadynagy.com weiter (behält das www bei)

Die Verwendung von $host respektiert, was der Benutzer eingegeben hat, und verhindert unnötige zusätzliche Weiterleitungen.

F4: Warum funktionierte die Weiterleitung mit curl, aber nicht in meinem Browser?

A: Dies ist normalerweise eines von drei Problemen:

1. Firewall blockiert Port 80 (mein Problem!) - Die Weiterleitungskonfiguration war korrekt, aber eingehender HTTP-Traffic erreichte nginx nie.

2. Browser-Cache - Browser cachen Weiterleitungen aggressiv. Lösung: Im Inkognito-Modus testen oder Cache leeren.

3. DNS-Cache - Ihr Computer hat möglicherweise alte DNS-Einträge. Lösung: DNS-Cache leeren oder einige Stunden warten.

Profi-Tipp: Testen Sie immer zuerst mit curl -I, da es alle Caches umgeht!

F5: Sollte ich return oder rewrite für HTTPS-Weiterleitungen verwenden?

A: Verwenden Sie immer return für Weiterleitungen!

return (empfohlen):

return 301 https://$host$request_uri;

• Schneller (nginx stoppt die Verarbeitung sofort)
• Klarere Absicht
• Weniger fehleranfällig

rewrite (für einfache Weiterleitungen vermeiden):

rewrite ^ https://$host$request_uri permanent;

• Langsamer (verwendet Regex-Engine)
• Komplexer
• Leicht, Endlosschleifen zu erstellen

Faustregel: Verwenden Sie return für Weiterleitungen, verwenden Sie rewrite nur, wenn Sie die URL-Struktur ändern müssen.

F6: Was ist der Unterschied zwischen reload und restart für nginx?

A:

systemctl reload nginx (empfohlen):

• Wendet Konfigurationsänderungen sanft an
• Hält bestehende Verbindungen aufrecht
• Keine Ausfallzeit
• Testet Konfiguration vor der Anwendung (lädt nicht neu, wenn Konfiguration fehlerhaft ist)

systemctl restart nginx (sparsam verwenden):

• Stoppt nginx vollständig und startet es dann neu
• Beendet alle aktiven Verbindungen
• Kurze Ausfallzeit (normalerweise Millisekunden bis Sekunden)
• Nützlich, wenn reload nicht funktioniert

Wann restart statt reload:

• Beim Hinzufügen neuer Module
• Wenn reload Änderungen nicht übernimmt
• Beim Debuggen seltsamer Probleme

F7: Woher weiß ich, ob meine Firewall den Traffic blockiert?

A: Führen Sie diese Diagnosebefehle aus:

# Überprüfen, ob nginx auf Port 80 lauscht
ss -tlnp | grep :80
# Wenn Sie nginx hier sehen, lauscht es

# Firewall-Regeln überprüfen
firewall-cmd --list-all
# Suchen Sie nach 'http' in der Dienstliste

# Von außerhalb Ihres Servers testen
curl -I http://your-domain.com
# Wenn es zeitüberschreitet, blockiert möglicherweise die Firewall

Wenn nginx lauscht, ABER curl von außen zeitüberschreitet → Firewall ist das Problem!

F8: Mein SSL-Test zeigt “Mixed Content”-Warnungen. Was bedeutet das?

A: Gemischter Inhalt tritt auf, wenn Ihre HTTPS-Seite Ressourcen (Bilder, Skripte, CSS) über HTTP lädt.

Beispielproblem:

<!-- ❌ SCHLECHT - Bild über HTTP auf HTTPS-Seite laden -->
<img src="http://shadynagy.com/image.jpg">

Lösungen:

<!-- ✅ GUT - HTTPS verwenden -->
<img src="https://shadynagy.com/image.jpg">

<!-- ✅ GUT - Protokoll-relative URL verwenden -->
<img src="//shadynagy.com/image.jpg">

<!-- ✅ AM BESTEN - Relative URL verwenden -->
<img src="/image.jpg">

Auf gemischten Inhalt prüfen:

1. Öffnen Sie Ihre Website in Chrome
2. Drücken Sie F12 (Entwicklertools)
3. Suchen Sie nach Warnungen im Konsolen-Tab

F9: Muss ich dies jedes Mal tun, wenn ich mein SSL-Zertifikat erneuere?

A: Teilweise, ja.

Was Sie erneut tun müssen:

• Ein neues Fullchain-Zertifikat erstellen (neues Zertifikat + Zwischenzertifikat kombinieren)
• Die alte Fullchain-Datei ersetzen

Was Sie NICHT erneut tun müssen:

• Nginx-Konfigurationsdateien ändern (sie verweisen auf dieselben Pfade)
• Firewall-Regeln ändern
• Weiterleitungen einrichten

Profi-Tipp: Automatisieren Sie die Zertifikatserneuerung mit Let’s Encrypt/Certbot, das die Fullchain automatisch handhabt!

F10: Kann ich meine SSL-Konfiguration testen, bevor ich sie live schalte?

A: Absolut! So geht’s:

1. Nginx-Konfigurationssyntax testen:

nginx -t

2. Lokal mit curl testen:

# Weiterleitung testen
curl -I http://localhost

# HTTPS testen (kann Zertifikatswarnung beim lokalen Testen erhalten)
curl -Ik https://localhost

3. Online-Tools verwenden:

• SSL Labs - Umfassender SSL-Test
• WhyNoPadlock - Schnelle SSL-Überprüfung
• SSL Shopper - Zertifikatsketten-Prüfer

4. In Staging-Umgebung testen: Wenn möglich, richten Sie eine Test-Subdomain ein (wie staging.shadynagy.com) und testen Sie dort zuerst.

F11: Was ist HTTP/2 und warum haben Sie es hinzugefügt?

A: HTTP/2 ist eine neuere, schnellere Version des HTTP-Protokolls.

Vorteile:

• ✅ Multiplexing: Mehrere Dateien werden gleichzeitig über eine Verbindung heruntergeladen
• ✅ Header-Komprimierung: Kleinere Anfragen/Antworten
• ✅ Server-Push: Server kann Dateien senden, bevor der Browser fragt
• ✅ Bessere Mobile-Performance

Wie aktivieren:

listen 443 ssl http2;  # Fügen Sie einfach 'http2' hier hinzu!

Anforderungen:

• HTTPS muss aktiviert sein (HTTP/2 erfordert SSL)
• Nginx 1.9.5 oder höher
• OpenSSL 1.0.2 oder höher

Überprüfung:

curl -I --http2 https://shadynagy.com
# Suchen Sie nach "HTTP/2 200" in der Antwort

F12: Was passiert, wenn ich vergesse, meine Firewall-Regeln permanent zu machen?

A: Wenn Sie --permanent nicht verwenden, verschwinden Ihre Firewall-Regeln beim Neustart des Servers!

Nicht permanent (geht beim Neustart verloren):

firewall-cmd --add-service=http  # ❌ Nach Neustart weg

Permanent (überlebt Neustart):

firewall-cmd --permanent --add-service=http  # ✅ Bleibt nach Neustart
firewall-cmd --reload  # Sofort anwenden

Überprüfen, ob eine Regel permanent ist:

# Laufzeit-(aktuelle) Regeln anzeigen
firewall-cmd --list-all

# Permanente (gespeicherte) Regeln anzeigen
firewall-cmd --permanent --list-all

Wenn sie nicht übereinstimmen, müssen Sie Ihre Änderungen permanent machen!

F13: Wie oft sollte ich mein SSL-Zertifikat überprüfen?

A: Hier ist ein guter Wartungsplan:

Monatlich:

• Ablaufdatum des Zertifikats überprüfen
• Schnellen SSL-Test auf WhyNoPadlock.com durchführen

Vor Ablauf:

• Zertifikat 30 Tage vor Ablauf erneuern
• Neues Zertifikat sofort testen
• Wenn möglich automatische Erneuerung einrichten

Nach Server-Updates:

• SSL nach nginx/OpenSSL-Updates testen
• Überprüfen, ob Weiterleitungen noch funktionieren

Überwachung einrichten: Viele Dienste bieten kostenloses SSL-Monitoring:

• UptimeRobot
• Pingdom
• SSL Labs Monitoring

Sie mailen Ihnen, bevor Ihr Zertifikat abläuft!

F14: Was ist, wenn ich mehrere Domains auf einem Server habe?

A: Sie benötigen einen separaten Serverblock für jede Domain.

Beispiel für mehrere Domains:

# Domain 1: shadynagy.com
server {
    listen 80;
    server_name shadynagy.com www.shadynagy.com;
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl http2;
    server_name shadynagy.com www.shadynagy.com;
    ssl_certificate /etc/nginx/ssl/shadynagy.com-fullchain.crt;
    ssl_certificate_key /etc/nginx/ssl/shadynagy.com.key;
    root /var/www/shadynagy.com;
}

# Domain 2: myotherdomain.com
server {
    listen 80;
    server_name myotherdomain.com www.myotherdomain.com;
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl http2;
    server_name myotherdomain.com www.myotherdomain.com;
    ssl_certificate /etc/nginx/ssl/myotherdomain.com-fullchain.crt;
    ssl_certificate_key /etc/nginx/ssl/myotherdomain.com.key;
    root /var/www/myotherdomain.com;
}

Alternative: Verwenden Sie ein Wildcard-Zertifikat oder Multi-Domain-Zertifikat (SAN), um mehrere Domains mit einem Zertifikat abzudecken.

F15: Warum wird mein Zertifikat auch nach all diesen Korrekturen als “nicht sicher” angezeigt?

A: Überprüfen Sie diese häufigen Probleme:

1. Zertifikatsname stimmt nicht überein:

   • Zertifikat ist für www.shadynagy.com, aber Sie besuchen shadynagy.com
   • Lösung: Holen Sie sich ein Zertifikat, das beide abdeckt (SAN-Zertifikat)

2. Abgelaufenes Zertifikat:

   • Ablaufdatum überprüfen: openssl x509 -in certificate.crt -noout -dates
   • Lösung: Zertifikat erneuern

3. Gemischter Inhalt:

   • HTTPS-Seite lädt HTTP-Ressourcen
   • Browser-Konsole auf Warnungen überprüfen

4. Falsche Domain in nginx-Konfiguration:

   • server_name stimmt nicht mit der Domain überein, die Sie besuchen
   • Lösung: Alle Domain-Varianten zu server_name hinzufügen

5. Zertifikat nicht vertrauenswürdig:

   • Verwendet selbstsigniertes Zertifikat
   • Lösung: Zertifikat von vertrauenswürdiger CA holen (Let’s Encrypt ist kostenlos!)

Schnelldiagnose:

# Überprüfen, welches Zertifikat bereitgestellt wird
openssl s_client -connect shadynagy.com:443 -servername shadynagy.com

Nützliche Online-SSL-Test-Tools

🔗 SSL Labs - Umfassendster SSL-Test, gibt Ihnen eine A-F-Bewertung

🔗 WhyNoPadlock - Schnelle visuelle Überprüfung auf häufige SSL-Probleme

🔗 SSL Shopper - Überprüft Zertifikatsinstallation und -kette

🔗 Security Headers - Testet HTTP-Sicherheitsheader

🔗 High-Tech Bridge - Detaillierte SSL/TLS- und Sicherheitsbewertung

Wichtigste Erkenntnisse

Für Zwischenzertifikate:

✅ Immer ein Fullchain-Zertifikat erstellen (Zertifikat + CA-Bundle)
✅ ssl_certificate-Direktive für die Fullchain verwenden
✅ ssl_trusted_certificate nur für OCSP-Stapling verwenden
✅ Mit Online-Tools nach Installation testen

Für HTTPS-Weiterleitungen:

✅ return 301 für Weiterleitungen verwenden (nicht rewrite)
✅ Weiterleitung VOR location-Blöcken platzieren
✅ $host verwenden, um Domänen-Eingabe des Benutzers beizubehalten
✅ Daran denken, Port 80 in der Firewall zu öffnen!

Für Tests:

✅ Nginx-Konfiguration immer mit nginx -t vor dem Neuladen testen
✅ curl verwenden, um Browser-Cache zu umgehen
✅ Firewall-Regeln mit firewall-cmd --list-all überprüfen
✅ Port-Lauschen mit ss -tlnp überprüfen

Für Wartung:

✅ Ablaufbenachrichtigungen für Zertifikate einrichten
✅ Firewall-Regeln permanent machen
✅ Nginx und OpenSSL aktuell halten
✅ SSL-Konfiguration regelmäßig testen

Abschließende Gedanken

Die SSL-Konfiguration mag zunächst entmutigend erscheinen, aber sobald Sie die Komponenten verstehen, ist sie ziemlich logisch:

1. Zertifikatskette - Identität nachweisen
2. HTTPS-Weiterleitung - Sichere Verbindungen erzwingen
3. Firewall-Regeln - Traffic erlauben, Ihren Server zu erreichen

Die Aufschlüsselung des Problems in diese Komponenten machte es viel einfacher zu diagnostizieren und zu beheben.

Die wichtigste Lektion? Wenn etwas nicht funktioniert, Schicht für Schicht überprüfen:

• Ist nginx korrekt konfiguriert? (nginx -t)
• Lauscht nginx? (ss -tlnp)
• Erlaubt die Firewall Traffic? (firewall-cmd --list-all)
• Funktioniert es lokal? (curl -I http://localhost)

Dieser systematische Ansatz ersparte mir stundenlange Frustration!

Feedback und Fragen

Wir würden uns über Ihr Feedback zu diesem Tutorial freuen! Wenn Sie Fragen oder Verbesserungsvorschläge haben, zögern Sie bitte nicht, uns zu kontaktieren. Sie können unten einen Kommentar hinterlassen oder uns über die folgenden Kanäle kontaktieren:

1. E-Mail: info@shadynagy.com
2. Twitter: @ShadyNagy_
3. LinkedIn: Shady Nagy
4. GitHub: ShadyNagy

War dies hilfreich? Teilen Sie es mit jemandem, der mit SSL-Konfiguration kämpft!