Archiv der Kategorie: Uncategorized

RA-Zugang zur alten DFN-PKI Generation bei Neueinrichtung mit TS-Operator-Zertifikat aus der neuen DFN-PKI Generation 2

Wo ist mein bestehender RA-Zugang zur alten DFN-PKI Generation 1 in der Java RA-Oberfläche geblieben?

Nach einer kompletten Neuinstallation Ihres Betriebssystems oder der Neukonfiguration der Java RA-Oberfläche (z.B. unter einem anderen Nutzerkonto) mit einem TS-Operator-Zertifikat der neuen DFN-PKI Generation 2 steht der RA-Zugang zur alten DFN-PKI Generation 1 zunächst nicht mehr in der Java RA-Oberfläche zur Verfügung.

Um auch diesen RA-Zugang zur alten DFN-PKI Generation 1 in der Java RA-Oberfläche wieder herzustellen, ist etwas Handarbeit nötig: Die Konfigurationsdatei der Java RA-Oberfläche muss manuell von Ihnen angepasst werden:

  1. Ggf. beenden Sie die noch laufende Java RA-Oberfläche.
  2. Suchen Sie unterhalb Ihres Home-Verzeichnisses nach der Datei configuration.xml im Verzeichnis .dfn-pki.
  3. Machen Sie ggf. eine Sicherheitskopie dieser Datei.
  4. Öffnen Sie die Datei configuration.xml in einem ASCII-Text-Editor.
  5. Suchen Sie darin den aktuellen Abschnitt für den RA-Zugang zur neuen DFN-PKI Generation, z.B.

    <node type=“de.dfncert.guira.pki.DFNPKICATreeNode“>
    <property name=“caName“>dfn-ca-global-g2</property>
    <property name=“raAlias“>Alias-Name des TS-Operator-Zertifikats</property>
    <property name=“raSource“>/Pfad/zum/TS-Operator-Zertifikat-G2.p12</property>
    <property name=“displayName“>Uni Musterstadt CA G2</property>
    <property name=“raType“>PKCS12</property>
    </node>

  6. Kopieren Sie diesen Abschnitt einschließlich der den Abschnitt einfassenden <node type=…> und </node> Tags und fügen Sie ihn gleich dahinter nochmals ein.
  7. Im eingefügten Abschnitt ändern Sie jetzt die Properties für caName und displayName wie folgt ab:
    1. Als neuen CA-Namen setzen Sie den bekannten CA-Namen aus der alten DFN-PKI Generation 1. Diesen können Sie z.B. aus den alten Web-URLs zur Zertifikatsbeantragung in der alten DFN-PKI Generation 1 ableiten. Für eine beispielhafte Web-URL der Form https://pki.pca.dfn.de/uni-musterstadt-ca/cgi-bin/pub/… aus der alten DFN-PKI Generation 1 ist uni-musterstadt-ca der gesuchte CA-Name für diesen neuen Konfigurationsabschnitt.
    2. Ändern Sie auch den Display-Namen auf z.B. Uni Musterstadt CA G1 ab, so dass Sie diesen neuen Eintrag im Anzeigebaum der Java RA-Oberfläche wiedererkennen können.
    3. Der neue Abschnitt für den RA-Zugang zur alten DFN-PKI Generation 1 sieht dann nach unserem Beispiel wie folgt aus:

      <node type=“de.dfncert.guira.pki.DFNPKICATreeNode“>
      <property name=“caName“>uni-musterstadt-ca</property>
      <property name=“raAlias“>Alias-Name des TS-Operator-Zertifikats</property>
      <property name=“raSource“>/Pfad/zum/TS-Operator-Zertifikat-G2.p12</property>
      <property name=“displayName“>Uni Musterstadt CA G1</property>
      <property name=“raType“>PKCS12</property>
      </node>

      Die anderen Properties wurden hierbei unverändert übernommen.

  8. Speichern Sie die Datei ab.
  9. Starten Sie die Java RA-Oberfläche.

(rkm, 13.04.2018)

Firefox 59, Windows und Probleme mit dem Zertifikatexport

[Update 22.3.: Thunderbird Im-/Export als weiteren Workaround]

