Archiv des Autors: Juergen Brauckmann

Java in der DFN-PKI

Oracle nimmt zur Zeit erhebliche Veränderungen an seiner Java Implementierung vor. Diese haben Auswirkungen auf die Java RA-Oberfläche der DFN-PKI. Die relevanten Änderungen betreffen die folgenden Punkte:

  • Java WebStart mit den bekannten JNLP-Dateien wird abgeschafft.
  • Die Lizenz von Oracle Java ändert sich.
  • Interne Mechanismen werden umgestellt. Teilweise geschieht dies in einer Art, die sowohl rückwärts als auch vorwärts inkompatibel ist (Initialisierung von PKCS11).

Daher werden wir die Java RA-Oberfläche im Herbst 2018 folgendermaßen umstellen:

  • Die Java RA-Oberfläche der DFN-PKI wird als komplettes Java-Archiv zusammen mit plattformspezifischen Start-Skripten zum Herunterladen angeboten werden (Download-Link wird noch bekanntgegeben).
  • Da es in Java keinen eingebauten Update-Mechanismus für Anwendungen mehr geben wird, den WebStart ganz bequem geliefert hat, wird die Java RA-Oberfläche selbst auf neue Versionen prüfen und gegebenenfalls zum Herunterladen einer Aktualisierung auffordern.
  • Systemvoraussetzung wird OpenJDK ab Version 11 sein.
  • Die existierende Java WebStart-Version der RA-Oberfläche, die unter Oracle Java 8 lauffähig ist, wird noch bis ca. Mitte 2019 zur Verfügung stehen.

Wir informieren Sie, wenn die neue Version zur Verfügung steht.

(jbr, 06.09.2018)

X.509-Authentifizierung im Shibboleth IdP

Die DFN-AAI ist bekanntermaßen ein sehr erfolgreicher Mechanismus zur organisationsübergreifenden Anmeldung. Herkömmliche Konfigurationen arbeiten üblicherweise mit normalen Passwörtern mit all ihren Nachteilen.

Im Wiki der Trust und Identity Dienste des DFN steht nun eine Anleitung zur Verwendung von Client-Zertifikaten im Shibboleth Identity Provider 3 bereit:

https://doku.tid.dfn.de/de:shibidp3x509

(jbr, 25.06.2018)

Der CAA-Record im DNS ist nicht passend gesetzt

Seit September 2017 muss jede CA, die den Regeln des CA/Browser-Forums unterliegt, vor der Ausstellung eines Serverzertifikats CAA Resource Records im DNS prüfen. Eine Beschreibung des Systems findet sich in den folgenden Artikeln:

https://blog.pki.dfn.de/2017/03/rfc-6844-certification-authority-authorization-caa

https://blog.pki.dfn.de/2017/09/caa-rrs-reihenfolge-im-dns

In der DFN-PKI im Sicherheitsniveau Global wird die Prüfung direkt im Anschluss an das Genehmigen eines Serverzertifikat-Antrags in der Java RA-Oberfläche durchgeführt. Der Prüf-Mechanismus läuft dabei selbstverständlich auf den Servern der DFN-PKI, nicht in der Java RA-Oberfläche. Ist die Prüfung nicht erfolgreich, erscheint die folgende Fehlermeldung:


Hierfür kann es mehrere Ursachen geben. Zur Untersuchung können die DNS-Abfragen, die das DFN-PKI-System durchführt, manuell nachgestellt werden. Ein nützliches Werkzeug ist dig. Achtung: Nur relativ neue Versionen unterstützen die Abfrage von CAA-Records in einer leserlichen Form. Eine Alternative sind Web-Werkzeuge wie z.B. die Dig-Toolbox von Google https://toolbox.googleapps.com/apps/dig/#CAA/

Erscheint die Fehlermeldung beispielsweise für den Namen www.sub1.hs-musterstadt.de, so sollten nacheinander die folgenden Abfragen durchgeführt werden:

dig +adflag www.sub1.hs-musterstadt.de CAA
dig +adflag sub1.hs-musterstadt.de CAA
dig +adflag hs-musterstadt.de CAA
dig +adflag de CAA

Wichtig: Der verwendete rekursive Resolver muss security-aware sein und DNSSEC validieren. Wenn der Standard-Resolver Ihrer Einrichtung dies nicht leistet, muss ein alternativer validierender Resolver wie 1.1.1.1 oder 8.8.8.8 verwendet werden.

