Die Technik ist im stetigen Wandel und es so müssen wir uns diesem Wandel und den daraus resultierenden Neuerungen auch anpassen. Zu einer dieser Neuerungen gehören Quantencomputer und ihr Einfluss auf die Kryptographie. Aktuell noch als sicher geltende Verschlüsselungsalgorithmen werden zukünftig, mittels Quantencomputer, nicht mehr sicher sein. Um diesem Trend entgegenzuwirken solltet ihr PQC aktivieren.
In diesem Beitrag gehe ich darauf ein, wie ihr PQC auf einem Apache Webserver aktiviert. Ich gehe davon aus, das ihr eueren Server bereits mittels SSL abgesichert habt und z.B. HSTS bereits aktiv ist. Seht dieses auch bitte nicht als 1zu1 Anleitung an, denn die Systeme sind unterschiedlich und meine Konfiguration passt eventuell nicht zu 100% zu eurer. Nutzt dieses also mehr als Wegweiser und Hinweis.
Sinn und Nutzen
Ist es überhaupt sinnvoll und nützlich sich jetzt bereits dazu Gedanken zu machen? Die Frage ist berechtigt und erst mal sieht es ja so aus, als ob Quantencomputer noch ein paar Jahre benötigen, bis sie überhaupt, für die Massen, einsatzfähig sind. Es gibt zwei Punkte die dabei zu beachten sind:
- Schutz vor dem Zusammenbruch der aktuellen Verschlüsselung
- Ein ausreichend starker Quantencomputer könnten unsere heutige Verschlüsselung in kurzer Zeit aushebeln, sobald er verfügbar ist. Den Zeitpunkt kann aktuell keiner nennen, daher sollte man vorbereitet sein. Ich sehe meinen Blog auch hier nicht als Ziel, aber es schadet auch nicht das Thema jetzt schon anzugehen,
- Schutz vor „Harvest now, decrypt later“
- Es hindert niemanden daran bereits heute verschlüsselte Datenströme aufzuzeichnen. Ziel ist es diese dann später in 5 bis 10 Jahren entschlüsseln zu können. Mit PQC könnt ihr dem jetzt bereits begegnen und eure Datenströme absichern. Ein normaler Blogger wie ich ist hier sicher kein Ziel, da der Aufwand (bzw. die Kosten) immer noch zu hoch und der Nutzen nahe 0 geht.
Ihr seht, es macht schon sinn sich mit dem Thema zu beschäftigen, wobei der normale Blogger sicher kein Ziel seien wird. Es kann aber nicht schaden sein Wissen aus dem privaten Umfeld und das berufliche zu überführen. Im sinne des Wissenszuwachses, lasst uns also weiter machen.
Selbst für die EU ist PQC ein Thema. Somit muss es also wirklich ernst sein 😉
Vorabcheck
Bevor ihr jetzt hektisch werdet, was nie gut ist, testen wir erst mal ob PQC nicht eventuell schon aktiv ist. Je nach Setup müsst ihr eventuell nichts mehr machen. Eine sehr gute Anlaufstelle für einen Test ist der SSL-Test von Qualys. Hier gebt ihr einfach euere URL an und euer Server wird, was SSL betrifft, durchgetestet. Am Ende erhaltet ihr ein Rating und eine Auflistung der Ergebnisse. Dort sollte nun stehen, das der Server PQC unterstützt. Wenn das nicht der Fall sein sollte, dann könnt ihr das ändern. Ansonsten ist das Thema für euch bereits erledigt und ihr könnt euch entspannt zurück lehnen.
Konfiguration für PQC anpassen
Eine Warnung vorab. Nicht jedes System ist gleich und ihr habt euere Server sicherlich anders aufgebaut als ich, also bitte immer ein Backup aller Dateien erstellen, die ihr ändert. Ein Fehlerhafter Eintrag und euer Apache startet nicht mehr.
Wie bereits erwähnt nutze ich einen Apache als Webserver und erzeuge meine Zertifikate mit Let’s Encrypt und binde die SSL Optionen für jeden VHost über seine Konfigurationsdatei ein. Um PQC nutzen zu können, muss OpenSSL ab der Version 3.5 installiert sein.
openssl -v
OpenSSL 3.5.6 7 Apr 2026 (Library: OpenSSL 3.5.6 7 Apr 2026)Ein guter Anhaltspunkt für eine valide Konfiguration ist https://configurator.tlsref.org. Hier könnt ihr angeben was für einen Webserver ihr nutzt und die Seite generiert eine Konfigurationsvorlage. Zusätzlich habt ihr die Möglichkeit auszuwählen ob ihr Modern, bzw. Restriktiv sein wollt, oder Intermediate, bzw. lockerer. Wenn ihr einen Server nur für euch nutzt, könnt ihr Modern auswählen, ansonsten lieber Intermediate. Die Option Modern kann also dazu führen, das ältere Geräte nicht mehr auf eure Webseite zugreifen können. Die Entscheidung liegt also bei euch. Intermediate unterstützt Chrome 49 (2016) oder Safari 9 (2015), wobei Modern Chrome 70 (2018) oder Safari 12.1 (2019) erfordert.
Da ich in meinem Setup weitere SSL Optionen über die options-ssl-apache.conf lade, muss ich auch nur dort die Modifikationen anbringen. Je nach Setup ändert ihr entweder die Konfiguration jedes VHosts oder legt die Einstellungen Global in einer Datei fest.
Include /etc/letsencrypt/options-ssl-apache.confIm folgenden findet ihr valide Einstellungen die PQC ermöglichen. die letzten SSL Parameter solltet ihr nach eueren Bedürfnissen anpassen. Nach erfolgten Einstellungen führt ihr einen reload oder restart des Apache Dienstes aus und testet mittels SSL-Test ob es geklappt hat. Sollte euer Apache nicht starten, solltet ihr die gemachten Änderungen überprüfen oder, dank Backup, rückgängig machen.
Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains; preload"
SSLProtocol -all +TLSv1.2 +TLSv1.3
SSLOpenSSLConfCmd Curves X25519MLKEM768:X25519:prime256v1:secp384r1
SSLCipherSuite 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
SSLCipherSuite TLSv1.3 TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256
SSLOptions +StrictRequire
SSLHonorCipherOrder on
SSLSessionTickets off
SSLCompression off
SSLStrictSNIVHostCheck on| Header | Die Einnstellung preload solltet ihr weglassen, außer ihr Meldet euere Seite bei https://hstspreload.org an |
| SSLHonorCipherOrder | Legt fest ob der Server oder der Client die Reihenfolge der Verschlüsselungsalgorithmen (Cipher Suites) bei einer TLS/SSL-Verbindung bestimmt. Bei on legt der Server die Reihenfolge fest. |
| SSLSessionTickets | Bei aktivierten SessionTickets solltet ihr den Webserver täglich neu starten |
| SSLCompression | Im Default aus und sollte auch aus bleiben |
| SSLStrictSNIVHostCheck | Verhindert den Zugriff von nicht SNI fähigen Clients. |
Die Beispielkonfiguration für einen Apache vHost mit der Option Intermediate sieht laut TLSRef z.B. so aus:
# generated 2026-09-04, TLSRef Guideline v6.0, Apache 2.4.60, OpenSSL 4.0.1, intermediate config, HSTS, gitrev=d96f668
# https://configurator.tlsref.org/#server=apache&version=2.4.60&config=intermediate&openssl=4.0.1&hsts&guideline=6.0
# this configuration requires mod_ssl, mod_rewrite, and mod_headers
<VirtualHost *:80>
RewriteEngine On
RewriteCond %{REQUEST_URI} !^/.well-known/acme-challenge/
RewriteRule ^.*$ https://%{HTTP_HOST}%{REQUEST_URI} [R=308,QSA,L]
</VirtualHost>
<VirtualHost *:443>
SSLEngine on
SSLCertificateFile /path/to/signed_cert_and_intermediate_certs
SSLCertificateKeyFile /path/to/private_key
# enable HTTP/2, if available
Protocols h2 http/1.1
# HTTP Strict Transport Security (mod_headers is required) (63072000 seconds)
Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains"
</VirtualHost>
# intermediate configuration
SSLProtocol -all +TLSv1.2 +TLSv1.3
SSLOpenSSLConfCmd Curves X25519MLKEM768:X25519:prime256v1:secp384r1
SSLCipherSuite 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
SSLCipherSuite TLSv1.3 TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256
SSLHonorCipherOrder off
SSLSessionTickets offIch hoffe die Anleitung hat euch geholfen und ihr seid nun PQC ready. Auf meiner kleinen Seite ist PQC eigentlich nicht notwendig, da ich nicht mit Benutzerkonten arbeite und auch eigentlich kein Ziel sein sollte. Aber mein Server speichert auch Daten wir eure Email Adresse sobald ihr kommentiert, somit ist hier auch Schutz geboten. Schaden kann es jedenfalls nicht und etwas Housekeeping kann auch nicht schaden.
Da wir schon mal bei Thema Security sind, lass ich euch noch den Link zum Mozilla HTTP Observatory hier stehen. Dort könnt ihr eure Webseite auf einige gängige Security Probleme scannen. Schaden kann es jedenfalls nicht, also schaut euch die Seite mal an.