Seit wenigen Tagen ist Firefox 59 verfügbar. Bei dieser Version kommt es beim Export von Zertifikaten zu einem Problem im Zusammenspiel mit Windows: Die aus Firefox exportierten Zertifikate im PKCS#12-Format sind nicht mehr in den Windows-Systemstore importierbar. Die Meldung von Windows lautet: „Das eingegebene Kennwort ist falsch“.

Mutmaßlicher Hintergrund: Firefox 59 setzt die Iterationen der Schlüsselableitungsfunktion zum Verschlüsseln des PKCS#12 auf den Wert 1.000.000 (Wert bei Firefox 58 war 100.000). Mit diesem Wert kommt anscheinend die Krypto-Bibliothek von Windows nicht zurecht.

Ticket bei Mozilla: https://bugzilla.mozilla.org/show_bug.cgi?id=1436873

Mögliche Abhilfe: Exportierte PKCS#12-Files können mit openssl oder einem anderen Werkzeug umkodiert werden. Dabei wird dann üblicherweise eine Windows-kompatible Anzahl an Iterationen verwendet.

Anleitung openssl: https://blog.pki.dfn.de/2018/02/pkcs12-akrobatik/

Fertiges Werkzeug (Windows-Executable) von den Kollegen vom Steinbuch Centre for Computing des KIT: https://git.scc.kit.edu/KIT-CA/RecodeCertificate/blob/master/README.md

Auch ein Import des PKCS#12 in den Mailclient Thunderbird (getestet mit Version 52.6.0) mit anschließendem Export erzeugt ein Objekt, das in Windows importiert werden kann.

(jbr, 21.03.2018)

Ausblick: Umstellung der Verfahren zur Freischaltung von Domains

[Update 21.03.: SOA-RR ergänzt]

Anfang Februar hat das CA/Browser Forum mit Ballot 218 festgelegt, dass
bestimmte auch in der DFN-PKI verwendete Verfahren zur Prüfung der
berechtigten Aufnahme von Domains in Serverzertifikaten umgestellt werden müssen.

Auf der letzten DFN-Betriebstagung am 14.-15.03.18 haben wir weitere Details der aktuellen Umstellungspläne vorgestellt, die Sie im Abschnitt „Validierung von Domains“ der Folien finden: https://www.dfn.de/fileadmin/3Beratung/Betriebstagungen/bt68/BT68_Sicherheit_NeuesPKI_Brauckmann.pdf

Nachtrag 21.03.:

Zusätzlich zu den Methoden, die in den Folien der Betriebstagung genannt sind, werden wir direkt im ersten Schritt eine Challenge-E-Mail an die E-Mail-Adresse des Zonenverwalters unterstützen. Diese E-Mail Adresse ist im SOA Resource Record zu der zu validierenden Domain im DNS hinterlegt (RNAME im SOA RR nach RFC 1035).

Beispiel anhand des SOAs für example.net:

example.net. 3600 IN SOA sns.dns.icann.org. noc.dns.icann.org. 2018013032 7200 3600 1209600 3600

Der Teilnehmerservice könnte in diesem Beispiel bestimmen, dass für eine Validierung die Challenge-E-Mail an noc@dns.icann.org gesendet wird. Auch die in den Folien bereits genannten Adressen hostmaster@example.net, webmaster@example.net, postmaster@example.net, admin@example.net, administrator@example.net wären zulässig.

(jbr, 19.03.2018)

Version 3.8 der Zertifizierungsrichtlinie DFN-PKI Global

Zum 19.03.2018 tritt die Zertifizierungsrichtlinie 3.8 im Sicherheitsniveau „Global“ in Kraft.

Änderungen in Version 3.8:

* Kapitel 3.2.2, Domain-Autorisierungen umgearbeitet.

Die neue Zertifizierungsrichtlinie (CP) finden Sie unter der folgenden URL:

https://www.pki.dfn.de/fileadmin/PKI/Policy-Archiv/DFN-PKI_CP_V3.8.pdf

Mit Änderungsmarkierungen:

https://www.pki.dfn.de/fileadmin/PKI/Policy-Archiv/DFN-PKI_CP_redline_V3.8.pdf

(jbr, 19.03.2018)

 

 

PKCS#12-Akrobatik