Ergibt eine Abfrage einen CNAME, muss auch das CNAME-Target auf CAA-Records abgefragt werden.

Im Idealfall ergeben alle Abfragen einen Status NOERROR oder NXDOMAIN (kein SERVFAIL). Wenn CAA-Records gefunden werden, so sollten diese immer auch den Wert pki.dfn.de enthalten.

Die Prüfung bricht stets beim ersten gefundenen CAA-Record ab.

Mögliche Fehlerursache: CAA-Record für falsche PKI gesetzt

Wenn Sie beispielsweise nur folgenden Record finden, ist es der DFN-PKI nicht erlaubt, Zertifikate auszustellen:

sub1.hs-musterstadt.de. IN CAA 0 issue "letsencrypt.org"

Lösung: Zusätzlichen CAA-Record hinzufügen.

sub1.hs-musterstadt.de. IN CAA 0 issue "letsencrypt.org"
sub1.hs-musterstadt.de. IN CAA 0 issue "pki.dfn.de"

Mögliche Fehlerursache: Defekter CAA-Record gesetzt

Mindestens ein uns bekanntes DNS-Management-Werkzeug produziert defekte CAA-Records, die die Ausstellung von Zertifikaten verhindern (beachten Sie den fehlenden Typ „issue“ vor dem Wert „pki.dfn.de“):

sub1.hs-musterstadt.de. IN CAA 0 0 "pki.dfn.de"

Lösung: Defekten CAA-Record entfernen oder Werkzeug dazu überreden, korrekte Records zu setzen.

Mögliche Fehlerursache: Abfrageprobleme (SERVFAIL) in Kombination mit DNSSEC

Bei Fehlern bei der DNS-Abfrage muss die DFN-PKI prüfen, ob die Zone mit DNSSEC gesichert sein sollte. Wenn dies der Fall ist, muss die Ausstellung von Zertifikaten abgelehnt werden. Insbesondere verhindern Nameserver, die (aus welchen Gründen auch immer) nicht aus dem Internet erreichbar sind, die Ausstellung von Zertifikaten, wenn die übergeordnete Zone mit DNSSEC gesichert ist.

Beispiel: Bei der Abfrage von sub1.hs-musterstadt.de kommt es zu einem Fehler, erkennbar am Header-Feld „status: SERVFAIL“:

$ dig +adflag sub1.hs-musterstadt.de
; <<>> DiG 9.11.3 <<>> +adflag sub1.hs-musterstadt.de
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 62481

Wie ist nun der Zustand der übergeordneten Zone?

$ dig +adflag hs-musterstadt.de

; <<>> DiG 9.11.3 <<>> +adflag hs-musterstadt.de
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36721
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 7

Da „flags: …ad“ zurückgeliefert wird, ist hs-musterstadt.de DNSSEC-geschützt. Damit kann die DFN-PKI keine Zertifikate für sub1.hs-musterstadt.de ausstellen.

Die Lösung hängt von der Ursache des SERVFAIL ab. Ist der eingetragene Nameserver nur für interne Zwecke vorgesehen und aufgrund von Router-ACLs nicht erreichbar, so bleibt leider keine andere Möglichkeit, als entweder für die DFN-PKI eine Erreichbarkeits-Ausnahme zu implementieren, oder aber die Zonen-Delegation aus der externen Sicht der hs-musterstadt.de-Nameserver zu entfernen (unterschiedliche Views für interne und externe Abfrager).

Liegt der Abfragefehler bei einer defekten DNSSEC-Konfiguration, so sollte diese repariert werden. Für eine genauere Analyse müssen in der Regel weitere Werkzeuge wie z.B. http://dnsviz.net verwendet werden.

Sollte die Ursache für die Fehlermeldung „Der CAA-Record im DNS ist nicht passend gesetzt“ weiterhin unklar bleiben, so helfen wir Ihnen gerne bei der Analyse. Kontakt: mailto:dfnpca@dfn-cert.de

(jbr, 30.04.2018)

Firefox 59, Windows und Probleme mit dem Zertifikatexport

[Update 18.5.: In Firefox 60 ist das Problem behoben]

[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“.

Update 18.05.: In Firefox 60 existiert das Problem nicht mehr.

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)

 

 

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)