Archiv des Autors: Juergen Brauckmann

Version 6 der Zertifizierungsrichtlinie der DFN-PKI im Sicherheitsniveau „Global“

Zum 03.04.2020 tritt die Zertifizierungsrichtlinie 6 im Sicherheitsniveau „Global“ in Kraft. Änderungen in Version 6:

  • Titel und Fußzeile: Versionsnummer und Datum.
  • 1.2: OIDs
  • 4.9.7 und 7.2: Anpassungen der Regeln zum Ausstellen von Sperrlisten

Die Version 6 der Erklärung zum Zertifizierungsbetrieb für das Sicherheitsniveau „Global“, Datum des Inkrafttretens ebenfalls 03.04.2020, beinhaltet folgende Änderungen:

  • Titel und Fußzeile: Versionsnummer und Datum
  • 1.2: OIDs

Die neuen Dokumente finden Sie unter den folgenden URLs:

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

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

Mit Änderungsmarkierungen:

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

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

(Jürgen Brauckmann, 20.03.2020)

DFN-PKI und COVID-19

[Version 4: 26.03.2020, Jürgen Brauckmann
Version 3: 25.03.2020, Reimer Karlsen-Masur
Version 2: 18.03.2020, Jürgen Brauckmann
Version 1: 17.03.2020, Jürgen Brauckmann]

Wir möchten Ihnen an dieser Stelle Informationen zum Betrieb der DFN-PKI in der aktuellen Corona-Krise geben.

DFN-PCA-Betrieb

Für die DFN-PCA in Hamburg stellen wir die Erreichbarkeit über die Telefonnummer 040 80 80 77 580 sicher, sind aber für eine primäre Kontaktaufnahme per E-Mail (mailto:dfnpca@dfn-cert.de) dankbar.

Die Bearbeitung von per Post eingehenden Anträgen für Teilnehmerservice-Zertifikate ist sichergestellt.

Nutzung von Remote-Verfahren

Kann der persönliche Kontakt bei der Ausstellung von Zertifikaten minimiert und weitestgehend auf Remote-Verfahren umgestellt werden?

Mit der Berechtigungsprüfung, den Antragsformularen auf Papier und der persönlichen Identifizierung, die für Nutzerzertifikate (nicht bei Server- und Gruppenzertifikaten!) gefordert ist, gibt es bekanntermaßen Hürden.

In den folgenden Situationen ist eine Ausstellung von Zertifikaten ohne persönlichen Kontakt aber doch möglich:

Verlängerung von Nutzerzertifikaten

Post / Fax: Wenn der Nutzer innerhalb der letzten 39 Monate identifiziert wurde, und Sie das alte Antragsformular vorliegen haben, können Sie sich das neue unterschriebene Antragsformular per Post oder Fax schicken lassen. Voraussetzung:

  • Sie müssen das alte Antragsformular physikalisch vorliegen haben (Also z.B. aus einem Archiv hervor suchen).
  • Prüfung der Unterschrift:
    • Sie müssen die Unterschrift des Antragsstellers eindeutig der Unterschrift auf dem alten Antragsformular zuordnen können.
  • Prüfung der letzten Identifizierung:
    • Wurde auf dem alten Antragsformular eine Identifizierung vorgenommen und ist diese nicht älter als 39 Monate? (Block „Identitätsprüfung“ vollständig ausgefüllt. Nicht „Identität bereits früher geprüft“ mit Datum älter 39 Monate.)
  • Prüfung des Namens:
    • Der Name des Antragsstellers darf sich nicht geändert haben. Der Name im beantragten Zertifikat muss mit dem Namen auf dem alten Antragsformular übereinstimmen.

Wenn der Name des Nutzers sich nicht geändert hat, Sie die Unterschriften erfolgreich vergleichen konnten und die letzte Identifizierung nachweislich nicht länger als 39 Monate alt ist, können Sie das Zertifikat ausstellen ohne den Nutzer persönlich gesehen zu haben.