Manchmal enthalten aus Anwendungen oder Appliances exportierte PKCS#12-Dateien (Dateiendung .p12 oder .pfx) leider doch nicht die gewünschten CA-Zertifikate der CA-Zertifikatskette oder sogar gar keine CA-Zertifikate, siehe auch Sicherung von eigenen Nutzerzertifikaten aus Mozilla/Firefox. Dann kann man hingehen und versuchen, die Anwendung oder Appliance zu überzeugen, doch das Gewünschte zu exportieren, oder man nimmt gleich das Kommandozeilenwerkzeug openssl her und formt sich die vorliegende unpassende PKCS#12-Datei selbst um.

Um etwa die CA-Zertifikatskette eines in einer PKCS#12-Datei vorliegenden Client-Zertifikats der DFN-Verein Global Issuing CA aus der neuen Generation der DFN-PKI auszutauschen, genügt folgende Akrobatik:

1. Privaten Schlüssel und Client-Zertifikat mittels

openssl pkcs12 -clcerts -in client-cert-with-privkey.p12 -out client-cert-with-privkey.pem

aus der vorliegenden PKCS#12-Datei in eine PEM-Datei exportieren. Hierbei wird das Passwort der PKCS#12-Datei abgefragt und ein neues Passwort auf dem exportierten privaten Schlüssel in der PEM-Datei gesetzt.

2. Vollständige CA-Kette der DFN-Verein Global Issuing CA im PEM-Format herunterladen:

wget https://pki.pca.dfn.de/dfn-ca-global-g2/pub/cacert/chain.txt

3. Neue PKCS#12-Datei mit der gerade heruntergeladenen CA-Zertifikatskette zusammenbauen:

openssl pkcs12 -export -in client-cert-with-privkey.pem -certfile chain.txt -out client-cert-with-privkey-and-chain.p12

Hierbei wird das eben gesetzte Passwort des privaten Schlüssels aus der PEM-Datei abgefragt und ein neues Passwort auf der zu erzeugenden PKCS#12-Datei gesetzt.

4. Abschließende Aufräumarbeiten durchführen, also die zwischenzeitlich erzeugten Dateien mit privatem Schlüssel, d.h. client-cert-with-privkey.pem und ggf. die alte unpassende PKCS#12-Datei client-cert-with-privkey.p12 nachhaltig löschen.

Dieses „Kunststück” kann natürlich für Client-Zertifikate, die in Form einer PKCS#12-Datei vorliegen und von beliebigen Zertifizierungsstellen ausgestellt sind, durchgeführt werden, sofern man die korrekte CA-Zertifikatskette im PEM-Format in einer Datei vorliegen hat.

(rkm, 09.02.2018)

Version 3.7 des CP DFN-PKI „Global“, Änderungen an weiteren Dokumenten

Als Ergebnis des letztjährigen Audits der DFN-PKI tritt zum 15.02.2018 eine neue Version 3.7 der Zertifizierungsrichtlinie der DFN-PKI im Sicherheitsniveau „Global“ in Kraft.

Die wichtigsten Änderungen sind im Einzelnen:

  • Neuer Audit-Standard ETSI EN 319 411-1
  • Klarstellungen bzgl. Verbots von E-Mail-Adressen in Serverzertifikaten
  • Klarstellungen bzgl. der Sperrgründe in Kapitel 4.9.1

Das neue CP finden Sie unter der folgenden URL:
https://www.pki.dfn.de/fileadmin/PKI/Policy-Archiv/DFN-PKI_CP_V3.7.pdf

Mit Änderungsmarkierungen:
https://www.pki.dfn.de/fileadmin/PKI/Policy-Archiv/DFN-PKI_CP_V3.7_redline.pdf

Änderungen an den Dokumenten „Pflichten der Teilnehmer“ und „Informationen für Zertifikatinhaber“

In „Pflichten der Teilnehmer“ wurden Regelungen für den Betrieb von Mailgateways aufgenommen. Des Weiteren wurde ein Passus zum regelmäßigen Audit der DFN-PKI „Global“ und die Notwendigkeit der Unterstützung durch die Teilnehmer ergänzt.

In „Informationen für Zertifikatinhaber“ wurden Hinweise für den Betrieb von Mailgateways und zur oben aufgeführten Veröffentlichung von Serverzertifikaten in Certificate Transparency eingeführt.

Die Dokumente finden Sie unter:

https://www.dfn.de/fileadmin/PKI/anleitungen/Pflichten-der-Teilnehmer_V1.3.pdf

