Fähigkeit

SSL/TLS-Beschleunigung

TLS-Terminierung über das Hochladen von Zertifikaten hinausbewegen — in eine Per-Service-Sicherheits-, Leistungs- und Post-Quantum-Bereitschaftsschicht verwandeln.

TR7 ADC SSL/TLS-Beschleunigung verwaltet TLS nicht nur als verschlüsselte Verbindungsbeendigung, sondern als zentrale Sicherheitsrichtlinie der Anwendungsbereitstellung. Minimale und maximale TLS-Version, Cipher-Template, manuelle Cipher-Liste, ALPN-Verhalten, TLS-Ticket-Richtlinie, SNI-Zertifikatsauswahl und Backend-Neuverschlüsselung werden alle innerhalb desselben Service-Profilmodells definiert. Mehrere Zertifikate können auf einem einzigen Listener bereitgestellt werden. Das richtige Zertifikat wird automatisch basierend auf SNI ausgewählt; ECDSA- und RSA-Zertifikate für dieselbe Domain können koexistieren, sodass sowohl moderne als auch Legacy-Clients über denselben Service-Eintrag bedient werden. TR7s moderner TLS-Stack bereitet sich auf Traffic der nächsten Generation mit TLS 1.3, HTTP/2, HTTP/3 over QUIC, einem 0-RTT-fähigen Verbindungsmodell und Post-Quantum-Hybrid-Schlüsselaustausch-Unterstützung vor. ML-KEM-basierter Hybrid-Schlüsselaustausch bietet heute eine Verteidigungsbasislinie für Organisationen, die auf langlebige Datenvertraulichkeit gegen „Harvest now, decrypt later“-Angriffe abzielen. Das Ergebnis: TR7 ADC vereint Zertifikatsoperationen, Per-Service-TLS-Profile, Backend-mTLS, SNI-basierte Multi-Zertifikatsauswahl und moderne Kryptografie-Bereitschaft in einer einzigen Steuerungsebene.

Cipher-Templates: onlySecure, tls13, old, general, strictSecure, strictOld, strictHardware, hardware und manueller Modus

TLS 1.0→1.3

Per-Service-Versionsrichtlinie in einem einzigen Konfigurationsmodell — verschiedene Profile auf demselben ADC

5.000

Maximale gleichzeitige TLS-Verbindungen mit 2.000 Handshakes pro Sekunde Referenzkapazität

TLS-Verwaltung ist nicht nur das Laden von Zertifikaten — es ist Per-Service-Sicherheit, Compliance und Zukunftsbereitschaft.

In vielen Umgebungen wird TLS-Terminierung immer noch als das Verwalten einer Zertifikatsdatei, eines privaten Schlüssels und einer Cipher-Liste behandelt. Moderne Anwendungsbereitstellung erfordert jedoch, TLS gemeinsam mit SNI, ALPN, TLS 1.3, HTTP/2, HTTP/3, Legacy-Client-Kompatibilität, Session-Ticket-Richtlinie, mTLS, Zertifikatserneuerung und detaillierter Log-Sichtbarkeit zu denken. Wenn diese Teile isoliert verwaltet werden, leiden sowohl die Sicherheitslage als auch die operative Komplexität.

In Unternehmensumgebungen laufen Legacy-Systeme und moderne Anwendungen Seite an Seite auf demselben ADC. Ein Dienst erfordert möglicherweise TLS 1.0- oder 1.1-Kompatibilität, während ein anderer TLS 1.3, HTTP/2 oder HTTP/3-Verhalten fordert. Wenn diese Anforderungen an eine einzige geräteweite Einstellung gebunden sind, brechen entweder Legacy-Dienste oder die Sicherheitsstufe moderner Dienste wird unnötigerweise gesenkt.

Zertifikatsoperationen sind ebenfalls ein wiederkehrendes Risikogebiet. Wenn das Team, das das Zertifikat besitzt, und das Team, das den ADC verwaltet, verschieden sind, wird jede Erneuerung zu einer Änderungsanfrage und jeder Kettenfelher zu einem potenziellen Ausfall. Wenn PFX, PEM, Passphrases, Schlüsseltypen, CNs, DNS-Namen und Gültigkeitsdaten nicht zentral validiert werden, wird der Erneuerungsprozess fragil.