Signierte E-Mail: Alternativ kann auch ein Antragsformular ohne handschriftliche Unterschrift per signierter E-Mail eingeschickt werden. Auch hier muss der alte archivierte Antragsformular vorliegen, um Prüfungen vornehmen zu können. Es sind folgende Vorgaben zur Prüfung der E-Mail-Signatur und zur sicheren Archivierung zu erfüllen.

  • Eingang des PDF-Antrags mit signierter E-Mail
  • Ausdruck des PDF-Antrags
  • Prüfung der Signatur der E-Mail:
    • Gültige Signatur und gültiges Zertifikat exakt des Antragsstellers?
    • Name des Antragsstellers im Zertifikat identisch mit beantragtem Namen?
    • Zertifikat nicht abgelaufen?
    • Zertifikat nicht gesperrt?
  • Prüfung der letzten Identifizierung:
    • Wurde auf dem alten Antragsformular eine Identifizierung vorgenommen und ist diese nicht älter als 39 Monate? (Block „Identitätsprüfung“ vollständig ausgefüllt. Nicht „Identität bereits früher geprüft“ mit Datum älter 39 Monate.)
  • Prüfung des Namens:
    • Der Name des Antragsstellers darf sich nicht geändert haben. Der Name im beantragten Zertifikat muss mit dem Namen auf dem alten Antragsformular übereinstimmen.
  • Dokumentation auf dem ausgedruckten Antrag, Ausfüllen der Felder des Teilnehmerservice
  • Geeignete Archivierung der signierten E-Mail, z.B. Abspeichern als Datei in einem geeignetem Verzeichnis oder Kopieren in einen dedizierten IMAP-Ordner. Achtung: Für dieses Archiv gilt die Aufbewahrungsfrist aus Kapitel 5.5.2 der Erklärung zum Zertifizierungsbetrieb: 7 Jahre nach Ablauf des Zertifikats!
  • Wenn Sie Ihr Archiv später konsolidieren wollen, um etwa nicht zwei unterschiedliche PKI-Archive pflegen zu müssen, können Sie die handschriftlichen Unterschriften der Antragssteller später nachholen und Ihr elektronisches Archiv wieder auflösen. Die Dokumentation der Prüfschritte muss aber stets vor Ausstellung des Zertifikats geschehen.>

Wir raten Ihnen dringend, die unterschriebenen Papieranträge im Original einzufordern, da dort die Datenschutzeinwilligung enthalten ist.

Neubeantragung von Nutzerzertifikaten

Nutzerzertifikate unterscheiden sich von Serverzertifikaten durch die erforderliche persönliche Identifizierung. Darum steht leider für Neubeantragungen kein rein elektronischer Workflow zentral zur Verfügung. Die Verwendung von PostIdent ist möglich. Hierzu muss aber ein Vertrag zwischen Ihrer Einrichtung und der Deutschen Post oder einem anderen zertifizierten Anbieter direkt geschlossen werden. Der DFN-Verein kann hier leider nicht als Vermittler auftreten.

Eine persönliche Identifizierung ist selbstverständlich auch in einer klassischen Schaltersituation hinter einer Trennscheibe möglich.

Gruppenzertifikate

Für geeignete Anwendungsfälle können auch Gruppenzertifikate („GRP:“ und „GRP – „) ausgestellt werden. Diese können ohne persönliche Identifizierung ausgestellt werden. So kann der individuelle Anwendungsfall im Subject des Zertifikats angegeben werden, bspw. „GRP: Max Mustermann VPN-Login“. Bitte beachten Sie hierbei aber, dass keine „gerichtsfeste“ Verbindung von Aktionen, die mit diesem Zertifikat durchgeführt werden zu genau einer natürlichen Person möglich ist. Gruppenzertifikate eignen sich somit mehr für interne Anwendungsfälle in der Einrichtung und weniger für die Signatur von E-Mails etc. die die Einrichtung verlassen – es sei denn, es handelt sich um Role-Accounts (bspw. „GRP: HS Musterstadt User Support“).

Hinweis: Dies ist streng zu unterscheiden von Pseudonym-Zertifikaten („PN:“ bzw. „PN – „). Diese werden in praktisch jeder Hinsicht wie Nutzerzertifikate behandelt.

Video-Identifizierungen

Leider ist ein einfacher Einsatz von Videochats nicht direkt für eine Identifizierung geeignet. Nach ETSI EN 319 411-1, REG-6.2.2-05, müssen die verwendeten Verfahren zur Identifizierung von Personen für Nutzerzertifikate in jedem Fall äquivalent zur physikalischen Anwesenheit sein. Ein selbst entworfener Videochat-Prozess wird diese Anforderungen regelmäßig nicht erfüllen.

