ForHosting KIT · Entwickler-Tools

Prüfen Sie, ob eine TLS-Version noch unterstützt wird

Geben Sie eine TLS-Version ein und sehen Sie sofort, ob sie noch gilt: TLS 1.3 und TLS 1.2 werden unterstützt, TLS 1.0 und TLS 1.1 gelten als veraltet, jeweils mit dem nächsten Schritt für Ihre Sicherheitsprüfung. Kostenlos in Ihrem Browser.

  • Kostenlos
  • Läuft in Ihrem Browser
  • Ohne Anmeldung
  • Ihre Daten bleiben auf Ihrem Gerät
Nutzen Sie es über WebAPIE-MailTelegramApp bald
Wenn Sie eingeben
Version
TLS 1.3
Erhalten Sie
Status
supported

Dieses Werkzeug stuft TLS 1.0, TLS 1.1, TLS 1.2 oder TLS 1.3 anhand einer klaren, festen Auslegung gängiger Branchenleitlinien ein. Es meldet, ob die angegebene Version veraltet ist, nennt den Unterstützungsstatus und empfiehlt kurz den nächsten Schritt. Unbekannte Versionsangaben führen zu einem eindeutigen Fehler. Dadurch eignet sich das Werkzeug für wiederholbare Prüfungen, Skripte, Checklisten und Dokumentationen.

Verstehen Sie die Bedeutung des Ergebnisses

Ein unterstütztes Ergebnis bedeutet, dass die Protokollversion nach den heute vorherrschenden Branchenleitlinien normalerweise nicht als veraltet gilt. Dieses Werkzeug stuft TLS 1.2 und TLS 1.3 als unterstützt, TLS 1.0 und TLS 1.1 dagegen als veraltet ein. Die Bewertung bezieht sich bewusst ausschließlich auf die Protokollversion.

Sie beweist weder eine sichere Konfiguration eines bestimmten Servers noch die Gültigkeit eines Zertifikats oder die Eignung aller aktivierten Cipher Suites. Auch ein Dienst mit TLS 1.2 kann schwache Einstellungen verwenden, und ein moderner Client kann weiterhin an Problemen mit Zertifikat, Hostname oder Vertrauenskette scheitern. Nutzen Sie den ausgegebenen Status deshalb als klar abgegrenzten Punkt einer umfassenderen Sicherheitsprüfung.

Die Antwort enthält boolesche Werte für veraltet und unterstützt, damit automatisierte Abläufe das Ergebnis ohne Textauslegung verarbeiten können, sowie eine verständliche Empfehlung für Berichte. Da die Zuordnung fest und deterministisch ist, erhält dieselbe erkannte Eingabe immer dieselbe Einstufung. Das vereinfacht Vergleiche und nachvollziehbare Auditnachweise.

Geben Sie eine TLS-Version ein und vereinheitlichen Sie sie

Geben Sie jeweils eine Version an. Die kanonischen Schreibweisen sind TLS 1.0, TLS 1.1, TLS 1.2 und TLS 1.3. Groß- und Kleinschreibung spielen keine Rolle, umgebende Leerzeichen werden ignoriert, und auch die gebräuchliche Form TLSv1.2 wird akzeptiert.

Die Ausgabe verwendet stets eine einheitliche Bezeichnung wie TLS 1.2. So lassen sich Werte aus Bestandslisten oder Konfigurationsnotizen zuverlässig normalisieren. Unvollständige oder unbekannte Angaben lehnt das Werkzeug bewusst ab, statt sie zu erraten.

SSL 3.0, TLS 2.0, Begriffe wie „neueste“ und unvollständige Zeichenfolgen werden nicht stillschweigend einem unterstützten Protokoll zugeordnet. Dieses strenge Verhalten ist für automatisierte Kontrollen wichtig: Ein Tippfehler sollte den Ablauf stoppen oder eine sichtbare Ausnahme erzeugen und nicht versehentlich eine Sicherheitsvorgabe bestehen. Wenn Sie eine Konfigurationsdatei auswerten, entnehmen Sie zunächst die tatsächliche Protokollversion aus der produktspezifischen Syntax und übermitteln Sie anschließend diesen Wert.

Sind mehrere Versionen aktiviert, prüfen Sie jede einzeln und behandeln Sie jede aktivierte veraltete Version als Anlass zur Konfigurationsprüfung.

Nutzen Sie die Einstufung in einer Sicherheitsprüfung

Verwenden Sie diese Prüfung, wenn ein Anlagenverzeichnis, Fragebogen, Bereitstellungsmanifest oder eine Lieferantenauskunft eine TLS-Version nennt und Sie eine einheitliche erste Einstufung benötigen. Veraltetes TLS 1.0 oder TLS 1.1 sollte normalerweise eine Migrationsaufgabe auslösen: Ermitteln Sie die Clients, die noch von der alten Version abhängen, aktivieren Sie TLS 1.2 oder TLS 1.3, testen Sie die Zusammenarbeit und entfernen Sie danach das Altprotokoll. Ein unterstütztes Ergebnis für TLS 1.2 oder TLS 1.3 beendet die Bewertung nicht.