Langfristige Vertraulichkeit ist die neue Risikoschicht. Traffic, der heute verschlüsselt erscheint, kann aufgezeichnet und später mit größerer Entschlüsselungskapazität angegriffen werden. Deshalb muss eine moderne TLS-Schicht nicht nur die heutige Cipher-Kompatibilität, sondern auch zukunftsorientierte Verteidigungsoptionen wie Post-Quantum-Hybrid-Schlüsselaustausch im Service-Profil tragen.

TR7 SSL/TLS-Beschleunigung erfüllt diesen Bedarf: Sie bewegt TLS über dateibasierte Konfiguration hinaus und verwandelt es in ein Per-Service-Sicherheitsprofil, einen Zertifikatslebenszyklus und eine moderne Kryptografie-Bereitschaftsschicht.

Unser Ansatz

TR7 verwaltet TLS-Terminierung gemeinsam mit einem Zertifikatspool, Service-Profilen, SNI-Auswahl und deterministischer Konfigurationsgenerierung.

TLS-Profil ist Teil der Service-Sicherheitsrichtlinie

TLS-Minimal- und -Maximalversion, Cipher-Template, manuelle Cipher-Liste und TLS-Ticket-Richtlinie werden alle innerhalb desselben Service-Profils definiert. Unterschiedliche TLS-Richtlinien können unabhängig auf Frontend- und Backend-Seite angewendet werden.

SNI-basiertes Multi-Zertifikat funktioniert auf einem einzigen Listener

Mehrere Zertifikate können auf demselben Service-Eintrag platziert werden. Das richtige Zertifikat wird basierend auf dem SNI-Wert ausgewählt; Wildcard-, Multi-Domain- und Dual-ECDSA/RSA-Szenarien können alle auf demselben Port verwaltet werden.

Zertifikatslebenszyklus wird in der ADC-Steuerungsebene verwaltet

CSR-Erstellung, Zertifikats-Parsing, Schlüsseltyp-Erkennung, Passphrase-Operationen und PFX↔PEM-Konvertierung werden alle innerhalb von TR7 gehandhabt. Gültigkeitsdaten, CN, DNS-Namen, Algorithmus und Schlüssellänge werden als Metadaten am Zertifikatsobjekt verfolgt.

Der moderne TLS-Stack unterstützt Post-Quantum-Bereitschaft

TR7 behandelt moderne TLS-Fähigkeiten — TLS 1.3, HTTP/3 over QUIC und ML-KEM-basierter Hybrid-Schlüsselaustausch — gemeinsam mit Service-Richtlinie. Diese Architektur hilft, sowohl aktuelle Leistungserwartungen als auch langfristige Vertraulichkeitsrisiken in derselben Schicht zu verwalten.

Fähigkeiten

SSL/TLS-Beschleunigung kombiniert Per-Service-TLS-Sicherheit mit Zertifikatsoperationen, Backend-Verschlüsselung und moderner Protokollunterstützung.

Per-Service-Versionsrichtlinie umfasst TLS 1.0 bis TLS 1.3

TR7 verwaltet minimale und maximale TLS-Version innerhalb des Service-Profils. Breitere Kompatibilität kann auf Legacy-Dienste angewendet werden, während strengere TLS 1.2+- oder TLS 1.3-Richtlinien bei modernen API- und Web-Diensten durchgesetzt werden — alles auf separaten Service-Einträgen. Keine geräteweite „alles alt oder alles neu“-Einschränkung wird auferlegt. Jeder Dienst wird entsprechend seinen eigenen Risiko-, Compliance- und Client-Anforderungen konfiguriert.

SNI-basiertes Multi-Zertifikat funktioniert auf einer einzigen Listener-Adresse

Mehrere Zertifikate können auf demselben Port und Dienst definiert werden. Das richtige Zertifikat wird basierend auf dem vom Client gesendeten SNI-Wert ausgewählt. Verschiedene Domains, Wildcard-Zertifikate oder ECDSA- und RSA-Zertifikate für dieselbe Domain können koexistieren. Dieses Design vereinfacht Multi-Domain-Publishing, ohne separate VIPs oder separate Ports zu erfordern.

HTTP/2- und HTTP/3-Unterstützung beschleunigt modernen Client-Traffic

TR7 kann HTTP/2- und HTTP/1.1-Verhalten via ALPN innerhalb des Service-Profils verwalten. HTTP/3 over QUIC reduziert die Verbindungsaufbaulatenz und Head-of-Line-Blocking-Effekte, insbesondere in mobilen und verlustbehafteten Netzwerken. HTTP/2-Fallback erhält die Abwärtskompatibilität. Der Dienst kann verschiedene Generationen von Clients innerhalb desselben Publishing-Modells bedienen.

