So bekommt man eine A+ SSL-Bewertung (Checkliste 2026)
Aktualisiert 2026-11-03 · 7 Min. Lesezeit
Ein A+ ist keine andere Art von Zertifikat, sondern eine andere TLS-Konfiguration. Den meisten Sites, die bei A hängen, fehlt genau eine Einstellung: Sie terminieren TLS 1.2 korrekt, haben aber nie TLS 1.3 aktiviert oder nie einen ausreichend langen HSTS-Header gesendet.
Was die Bewertung wirklich entscheidet
CertH bewertet fünf gewichtete Bereiche aus einem reinen TLS-Handshake: Gültigkeit und Kette des Zertifikats, Schlüsselstärke und Signaturalgorithmus, angebotene Protokollversionen, ausgehandelte Cipher Suites sowie HSTS und OCSP-Stapling. Es gibt keinen Serverzugriff, keinen Agenten und keinen Upload von Konfigurationsdateien — alles wird von außen beobachtet, genau so, wie ein Browser es sieht.
Die Schwellen sind einfach. A+ verlangt mindestens 95 Punkte, TLS 1.3 in der ausgehandelten Protokollliste und HSTS, das entweder preloaded ist oder eine max-age von mindestens 180 Tagen hat. A beginnt bei 90, B bei 80, C bei 70, D bei 55, alles unter 55 ist ein F. Ein abgelaufenes Zertifikat ergibt automatisch 0.
Die vier Änderungen, die von A zu A+ führen
In der Praxis ist die Lücke fast immer eine dieser vier. Beheben Sie sie der Reihe nach — jede ist von außen unabhängig prüfbar, also können Sie nach jedem Schritt neu scannen.
- •TLS 1.3 aktivieren. Es bringt eigene Punkte und ist für A+ Pflicht, selbst bei perfekten 100 überall sonst.
- •HSTS auf mindestens max-age=15552000 (180 Tage) anheben. Ein Jahr (31536000) ist die übliche Wahl.
- •Eine vollständige Kette inklusive Zwischenzertifikaten ausliefern. Ein fehlendes Intermediate erscheint bei manchen Clients als Kettenfehler und kostet Punkte.
- •OCSP-Stapling aktivieren, damit die Sperrprüfung mit dem Handshake reist, statt die Besucher-IP an die CA zu verraten.
nginx-Konfiguration für A+
Ein vollständiger server-Block für ein modernes nginx (1.19+ mit OpenSSL 1.1.1+). Wurde nginx gegen ein älteres OpenSSL gebaut, ist TLS 1.3 stillschweigend nicht verfügbar — egal, was hier steht. Prüfen Sie zuerst mit nginx -V.
ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers off;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305;
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 1d;
ssl_session_tickets off;
ssl_stapling on;
ssl_stapling_verify on;
ssl_trusted_certificate /etc/letsencrypt/live/example.com/chain.pem;
resolver 1.1.1.1 8.8.8.8 valid=300s;
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;Apache-Konfiguration für A+
Apache braucht den Stapling-Cache einmal auf Server-Ebene, nicht innerhalb eines Virtual Hosts. Alles andere gehört in den Block <VirtualHost *:443>.
SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1
SSLCipherSuite ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384
SSLHonorCipherOrder off
SSLSessionTickets off
SSLUseStapling on
SSLStaplingCache "shmcb:logs/ssl_stapling(32768)"
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"Die Fehler, die Sites bei A halten
Der häufigste: HSTS mit includeSubDomains auf einer Domain aktivieren, die noch reine HTTP-Subdomains hat — die brechen sofort, und die übliche Reaktion ist, den Header komplett zu entfernen, was zurück auf A führt. Rollen Sie HSTS in Stufen aus: erst 300 Sekunden max-age, eine Woche auf Brüche achten, dann auf ein Jahr hochziehen.
Der zweithäufigste: annehmen, TLS 1.3 sei an, weil das Zertifikat modern ist. Zertifikate und Protokollversionen sind unabhängig. Ein brandneues Zertifikat auf einem Server, der nur TLS 1.2 spricht, bleibt unter 95.
Der dritte: ein CDN vor dem Origin. Wenn Cloudflare, Fastly oder ein Load Balancer TLS terminiert, ist die Origin-Konfiguration irrelevant — die Bewertung spiegelt den Edge wider, also muss dort geändert werden.
Selbst nachprüfen
Jede Änderung lässt sich im Terminal in Sekunden bestätigen. TLS 1.3 wird nur ausgehandelt, wenn der Server es wirklich anbietet, HSTS erscheint in den Response-Headern, und Stapling zeigt sich im OCSP-Response-Block.
# Does the server actually negotiate TLS 1.3?
openssl s_client -connect example.com:443 -tls1_3 -servername example.com </dev/null 2>/dev/null | grep "Protocol"
# Is HSTS set, and for how long?
curl -sI https://example.com | grep -i strict-transport-security
# Is OCSP stapling actually working?
openssl s_client -connect example.com:443 -status -servername example.com </dev/null 2>/dev/null | grep -A2 "OCSP Response"FAQ
Braucht ein A+ ein kostenpflichtiges oder Extended-Validation-Zertifikat?
Nein. Ein domain-validiertes (DV) Zertifikat kann A+ erreichen — die Bewertung misst die TLS-Konfiguration, nicht die Validierungsstufe. Der Zertifikatstyp zählt nur, wenn er Kette oder Schlüsselalgorithmus ändert.
Warum ist meine Bewertung nach einer Zertifikatserneuerung gefallen?
Erneuerungen bringen oft einen anderen Aussteller oder Schlüsseltyp, und manche Server fallen nach dem Reload auf ein anderes Cipher-Set zurück. CertH hält die Änderung im Abschnitt zur Score-Entwicklung des Domain-Reports fest, inklusive des konkreten Grundes.
Brauche ich HSTS-Preload für ein A+?
Nein. Preload ist eine von zwei Möglichkeiten, die HSTS-Anforderung zu erfüllen; eine max-age von mindestens 180 Tagen ohne Preload genügt. Preload ist strenger und viel schwerer rückgängig zu machen — behandeln Sie es als optional.