PKI für das System und Service

Größe: px
Ab Seite anzeigen:

Download "PKI für das System und Service"

Transkript

1 Einführung der Gesundheitskarte PKI für das System und Service Level Monitoring Version: Revision: main/rel_main/17 Stand: Status: freigegeben gematik_pki_x 509_SSL_Monitoring.doc Seite 1 von 42

2 Dokumentinformationen Änderungen zur Vorversion Die zunächst in Kap. 4.3 angeführten Zertifikatsprofile werden im Dokument Festlegungen zu den X.509-Komponentenzertifikaten der Server und (Fach-) Dienste [gemx.509_sd] definiert und demzufolge hier gestrichen. In den Abschnitten 4.3.2, und wurden Formulierungen an andere PKI-Dokumente angepasst. Die Bezeichnungen der Zertifikate, technischen Rollen und Zertifikatstypen wurden an die neuen Vorgaben angepasst. Der offene Punkt bezüglich Suspendierung der Zertifikate wurde entfernt, da diese Funktion erforderlich ist. Der Zertifikatstyp wird nun in der Extension CertificatePolicy kodiert. Die Extension AdditionalInformation wurde gestrichen. In Anhang A2 wird jetzt verbindlich vorgegeben, dass die Zulassungsanforderungen für TSPs um die Berücksichtigung der Vorgaben aus gemsysslm erweitert werden. Inhaltliche Änderungen gegenüber der letzten freigegebenen Version sind gelb markiert. Sofern ganze Kapitel bzw. Abschnitte eingefügt wurden, wurde zur besseren Lesbarkeit lediglich die Überschrift durch gelbe Markierung hervorgehoben. Referenzierung Die Referenzierung in weiteren Dokumenten der gematik erfolgt unter: [gempki_mon] gematik: Einführung der Gesundheitskarte - PKI für das System und Service Level Monitoring () Dokumentenhistorie Version Stand Kap./ Seite Grund der Änderung, besondere Hinweise Bearbeitung Neuerstellung gematik, AG AG8-interne QS gematik, AG AG8-interne QS durch SSLM gematik, AG Kap. 5 Inhalt eingefügt gematik, AG Monitoring für einen OCSP-Responder überarbeitet Abb. 1 an neue Version [gemsysslm] angepasst gematik, AG8 gematik, AG8 gematik_pki_x 509_SSL_Monitoring.doc Seite 2 von 42

3 Version Stand Kap./ Seite Grund der Änderung, besondere Hinweise Einarbeitung Kommentare gematik-qs altes Kapitel 5 in neues Dok. ausgelagert Bearbeitung gematik, AG Formale Überprüfung gematik QS Einarbeitung Kommentare QS gematik, AG Abs. 2.5 an abgestimmte Formulierung angepasst. Extensionen Admission und Additional- Information zum Zertifikatsprofil hinzugefügt. Liste der Referenzen ergänzt. SPE/ZD freigegeben gematik OID-Referenzen für Rolle und Zertifikatstyp gemäß [gemspec_oid] angepasst und Inhalt common name im Zertifikat in Angabe des FQDN geändert formelle Überarbeitung QM SPE/ZD Einarbeitung Reviewergebnisse SPE/ZD freigegeben gematik Anpassungen Zertifikatstypen, Rollen und Extensions Einarbeitung Reviewergebnisse Kapitel 4.3 stark vereinfacht Anhang A3 aufgenommen SPE/ZD SPE/ZD freigegeben gematik gematik_pki_x 509_SSL_Monitoring.doc Seite 3 von 42

4 Inhaltsverzeichnis Dokumentinformationen...2 Inhaltsverzeichnis Zusammenfassung Einführung Zielsetzung und Einordnung des Dokuments Zielgruppe Geltungsbereich Arbeitsgrundlagen Abgrenzung des Dokuments Methodik Verwendung von Schüsselworten Hinweis auf offene Punkte Anforderungen PKI für das System und Service Level Monitoring Grundlagen Vertrauensmodell Zertifikatsaufbau Festlegungen zur Definition der Betreiber- bzw. gematik-identität Übersicht: Attribute im SubjectDN (X.509-Zertifikat für MON) Nutzung der Attribute im SubjectDN Aufbau der serialnumber im Feld SubjectDN Aufbau des gesamten SubjectDN Notwendige Zertifikatsfelder Kennzeichnung von Rollen in Extension Admission Extension Kennzeichnung von Angaben zum Zertifikatstyp in der Extension CertificatePolicy Zertifikatsprofile Zertifikat für einen Betreiber bzw. für die gematik (C.MGMTSS.SSL) CA-Zertifikat der CA-MON (C.MGMTSS.CA) Umgang mit den Zertifikaten für das Monitoring Registrierung/Zertifikatsgenerierung Registrierung der Betreiber und Information des TSP Ausstellen eines X.509-Zertifikats für Monitoring Nutzen/Verifizieren der Zertifikate Suspendieren, Desuspendieren bzw. Sperren der Zertifikate...30 gematik_pki_x 509_SSL_Monitoring.doc Seite 4 von 42

5 4.5 Verzeichnisdienste der CA-MON Vorgaben für die Policy der CA-MON Produktiv-/Test-CA-MON...33 Anhang A...34 A1 Monitoring für einen Broker...34 A2 Monitoring für einen OCSP-Responder...37 A3 Im Rahmen des Monitoring verwendete Rollen...38 Anhang B...39 B1 Abkürzungen...39 B2 Glossar...39 B3 Abbildungsverzeichnis...39 B4 Tabellenverzeichnis...39 B5 Referenzierte Dokumente...40 B6 Klärungsbedarf...41 gematik_pki_x 509_SSL_Monitoring.doc Seite 5 von 42

6 1 Zusammenfassung Für das System und Service Level Monitoring der Komponenten der Telematikinfrastruktur sammeln und verarbeiten die Betreiber der dezentralen Services die benötigten Daten in ihren eigenen Managementsystemen. Teile dieser Daten müssen aber für eine zentrale Überwachung und Darstellung der Performanz und Verfügbarkeit der dezentralen Services an das zentrale Managementsystem der gematik übermittelt werden. Der Austausch dieser Daten geschieht dabei nicht über das Netzwerk der Telematikinfrastruktur, sondern über ein gesondertes Management-VPN. Die Betreiber der dezentralen Services und die gematik implementieren zu diesem Zweck eine einheitliche Managementschnittstelle gemäß den Vorgaben aus [gemsysslm]. Hinweis: Der Begriff "dezentrale Services" wird in diesem Dokument, wie in [gem- SysSLM] definiert in seiner ursprünglichen allgemeinen Bedeutung verwendet und nicht in der engeren Definition aus [gemgesarch]. Für den Datenaustausch über das Management-VPN müssen sich die Kommunikationspartner gegenseitig authentisieren. Zu diesem Zweck erhalten alle Betreiber dezentraler Services und die gematik spezielle X.509-Zertifikate. Diese Zertifikate werden durch eine spezielle CA (CA-MON) ausgestellt. Die gematik wird nach einer Ausschreibung einen TSP mit dem Betrieb dieser CA beauftragen. Die Anforderungen an die PKI für die Zertifikate des System und Service Level Monitoring sind im Wesentlichen vergleichbar zu den Anforderungen an die PKI für die Komponentenzertifikate der Server und (Fach-) Dienste (siehe [gemx.509_sd]). Aufgrund der sehr einfachen Kommunikationsstruktur über das Management-VPN können die Anforderungen an die PKI (und damit die Anforderungen an den TSP bezüglich des Betriebs der CA- MON) aber zum Teil vereinfacht werden. So ist zum Beispiel eine OCSP-Abfrage im Rahmen des Verifizierens eines Zertifikats nicht notwendig, d. h. der TSP muss für die Zertifikate für das System und Service Level Monitoring keinen OCSP-Responder zur Verfügung stellen. Das vorliegende Dokument enthält in Kap. 4 neben der Festlegung des Aufbaus der X.509-Zertifikate für das System und Service Level Monitoring (im Sinne eines s) die Beschreibung der vereinfachten Anforderungen für einen TSP für den Betrieb der CA-MON. Beschrieben werden u. a. das Zusammenspiel zwischen gematik und TSP bei der Registrierung der Betreiber und bei dem Generieren der Zertifikate, Vorgaben für den Einsatz und das Verifizieren der Zertifikate sowie Regelungen für das Sperren der Zertifikate. Neben den Anforderungen an den Aufbau und Betrieb der CA-MON ergeben sich aus der Spezifikation des System und Service Level Monitoring auch weitere Vorgaben für andere PKI der Telematikinfrastruktur. Diese werden in Anhang A zusammengestellt. gematik_pki_x 509_SSL_Monitoring.doc Seite 6 von 42

7 2 Einführung 2.1 Zielsetzung und Einordnung des Dokuments Beim Datenaustausch im Rahmen des System und Service Level Monitoring müssen sich die Kommunikationspartner gegenseitig authentifizieren. Dabei werden X.509-Zertifikate genutzt, die gemäß den Vorgaben aus [gemsysslm] aus einer gesonderten (von den anderen PKIen der Telematikinfrastruktur getrennten) PKI stammen. In dem vorliegenden Dokument werden im Sinne eines s die wesentlichen Anforderungen an diese PKI beschrieben. Primäres Ziel dieses Dokuments ist es, den Leistungsumfang des TSP festzulegen, der die für das Ausstellen der benötigten X.509-Zertifikate zuständige CA betreibt. Dieses Dokument wird u. a. Bestandteil der Ausschreibung des Betriebs des TSP sein. Anmerkung: Die gematik wird (voraussichtlich) einen externen Dienstleister mit dem Betrieb des zentralen System und Service Level Monitoring beauftragen. Hierauf wird in diesem Dokument nicht weiter eingegangen. Es wird daher immer der Begriff gematik für den Betreiber des zentralen System und Service Level Monitoring verwendet. 2.2 Zielgruppe Das Dokument richtet sich im Wesentlichen an den TSP, der die CA-MON für das Ausstellen der benötigten X.509-Zertifikate für das System und Service Level Monitoring betreibt. Zusätzlich richtet es sich an die Betreiber einer Managementschnittstelle für den Austausch von Daten zwischen einem dezentralen System und Service Level Monitoring und dem zentralen System und Service Level Monitoring der gematik. Anhang A enthält die Beschreibung von Problemen, die sich aus Auswirkungen des System und Service Level Monitoring auf andere PKIen der Telematikinfrastruktur ergeben. Die Lösungen dieser Probleme müssen im Rahmen der Spezifikationen dieser PKIen gelöst werden. Aus den Lösungen werden sich dann Anforderungen an Betreiber eines Brokers und an Betreiber von OCSP-Respondern ergeben. 2.3 Geltungsbereich Die in diesem enthaltenen Vorgaben sind verbindlich für den TSP, der die CA- MON betreibt, sowie für alle Betreiber, die ein durch die CA-MON ausgestelltes X.509- Zertifikat für das System und Service Level Monitoring besitzen und nutzen. 2.4 Arbeitsgrundlagen Die wesentliche Grundlage für die Vorgaben des s bilden die folgenden Dokumente: gematik_pki_x 509_SSL_Monitoring.doc Seite 7 von 42