8 Cipher-Templates und manueller Modus balancieren Kompatibilität mit Sicherheit

TR7 unterstützt die Templates onlySecure, tls13, old, general, strictSecure, strictOld, strictHardware und hardware sowie die manuelle Cipher-Listen-Definition. Sicherheitsteams können Standard-Compliance-Profile wählen; Operations-Teams können in Ausnahmefällen spezifisches Cipher-Verhalten manuell anpassen. Dieses Modell bewegt das Cipher-Management von langen und fragilen Textlisten zur Profilauswahl. Wenn manueller Modus benötigt wird, behält der Operator volle Kontrolle. Fünf der acht Vorlagen basieren auf ephemerem Schlüsselaustausch, sodass Perfect Forward Secrecy (PFS) die Voreinstellung ist und keine Option: strictSecure löst zu ECDHE+AESGCM, ECDHE+CHACHA20, DHE+AESGCM und DHE+CHACHA20 auf. Die beiden Hardware-Vorlagen sind nicht austauschbar — strictHardware ist die moderne (ECDHE+AESGCM und DHE+AESGCM: Elliptische-Kurven- (ECC-)-Schlüsselaustausch mit AES-GCM auf dem AES-NI-Pfad, Forward Secrecy bleibt erhalten), während hardware AES-CBC-Suiten beibehält, damit ältere Clients weiterhin auf dem beschleunigten Pfad verhandeln können, und deshalb keine Forward Secrecy bietet. Die Kurvenauswahl umfasst zwölf benannte Kurven — X25519, X448, die brainpool-Familie und secp192r1 bis secp521r1 — pro Profil und pro Backend konfigurierbar.

Post-Quantum-Hybrid-Schlüsselaustausch reduziert langfristiges Vertraulichkeitsrisiko

TR7 bietet Post-Quantum-Bereitschaft durch ML-KEM-basierten Hybrid-Schlüsselaustausch-Unterstützung. Dieser Ansatz kombiniert klassischen Schlüsselaustausch mit einem Post-Quantum-KEM und bietet ein Übergangsmodell zwischen Client-Kompatibilität und langfristiger Vertraulichkeit. Sensibler Unternehmens-Traffic kann heute gegen das „Harvest now, decrypt later“-Risiko auf eine stärkere kryptografische Grundlage gebracht werden. Diese Bereitschaft ist besonders wichtig in Sektoren wie Finanzen, Behörden und Gesundheitswesen, wo Daten jahrelang vertraulich bleiben müssen.

Backend-Neuverschlüsselung und mTLS werden unterstützt

TR7 kann TLS zwischen Client und ADC terminieren, während die Verbindung zwischen ADC und Backend mit TLS neu verschlüsselt wird. Backend-mTLS-Einstellungen — verify required, CA-Datei und Client-Zertifikat — können an das Service-Profil gebunden werden. Dieses Modell erhält verschlüsselte Kommunikation im internen Netzwerk, während Inspektion am Edge ermöglicht wird. Unterschiedliche TLS-Versions- und Cipher-Richtlinien können unabhängig auf Frontend- und Backend-Seite angewendet werden.

TLS-Handshake-Daten werden zu einem Signal für Sicherheits- und Bot-Analyse

TLS-Protokollversion, ALPN-Status und Client-Handshake-Verhalten sind nicht nur Verbindungsdetails. Signale wie eine veraltete TLS-Version oder das Fehlen von ALPN können als zusätzliche Indikatoren in der Bot- und Risikoanalyse ausgewertet werden. Die TLS-Schicht produziert so Daten nicht nur über Verschlüsselung, sondern auch über Client-Qualität und Automatisierungsverhalten. Diese Signale bereichern Sicherheitsentscheidungen.

Zertifikats-Parsing- und -Konvertierungsoperationen erfolgen in der Steuerungsebene

TR7 kann DNS-Namen, CN, Aussteller, Gültigkeitsdaten, Algorithmus und Schlüssellänge aus Zertifikaten extrahieren. RSA- und EC-Schlüsseltypen werden unterschieden; das Hinzufügen oder Entfernen von Passphrases wird unterstützt. PFX/P12-Dateien können in PEM-Struktur geparst oder in umgekehrter Richtung verpackt werden. Diese Fähigkeiten beseitigen die Abhängigkeit von externen Tools für Zertifikatsoperationen.