Der Einsatz eines Dienstleisters, der eine Zertifizierung für die Durchführung von VideoIdent für Zwecke des TKG oder Geldwäschegesetz hat, ist aber möglich. Auch hier kann der DFN-Verein leider nicht als Vermittler auftreten. Es ist ein Vertrag zwischen Ihrer Einrichtung und dem Anbieter erforderlich.

Serverzertifikate

Bei Serverzertifikaten ist keine persönliche Identifizierung des Antragsstellers erforderlich. Sie müssen lediglich garantieren, dass die Berechtigung gegeben ist. Darum sind bei Serverzertifikaten alternative Workflows leichter umsetzbar.

Übermittlung der Anträge von Serverzertifikaten

Post / Fax: Wenn Sie in der Lage sind, aus der Unterschrift des Antragsstellers eine Zuordnung und eine Berechtigungsprüfung abzuleiten, können Sie per Post oder Fax eingehende Anträge bearbeiten. Das Verfahren der Zuordnung / Berechtigungsprüfung ist von der DFN-PKI nicht zentral vorgegeben, da die Gegebenheiten in den Einrichtungen zu unterschiedlich sind. Das Verfahren darf nicht angewandt werden, wenn Sie keine Möglichkeit zur Prüfung von Unterschriften oder anderen Authentifizierungsmerkmalen haben. Andernfalls können Sie nicht verhindern, dass Ihnen ein Unbefugter einen Antrag unterschiebt.
Signierte E-Mail: Prinzipiell können Anträge für Serverzertifikate papierlos per signierter E-Mail zum Teilnehmerservice gelangen. Allerdings müssen zusätzliche Prüfschritte durchlaufen und dokumentiert werden. Hierzu müssen Sie folgendermaßen vorgehen:

  • Eingang des PDF-Antrags mit signierter E-Mail
  • Ausdruck des PDF-Antrags
  • Prüfung der Signatur der E-Mail:
    • Gültige Signatur und gültiges Zertifikat eines Berechtigten?
    • Zertifikat nicht abgelaufen?
    • Zertifikat nicht gesperrt?
  • Dokumentation auf dem ausgedruckten Antrag, Ausfüllen der Felder des Teilnehmerservice
  • Geeignete Archivierung der signierten E-Mail, z.B. Abspeichern als Datei in einem geeignetem Verzeichnis oder Kopieren in einen dedizierten IMAP-Ordner. Achtung: Für dieses Archiv gilt die Aufbewahrungsfrist aus Kapitel 5.5.2 der Erklärung zum Zertifizierungsbetrieb: 7 Jahre nach Ablauf des Zertifikats!
  • Wenn Sie Ihr Archiv später konsolidieren wollen, um etwa nicht zwei unterschiedliche PKI-Archive pflegen zu müssen, können Sie die handschriftlichen Unterschriften der Antragssteller später nachholen und Ihr elektronisches Archiv wieder auflösen. Die Dokumentation der Prüfschritte muss aber stets vor Ausstellung des Zertifikats geschehen.

Das Verfahren darf nicht angewandt werden, wenn Sie keine Möglichkeit zur authentifizierten Übermittlung der Anträge (eben durch signierte E-Mails) haben. Andernfalls können Sie nicht verhindern, dass Ihnen ein Unbefugter einen Antrag unterschiebt.

Erzeugung von Serverzertifikaten durch den Teilnehmerservice-Mitarbeiter

Bei Serverzertifikaten tritt die Einrichtung (juristische Person) als Antragsteller auf und nicht der individuelle Mitarbeiter (natürliche Person). Es ist daher aus PKI-Sicht grundsätzlich nichts dagegen einzuwenden, dass der Teilnehmerservice-Mitarbeiter Serverzertifikate selber beantragt und ausstellt.

Es gibt hierfür bereits ein Werkzeug: In der Java RA-Oberfläche finden Sie im Menü „Assistenten“ den Punkt „Serverzertifikat erstellen“, der die Erzeugung von privatem Schlüssel und Antrag und dessen Genehmigung automatisiert.