https://www.dfn.de/fileadmin/PKI/anleitungen/Informationen-fuer-Zertifikatinhaber_V1.2.pdf

Mit Änderungsmarkierungen:

https://www.dfn.de/fileadmin/PKI/anleitungen/Pflichten-der-Teilnehmer_V1.3_redline.pdf

https://www.dfn.de/fileadmin/PKI/anleitungen/Informationen-fuer-Zertifikatinhaber_V1.2_redline.pdf

(jbr, 30.01.2018)

Certificate Transparency in der DFN-PKI

Als Konsequenz aus Problemen mit den Zertifizierungsprozessen bei einigen CAs, die in den letzten Jahren offenbar wurden, haben Forscher u.a. von Google ein System namens Certificate Transparency (CT) entwickelt.

Hierbei handelt es sich um einen Mechanismus, mit dem ausgestellte Serverzertifikate von einer oder mehreren Sammelpunkten öffentlich einsehbar gehalten werden. Ziel ist die Erhöhung der Transparenz der Browser-PKI durch die komplette Überprüfbarkeit der CAs durch die Öffentlichkeit.

Diese Sammelpunkte sind die Kernkomponenten des Certificate Transparency Systems, sie werden als Certificate Transparency Logs (CT-Logs) bezeichnet und von beliebigen Parteien betrieben. Über kryptographische Beweise (Consistency Proofs über Merkle Hash Trees) ist sichergestellt, dass Außenstehende eine nachträgliche Manipulation des CT-Logs bemerken können.

Einen technischen Überblick über die Funktionsweise bietet https://www.certificate-transparency.org

Weitere Erläuterungen finden sich in folgendem Golem-Artikel (die dort dargestellte Timeline von Google Chrome ist allerdings überholt): https://www.golem.de/news/certificate-transparency-betrug-mit-tsl-zertifikaten-wird-fast-unmoeglich-1610-124024.html

Praktischer Einsatz

Google hat angekündigt, dass sein Browser Chrome ab Frühjahr 2018 erzwingen wird, dass neu ausgestellte Serverzertifikate der öffentlichen Browser-PKI in CT-Logs veröffentlicht werden. Chrome setzt dies um, indem beim TLS-Verbindungsaufbau das Vorhandensein von mehreren sogenannten Signed Certificate Timestamps (SCTs), kryptographisch gesicherte Artefakte von der Veröffentlichung eines Zertifikats, geprüft wird. Können von Chrome keine SCTs geprüft werden, wird die Webseite als unsicher klassifiziert, wobei die genaue Art der Darstellung in Chrome noch unbekannt ist.

Es gehört inzwischen zu den Qualitätsmerkmalen einer PKI, am Certificate Transparency System teilzunehmen und ausgestellte Serverzertifikate über CT-Logs verfügbar zu machen. Auch die DFN-PKI wird selbstverständlich Certificate Transparency unterstützen. Ab 26.02.2018 werden alle Serverzertifikate in der DFN-PKI Sicherheitsniveau Global in CT-Logs veröffentlicht.

Wichtig: Es gibt keine Auswirkungen auf bereits ausgestellte Serverzertifikate! Diese sind nicht betroffen, bleiben nach unserem Kenntnisstand auch in Google Chrome voll gültig und müssen nicht ausgetauscht werden.

Die DFN-PKI wird die folgenden CT-Logs verwenden:
https://plausible.ct.nordu.net
https://mammoth.ct.comodo.com
https://sabre.ct.comodo.com
https://ct.googleapis.com/rocketeer
https://ct.googleapis.com/pilot