Operative Tiefe

TLS-Operationen werden gemeinsam mit Zertifikats-Parsing, Schlüsselkonvertierung, PFX/PEM-Verarbeitung, Diff-basiertem Reload, Kurven-Kompatibilitätsprüfungen und Ablaufbenachrichtigungen verwaltet.

Zertifikats-Parse-Pipeline

Wenn ein Zertifikat geladen wird, werden DNS-Namen, CN, Aussteller, Gültigkeitsbeginn, Ablaufdatum, Algorithmus und Schlüssellänge extrahiert. Wenn eine Parse-Methode fehlschlägt, kann ein alternativer Parse-Pfad eingeschlagen werden. Zertifikats-Metadaten werden daher durch tatsächlichen Inhalt verwaltet, nicht nur durch Dateinamen.

Schlüsseltyp-Erkennung und -Konvertierung

Ob ein privater Schlüssel RSA oder EC ist, wird automatisch erkannt. EC- und RSA-Schlüsseloperationen werden entsprechend ihren jeweiligen Anforderungen gehandhabt. Passphrase-Hinzufügung, -Entfernung und Formatkompatibilität werden als Teil der Zertifikatsoperation verwaltet.

PFX- und PEM-Operationen

PFX/P12-Bundles können in ihre Schlüssel- und Zertifikatskomponenten geparst werden. Bei Bedarf können PEM-Inhalte zurück in das PFX-Format konvertiert werden. Dies macht es unkompliziert, die verschiedenen Zertifikatslieferungsformate verschiedener Organisationen zu standardisieren — alles innerhalb von TR7.

Diff-basierter Reload

Dieselbe Eingabe erzeugt immer dieselbe Konfiguration; ein Reload wird nur ausgelöst, wenn ein echter Unterschied erkannt wird. Unnötige Service-Unterbrechungen werden vermieden, wenn Zertifikate oder TLS-Profile geändert werden. Bestehende Verbindungen werden erhalten, während neue Verbindungen mit dem aktualisierten TLS-Verhalten bedient werden.

Kurven-Kompatibilitätsprüfung

Kurvennamen werden normalisiert, um Kompatibilitätsunterschiede zu reduzieren. Die Verwendung nicht unterstützter oder entfernter Kurven kann blockiert werden. Diese Prüfung hilft, das Zertifikat und TLS-Profil mit modernen Kryptografie-Erwartungen in Einklang zu halten.

Zertifikats-Ablaufbenachrichtigung

Das Zertifikats-Ablaufdatum wird als Metadaten verfolgt. Benachrichtigungen können so konfiguriert werden, dass sie standardmäßig 30 Tage vor dem Ablauf ausgelöst werden. Dies hilft, Service-Ausfälle durch unbemerkte Zertifikatsabläufe zu verhindern.

Wann zu verwenden

Striktes TLS-Profil und Zertifikatsverwaltung für E-Commerce

E-Commerce-Teams können TLS 1.2+-Richtlinie, ein sicheres Cipher-Template, geschlossenes Ticket-Verhalten und regelmäßige Zertifikatsverfolgung innerhalb eines einzigen Service-Profils anwenden. Welches TLS-Profil bei welchen Diensten verwendet wird, kann für Compliance-Audits zentral eingesehen werden.

Legacy-Banking und moderne Dienste Seite an Seite betreiben

In Banking-Umgebungen können ein Dienst, der Legacy-Clients erfordert, und eine Internet-Banking-Anwendung, die TLS 1.3 verwendet, auf demselben TR7 ADC mit verschiedenen Profilen veröffentlicht werden. Legacy-Kompatibilität senkt nicht die Sicherheitsstufe moderner Dienste.

Post-Quantum-Bereitschaft für Organisationen mit langfristiger Vertraulichkeitsanforderung

Finanz-, Behörden- und Gesundheitsorganisationen können sensiblen Traffic mit ML-KEM-Hybrid-Schlüsselaustausch auf eine stärkere kryptografische Grundlage gegen zukünftige Entschlüsselungsrisiken bringen. Dieses Szenario bietet kryptografische Bereitschaft heute für Daten, die jahrelang vertraulich bleiben müssen.

Backend-Neuverschlüsselung mit TLS