Prüfen Sie außerdem Zertifikate, Vertrauensketten, Hostnamenvalidierung, Verschlüsselungs- und Signaturverfahren, Patchstände der Bibliotheken sowie die von relevanten Netzen tatsächlich ausgehandelten Versionen. Vertragliche, regulatorische, plattformspezifische oder interne Sicherheitsanforderungen können strenger als die allgemeinen Leitlinien sein. Verwenden Sie dann die strengste geltende Vorgabe als maßgebliche Instanz.

Die Browserausführung unterstützt schnelle manuelle Prüfungen, während sich die strukturierte Antwort gut in Compliance-Abläufe und wiederholbare Konfigurationskontrollen integrieren lässt.

Servervorgabe überprüfen

Stufen Sie jede in einer Server- oder Load-Balancer-Vorgabe genannte TLS-Version vor der Freigabe ein.

Lieferantenfragebögen vereinheitlichen

Überführen Sie unterschiedlich formatierte Antworten in eine einheitliche Bezeichnung und Statusangabe.

Veraltete Protokolle kennzeichnen

Erzeugen Sie eine Migrationsaufgabe, sobald ein Bestandseintrag TLS 1.0 oder TLS 1.1 meldet.

Welche TLS-Versionen werden erkannt?

Erkannt werden TLS 1.0, TLS 1.1, TLS 1.2 und TLS 1.3 einschließlich der Schreibweise TLSv ohne Beachtung der Groß- und Kleinschreibung.

Welche Versionen gelten als veraltet?

TLS 1.0 und TLS 1.1 werden als veraltet eingestuft. TLS 1.2 und TLS 1.3 gelten als unterstützt.

Bedeutet unterstützt, dass ein Server vollständig sicher ist?

Nein. Das Ergebnis betrifft nur die Protokollversion, nicht Zertifikate, Cipher Suites, Implementierungsupdates oder Servereinstellungen.

Was tun, wenn ein Server noch TLS 1.0 zulässt?

Planen Sie eine Umstellung. TLS 1.0 und TLS 1.1 sind veraltet: Ermitteln Sie, welche Clients noch darauf angewiesen sind, und bringen Sie diese auf TLS 1.2 oder TLS 1.3. Sind mehrere Versionen aktiv, prüfen Sie jede einzeln.

Warum werden SSL 3.0 oder TLS 2.0 abgelehnt?

Weil das Werkzeug nur TLS 1.0, 1.1, 1.2 und 1.3 kennt und nie rät. SSL 3.0, TLS 2.0, Wörter wie „latest“ oder unvollständige Angaben werden sichtbar abgelehnt, statt versehentlich als unterstützt durchzugehen.

Alles auf dieser Seite ist auch per API verfügbar. Dieser Abschnitt richtet sich an Teams, die es in ihre eigenen Systeme einbinden möchten; alle anderen nutzen einfach das Tool oben.

POSThttps://api.kit.forhosting.com/security/tls-version-support-check

Authentifizierung per Bearer-Token. Ein einziger POST stellt die Aufgabe in die Warteschlange; das Ergebnis erhalten Sie per Webhook oder über einen signierten Link.

curl -X POST https://api.kit.forhosting.com/security/tls-version-support-check \
  -H "Authorization: Bearer $KIT_KEY" \
  -H "Content-Type: application/json" \
  -d '{"version":"TLS 1.2"}'
{
  "version": "TLS 1.2"
}
{
  "task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
  "type": "security.tls_version_support_check",
  "status": "queued",
  "_links": {
    "result": "/tasks/tsk_…/result"
  }
}

Die API arbeitet asynchron: Sie erhalten sofort eine task_id. Polling ist mit 1 Anfrage pro Sekunde erlaubt.

pro Anfrage$0.002

Der Preis steht auf der Seite – keine Tokens, keine Credits. Fehlgeschlagene Aufgaben werden nicht berechnet.

HTTPCodeBedeutung
401unauthorizedDer API-Schlüssel fehlt oder ist ungültig – prüfen Sie den Authorization-Header (Bearer).
402insufficient_balanceIhr Guthaben reicht für diese Aufgabe nicht aus – Aufladungen verfallen nicht.
404unknown_typeUnbekannter Aufgabentyp – prüfen Sie das Feld „type“ gegen den Katalog.
429rate_limitedZu viele Anfragen – warten Sie kurz; Polling ist mit 1 Anfrage pro Sekunde erlaubt.

Nutzen Sie die Einstufung in einer Sicherheitsprüfung

Bei automatisierter Abfrage beträgt der API-Preis $0.002 pro Anfrage.

Was geschieht bei einer unbekannten Version?

Die Anfrage liefert einen invalid_input-Fehler mit den vier erkannten TLS-Versionen, statt eine Vermutung anzustellen.

Was kostet eine Prüfung über die API?

Jede API-Anfrage kostet $0.002. Die Fähigkeit führt pro Anfrage eine deterministische Versionseinstufung aus.

Vollständige KIT-Dokumentation lesen →