Eine Voraussetzung hierfür ist die Beachtung der folgenden Bedingung zur Nutzung von Serverzertifikaten (festgeschrieben zum einen im Antragsformular, zum anderen in „Informationen für Zertifikatinhaber“:

Der private Schlüssel darf nur Administratoren der im Zertifikat genannten Server zugänglich sein.

Sollte Ihr Teilnehmerservice also die Definition eines Administrators erfüllen (z.B. weil dieser direkt im Rechenzentrum angesiedelt ist), können Sie das Verfahren sofort umsetzen.

Voraussetzung: Sie müssen sichere Kommunikationskanäle haben, um die vom Teilnehmerservice erzeugten privaten Schlüssel übertragen zu können. Sie dürfen das Verfahren nicht anwenden, wenn Sie keine Möglichkeit haben, die Schlüssel sicher auf die Server zu übertragen.

Newsticker für weitere Dienste im DFN

Auf dem COVID-19-Newsticker vom DFN finden Sie Status-Updates für weitere DFN-Dienste.

Mögliche weitere Reduzierung der Laufzeit von Serverzertifikaten

Nach Presseberichten aus der letzten Woche (z.B. https://www.golem.de/news/apple-safari-soll-nur-noch-einjaehrige-tls-zertifikate-akzeptieren-2002-146779.html) hat Apple auf einem Meeting des CA/Browser Forums angekündigt, dass seine Software (wie z.B. Safari, iOS oder macOS) ab 1. September 2020 neu ausgestellte Serverzertifikate nur noch dann akzeptiert, wenn deren Laufzeit kleiner oder gleich 398 Tagen ist.

Damit setzt sich der Trend zu kürzeren Laufzeiten und damit verbunden die Notwendigkeit von höheren Automatisierungsgraden im Handling von PKIs fort.

Da Apple bisher offensichtlich nur eine mündliche Ankündigung gemacht hat, über die nur Berichte aus zweiter Hand vorliegen, ist es zur Zeit noch nicht möglich die exakten Konsequenzen abzuschätzen. Wir verfolgen die Entwicklung und prüfen, ob wir die Laufzeit von Serverzertifikaten ab 1. September 2020 generell auf 398 Tage begrenzen müssen, oder ob es weitere Optionen geben kann, beispielsweise für Anwendungsfälle jenseits von Webservern.

Wir möchten außerdem auf die bestehenden Automatisierungsmöglichkeiten in der DFN-PKI per Web-Service-Schnittstelle (https://blog.pki.dfn.de/tag/soapclient-releases/) hinweisen. Des Weiteren arbeiten wir an der Abschaffung des bisherigen Papierformulars für Serverzertifikate, wodurch der Aufwand bei der manuellen Beantragung von Serverzertifikaten reduziert werden wird.

(Jürgen Brauckmann, 27.02.2020)

Version 5 der Zertifizierungsrichtlinie der DFN-PKI im Sicherheitsniveau „Global“

Zum 31.01.2020 tritt die Zertifizierungsrichtlinie 5 im Sicherheitsniveau „Global“ in Kraft. Änderungen in Version 5:

  • Titel und Fußzeile: Versionsnummer und Datum.
  • 1.2: OIDs
  • 1.3.1: Liste der Root-Zertifikate und ausstellenden CAs aktualisiert
  • 2.2: Liste der Root-Zertifikate aktualisiert
  • 3.2.3: Validierung von Domains von E-Mail-Adressen beschrieben

Die Version 5 der Erklärung zum Zertifizierungsbetrieb für das Sicherheitsniveau „Global“, Datum des Inkrafttretens ebenfalls 31.01.2020, beinhaltet folgende Änderungen:

  • Titel und Fußzeile: Versionsnummer und Datum
  • 1.2: OIDs
  • 6.6.2: Intervall der Konfigurationsüberprüfung

Die neuen Dokumente finden Sie unter den folgenden URLs:

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

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

(Jürgen Brauckmann, 17.01.2020)

ETSI-Audit 2019 abgeschlossen

Das Audit der DFN-PKI nach ETSI EN 319 411-1 wurde bereits Mitte Dezember erfolgreich abgeschlossen. Die zugehörige Zertifizierungsurkunde ist vom TÜViT veröffentlicht: https://www.tuvit.de/fileadmin/Content/TUV_IT/zertifikate/de/67122UD_s.pdf

Auch 2019 fanden wieder angekündigte und vorbereitete Besuche bei Teilnehmern der DFN-PKI statt, bei der der Teilnehmerservice stichprobenartig untersucht wurde. Wir bedanken uns bei allen Einrichtungen, die wie auch in den letzten Jahren mit ihrer guten Arbeit ein erfolgreiches Audit der DFN-PKI  ermöglicht haben!

(Jürgen Brauckmann, 17.01.2020)

Java RA-Oberfläche Version 3.2.1

Die Java RA-Oberfläche für den Teilnehmerservice der DFN-PKI können Sie in der Version 3.2.1 hier herunterladen:

guira-3.2.1.zip

guira-3.2.1.zip.SHA256sum

Entpacken Sie das ZIP-Archiv. In den Dateien README.txt und Anleitung_Windows.pdf finden Sie weitere Hinweise zur Installation und Inbetriebnahme.

Änderungen

Version 3.2.1 (10.12.2019)

  • Bugfix BouncyCastle class cast

Systemvoraussetzungen

  • OpenJDK ab Version 11
  • Oracle Java ab Version 11 kann auch verwendet werden. Bitte beachten Sie hierzu:
    • In unseren Abnahmetests verwenden wir OpenJDK
    • Bitte berücksichtigen Sie die geänderten Lizenzbedingungen für den nicht-privaten Einsatz von Oracle.

Die enthaltenen Startskripte erwarten eine gesetzte Umgebungsvariable JAVA_HOME. Hinweise hierfür finden Sie in den Dateien README.txt und Anleitung_Windows.pdf.

Hinweise zum Bezug von Java finden Sie unter: https://blog.pki.dfn.de/2019/05/bezugsquellen-fuer-java-zum-betrieb-der-ra-oberflaeche

Konfiguration

Die RA-Oberfläche speichert die Einstellungen in Ihrem Home-Verzeichnis im Verzeichnis .dfn-pki. Sie können das entpackte ZIP-Archiv mit den ausführbaren Dateien beliebig verschieben, löschen oder neu herunterladen, ohne dass Sie die Einstellungen verlieren.

(Jürgen Brauckmann, 10.12.2019)

Java RA-Oberfläche Version 3.2

Die Java RA-Oberfläche für den Teilnehmerservice der DFN-PKI können Sie in der Version 3.2 hier herunterladen:

guira-3.2.zip

guira-3.2.zip.SHA256sum

Entpacken Sie das ZIP-Archiv. In den Dateien README.txt und Anleitung_Windows.pdf finden Sie weitere Hinweise zur Installation und Inbetriebnahme.

Änderungen

Version 3.2 (04.12.2019)

  • Workflow zum Beantragen von E-Mail-Domains aktualisiert: E-Mail-Domains müssen nun wie bereits Server-Domains per Challenge-E-Mail validiert werden.

Systemvoraussetzungen

  • OpenJDK ab Version 11
  • Oracle Java ab Version 11 kann auch verwendet werden. Bitte beachten Sie hierzu:
    • In unseren Abnahmetests verwenden wir OpenJDK
    • Bitte berücksichtigen Sie die geänderten Lizenzbedingungen für den nicht-privaten Einsatz von Oracle.

Die enthaltenen Startskripte erwarten eine gesetzte Umgebungsvariable JAVA_HOME. Hinweise hierfür finden Sie in den Dateien README.txt und Anleitung_Windows.pdf.

Hinweise zum Bezug von Java finden Sie unter: https://blog.pki.dfn.de/2019/05/bezugsquellen-fuer-java-zum-betrieb-der-ra-oberflaeche

Konfiguration

Die RA-Oberfläche speichert die Einstellungen in Ihrem Home-Verzeichnis im Verzeichnis .dfn-pki. Sie können das entpackte ZIP-Archiv mit den ausführbaren Dateien beliebig verschieben, löschen oder neu herunterladen, ohne dass Sie die Einstellungen verlieren.

(Jürgen Brauckmann, 09.12.2019)

Java RA-Oberfläche Version 3.1.1

Die Java RA-Oberfläche für den Teilnehmerservice der DFN-PKI können Sie in der Version 3.1.1 hier herunterladen:

guira-3.1.1.zip

guira-3.1.1.zip.SHA256sum

Entpacken Sie das ZIP-Archiv. In den Dateien README.txt und Anleitung_Windows.pdf finden Sie weitere Hinweise zur Installation und Inbetriebnahme.

Änderungen

Version 3.1.1 (29.10.2019)

  • Anpassung an aktuelle TLS-Cipher

Systemvoraussetzungen

  • OpenJDK ab Version 11
  • Oracle Java ab Version 11 kann auch verwendet werden. Bitte beachten Sie hierzu:
    • In unseren Abnahmetests verwenden wir OpenJDK
    • Bitte berücksichtigen Sie die geänderten Lizenzbedingungen für den nicht-privaten Einsatz von Oracle.

Die enthaltenen Startskripte erwarten eine gesetzte Umgebungsvariable JAVA_HOME. Hinweise hierfür finden Sie in den Dateien README.txt und Anleitung_Windows.pdf.

Konfiguration

Die RA-Oberfläche speichert die Einstellungen in Ihrem Home-Verzeichnis im Verzeichnis .dfn-pki. Sie können das entpackte ZIP-Archiv mit den ausführbaren Dateien beliebig verschieben, löschen oder neu herunterladen, ohne dass Sie die Einstellungen verlieren.

(Jürgen Brauckmann, 07.11.2019)

SOAP-Client Version 3.8.1/4.0.2

Das Bundle mit der Dokumentation und der Java-Client-Bibliothek der SOAP-Schnittstelle der DFN-PKI steht nun in neuen Versionen bereit. Wesentliche Neuerung ist eine interne Verbesserung beim Aufbau von TLS-Verbindungen. In früheren Versionen konnte es in Abhängigkeit von der Java-Version zu Problemen kommen, wenn der Server nur TLS >= 1.2 unterstützte.

Für JDK >=11: https://info.pca.dfn.de/doc/soapclient-bundle-4.0.2.tar.gz

Für JDK 8 (Umstieg auf JDK 11 empfohlen): https://info.pca.dfn.de/doc/soapclient-bundle-3.8.1.tar.gz

Für Entwicklungsarbeiten empfehlen wir dringend, dass Sie unsere Test-PKI verwenden. Sprechen Sie uns bitte an, um einen Zugang zu erhalten. Kontakt: mailto:dfnpca@dfn-cert.de

Bitte beachten Sie, dass Sie bei der Implementierung von eigenen Systemen unbedingt die Vorgaben der Zertifizierungsrichtlinie und des Dokumentes Pflichten der Teilnehmer einhalten müssen. Bitte besprechen Sie Ihr Projekt vorab mit uns. Kontakt: mailto:dfnpca@dfn-cert.de

(Jürgen Brauckmann, 07.11.2019)

Änderungen an Browsern: Verstecken von Extended Validation und Abschaltung von TLS < 1.2

Extended Validation

Nach dem Safari und Edge vorgelegt haben, werden auch in Chrome 77 (Release Mitte September 2019) und Firefox 70 (Mitte Oktober 2019) die  Hinweise auf Extended Validation Zertifikate aus der Adresszeile verschwinden und in Page Info o.ä. Stellen versteckt werden.

Ankündigungen mit Screenshots:

https://groups.google.com/a/chromium.org/forum/#!topic/security-dev/h1bTcoTpfeI

https://groups.google.com/forum/#!topic/firefox-dev/6wAg_PpnlY4

Abschaltung alter TLS-Versionen

Ab Januar 2020 werden alle Browser-Hersteller Updates herausbringen, in denen der Support für TLS 1.0 und 1.1 entfernt wird. Sollten Sie Server einsetzen, die noch kein TLS 1.2 unterstützen, müssen Sie, je nach Nutzung des Servers, tätig werden. Grundsätzlich sollten alle Server-Betriebssysteme, die in 2020 noch Support haben, TLS 1.2 unterstützen. Es empfiehlt sich aber trotzdem, insbesondere ältere Installationen mit Werkzeugen wie https://ssllabs.com/ssltest oder https://testssl.sh zu überprüfen, ob TLS 1.2 wirklich konfiguriert ist.

https://blog.mozilla.org/security/2018/10/15/removing-old-versions-of-tls

https://security.googleblog.com/2018/10/modernizing-transport-security.html

https://blogs.windows.com/msedgedev/2018/10/15/modernizing-tls-edge-ie11/

https://webkit.org/blog/8462/deprecation-of-legacy-tls-1-0-and-1-1-versions/

 

(Jürgen Brauckmann, 13.08.2019)