8 Spezifikation System und Service Level Monitoring [gemsysslm] Festlegungen zu den X.509-Komponentenzertifikaten der Server und (Fach-) Dienste [gemx.509_sd] 2.5 Abgrenzung des Dokuments Die langfristige Bestimmung der Hash-Algorithmen, der Schlüssellängen und der Signatur- und Verschlüsselungsalgorithmen ist nicht Gegenstand der Betrachtung. Hier werden jeweils aktuell die Empfehlungen der international relevanten Gremien bzw. die Anforderungen von SigG/SigV [ALGCAT] berücksichtigt. Die Vorgaben für die Vereinheitlichung der Public-Key-Infrastrukturen, insbesondere hinsichtlich der Policy-Aspekte [gemtsl_sp_cp], werden in gesonderten Dokumenten getroffen. Im vorliegenden Dokument werden ebenfalls keine Aussagen zum Management der kryptographischen Schlüssel getroffen. Diesbezüglich wird auf das übergreifende Sicherheitskonzept der gematik [gemsiko] verwiesen, insbesondere auf Abschnitt F5 [gemsi- Ko#AnhF5]. Die für die Verwendung in der TI zulässigen Algorithmen, Schlüssellängen und maximalen Gültigkeitsdauern von Schlüsseln und Zertifikaten werden in [gemsiko] entsprechend der Technischen Richtlinie für ecard-projekte der Bundesregierung [BSI-TR03116] normativ vorgegeben. Die freie Auswahl aus den hier zugelassenen Algorithmen durch die Hersteller könnte zu Interoperabilitätsproblemen führen, während die Implementierung aller zulässigen Algorithmen erheblichen Aufwand verursacht. Dieser Konflikt wird durch [gemspec_krypt] adressiert. Ziel des Dokumentes Verwendung kryptographischer Algorithmen in der Telematikinfrastruktur [gemspec_krypt] ist es, das Spektrum der zulässigen kryptographischen Algorithmen, sofern sie betreiberübergreifend verwendet werden, einzuschränken, um so mit einer minimalen Anzahl von Algorithmen kryptographische Interoperabilität herzustellen. Deshalb wird als Basis zur Referenzierung der kryptographischen Algorithmen auf o. g. Dokument, Abschnitt [gemspec_krypt#5.1.1] bzw. relevante Unterabschnitte verwiesen. Detaillierte Vorgaben zur Validierung von Zertifikaten und der Listen der vertrauenswürdigen Herausgeber werden in [gemverw_zert_ti] gemacht. Das vorliegende Dokument trifft nicht die Festlegungen zu den tatsächlich einzutragenden OIDs, sondern verwendet stattdessen eine gematik-oid-referenz. Die normative Festlegung der OIDs trifft das Dokument [gemspec_oid], dort ist die jeweilige Zuordnung der hier verwendeten OID-Referenz zur registrierten OID ersichtlich. Aktuell behandelt dieses nur die Aspekte der Nutzung der PKI im Rahmen des System und Service Level Monitoring. Die Nutzung im Rahmen weiterer Anwendungen wie z. B. Zertifikate über Schlüssel für Signaturen über Code bzw. Konfigurationen werden dagegen aktuell nicht betrachtet. Dieses geht auf alle PKI-relevanten Aspekte ein, die sich aus dem System und Service Level Monitoring ergeben. Die aufgeführten Vorgaben werden dabei jedoch nicht im Detail ausgearbeitet. Dies muss vielmehr in folgenden weiteren Tätigkeiten erfolgen: gematik_pki_x 509_SSL_Monitoring.doc Seite 8 von 42

9 Für den Aufbau und Betrieb der CA-MON muss eine Feinspezifikation erstellt werden. Dies muss gemäß Ausschreibung der gematik durch den Auftragnehmer durchgeführt werden, der als TSP für alle Komponenten-PKIen durch die gematik beauftragt wird. In der gematik müssen Prozesse für die Registrierung der beteiligten Betreiber etabliert werden. Hierfür muss die gematik entsprechende Konzepte erstellen und umsetzen. In der gematik müssen Prozesse für die Sperrung (ggf. auch die Suspendierung und Desuspendierung) von Zertifikaten etabliert werden. Hierfür muss die gematik entsprechende Konzepte erstellen und umsetzen. In der gematik müssen Prozesse für eine unverzügliche Information aller Betreiber im Falle der Änderung ihres eigenen MON-Zertifikats etabliert werden. Hierfür muss die gematik entsprechende Konzepte erstellen und umsetzen. Für das zentrale System und Service Level Monitoring muss der Umgang mit der White-List der MON-Zertifikate der Betreiber spezifiziert werden. Dies muss im Rahmen der Konzeption und Umsetzung des zentralen System und Service Level Monitoring erfolgen. Die in Anhang A zusammengestellten Probleme, die sich aus dem System und Service Level Monitoring für andere PKIen ergeben, müssen im Rahmen der Spezifikationen dieser PKIen gelöst werden. 2.6 Methodik Verwendung von Schüsselworten Für die genauere Unterscheidung zwischen normativen und informativen Inhalten werden die dem RFC 2119 [RFC2119] entsprechenden in Großbuchstaben geschriebenen, deutschen Schlüsselworte verwendet: MUSS bedeutet, dass es sich um eine absolutgültige und normative Festlegung bzw. Anforderung handelt. DARF NICHT bezeichnet den absolutgültigen und normativen Ausschluss einer Eigenschaft. SOLL beschreibt eine dringende Empfehlung. Abweichungen zu diesen Festlegungen sind in begründeten Fällen möglich. Wird die Anforderung nicht umgesetzt, müssen die Folgen analysiert und abgewogen werden. SOLL NICHT kennzeichnet die dringende Empfehlung, eine Eigenschaft auszuschließen. Abweichungen sind in begründeten Fällen möglich. Wird die Anforderung nicht umgesetzt, müssen die Folgen analysiert und abgewogen werden. KANN bedeutet, dass die Eigenschaften fakultativ oder optional sind. Diese Festlegungen haben keinen Normierungs- und keinen allgemeingültigen Empfehlungscharakter. gematik_pki_x 509_SSL_Monitoring.doc Seite 9 von 42

10 2.6.2 Hinweis auf offene Punkte Offene Punkte, die bis zur nächsten Dokumentenversion bearbeitet werden, sind vorläufig nach der folgenden Konvention gekennzeichnet. Das Kapitel wird in einer späteren Version des Dokumentes ergänzt. gematik_pki_x 509_SSL_Monitoring.doc Seite 10 von 42

11 3 Anforderungen Die Anforderungen müssen noch mit dem Anforderungsmanagement abgestimmt werden. Dieses Kapitel wird in einer späteren Version des Dokuments dann entsprechend vollständig überarbeitet. Die Notwendigkeit für eine PKI für die, für das System und Service Level Monitoring benötigten, X.509-Zertifikate ergibt sich direkt aus [gemsysslm]. Dabei müssen die folgenden wesentlichen Anforderungen berücksichtigt werden: Über die Managementschnittstelle DÜRFEN nur hierfür autorisierte Systeme kommunizieren. Teilnehmer des Management-VPN MÜSSEN sich authentisieren. Die gematik hat die Verantwortung für die Registrierung der berechtigten Teilnehmer. Die gematik MUSS die Interoperabilität dieser PKI sicherstellen. Es MUSS für die benötigten X.509-Zertifikate eine separate PKI aufgebaut und betrieben werden. Die X.509-Zertifikate werden nur im Rahmen der Kommunikation über die Managementschnittstelle zu dem Management-VPN genutzt. Die folgende Tabelle enthält die entsprechenden, bereits durch das Anforderungsmanagement erfassten relevanten Eingangsanforderungen: Tabelle 1: Bereits erfasste Eingangsanforderungen Quelle Anforderungsnummer Anforderungslevel Beschreibung gempolicy A_01298 MUSS gematik MUSS die Interoperabilität aller Telematikkomponenten sicherstellen. Dies gilt im Sinne der: * Spezifikationsverantwortung * Verantwortung für das Test- und Zulassungsverfahren * Betriebsverantwortung (Betriebsprozesse sowie das einzuhaltende Sicherheitsniveau) * Sicherstellung der Interoperabilität über alle PKI- Strukturen der Telematikinfrastruktur des Gesundheitswesens gemgesarch A_01260 MUSS Es MUSS sichergestellt sein, dass nur autorisierte Personen und Systeme über die Managementschnittstelle kommunizieren. gemsysslm A_01370 MUSS Das der Managementschnittstelle zugrunde liegende Netzwerk MUSS das System Management VPN sein. gemsysslm A_01399 MUSS Eine separate PKI MUSS zur Abdeckung sicher- gematik_pki_x 509_SSL_Monitoring.doc Seite 11 von 42

12 Quelle Anforderungsnummer Anforderungslevel Beschreibung heitsrelevanter Funktionalität im System und Service Level Monitoring System implementiert werden. Die für die Anwendungen der egk implementierten PKI der Telematikinfrastruktur DÜRFEN NICHT verwendet werden. gemsysslm A_01400 MUSS Die Registrierungsverantwortung der internen PKI zur Abdeckung sicherheitsrelevanter Funktionalität im System und Service Level Monitoring MUSS durch die zentralen Betriebsprozesse der gematik wahrgenommen werden. Neben den genannten Anforderungen MÜSSEN bei der PKI für das System und Service Level Monitoring auch die Vorgaben der Zertifizierungsrichtlinie der gematik [gemtsl_sp_cp] berücksichtigt werden. gematik_pki_x 509_SSL_Monitoring.doc Seite 12 von 42

13 4 PKI für das System und Service Level Monitoring 4.1 Grundlagen Gemäß [gemsysslm] sammeln die einzelnen Betreiber der dezentralen Services, die für das System und Service Level Monitoring (im Folgenden abkürzend mit MON bezeichnet) benötigten Daten in ihren eigenen Managementsystemen. Die für das zentrale System und Service Level Monitoring der gematik benötigten Daten, werden dann durch die einzelnen Betreiber an die gematik weitergeleitet. Die Betreiber und die gematik realisieren für diesen Datenaustausch die in [gemsysslm] spezifizierte Managementschnittstelle. Die folgende Abbildung (entnommen aus [gemsysslm]) zeigt die dabei verwendete Netzwerkarchitektur: Abbildung 1: Netzarchitektur dezentrales System und Service Level Monitoring Der Datenaustausch zwischen den Betreibern und der gematik erfolgt über ein separates Management-VPN. Durch [gemsysslm] sind hierfür die folgenden Vorgaben gegeben: Als Protokoll wird HTTPS verwendet. gematik_pki_x 509_SSL_Monitoring.doc Seite 13 von 42

14 Beim Verbindungsaufbau wird eine gegenseitige Authentisierung der beiden Kommunikationspartner durchgeführt. Bei der Authentisierung werden X.509-Zertifikate verwendet, die durch eine speziell hierfür zu betreibende PKI erzeugt werden. Im Rahmen der Authentisierung muss jede Seite die aktuelle Gültigkeit des Zertifikats der anderen Seite überprüfen. Bei dem Datenaustausch über die gematik-managementschnittsstelle ist die Größe der auszutauschenden Daten auf 10 MB beschränkt. Für große Datenmengen stellen die Betreiber und die gematik eine Up- und Download-Funktionalität für Software und Dateien zur Verfügung. Als Protokolle kommen HTTPS und SFTP dabei zum Einsatz. Eine Authentisierung der Kommunikationspartner findet ebenfalls statt, wobei X.509-Zertifikate aus der gleichen PKI genutzt werden. Beim Datenaustausch für das System und Service Level Monitoring findet eine Kommunikation immer zwischen einem Betreiber einerseits und der gematik andererseits statt. Eine direkte Kommunikation zwischen zwei Betreibern findet nicht statt. Aus logischer Sicht hat das Management VPN daher eine Sterntopologie mit der gematik als zentralen Knoten. Die folgende Abbildung zeigt die möglichen direkten Kommunikationswege: Management Schnittstelle Betreiber 2 Management Schnittstelle Betreiber 1 Management Schnittstelle Betreiber n Management Schnittstelle gematik Abbildung 2: Netztopologie für das dezentrale System und Service Level Monitoring Aus dieser logischen Sterntopologie können Vorgaben für die benötigte PKI abgeleitet werden, die den Aufbau und Betrieb insbesondere in Bezug auf das Verifizieren der Zertifikate wesentlich vereinfachen. Diese Punkte werden in den folgenden Abschnitten näher beschrieben. gematik_pki_x 509_SSL_Monitoring.doc Seite 14 von 42

15 4.2 Vertrauensmodell Alle X.509-Zertifikate für das System und Service Level Monitoring werden von einem zentralen TSP ausgestellt. Die gematik wird hierfür einen geeigneten Betreiber auswählen und mit dem Betrieb der CA beauftragen. Der TSP setzt für die Ausgabe der Zertifikate für das MON eine gesonderte (Sub-) CA- MON auf, die getrennt von CAs für andere PKIen der Telematikinfrastruktur betrieben wird. Das Zertifikat über den öffentlichen Schlüssel dieser (Sub-) CA-MON wird durch die Root-CA (Komponenten PKI) desselben TSP mit ihrem privaten Schlüssel signiert. Es ergibt sich somit folgende Hierarchie für die PKI für das System und Service Level Monitoring: TSP Root-CA Sub-CA Zertifikat Sub-CA Zertifikat Sub-CA Zertifikat Sub-CA PKI x CA-MON Sub-CA PKI y X.509 Zertifikat für SSLM X.509 Zertifikat für SSLM X.509 Zertifikat für SSLM Betreiber 1 Management Schnittstelle Betreiber n Management Schnittstelle gematik Management Schnittstelle Abbildung 3: Hierarchie PKI für System und Service Level Monitoring Alle Zertifikate für die Absicherung der Kommunikation zwischen dezentralem und zentralem System und Service Level Monitoring werden durch die gleiche CA-MON ausgestellt. Die Zertifikate werden auch nur zur Absicherung dieser Kommunikation eingesetzt. Die Anzahl der beteiligten Betreiber und damit die Anzahl der benötigten X.509-Zertifikate ist gering. Für die Verteilung dieser Zertifikate wird daher das folgende vereinfachte Vorgehen umgesetzt: Das aktuell gültige CA-Zertifikat der CA-MON wird auf der Webseite des TSP für einen Download zur Verfügung gestellt. Jeder beteiligte Betreiber (mit einem dezentralen System und Service Level Monitoring) sowie die gematik laden dieses Zertifikat von dieser Webseite. Die CA-MON stellt einen Fingerprint über sein CA-Zertifikat auf Anfrage schriftlich zur Verfügung. Siehe dazu auch den Abschnitt gematik_pki_x 509_SSL_Monitoring.doc Seite 15 von 42

16 gematik und Betreiber erhalten ihr X.509-Zertifikat für das Monitoring der CA-MON. Siehe dazu Abschnitt Das aktuell gültige X.509-Zertifikat für das Monitoring der gematik wird (zusätzlich) auf der Webseite der gematik und auf der Webseite des TSP für einen Download zur Verfügung gestellt. Jeder beteiligte Betreiber (mit einem dezentralen System und Service Level Monitoring) lädt dieses Zertifikat von einer dieser Webseiten. Die gematik informiert alle Betreiber per , falls sich ihr Zertifikat geändert hat. Die Betreiber laden dann das neue Zertifikat von einer der genannten Webseiten. Die gematik erhält von dem TSP eine White-List mit allen aktuell gültigen X.509-Zertifikaten für MON aller beteiligten Betreiber. Das genaue Vorgehen bei dem Austausch dieser White-List wird zwischen gematik und TSP bilateral abgestimmt. Die im Rahmen des Verbindungsaufbaus zwischen der gematik und einem Betreiber notwendige Überprüfung des Zertifikats des jeweiligen Kommunikationspartners kann bei diesem Vorgehen rein lokal geschehen. Eine Online-Überprüfung z. B. durch eine OCSP- Abfrage wird nicht benötigt. 4.3 Zertifikatsaufbau Der Aufbau der Zertifikate für Betreiber bzw. für die gematik MUSS dem Zertifikatsprofil C.SF.SSL entsprechen. Für das CA-Zertifikat MUSS das Profil C.SF.CA mit den Festlegungen für CAs von SSL- Zertifikaten eingerichtet werden. Diese Profile werden im Dokument Festlegungen zu den X.509-Komponentenzertifikaten der Server und (Fach-) Dienste [gemx.509_sd] definiert. Sie beschreiben Inhalt und Kodierung der Zertifikatsfelder bzw. Extensions. In diesem Kapitel werden nur die Zertifikatseigenschaften aufgeführt, deren Definition für System und Service Level Monitoring präzisiert werden muss Festlegungen zur Definition der Betreiber- bzw. gematik-identität Die Identität eines Betreibers bzw. der gematik ist durch den Inhalt des Feldes SubjectDN (subject distinguishedname) des X.509-Zertifikats für MON gegeben Übersicht: Attribute im SubjectDN (X.509-Zertifikat für MON) Tabelle 2: Attribute im SubjectDN Attribut OID Kodierung max. String-Länge Art commonname {id-at 3} UTF8 64 Pflicht givenname {id-at 42} UTF8 64 P serialnumber {id-at 5} PrintableString 64 P gematik_pki_x 509_SSL_Monitoring.doc Seite 16 von 42

17 streetaddress {id-at 9} UTF8 128 Option postalcode {id-at 17} UTF8 40 O localityname {id-at 7} UTF8 128 O stateorprovincename {id-at 8} UTF8 128 O organizationalunitname {id-at 11} UTF8 64 O organizationname {id-at 10} UTF8 64 P countryname {id-at 6} PrintableString 2 (ISO 3166 Code) P Die Eindeutigkeit der Identität eines Betreibers (bzw. der gematik) innerhalb der Telematikinfrastruktur ist bereits durch den Inhalt des Attributs commonname innerhalb des SubjectDN gegeben ([gemsysslm]). Zusätzlich enthält SubjectDN noch den Namen und das Land des Betreibers als weitere Pflichtangaben. Optionale Felder mit der Anschrift des Betreibers bzw. dem Namen einer relevanten Abteilung können ebenfalls in einem X.509-Zertifikat für das Monitoring enthalten sein Nutzung der Attribute im SubjectDN commonname Datenfeld: FQDN. Es MUSS der durch die gematik für die Managementschnittstelle des Betreibers vergebene FQDN eingetragen werden (näheres siehe 4.4.1). Feld Länge Kardinalität Datentyp Format Durch die gematik vergebener FQDN der Managementschnittstelle givenname AN UTF-8 Datenfeld: Name des Services. Zurzeit MUSS hier der konstante Wert "Managementschnittstelle" eingetragen werden. Zukünftig kann es hier zu Erweiterungen kommen. Feld Länge Kardinalität Datentyp Format Zurzeit konstanter Wert "Managementschnittstelle" serialnumber AN UTF-8 Datenfeld: Laufende Nummer der Komponente. Zurzeit MUSS der Wert "1" eingetragen werden. Zukünftig kann es hier zu Erweiterungen kommen. Feld Länge Kardinalität Datentyp Format Zurzeit konstanter Wert "1" AN Printable- String streetaddress Datenfeld: Straßenanschrift des Betreibers gematik_pki_x 509_SSL_Monitoring.doc Seite 17 von 42

18 Feld Länge Kardinalität Datentyp Format Straße Hausnummer (mehrere Wörter sind durch Blank getrennt) AN UTF-8 postalcode Datenfeld: Postleitzahl des Betreibers Feld Länge Kardinalität Datentyp Format Postleitzahl Deutsche Postleitzahlen werden in einer Länge von 5 Byte abgebildet localityname Datenfeld: Stadt des Betreibers AN UTF-8 Feld Länge Kardinalität Datentyp Format Stadt AN UTF-8 stateorprovincename Datenfeld: Bundesland der Anschrift des Betreibers Feld Länge Kardinalität Datentyp Format Bundesland AN UTF-8 organizationalunitname Datenfeld: Name der relevanten Einheit des Betreibers. Feld Länge Kardinalität Datentyp Format Name der relevanten Einheit des Betreibers. organizationname AN UTF-8 Datenfeld: Name des Betreibers. Es MUSS der gleiche Name eingetragen werden, wie er im Rahmen der Zulassung/Registrierung des Betreibers durch die gematik genannt wurde. Feld Länge Kardinalität Datentyp Format Name des Betreibers: Angabe wie bei der Registrierung durch die gematik (Ist die maximal zulässige Länge des Namens überschritten, muss dieser zusätzlich in die X.509-Extension SubjectAltNames (GeneralDN) eingetragen werden.) AN UTF-8 gematik_pki_x 509_SSL_Monitoring.doc Seite 18 von 42

19 countryname Datenfeld: Land der Anschrift des Betreibers Feld Länge Kardinalität Datentyp Format countryname AN Printable String Aufbau der serialnumber im Feld SubjectDN Zurzeit MUSS immer der konstante Wert "1" in das Attribut serialnumber aufgenommen werden, da bereits durch den Inhalt des Attributs commonname eine Managementschnittstelle eindeutig identifiziert wird (siehe auch [gemsysslm]). Zukünftig kann es hier jedoch zu Erweiterungen kommen, z. B. falls die Managementschnittstelle (aus Gründen der Hochverfügbarkeit) redundant mehrfach bei einem Betreiber vorhanden ist. Von der eindeutigen Seriennummer der Komponente muss die eindeutige Nummer des X.509-Zertifikats unterschieden werden. Diese wird durch die ausstellende CA (ganze Zahl, 1<=serialNumber<= ) definiert und ist nur innerhalb der Domäne der CA eindeutig zuzuordnen Aufbau des gesamten SubjectDN Der SubjectDN eines Betreibers bzw. der gematik setzt sich wie folgt zusammen (Optionale Daten sind grau hinterlegt): commonname = [FQDN], givenname = Managementschnittstelle, serialnumber = 1, streetaddress = [Straße und Hausnummer], postalcode = [Postleitzahl], localityname = [Stadt] stateorprovincename = [Bundesland], organizationalunitname = [Relevante Einheit des Betreibers], organizationname = [Name des Betreibers], countryname = [Herkunftsland des Betreibers, z. B. DE] Die Werte der Attribute givenname und serialnumber enthalten zurzeit die angegebenen konstanten Werte. Zukünftig kann es hier zu Erweiterungen kommen Notwendige Zertifikatsfelder Abweichend von Kapitel 5.3 Notwendige Zertifikatsfelder aus dem Dokument Festlegungen zu den Komponentenzertifikaten der Server- und (Fach-) Dienste [gemx.509_sd#5.3] ist die Extension AuthorityInfoAccess in allen Monitoring-Zertifikaten optional. Die folgende Tabelle gibt einen Überblick über die möglichen Extensions, die in einem Zertifikat enthalten sein MÜSSEN (P) bzw. enthalten sein KÖNNEN (O): Tabelle 3: Überblick der im Zertifikat enthaltenen Extensions Betreiberzertifikat (C.MGMTSS.SSL) CA-Zertifikat (C.MGMTSS.CA) SubjectKeyIdentifier O O gematik_pki_x 509_SSL_Monitoring.doc Seite 19 von 42

20 Betreiberzertifikat (C.MGMTSS.SSL) CA-Zertifikat (C.MGMTSS.CA) BasicConstraints - P KeyUsage P P SubjectAltNames O O CertificatePolicy P P CRLDistributionPoint O O AuthorityKeyIdentifier O O Admission P O AdditionalInformation P O ExtendedKeyUsage P O Die Extension BasicConstraints MUSS für das CA-Zertifikat den Wert "CA:true enthalten. Die Extension KeyUsage MUSS für ein Betreiberzertifikat den Wert "digitalsignature enthalten. Zusätzlich KANN der Wert "keyencipherment enthalten sein. Für das CA-Zertifikat MUSS die Extension den Wert "keycertsign enthalten. Die Extension ExtendedKeyUsage MUSS für ein Betreiberzertifikat die Werte "serverauth und "clientauth enthalten. Für die OIDs der anzugebenden Werte siehe [ISIS-MTT]. In allen Komponentenzertifikaten wird in der Extension Admission die technische Rolle des Zertifikatsinhabers (hier Management Schnittstelle [gemgesarch#anhb1]) angegeben. Die genaue Festlegung der OID erfolgt verbindlich im Dokument [gemspec_oid]. Zur Unterscheidung von Endnutzerzertifikaten wird neben den Referenzen auf die Policies auch der jeweilige Zertifikatstyp (OID) in der Extension AdditionalInformationCertificatePolicy gespeichert. Die genaue Festlegung der Inhalte erfolgt nun verbindlich im Dokument [gemspec_oid]. Die Kennzeichnung des Zertifikatstyps in der Extension AdditionalInformation kann sicherheitsrelevant sein. Es MUSS daher eine entsprechende Schutzbedarfsfeststellung im Rahmen des übergreifenden Sicherheitskonzepts der gematik durchgeführt werden. Die Schutzbedarfsfeststellung MUSS durchgeführt werden. Bis auf die Extension KeyUsage werden alle Extensions auf "nicht kritisch" gesetzt. Dieses ermöglicht den Einsatz der Zertifikate auch außerhalb der TI und innerhalb von ggf. zum Einsatz kommender Standardsoftware. Falls der Wert einer Extension für die Ablaufsteuerung einer Komponente der TI benötigt wird, MUSS diese Komponenten der TI jedoch die Extension korrekt auswerten. Dieses MUSS durch die Ablaufsteuerung dieser Komponenten sichergestellt werden. gematik_pki_x 509_SSL_Monitoring.doc Seite 20 von 42

Registrierungsverfahren für die kryptographische Identität von Server- und (Fach-) Diensten

Registrierungsverfahren für die kryptographische Identität von Server- und (Fach-) Diensten Einführung der Gesundheitskarte Registrierungsverfahren für die kryptographische Identität von Server- und (Fach-) Diensten Version: 1.2.0 Revision: main/rel_main/32 Stand: 01.07.2008 Status: freigegeben

Mehr

Einführung der Gesundheitskarte Verwendung von Zertifikaten in der Telematikinfrastruktur

Einführung der Gesundheitskarte Verwendung von Zertifikaten in der Telematikinfrastruktur Einführung der Gesundheitskarte Verwendung von Zertifikaten in der Telematikinfrastruktur Version: 1.2.0 Revison: main/rel_main/21 Stand: 16.07.2008 Status: freigegeben gematik_pki_verwendung_zertifikate_der_ti.doc

Mehr

PKI und X.509 Zertifikatsprofile Beschreibung eines Konzepts zur Erstellung und Verwaltung von X.509 Zertifikaten

PKI und X.509 Zertifikatsprofile Beschreibung eines Konzepts zur Erstellung und Verwaltung von X.509 Zertifikaten PKI und X.509 Zertifikatsprofile Beschreibung eines Konzepts zur Erstellung und Verwaltung von X.509 Zertifikaten Editor: Olaf Rode Dokumenten-ID: PKI und X.509 Zertifikatsprofile Verantwortlich: Fraunhofer

Mehr

IT-Sicherheit WS 2012/13. Übung 5. zum 28. November 2012

IT-Sicherheit WS 2012/13. Übung 5. zum 28. November 2012 Prof. Dr. C. Eckert Thomas Kittel IT-Sicherheit WS 2012/13 Übung 5 zum 28. November 2012 Institut für Informatik Lehrstuhl für Sicherheit in der Informatik 1 X.509-Zertifikate Zertifikate nach dem X.509-Standard

Mehr

Gültigkeitsmodell der elektronischen Arztausweise und Laufzeit der Zertifikate

Gültigkeitsmodell der elektronischen Arztausweise und Laufzeit der Zertifikate Seite 1 von 6 Autor: G. Raptis Gültigkeitsmodell der elektronischen Arztausweise und Laufzeit der Zertifikate Gültigkeitsmodelle beschreiben den Algorithmus nach dem ein Client oder Dienst entscheidet,

Mehr

X.509-Zertifikate mit OpenSSL Mario Lorenz mailto:ml@vdazone.org. 18. November 2002

X.509-Zertifikate mit OpenSSL Mario Lorenz mailto:ml@vdazone.org. 18. November 2002 X.509-Zertifikate mit OpenSSL Mario Lorenz mailto:ml@vdazone.org 18. November 2002 1 Grundlagen Wir nehmen an, dass mathematische Algorithmen zur sicheren Verschlüsselung und zur Signatur verfügbar seien

Mehr

PKI für CV-Zertifikate

PKI für CV-Zertifikate Einführung der Gesundheitskarte PKI für CV-Zertifikate Registrierung einer CVC-CA der zweiten Ebene Version: 1.5.0 Stand: 18.03.2008 Status: freigegeben gematik_pki_cvc_registrierung_subca_v1_5_0.doc Seite

Mehr

Zertifizierungsrichtlinien

Zertifizierungsrichtlinien Zertifizierungsrichtlinien Certification Practice Statement (CPS) Migros Corporate PKI NG-PKI 2014 Interne CA Hierarchie keyon AG Schlüsselstrasse 6 8645 Jona Tel +41 55 220 64 00 www.keyon.ch Switzerland

Mehr

Einführung der Gesundheitskarte Verwendung von Zertifikaten in der Telematikinfrastruktur

Einführung der Gesundheitskarte Verwendung von Zertifikaten in der Telematikinfrastruktur Einführung der Gesundheitskarte Verwendung von Zertifikaten in der Telematikinfrastruktur Version: 1.1.0 Stand: 28.02.2008 Status: freigegeben gematik_pki_verwendung_zertifikate_der_ti_v1.1.0.doc Seite

Mehr

Festlegungen zu den Notationen

Festlegungen zu den Notationen Einführung der Gesundheitskarte Festlegungen zu den Notationen von Schlüsseln und Zertifikaten kryptographischer Objekte in der TI Version: 1.0.0 Stand: 17.03.2008 Status: freigegeben gematik_pki_notationen_schl_und_zert_v1.0.0.doc

Mehr

Erinnerung Public Key Infrastruktur

Erinnerung Public Key Infrastruktur Erinnerung Public Key Infrastruktur Certification Authority (CA) (pk CA, sk CA ) Nutzer 1 (pk 1, sk 1 ), C 1 Nutzer n (pk n, sk n ), C n Angaben zum Nutzer: Name, Organisation, usw. C i = öff. Schl. pk

Mehr

Für die Ausgabe der Zertifikate betreibt die Hochschule Ulm eine Registrierungsstelle (RA).

Für die Ausgabe der Zertifikate betreibt die Hochschule Ulm eine Registrierungsstelle (RA). Inhaltsverzeichnis 1 Einleitung...2 1.1 Identifikation des Dokuments...2 2. Zertifikate...2 2.2 Server-Zertifikate...2 2.2.1 Antrag...2 2.2.1.1 Erzeugung des Antrags...3 2.2.1.1.1 Erzeugung des Antrags

Mehr

SIC CA Zertifizierungsrichtlinien Certificate Practice Statement (CPS) der SIC Customer ID CA 1024 Level 2

SIC CA Zertifizierungsrichtlinien Certificate Practice Statement (CPS) der SIC Customer ID CA 1024 Level 2 SIC CA Zertifizierungsrichtlinien Certificate Practice Statement (CPS) der SIC Customer ID CA 1024 Level 2 Version 2.2 / Dezember 2012 1 Hinweise Die in diesem Dokument enthaltenen Angaben sind ohne Gewähr

Mehr

Kleines SSL Handbuch. Inhaltsverzeichnis. Daniel Klaenbach 18.07.2007. 1 Einleitung 2

Kleines SSL Handbuch. Inhaltsverzeichnis. Daniel Klaenbach 18.07.2007. 1 Einleitung 2 Kleines SSL Handbuch Daniel Klaenbach 18.07.2007 Inhaltsverzeichnis 1 Einleitung 2 2 Selbstsignierte Zertikate erstellen 3 2.1 Einen privaten Schlüssel erstellen.................................... 3 2.1.1

Mehr

X.509v3 Zertifizierungsinstanz der Universität Würzburg

X.509v3 Zertifizierungsinstanz der Universität Würzburg X.509v3 Zertifizierungsinstanz der Universität Würzburg Markus Krieger Rechenzentrum Uni Würzburg ca@uni-wuerzburg.de 22.01.06 1 Notwendigkeit von Zertifikaten Steigende Anzahl von Kommunikationsbeziehungen

Mehr

LDAP für PKI. von. Marc Saal

LDAP für PKI. von. Marc Saal LDAP für PKI von Inhalt - Einführung - Die Infrastruktur - Benötigte Objektklassen - Aufbau der Einträge in den Objektklassen - Quiz - Literatur Einführung PKI: System, welches es ermöglicht, digitale

Mehr

1. IKEv2 zwischen Windows 7 und Gateway mit Zertifikaten (PKCS#12)

1. IKEv2 zwischen Windows 7 und Gateway mit Zertifikaten (PKCS#12) 1. IKEv2 zwischen Windows 7 und Gateway mit Zertifikaten (PKCS#12) 1.1 Einleitung Im Folgenden wird die Konfiguration einer IPSec-Verbindung mit IKEv2 von einem Windows 7 Rechner zum bintec IPSec-Gateway

Mehr

Programmiertechnik II

Programmiertechnik II X.509: Eine Einführung X.509 ITU-T-Standard: Information Technology Open Systems Interconnection The Directory: Public Key and attribute certificate frameworks Teil des OSI Directory Service (X.500) parallel

Mehr

Public-Key-Infrastrukturen

Public-Key-Infrastrukturen TECHNISCHE UNIVERSITÄT DARMSTADT FACHGEBIET THEORETISCHE INFORMATIK PROF. DR. J. BUCHMANN DR. A. WIESMAIER 9. Übung zur Vorlesung Public-Key-Infrastrukturen Sommersemester 2011 Aufgabe 1: Indirekte CRL

Mehr

Anleitung zur Nutzung von OpenSSL in der DFN-PKI

Anleitung zur Nutzung von OpenSSL in der DFN-PKI Anleitung zur Nutzung von OpenSSL in der DFN-PKI Kontakt: Allgemeine Fragen zur DFN-PKI: Technische Fragen zur DFN-PKI: pki@dfn.de dfnpca@dfn-cert.de DFN-Verein, Januar 2008; Version 1.2 Seite 1 1 OpenSSL

Mehr

Internet Security: Verfahren & Protokolle

Internet Security: Verfahren & Protokolle Internet Security: Verfahren & Protokolle 39 20 13 Vorlesung im Grundstudium NWI (auch MGS) im Sommersemester 2003 2 SWS, Freitag 10-12, H10 Peter Koch pk@techfak.uni-bielefeld.de 30.05.2003 Internet Security:

Mehr

Containerformat Spezifikation

Containerformat Spezifikation Containerformat Spezifikation Version 1.0-09.05.2011 Inhaltsverzeichnis 0 Einführung... 4 0.1 Referenzierte Dokumente... 4 0.2 Abkürzungen... 4 1 Containerformat... 5 1.1 Aufbau des Container-Headers...

Mehr

Erklärung zum Zertifizierungsbetrieb der TU Dortmund Chipcard CA in der DFN-PKI. - Sicherheitsniveau: Global -

Erklärung zum Zertifizierungsbetrieb der TU Dortmund Chipcard CA in der DFN-PKI. - Sicherheitsniveau: Global - Erklärung zum Zertifizierungsbetrieb der TU Dortmund Chipcard CA in der DFN-PKI - Sicherheitsniveau: Global - Technische Universität Dortmund CPS der TU Dortmund Chipcard CA V1.3 01.10.2011 1 Einleitung

Mehr

Die Zertifizierungsstelle der TÜV Informationstechnik GmbH bescheinigt hiermit dem Unternehmen

Die Zertifizierungsstelle der TÜV Informationstechnik GmbH bescheinigt hiermit dem Unternehmen Die Zertifizierungsstelle der TÜV Informationstechnik GmbH bescheinigt hiermit dem Unternehmen D-TRUST GmbH Kommandantenstraße 15 10969 Berlin für den Zertifizierungsdienst D-TRUST SSL Class 3 CA 1 EV

Mehr

Gemeinsame Zertifizierungs- Richtlinie für Teilnehmer der gematik- TSL zur Herausgabe von X.509-

Gemeinsame Zertifizierungs- Richtlinie für Teilnehmer der gematik- TSL zur Herausgabe von X.509- Einführung der Gesundheitskarte - Certificate Policy - Gemeinsame Zertifizierungs- Richtlinie für Teilnehmer der gematik- TSL zur Herausgabe von X.509- ENC/AUT/OSIG-Zertifikaten Version: 1.0.0 Stand: 16.10.2006

Mehr

Digitale Signatur. Digitale Signatur. Anwendungen der Kryptographie. Secret Sharing / Splitting. Ziele SSL / TLS

Digitale Signatur. Digitale Signatur. Anwendungen der Kryptographie. Secret Sharing / Splitting. Ziele SSL / TLS Digitale Signatur Digitale Signatur kombiniert Hash Funktion und Signatur M, SIGK(HASH(M)) wichtige Frage: Wie wird der Bithaufen M interpretiert Struktur von M muss klar definiert sein Wie weiss ich,

Mehr

Gemeinsame Zertifizierungs- Richtlinie für Teilnehmer der gematik- TSL zur Herausgabe von X.509-

Gemeinsame Zertifizierungs- Richtlinie für Teilnehmer der gematik- TSL zur Herausgabe von X.509- Einführung der Gesundheitskarte - Certificate Policy - Gemeinsame Zertifizierungs- Richtlinie für Teilnehmer der gematik- TSL zur Herausgabe von X.509- ENC/AUT/OSIG-Zertifikaten Version: 1.3.0 Revision:

Mehr

OFTP2 - Checkliste für die Implementierung

OFTP2 - Checkliste für die Implementierung connect. move. share. Whitepaper OFTP2 - Checkliste für die Implementierung Die reibungslose Integration des neuen Odette-Standards OFTP2 in den Datenaustausch- Workflow setzt einige Anpassungen der Systemumgebung

Mehr

E-Mail-Verschlüsselung mit Geschäftspartnern

E-Mail-Verschlüsselung mit Geschäftspartnern E-Mail-Verschlüsselung mit (Anleitung für Geschäftspartner) Datum: 13.07.2011 Dokumentenart: Anwenderbeschreibung Version: 3.0 : Redaktionsteam PKI cio.siemens.com Inhaltsverzeichnis 1. Zweck des Dokumentes:...3

Mehr

Hinweise zur Security Schnittstelle für das Gesundheitswesen

Hinweise zur Security Schnittstelle für das Gesundheitswesen Hinweise zur Security Schnittstelle Hinweise der Schnittstellen für die Übermittlung von verschlüsselten und signierten Nachrichten Stand der Spezifikation: 01.04.2012 Version: 2.1.1 Herausgeber: Redaktion:

Mehr

Sichere Identitäten in Smart Grids

Sichere Identitäten in Smart Grids Informationstag "IT-Sicherheit im Smart Grid" Berlin, 23.05.2012 Sichere Identitäten in Smart Grids Dr. Thomas Störtkuhl, Agenda 1 2 Beispiele für Kommunikationen Digitale Zertifikate: Basis für Authentifizierung

Mehr

Fachhochschule Frankfurt am Main Fachbereich 2: Informatik WS 2008/2009. IT-Security. Teil 2: Zertifikate, X.509, PKI Dr.

Fachhochschule Frankfurt am Main Fachbereich 2: Informatik WS 2008/2009. IT-Security. Teil 2: Zertifikate, X.509, PKI Dr. Fachhochschule Frankfurt am Main Fachbereich 2: Informatik WS 2008/2009 IT-Security Teil 2: Zertifikate, X.509, PKI Dr. Erwin Hoffmann E-Mail: it-security@fehcom.de Einsatz von Zertifikaten Ein Zertifikat

Mehr

Containerformat Spezifikation

Containerformat Spezifikation Containerformat Spezifikation Version 1.1-21.02.2014 Inhaltsverzeichnis 0 Einführung... 4 0.1 Referenzierte Dokumente... 4 0.2 Abkürzungen... 4 1 Containerformat... 5 1.1 Aufbau des Container-Headers...

Mehr

Hinweise zur Security Schnittstelle für das Gesundheitswesen Version 1.5

Hinweise zur Security Schnittstelle für das Gesundheitswesen Version 1.5 Gesundheitswesen Version 1.5 Hinweise zur Security Schnittstelle für das Gesundheitswesen Version 1.5 Hinweise der Schnittstellen für die Übermittlung von verschlüsselten und signierten Nachrichten Stand

Mehr

Beantragung eines Softwarezertifikates für das EGVP-Backend

Beantragung eines Softwarezertifikates für das EGVP-Backend Beantragung eines Softwarezertifikates für das EGVP-Backend Anleitung Version 1.3 Stand 23.10.2009 Landesbetrieb für Statistik und Kommunikationstechnologie Niedersachsen (LSKN) Fachgebiet 243 Beratung

Mehr

Die Zertifizierungsstelle der TÜV Informationstechnik GmbH bescheinigt hiermit dem Unternehmen

Die Zertifizierungsstelle der TÜV Informationstechnik GmbH bescheinigt hiermit dem Unternehmen Die Zertifizierungsstelle der TÜV Informationstechnik GmbH bescheinigt hiermit dem Unternehmen TC TrustCenter GmbH Sonninstraße 24-28 20097 Hamburg für den Zertifizierungsdienst TC TrustCenter Class 2

Mehr

2 Public Key Infrastruktur (PKI)

2 Public Key Infrastruktur (PKI) 3827315670 Sicherheit und Kryptographie in Java 2 Public Key Infrastruktur (PKI)... Als ihm der Bäcker die Pfote bestrichen hatte, lief er zum Müller und sprach:»streu mir weißes Mehl auf meine Pfote!«Der

Mehr

Einführung der Gesundheitskarte Verwendung kryptographischer Algorithmen in der Telematikinfrastruktur

Einführung der Gesundheitskarte Verwendung kryptographischer Algorithmen in der Telematikinfrastruktur Einführung der Gesundheitskarte Verwendung kryptographischer Algorithmen in der Version: 1.3.0 Stand: 26.03.2008 Status: freigegeben gematik_ga_spezifikation_kryptographischer_algorithmen_v1_3_0.doc Seite

Mehr

Smart Metering PKI - Public Key Infrastruktur für Smart Meter Gateways

Smart Metering PKI - Public Key Infrastruktur für Smart Meter Gateways Technische Richtlinie BSI TR-03109-4 Smart Metering PKI - Public Key Infrastruktur für Smart Meter Gateways Version 1.1.1 Datum: 18.05.15 Bundesamt für Sicherheit in der Informationstechnik Postfach 20

Mehr

Karlsruher IT-Sicherheitsinitiative - 26. April 2001. "For your eyes only" Sichere E-Mail in Unternehmen. Dr. Dörte Neundorf neundorf@secorvo.

Karlsruher IT-Sicherheitsinitiative - 26. April 2001. For your eyes only Sichere E-Mail in Unternehmen. Dr. Dörte Neundorf neundorf@secorvo. Karlsruher IT-Sicherheitsinitiative - 26. April 2001 "For your eyes only" Sichere E-Mail in Unternehmen Dr. Dörte Neundorf neundorf@secorvo.de Secorvo Security Consulting GmbH Albert-Nestler-Straße 9 D-76131

Mehr

Attribut Kürzel Beispiele Bemerkungen Country Name C DE bitte Großbuchstaben State or Province Name ST Nordrhein-Westfalen

Attribut Kürzel Beispiele Bemerkungen Country Name C DE bitte Großbuchstaben State or Province Name ST Nordrhein-Westfalen Erzeugen eines externen Schlüssels außerhalb des Browsers für Nutzerzertifikate Sollten bei Ihnen Abhängigkeiten zwischen ihrem privaten Schlüsselteil und verwendeter Hardware und oder Software bestehen,

Mehr

Einführung in OpenSSL und X.509-Zertifikate. Martin Kaiser http://www.kaiser.cx/

Einführung in OpenSSL und X.509-Zertifikate. Martin Kaiser http://www.kaiser.cx/ Einführung in OpenSSL und X.509-Zertifikate Martin Kaiser http://www.kaiser.cx/ Über mich Elektrotechnik-Studium Uni Karlsruhe System-Ingenieur UNIX und IP-Netze (2001-2003) Embedded Software-Entwicklung

Mehr

E-Mail-Verschlüsselung Vorrausetzungen

E-Mail-Verschlüsselung Vorrausetzungen E-Mail-Verschlüsselung Vorrausetzungen Datum: 09.08.2011 Dokumentenart: Anwenderbeschreibung Version: 2.0 : Redaktionsteam PKI cio.siemens.com Inhaltsverzeichnis 1. Zweck des Dokumentes:...3 2. Voraussetzungen...4

Mehr

Studentenzertifikate für Online-Dienste der Fachhochschule Landshut

Studentenzertifikate für Online-Dienste der Fachhochschule Landshut Studentenzertifikate für Online-Dienste der Fachhochschule Landshut Die FH Landshut CA Entstanden aus einem Studienprojekt des Fachbereichs Informatik Start Sommersemester 2001 Ziel: CA für FH-Server,

Mehr

Merkblatt: HSM. Version 1.01. Systemvoraussetzungen, Setup und Trouble Shooting. pdfsupport@pdf-tools.com

Merkblatt: HSM. Version 1.01. Systemvoraussetzungen, Setup und Trouble Shooting. pdfsupport@pdf-tools.com Merkblatt: HSM Version 1.01 Systemvoraussetzungen, Setup und Trouble Shooting Kontakt: pdfsupport@pdf-tools.com Besitzer: PDF Tools AG Kasernenstrasse 1 8184 Bachenbülach Schweiz www.pdf-tools.com Copyright

Mehr

Einsatz von Public Key Infrastrukturen in großen heterogenen Organisationen. Christoph Thiel

Einsatz von Public Key Infrastrukturen in großen heterogenen Organisationen. Christoph Thiel Einsatz von Public Key Infrastrukturen in großen heterogenen Organisationen Christoph Thiel Stuttgart, 4. November 2014 Das extented enterprise SSL E-Mail Grundlegende Sicherheitsanforderungen Authentisierung

Mehr

Trustcenter der Deutschen Rentenversicherung

Trustcenter der Deutschen Rentenversicherung Trustcenter der Deutschen Rentenversicherung Certificate Policy und Certification Practice Statement für nicht-qualifizierte Serverzertifikate der Wurzelzertifizierungsstelle der Deutschen Rentenversicherung

Mehr

Systemsicherheit 14: PKI Teil 2

Systemsicherheit 14: PKI Teil 2 Systemsicherheit 14: PKI Teil 2 Gliederung Einführung Zertifikate X.509-Zertifikatsprofile (S/MIME, SSL, SigG) Identität und LDAP Erweiterungen Key Usage, Extended Key Usage, und Netscape cert-type Basic

Mehr

Variabler Parameter, der in der Implementierung und Betriebsphase definiert wird. z.b. [fqdn] kann durch www.f-i-ts.de ersetzt werden.

Variabler Parameter, der in der Implementierung und Betriebsphase definiert wird. z.b. [fqdn] kann durch www.f-i-ts.de ersetzt werden. RICHTLINIE Zertifikate im FITS Trustcenter Dokumentenverantwortliche(r): Tauber, Matthias 1 Ziel Diese Zertifikatsrichtlinie enthält zusammen mit der Zertifizierungsrichtline im FI-TS- Trustcenter die

Mehr

Stammtisch 04.12.2008. Zertifikate

Stammtisch 04.12.2008. Zertifikate Stammtisch Zertifikate Ein Zertifikat ist eine Zusicherung / Bestätigung / Beglaubigung eines Sachverhalts durch eine Institution in einem definierten formalen Rahmen 1 Zertifikate? 2 Digitale X.509 Zertifikate

Mehr

Literatur. ISM SS 2015 - Teil 18/PKI-2

Literatur. ISM SS 2015 - Teil 18/PKI-2 Literatur [18-1] Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile http://tools.ietf.org/html/rfc5280 [18-2] Verifikation digitaler Signaturen http://www.informatik.tu-darmstadt.de/

Mehr

1. Sept. 2010. Über Keyon

1. Sept. 2010. Über Keyon Über Keyon 1 Eidgenössisches Volkswirtschaftsdepartement EVD Staatssekretariat für Wirtschaft SECO 1. September 2010, Zürich eberhard@keyon.ch 3 SuisseID: Kurz-Steckbrief Die SuisseID ist: ein ZertES-konformes

Mehr

Zertifizierungsrichtlinie der bw-trust Basic-CA. Version 1.0

Zertifizierungsrichtlinie der bw-trust Basic-CA. Version 1.0 Seite 1 Version 1.0 1 Einleitung... 3 1.1 Überblick... 3 1.2 Identifikation des Dokuments... 3 1.3 Beschreibung und Teilnehmer der PKI... 3 1.3.1 Zertifizierungsstelle (certification authority)... 3 1.3.2

Mehr

VR-Ident Certification Practice Statement (CPS)

VR-Ident Certification Practice Statement (CPS) VR-Ident Certification Practice Statement (CPS) für VR-Ident SSL Zertifikate Version: 1 Status: Final Veröffentlicht am: 19. Mai 2011 Author: GAD eg, Frank Fischer, Gerald Scheer Zertifizierungsdienst

Mehr

Erklärung zum Zertifizierungsbetrieb der GRS CA in der DFN-PKI

Erklärung zum Zertifizierungsbetrieb der GRS CA in der DFN-PKI Erklärung zum Zertifizierungsbetrieb der GRS CA in der DFN-PKI - Sicherheitsniveau: Global - Gesellschaft für Anlagen- und Reaktorsicherheit (GRS) mbh CPS der GRS CA V2.1 12.07.2011 CPS der GRS CA Seite

Mehr

Nutzungsbedingungen ETCS Seite 1 von 7

Nutzungsbedingungen ETCS Seite 1 von 7 Anlage 3.3.1 zu den Schienennetz-Benutzungsbedingungen der DB Netz AG 2016 Nutzungsbedingungen ETCS Seite 1 von 7 (1) Einleitung Um Fahrzeugen Fahrten im ETCS Level 2 zu ermöglichen müssen ETCS-Fahrzeuggeräte

Mehr

E-Mail-Verschlüsselung mit Geschäftspartnern

E-Mail-Verschlüsselung mit Geschäftspartnern E-Mail-Verschlüsselung mit (Anleitung für Geschäftspartner) Datum: 15.07.2013 Dokumentenart: Anwenderbeschreibung Version: 3.2 : Redaktionsteam PKI cio.siemens.com Inhaltsverzeichnis 1. Zweck des Dokumentes:...

Mehr

UH-CA: Zertifikate für digitale Signaturen und Verschlüsselung an der Universität Hannover

UH-CA: Zertifikate für digitale Signaturen und Verschlüsselung an der Universität Hannover UH-CA: Zertifikate für digitale Signaturen und Verschlüsselung an der Universität Hannover Sicherheitstage WS 04/05 Birgit Gersbeck-Schierholz, RRZN Einleitung und Überblick Warum werden digitale Signaturen

Mehr

E-Mail-Verschlüsselung mit Geschäftspartnern

E-Mail-Verschlüsselung mit Geschäftspartnern E-Mail-Verschlüsselung mit (Anleitung für Siemens Mitarbeiter) Datum: 13.07.2011 Dokumentenart: Anwenderbeschreibung Version: 3.0 : Redaktionsteam PKI cio.siemens.com Inhaltsverzeichnis 1. Zweck des Dokumentes:...3

Mehr

Certification Practice Statement

Certification Practice Statement Certification Practice Statement Revision R1 2013-01-09 1 Copyright Druckdatum: 9. Januar 2013 Dieses Dokument ist das geistige Eigentum der Salzburger Banken Software. Die Vervielfältigung sowie Verteilung

Mehr

Certificate Policy (CP) VR-Ident Zertifikate (WebTrust)

Certificate Policy (CP) VR-Ident Zertifikate (WebTrust) Version: Zielgruppe: Datum/Uhrzeit: Version 2.01.00, Freigegeben Nutzer und Besitzer von / 13:32 Uhr Gegenüber der vorherigen Ausgabe wurden folgende Änderungen vorgenommen: Nummer 2.0 Datum 30.04.2013

Mehr

ELMA5-Verfahren. Benutzerleitfaden zur Massendatenschnittstelle des BZSt

ELMA5-Verfahren. Benutzerleitfaden zur Massendatenschnittstelle des BZSt ELMA5-Verfahren Benutzerleitfaden zur Massendatenschnittstelle des BZSt Stand: 08.03.2013 Seite 1 von 12 Inhaltsverzeichnis 1 Einleitung... 3 2 Voraussetzungen... 3 3 Dienste zur Teilnahme am ELMA5-Verfahren

Mehr

Certification Practice Statement (CPS) VR-Ident SSL-Zertifikate (WebTrust)

Certification Practice Statement (CPS) VR-Ident SSL-Zertifikate (WebTrust) Version: Zielgruppe: Datum/Uhrzeit: Version 2.01.00, Freigegeben Nutzer und Besitzer von / 13:32 Uhr Gegenüber der vorherigen Ausgabe wurden folgende Änderungen vorgenommen: Nummer 2.0 Datum 30.04.2013

Mehr

(HTTPS) Hypertext Transmission Protokol Secure

(HTTPS) Hypertext Transmission Protokol Secure (HTTPS) Hypertext Transmission Protokol Secure HTTPS steht für HyperText Transfer Protocol Secure (dt. sicheres Hypertext- Übertragungsprotokoll) und ist ein Verfahren, um Daten im WWW abhörsicher zu übertragen.

Mehr

Hinweise zum Erstellen eines Verfahrensverzeichnisses

Hinweise zum Erstellen eines Verfahrensverzeichnisses Hinweise zum Erstellen eines Verfahrensverzeichnisses Eine Information des Datenschutzbeauftragten der PH Freiburg Stand: 11.03.2010 Inhalt Hinweise zum Erstellen eines Verfahrensverzeichnisses... 1 Vorbemerkung...

Mehr

Dokumentation Mail-Test

Dokumentation Mail-Test Dokumentation Mail-Test 1. Verschicken vordefinierter E-Mails... 1 Zweck des Testmailservice... 1 Fingerprint... 2 Explizit/Implizit Signed Mails... 2 Attachment... 3 "A mail with a signed attachment -

Mehr

Netzwerksicherheit Übung 5 Transport Layer Security

Netzwerksicherheit Übung 5 Transport Layer Security Netzwerksicherheit Übung 5 Transport Layer Security Tobias Limmer, Christoph Sommer, David Eckhoff Computer Networks and Communication Systems Dept. of Computer Science, University of Erlangen-Nuremberg,

Mehr

- Sicherheitsniveau: Global -

- Sicherheitsniveau: Global - Erklärung zum Zertifizierungsbetrieb der FH-D-CA in der DFN-PKI - Sicherheitsniveau: Global - Fachhochschule Düsseldorf CPS der FH-D-CA V2.1 15.02.2007 CPS der FH-D-CA Seite 2/6 V2.1 1 Einleitung Die FH-D-CA

Mehr

D2D-Anmeldung. Merkblatt für Arztpraxen zur D2D-Registrierung

D2D-Anmeldung. Merkblatt für Arztpraxen zur D2D-Registrierung Kassenärztliche Vereinigung Niedersachsen Unsere gebührenfreie IT-Servicehotline für Sie: 0800 5 10 10 25 Unsere Servicezeit für Sie: Mo.-Fr.: 08:00 h 18:00 h Serviceanfrage per email: it-service@kvn.de

Mehr

Zertifizierungsstelle für Kontakte der Fraunhofer-Gesellschaft PKI-Contacts

Zertifizierungsstelle für Kontakte der Fraunhofer-Gesellschaft PKI-Contacts Zertifizierungsstelle für Kontakte der Fraunhofer-Gesellschaft PKI-Contacts Richtlinien für die Beantragung und Nutzung von Zertifikaten Version 1.0 Fraunhofer Competence Center PKI Kontakt: Fraunhofer

Mehr

Benutzerzertifikate für Java Webstart

Benutzerzertifikate für Java Webstart Benutzerzertifikate für Java Webstart Benutzerdokumentation Wien 5. Dezember 2011 Florian Bruckner, Florian Heinisch 3kraft IT GmbH & Co KG Wasagasse 26/2 1090 Wien Österreich Tel: +43 1 920 45 49 Fax

Mehr

VPN KickStart. Eine Schritt-für-Schritt Anleitung für das sichere Verbinden zweier Netzwerke durch ein mguard basierendes IPsec-VPN

VPN KickStart. Eine Schritt-für-Schritt Anleitung für das sichere Verbinden zweier Netzwerke durch ein mguard basierendes IPsec-VPN VPN KickStart Eine Schritt-für-Schritt Anleitung für das sichere Verbinden zweier Netzwerke durch ein mguard basierendes IPsec-VPN Der VPN-Aufbau - Zwischen dem Firmennetz (erreichbar unter der IP-Adresse

Mehr

SSL Algorithmen und Anwendung

SSL Algorithmen und Anwendung SSL Algorithmen und Anwendung Stefan Pfab sisspfab@stud.uni-erlangen.de Abstract Viele Anwendungen erfordern nicht nur eine eindeutige und zuverlässige Identifizierung der an einer Kommunikation beteiligten

Mehr

greenitblue CRM-Mailsystem

greenitblue CRM-Mailsystem greenitblue CRM-Mailsystem Das teamfähige Mailsystem zur Abwicklung und Dokumentation Ihrer Kommunikationsprozesse Steffen Pöllot. Hans-Günter Stein Dieses Dokument dient ausschließlich zur Information

Mehr

Bedienungsanleitung für PolterPhones (Smartphones ohne Touchscreen) Inhaltsverzeichnis

Bedienungsanleitung für PolterPhones (Smartphones ohne Touchscreen) Inhaltsverzeichnis Bedienungsanleitung für PolterPhones (Smartphones ohne Touchscreen) Inhaltsverzeichnis 1. Allgemeines... 2 1.1 Einschalten... 2 1.2 Polter Programm starten... 2 1.3 Info Anzeige... 2 1.4 Haupt Fenster...

Mehr

Qualifizierte Signaturkarten

Qualifizierte Signaturkarten Seite 1/5 Qualifizierte Signaturkarten» Standardsignaturkarten Qualifizierte D-TRUST Card 2048 Bit*, SHA-256 Signaturkarte mit qualifiziertem Zertifikat zum Signieren von elektronischen Daten und fortgeschrittenem

Mehr

Fragen und Antworten zur Vereinfachung der elektronischen Rechnungsstellung

Fragen und Antworten zur Vereinfachung der elektronischen Rechnungsstellung 2011/0604162 IV D 2 - S 7287-a/09/10004 26. Juli 2011 Fragen und Antworten zur Vereinfachung der elektronischen Rechnungsstellung Durch das Steuervereinfachungsgesetz 2011 sollen durch Änderungen im Umsatzsteuergesetz

Mehr

Vorlesung IT-Sicherheit FH Frankfurt Sommersemester 2007

Vorlesung IT-Sicherheit FH Frankfurt Sommersemester 2007 Vorlesung IT-Sicherheit FH Frankfurt Sommersemester 2007 Dr. Volker Scheidemann Digitale Zertifikate Public Key Infrastrukturen (PKI) Sicherheitsprozesse Seite: 2 Gefahr bei PKC: Die Man in the Middle-Attacke

Mehr

Daten-Kommunikation mit crossinx

Daten-Kommunikation mit crossinx Daten-Kommunikation mit Datenübertragung.doc Seite 1 von 8 Inhaltsverzeichnis 1 Einführung... 3 1.1 Datenübertragung an... 3 1.2 Datenversand durch... 3 2 X.400... 4 3 AS2... 4 4 SFTP (mit fester Sender

Mehr

Spezifikationen und Voraussetzung

Spezifikationen und Voraussetzung Projekt IGH DataExpert Paynet Adapter Spezifikationen Voraussetzungen Datum : 21.07.08 Version : 1.0.0.2 21.07.2008 Seite 1 von 7 Inhaltsverzeichnis 1 Einleitung... 3 2 Architektur... 3 2.1 Grundsätze

Mehr

Zertifizierungsrichtlinie der HvS PKI Version 1.0 vom 22.01.2013

Zertifizierungsrichtlinie der HvS PKI Version 1.0 vom 22.01.2013 Zertifizierungsrichtlinie der HvS PKI HvS-Consulting AG Seite 1 von 30 Freigabe Datum Erstellt: Marc Ströbel Technical Security Consultant HvS-Consulting AG Genehmigt: Michael Hochenrieder Vorstand HvS-Consulting

Mehr

Zertifizierungsrichtlinie für die T-Systems Trust Center Public Key Infrastrukturen

Zertifizierungsrichtlinie für die T-Systems Trust Center Public Key Infrastrukturen Zertifizierungsrichtlinie für die T-Systems Trust Center Public Key Infrastrukturen Certificate Policy, CP Version: 1.5 Stand: 17.04.2009 Status: Freigegeben Impressum Herausgeber T-Systems Enterprise

Mehr

Allgemeine und technische Anforderungen an das Replikat

Allgemeine und technische Anforderungen an das Replikat ===== "=== Allgemeine und technische Anforderungen an das Version: 1.2 Gültig ab: 09.03.2011 Stand: 09.03.2011 Version1.2; Stand: 09.03.2011 Seite 1 von 14 Inhaltsverzeichnis Allgemeine und technische

Mehr

S Sparkasse. UnnaKamen. Secure Mail Notwendigkeit?

S Sparkasse. UnnaKamen. Secure Mail Notwendigkeit? S Sparkasse UnnaKamen Secure Mail Notwendigkeit? Das sogenannte Sniffen, Ausspähen von E-Mailinhalten und Authentifizierungsdateien sowie das E-Mail Spoofing, das Erstellen einer E-Mail mit gefälschtem

Mehr

SSL/TLS und SSL-Zertifikate

SSL/TLS und SSL-Zertifikate SSL/TLS und SSL-Zertifikate Konzepte von Betriebssystem-Komponenten Informatik Lehrstuhl 4 16.06.10 KvBK Wolfgang Hüttenhofer sethur_blackcoat@web.de Motivation Sichere, verschlüsselte End-to-End Verbindung

Mehr

Spezifikationen und Voraussetzung

Spezifikationen und Voraussetzung Projekt IGH DataExpert Yellowbill Adapter Spezifikationen Voraussetzungen Datum : 22.08.2013 Version : 1.0.0.2 22.08.2013 Seite 1 von 7 Inhaltsverzeichnis 1 Einleitung...3 2 Architektur...3 2.1 Grundsätze

Mehr

1 Bedienungsanleitung esignature SSL

1 Bedienungsanleitung esignature SSL 1 Bedienungsanleitung esignature SSL 1.1 esignature SSL beantragen Im Anhang finden Sie die allgemeine Leistungsbeschreibung zu esignature SSL dem Service von Telekom Austria für elektronische Signaturen

Mehr

Konfigurieren der Netzwerksicherheit mit Hilfe von PKI (Public Key Infrastructure)

Konfigurieren der Netzwerksicherheit mit Hilfe von PKI (Public Key Infrastructure) Unterrichtseinheit 5: Konfigurieren der Netzwerksicherheit mit Hilfe von PKI (Public Key Infrastructure) Verschlüsselung mit öffentlichen Schlüsseln ist eine bedeutende Technologie für E- Commerce, Intranets,

Mehr

Anwenderinnen und Anwender im IT-Verbund des Evangelischen Oberkirchenrats Stuttgart

Anwenderinnen und Anwender im IT-Verbund des Evangelischen Oberkirchenrats Stuttgart Evangelischer Oberkirchenrat Gänsheidestraße 4 70184 Stuttgart Bei Rückfragen wenden Sie sich bitte an folgende Nummer: 0711 2149-533 Anwenderinformation des Referats Informationstechnologie Thema Betroffene

Mehr

Anleitung zur Überprüfung der Signatur von Elektronischen Kontoauszügen

Anleitung zur Überprüfung der Signatur von Elektronischen Kontoauszügen Seite 1 Anleitung zur Überprüfung der Signatur von Elektronischen Kontoauszügen Zur Prüfung, ob die qualifizierte Signatur eines elektronischen Kontoauszugs gültig ist, können verschiedene Softwarelösungen

Mehr

Terravis - Hinweise zur Implementierung der SSL-Verbindung

Terravis - Hinweise zur Implementierung der SSL-Verbindung Terravis - Hinweise zur Implementierung der -Verbindung Version: 1.0 Datum: 19.04.2013 Autoren: Claude Eisenhut -Hinweise.docx 19.04.2013 Seite 1/8 Verzeichnis: Einführung... 3 Kontaktpersonen 3 Allgemeines...

Mehr

Auslandszahlungsverkehr im Datenaustausch zwischen Kunde und Bank

Auslandszahlungsverkehr im Datenaustausch zwischen Kunde und Bank Deutsche Bundesbank 60006 Frankfurt am Main Zentralbereich Statistik 069 / 9566-8565 S42-2 Auslandszahlungsverkehr im Datenaustausch zwischen Kunde und Bank (DTAZV) gültig ab 31. Oktober 2009 Stand 15.

Mehr

Informationen zur sicheren E-Mail-Kommunikation. Unternehmensgruppe ALDI SÜD

Informationen zur sicheren E-Mail-Kommunikation. Unternehmensgruppe ALDI SÜD Informationen zur sicheren E-Mail-Kommunikation Unternehmensgruppe ALDI SÜD Sichere E-Mail-Kommunikation Vorwort E-Mail ist heute für Unternehmen ein häufig eingesetztes Kommunikationsmittel, das zum Austausch

Mehr

Einführung der Gesundheitskarte Schemaversion 5.2 VSD - Überblick und Änderungen

Einführung der Gesundheitskarte Schemaversion 5.2 VSD - Überblick und Änderungen Einführung der Gesundheitskarte Schemaversion 5.2 VSD - Version: 1.2.0 Stand: 14.09.2015 Status: freigegeben Klassifizierung: öffentlich Referenzierung: [gemschema_vsdm_5_2] gemschema_vsdm_5_2_v1_2_0.doc

Mehr

z/os Communication Server + Express Logon Facility

z/os Communication Server + Express Logon Facility Qualität unser Service z/os Communication Server + Express Logon Facility Erfahrungsbericht Bernd Daubner, Mainframe Bereitstellung Agenda Funktionsweise ELF Public Key Infrastruktur, Zertifikate Zertifikatsverwaltung

Mehr

Secure Socket Layer (SSL) 1: Allgemeiner Überblick. Gilt für die Geräte: HL-4040CN HL-4050CDN HL-4070CDW DCP-9040CN DCP-9045CDN MFC-9440CN MFC-9840CDW

Secure Socket Layer (SSL) 1: Allgemeiner Überblick. Gilt für die Geräte: HL-4040CN HL-4050CDN HL-4070CDW DCP-9040CN DCP-9045CDN MFC-9440CN MFC-9840CDW Secure Socket Layer (SSL) Gilt für die Geräte: HL-4040CN HL-4050CDN HL-4070CDW DCP-9040CN DCP-9045CDN MFC-9440CN MFC-9840CDW Inhalt 1) Allgemeiner Überblick 2) Kurzer geschichtlicher Rückblick 3) Vorteile

Mehr