(Diese Liste stellt den aktuellen Stand vom Februar 2018 dar. Die von der DFN-PKI verwendeten CT-Logs können sich kurzfristig und ohne Vorankündigung ändern. Zertifikate aus der DFN-PKI können über Uploads von Dritten auch in anderen als den aufgeführten CT-Logs erscheinen. Eine aktuelle Liste ist erhältlich über https://www.pki.dfn.de/faqpki/faqpki-allgemein/#c19130)

Auslieferung von SCTs

Die DFN-PKI stellt die oben erwähnten notwendigen Signed Certificate Timestamps direkt als Erweiterung in den ausgestellten Serverzertifikaten zur Verfügung („Embedded SCT“). Ein Beispiel mit eingebetteten SCTs finden Sie unter: https://crt.sh/?id=313019897

Grundsätzlich gibt es im Certificate Transparency System noch weitere Möglichkeiten, wie die SCTs einem Browser zugänglich gemacht werden können („OCSP Stapling“, „TLS Extension“). Diese anderen Varianten setzen aber üblicherweise Konfigurationseingriffe des Serveradministrators voraus.

Durch die von der DFN-PKI gewählte Variante der Embedded SCT müssen Serveradministratoren keine Änderungen an ihrem System vornehmen.

Zustimmung zur Veröffentlichung

Neben der rein technischen Anbindung, die von der DFN-PKI in den letzten Monaten umgesetzt worden ist, ergibt sich eine Änderung für Antragssteller: Wird ein Serverzertifikat in der DFN-PKI im Sicherheitsniveau Global beantragt, so muss in Zukunft der Antragssteller der Veröffentlichung zustimmen. Ohne diese Zustimmung wird in der DFN-PKI in Zukunft kein Serverzertifikat mehr erstellt werden können.

Des Weiteren ist eine Rücknahme dieser Zustimmung nicht mehr möglich. Technischer Hintergrund: Ein einmal mit Certificate Transparency veröffentlichtes Zertifikat kann technisch nicht mehr „depubliziert“ werden.

Nutzerzertifikate sind selbstverständlich von dieser Änderung nicht betroffen und werden generell nicht durch die DFN-PKI in den CT-Logs veröffentlicht. Je nach Grundeinstellung Ihres PKI-Zugangs sind auch weiterhin nicht-öffentliche Nutzerzertifikate möglich, die damit dann auch nicht über die von der DFN-PKI selbst betriebenen Verzeichnisdienste (LDAP und Web-Suche) veröffentlicht werden. Die gesetzlich vorgeschriebenen Widerrufsmöglichkeiten werden für Nutzerzertifikate natürlich ebenfalls vollumfänglich angeboten.

 (jbr, 30.01.2018)

Löschen privater Schlüssel in Firefox

Firefox speichert die privaten Schlüssel zu importierten Zertifikaten in einer Datenbank im Benutzerprofil. Dabei können zwei unterschiedliche Datenbankformate zur Anwendung kommen: Bisheriger Standard war die Berkeley DB, mit Firefox 58 wird ausschließlich SQLite zum Einsatz kommen.

Löschprobleme

Die aktuell überwiegend verwendete Berkeley DB markiert zu löschende Schlüssel lediglich als gelöscht, statt sie tatsächlich zu entfernen. Ist die DB nicht durch ein Masterpasswort geschützt, lassen sich die Schlüssel nach dem vermeintlichen Löschen weiterhin auslesen. (Die Verwendung eines Masterpassworts ist grundsätzlich ratsam, da die privaten Schlüssel sonst permanent ungeschützt auf der Festplatte liegen.)

In einem einfachen Experiment lässt sich das Problem nachvollziehen:

Unter der besonderen Adresse „about:support“ lässt sich das Profilverzeichnis öffnen; dort findet sich die key3.db, in der Firefox die privaten Schlüssel speichert. Beobachtet man diese Datei in einem Hexeditor, während man ein Zertifikat importiert, stellt man fest, dass sich ein signifikanter Block durch den neu hinzukommenden Schlüssel ändert. Löscht man das Zertifikat wieder, ist der Unterschied nur wenige Bytes groß. Der Schlüssel wird also nicht korrekt entfernt.

Won’t fix

Dieses Verhalten wird von den Entwicklern als Bug eingestuft, aber vermutlich nicht mehr behoben, da neue Firefox-Versionen nicht mehr betroffen sein werden:

https://bugzilla.mozilla.org/show_bug.cgi?id=1413994

Ab Firefox 58 wird eine bestehende Berkeley DB von Firefox auf eine SQLite-DB aktualisiert. Das neue Format hat das Löschproblem nicht mehr, daher wird es auch keine Aktualisierung der zugrunde liegenden Bibliothek geben.

Problematisch ist jedoch, dass bestehende key3.db-Dateien nicht entfernt werden. In langlebigen Profilordnern oder deren archivierten Backups werden also auch noch in einigen Jahren die längst gelöscht geglaubten Schlüssel zu finden sein.

Abhilfe

Der wichtigste Schritt ist das Setzen eines Masterpassworts. Ohne ein Masterpasswort sind die privaten Schlüssel nicht ausreichend geschützt. Denn unabhängig vom identifizierten Bug können ungeschützte private Schlüssel durch forensische Analyse aus früheren Versionen der key3.db von einer Festplatte extrahiert werden.

Das Passwort kann in den Einstellungen unter „Sicherheit“ gesetzt werden. (Direkt erreichbar unter about:preferences#security)

Unabhängig davon, ob ein Masterpasswort aktiv verwendet wird oder nicht, sorgt ein zwischenzeitliches Ändern des Passwortes (falls man kein Masterpasswort verwenden möchte: Aktivieren –> Setzen –> wieder Deaktivieren) für die Verwendung eines neuen Salzes, so dass die Datenbank neu verschlüsselt wird. Gelöschte Schlüssel werden dabei nicht verändert und können mit dem neuen Salz nicht mehr entschlüsselt werden. Daher sorgt eine Änderung des Masterpasswortes dafür, dass gelöschte Schlüssel unzugänglich werden.

Linux-Benutzer können mit folgenden Befehlen auf der Kommandozeile ein neues Masterpasswort setzen:

# Pfad zum Firefoxprofil (bei mehreren Profilen das Sternchen ersetzen)
 profile=~/.mozilla/firefox/*.default
 # Anzeigen vorhandener privater Schlüssel
 certutil -d $profile -K
 # Setzen eines neuen Masterpasswortes
 certutil -d $profile -W

Falls bislang kein Masterpasswort gesetzt war, kann die entsprechende Frage einfach mit Enter beantwortet werden.

Wichtig: Firefox muss vollständig beendet worden sein, bevor versucht wird, mit separaten Programmen wie certutil auf die Datenbank zuzugreifen! Andernfalls kann die Datenbank unwiderruflich beschädigt werden.

Für die Verwendung von certutil gibt es weitere Informationen unter:
https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/Reference/NSS_tools_:_certutil

Nach dem Umstieg auf Firefox 58 kann die key3.db gelöscht (eventuell mit vorherigem Backup auf USB-Stick o.ä.) und damit alle potentiellen Altlasten entfernt werden.

(11.01.2018, Finn Nielsen)

ETSI-Audit 2017 abgeschlossen

Auch 2017 wurde die DFN-PKI selbstverständlich auditiert. Im Gegensatz zu den vergangenen Jahren wurde diesmal der Standard ETSI EN 319 411-1 verwendet.

Hintergrund hierfür: Zur Umsetzung der eIDAS-Verordnung wurden die europäischen technischen Richtlinien und Standards für Trust Service Provider durch die ETSI grundlegend umgestaltet. Damit wurde auch die bisherige ETSI TS 102 042, nach der die DFN-PKI bisher auditiert wurde, durch die ETSI EN 319 411-1 abgelöst.

Auch diesmal fanden angekündigte und vorbereitete Besuche bei Teilnehmern der DFN-PKI statt, bei der die Arbeit des Teilnehmerservice stichprobenartig untersucht wurde. Wir bedanken uns wieder bei allen Einrichtungen, die ein erfolgreiches Audit der DFN-PKI  ermöglicht haben!

Die Bescheinigung über das Audit ist auf den Webseiten von TÜViT zu finden: https://www.tuvit.de/fileadmin/Content/TUV_IT/zertifikate/de/6771UD_s.pdf

 

(jbr, 08.01.2017)

Konfiguration von TLS-Servern: Aktueller Cipher-String

Bekanntermaßen ist die Konfiguration der Crypto-Parameter von TLS-Servern  eine kontinuierliche Aufgabe, siehe hierzu auch den ausführlichen Artikel Konfiguration von TLS-Servern: Ständige Herausforderung.

In unserem aktuellen Apache Cipher-String haben wir 3DES entfernt:

SSLCipherSuite 'ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:RSA+AESGCM:RSA+AES:!aNULL:!eNULL:!LOW:!RC4:!MD5:!EXP:!PSK:!DSS:!SEED:!ECDSA:!CAMELLIA'

Bitte beachten Sie auch die weiteren Konfigurationsempfehlungen aus dem oben genannten Artikel , insbesondere die Anleitung für individuelle Diffie-Hellman-Parameter!

(jbr, 10.12.2017)