Sicherheitsteams können TLS zwischen Client und TR7 terminieren, während die Verbindung zwischen TR7 und dem Backend mit TLS neu verschlüsselt wird. mTLS und CA-Validierung bringen internen Netzwerk-Traffic ebenfalls unter die Sicherheitsrichtlinie.

Häufig gestellte Fragen

Können auf demselben ADC unterschiedliche TLS-Versionsrichtlinien für verschiedene Dienste angewendet werden?

Ja. In TR7 werden minimale und maximale TLS-Version innerhalb des Service-Profils definiert. Das bedeutet, ein Dienst kann TLS 1.0/1.1-Kompatibilität erfordern, während ein anderer nur TLS 1.3 akzeptiert — alles auf demselben Gerät. Anstatt in eine einzige geräteweite Richtlinie gezwungen zu werden, wird jeder Dienst entsprechend seinem eigenen Sicherheits- und Compliance-Profil verwaltet.

Wie funktioniert SNI-basiertes Multi-Zertifikat?

Mehrere Zertifikate können auf demselben Port und Service-Eintrag definiert werden. Das richtige Zertifikat wird automatisch basierend auf dem SNI-Wert ausgewählt, den der Client während des TLS-Handshakes sendet. ECDSA- und RSA-Zertifikate für dieselbe Domain können koexistieren, sodass moderne Clients ECDSA verwenden, während Legacy-Clients RSA erhalten. Wildcard- und Multi-Domain-Zertifikate funktionieren ebenfalls auf demselben Port.

Warum ist Post-Quantum-Hybrid-Schlüsselaustausch wichtig?

Traffic, der heute verschlüsselt ist, kann mit dem „Harvest now, decrypt later“-Ansatz aufgezeichnet und später entschlüsselt werden, wenn größere Rechenkapazität verfügbar ist. ML-KEM-basierter Hybrid-Schlüsselaustausch kombiniert klassische Kryptografie mit einem Post-Quantum-KEM und bringt Traffic, der jahrelang vertraulich bleiben muss, noch heute auf eine stärkere Grundlage. Diese Bereitschaft ist in Sektoren wie Finanzen, Behörden und Gesundheitswesen kritisch.

Kann die Backend-Verbindung ebenfalls mit TLS verschlüsselt werden?

Ja. TR7 kann TLS zwischen Client und ADC terminieren, während die Verbindung zwischen ADC und Backend mit TLS neu verschlüsselt wird. Backend-mTLS-Einstellungen — verify required, CA-Datei und Client-Zertifikat — können an das Service-Profil gebunden werden. Unterschiedliche TLS-Versions- und Cipher-Richtlinien können unabhängig auf Frontend- und Backend-Seite angewendet werden.

Wie wird das Zertifikats-Ablaufdatum verfolgt?

Wenn ein Zertifikat geladen wird, werden sein Gültigkeitsbeginn und Ablaufdatum als Metadaten innerhalb von TR7 aufgezeichnet. Benachrichtigungen können so konfiguriert werden, dass sie standardmäßig 30 Tage vor dem Ablauf ausgelöst werden. Dies verhindert Service-Ausfälle durch unbemerkte Zertifikatsabläufe.

Was tun Cipher-Templates und manueller Modus?

TR7 bietet 8 Cipher-Templates: onlySecure, tls13, old, general, strictSecure, strictOld, strictHardware und hardware. Sicherheitsteams können ein Template basierend auf ihren Compliance-Anforderungen wählen; Operations-Teams können in Ausnahmefällen eine manuelle Cipher-Liste definieren. Dieses Modell bewegt das Cipher-Management von langen und fragilen Textstrings zur profilbasierten Auswahl. Fünf der acht basieren auf ephemerem Schlüsselaustausch, sodass Perfect Forward Secrecy (PFS) die Voreinstellung ist: strictSecure bedeutet ECDHE+AESGCM und ECDHE+CHACHA20 samt ihren DHE-Entsprechungen. Beachten Sie den Unterschied der beiden Hardware-Vorlagen — strictHardware ist ECDHE+AESGCM auf dem AES-NI-Pfad mit Forward Secrecy, hardware behält AES-CBC-Suiten für ältere Clients und hat keine.

TLS in eine Per-Service-Sicherheitsrichtlinie verwandeln

Per-Service-TLS-Profile, SNI-basiertes Multi-Zertifikat, Post-Quantum-Hybrid-Schlüsselaustausch und Backend-mTLS. Lassen Sie uns ein Live-Setup in Ihrer eigenen Umgebung durchgehen.