Dokumentation DFN-AAI, DFN-PKI und eduroam - de:dfnpki

contact

Anonymous (anonymous@undisclosed.example.com) — 2025-01-27T16:16:44+00:00

2025/01/16 17:51		aktuell
Zeile 12:		Zeile 12:
	Bei Fragen zu Zertifikaterstellung, Konfiguration, Policies, etc. wenden Sie sich bitte an:		Bei Fragen zu Zertifikaterstellung, Konfiguration, Policies, etc. wenden Sie sich bitte an:

-	\|E-Mail: [[dfnpca@dfn-cert.de]] \| \|	+	\|E-Mail: [[ti-services@dfn-cert.de]] \| \|
	\|Telefon: +49 40 808077 580 \| \|		\|Telefon: +49 40 808077 580 \| \|

dfndienste

Anonymous (anonymous@undisclosed.example.com) — 2026-03-30T09:13:11+00:00

2026/02/10 11:39		aktuell
Zeile 17:		Zeile 17:
	1. Für den RADIUS-Server, gegen den sich die User authentifizieren		1. Für den RADIUS-Server, gegen den sich die User authentifizieren

-	2. Für den radsecproxy, der die Kommunikation zur eduroam-Föderation übernimmt	+	2. Für den Radsecproxy, der die Kommunikation zur eduroam-Föderation übernimmt

	Für 1. ist es die eigene Entscheidung jeder Einrichtung, welche PKIs eingesetzt werden. Denkbar sind öffentlich vertraute PKIs wie GÉANT TCS, eigene interne PKIs, DFN-Verein Community PKI o.ä. . Die eingesetzte PKI muss in der Regel auf den Endgeräten Ihrer Nutzenden konfiguriert werden, so dass ein Wechsel gegebenenfalls große Auswirkungen hat. Öffentlich vertraute PKIs machen erfahrungsgemäß am wenigsten Schwierigkeiten auf den Endgeräten der Nutzenden.		Für 1. ist es die eigene Entscheidung jeder Einrichtung, welche PKIs eingesetzt werden. Denkbar sind öffentlich vertraute PKIs wie GÉANT TCS, eigene interne PKIs, DFN-Verein Community PKI o.ä. . Die eingesetzte PKI muss in der Regel auf den Endgeräten Ihrer Nutzenden konfiguriert werden, so dass ein Wechsel gegebenenfalls große Auswirkungen hat. Öffentlich vertraute PKIs machen erfahrungsgemäß am wenigsten Schwierigkeiten auf den Endgeräten der Nutzenden.

-	Für 2. können ausschließlich Zertifikate aus der speziellen eduroam CA zum Einsatz kommen. Die radsecproxy müssen mit Zertifikate aus der eduroam CA ausgestattet werden.	+	Für 2. können ausschließlich Zertifikate aus der speziellen eduroam CA zum Einsatz kommen. Die Radsecproxy müssen mit Zertifikate aus der eduroam CA ausgestattet werden.

-	Informationen zur eduroam CA und den Antragswegen finden Sie unter [[https://doku.tid.dfn.de/de:eduroam:eduroam-ca#wie_wird_ein_eduroam_ca_zertifikat_beantrag]]	+	Informationen zur eduroam CA und den Antragswegen finden Sie unter [[https://doku.tid.dfn.de/de:eduroam:eduroam-ca#beantragung_eines_zertifikats]]

-	GÉANT TCS Zertifikate sind nicht für das Einsatzszenario 2. radsecproy nutzbar.	+	GÉANT TCS Zertifikate sind nicht für das Einsatzszenario "2. Radsecproxy" nutzbar.

	====DFN-AAI====		====DFN-AAI====

dfnpkiglobal

Anonymous (anonymous@undisclosed.example.com) — 2024-02-08T14:42:47+00:00

2026/05/01 08:50	aktuell
Zeile 1:	Zeile 1:
	+	=====DFN-PKI Global=====

	+	Die zentrale Informationsseite zur DFN-PKI Global ist zu finden unter: https://www.pki.dfn.de/policies/informationen

dfnpki_crl_ocsp

Anonymous (anonymous@undisclosed.example.com) — 2024-02-02T15:24:30+00:00

2024/02/02 16:20		aktuell
Zeile 11:		Zeile 11:
	\| DFN-Verein Community-PKI \| [[http://cdp.pca.dfn.de/dfn-verein-community-ca/pub/crl/cacrl.pem\|PEM]], [[http://cdp.pca.dfn.de/dfn-verein-community-ca/pub/crl/cacrl.txt\|TXT]], [[http://cdp.pca.dfn.de/dfn-verein-community-ca/pub/crl/cacrl.der\|DER]] \|		\| DFN-Verein Community-PKI \| [[http://cdp.pca.dfn.de/dfn-verein-community-ca/pub/crl/cacrl.pem\|PEM]], [[http://cdp.pca.dfn.de/dfn-verein-community-ca/pub/crl/cacrl.txt\|TXT]], [[http://cdp.pca.dfn.de/dfn-verein-community-ca/pub/crl/cacrl.der\|DER]] \|
	\| DFN-PKI Grid \| [[http://cdp.pca.dfn.de/grid-root-ca/pub/crl/cacrl.pem\|PEM]], [[http://cdp.pca.dfn.de/grid-root-ca/pub/crl/cacrl.txt\|TXT]], [[http://cdp.pca.dfn.de/grid-root-ca/pub/crl/cacrl.der\|DER]] \|		\| DFN-PKI Grid \| [[http://cdp.pca.dfn.de/grid-root-ca/pub/crl/cacrl.pem\|PEM]], [[http://cdp.pca.dfn.de/grid-root-ca/pub/crl/cacrl.txt\|TXT]], [[http://cdp.pca.dfn.de/grid-root-ca/pub/crl/cacrl.der\|DER]] \|
-	\| DFN-PKI Global \| [[http://cdp.pca.dfn.de/dfn-ca-global-g2/pub/crl/cacrl.pem\|PEM]], [[http://cdp.pca.dfn.de/dfn-ca-global-g2/crl/cacrl.txt\|TXT]], [[http://cdp.pca.dfn.de/dfn-ca-global-g2/pub/crl/cacrl.der\|DER]] \|	+	\| DFN-PKI Global \| [[http://cdp.pca.dfn.de/dfn-ca-global-g2/pub/crl/cacrl.pem\|PEM]], [[http://cdp.pca.dfn.de/dfn-ca-global-g2/pub/crl/cacrl.txt\|TXT]], [[http://cdp.pca.dfn.de/dfn-ca-global-g2/pub/crl/cacrl.der\|DER]] \|

	====OCSP====		====OCSP====

dfnpki_root_certs

Anonymous (anonymous@undisclosed.example.com) — 2024-07-08T10:28:02+00:00

2024/02/02 15:31		aktuell
Zeile 67:		Zeile 67:
	Die DFN VoIP PKI dient ausschließlich der Verifikation der Session Border Controller (SBC) im Rahmen des Dienstes DFNFernsprechen.		Die DFN VoIP PKI dient ausschließlich der Verifikation der Session Border Controller (SBC) im Rahmen des Dienstes DFNFernsprechen.

-	Hinweis: Die VoIP-TK-Anlage der Einrichtungen werden stets mit Zertifikaten aus anderen PKIs betrieben, siehe Dienste-Dokumentation https://www2.dfn.de/dienstleistungen/dfnfernsprechen/zertifikate	+	Hinweis: Die VoIP-TK-Anlage der Einrichtungen werden stets mit Zertifikaten aus anderen PKIs betrieben, siehe [[https://www.dfn.de/wp-content/uploads/2023/04/DFNFernsprechen_Verschluesselung_Stand_Dezember_2022.pdf\|Dienste-Dokumentation für DFN-Fernsprechen]]

	^ CommonName ^ Gültigkeitsende ^ SHA256 Fingerprint \| \|		^ CommonName ^ Gültigkeitsende ^ SHA256 Fingerprint \| \|
	\| DFN VoIP Verschluesselung \| Dec 8 00:00:00 2030 GMT \| A7:43:19:FF:BA:50:5D:BE:14:AF:E8:64:D9:7A:FA:99: DA:F5:43:6F:00:1D:F1:2C:65:16:8C:ED:B6:21:A3:CC \| {{ :de:dfnpki:ca:dfn_voip_verschluesselung.cer \| .cer}} {{ :de:dfnpki:ca:dfn_voip_verschluesselung.pem \| .pem}}\|		\| DFN VoIP Verschluesselung \| Dec 8 00:00:00 2030 GMT \| A7:43:19:FF:BA:50:5D:BE:14:AF:E8:64:D9:7A:FA:99: DA:F5:43:6F:00:1D:F1:2C:65:16:8C:ED:B6:21:A3:CC \| {{ :de:dfnpki:ca:dfn_voip_verschluesselung.cer \| .cer}} {{ :de:dfnpki:ca:dfn_voip_verschluesselung.pem \| .pem}}\|

dfnvereincommunitypki

Anonymous (anonymous@undisclosed.example.com) — 2024-09-09T11:25:01+00:00

2024/02/02 15:30		aktuell
Zeile 1:		Zeile 1:
	====== DFN-Verein Community-PKI ======		====== DFN-Verein Community-PKI ======
-	Neben der selbstverständlichen Nutzung von Zertifikaten mit Browser- und Betriebssystemverankerung aus GÉANT TCS hat auch der Einsatz von PKIs ohne Verankerung seine Berechtigung.Vorteile:	+	Neben der selbstverständlichen Nutzung von Zertifikaten mit Browser- und Betriebssystemverankerung aus GÉANT TCS hat auch der Einsatz von PKIs ohne Verankerung seine Berechtigung. Vorteile:

	* Laufzeit kann länger gewählt werden		* Laufzeit kann länger gewählt werden

esig

Anonymous (anonymous@undisclosed.example.com) — 2025-04-07T15:20:02+00:00

2024/02/01 15:51		aktuell
Zeile 7:		Zeile 7:

	* {{:de:dfnpki:dokumentensignatur_2022.pdf \|Technische und rechtliche Aspekte bei Dokumentensignaturen}}		* {{:de:dfnpki:dokumentensignatur_2022.pdf \|Technische und rechtliche Aspekte bei Dokumentensignaturen}}
-
-	* [[:de:dfnpki:tcs:documentsigning\|Dokumentensignatur in GÉANT TCS]]

	* [[:de:dfnpki:dfnvereincommunitypki:documentsigning\|Dokumentensignatur in der DFN-Verein Community-PKI]]		* [[:de:dfnpki:dfnvereincommunitypki:documentsigning\|Dokumentensignatur in der DFN-Verein Community-PKI]]

faqemailvalidierung

Anonymous (anonymous@undisclosed.example.com) — 2024-01-19T09:18:03+00:00

2026/05/01 08:50	aktuell
Zeile 1:	Zeile 1:
	+	====== FAQ E-Mail-Adressen ======
	+
	+	==== Welchen Zweck hat das Versenden von Bestätigungs-Emails an E-Mail-Adressen, die in ein Zertifikat eingebunden werden sollen? ====
	+
	+	Vor der Ausstellung von Zertifikaten muss geprüft werden, ob dem zukünftigen Zertifikatinhaber alle eventuell enthaltenen E-Mail-Adressen zugeordnet sind.
	+
	+	Gerade bei einrichtungsfremden Adressen ist dies am einfachsten mit einer E-Mail an die aufzunehmende Adresse möglich. In der E-Mail sind Links enthalten, die zur Bestätigung bzw. zur Ablehnung der Aufnahme der E-Mail-Adresse angeklickt werden müssen.
	+
	+	==== Wie ist das Verfahren? ====
	+	Es wird an jede E-Mail-Adresse, die in ein Zertifikat aufgenommen werden soll und nicht in der Liste der in dieser CA vorab zugelassenen E-Mail-Domains steht, eine Bestätigungs-E-Mail mit einem Bestätigungs-Link geschickt. Bevor der Bestätigungs-Link nicht aufgerufen wurde, kann der zugehörige Zertifikatantrag nicht genehmigt werden.
	+
	+	==== Was passiert, wenn Sie der Aufnahme einer E-Mail-Adresse in ein Zertifikat widersprechen? ====
	+	In diesem Fall kann der Zertifikatantrag nicht vom Teilnehmerservice genehmigt werden. Wenn Sie den Zertifikatantrag ohne diese E-Mail-Adresse bearbeiten lassen möchten, wenden Sie sich bitte an Ihren Teilnehmerservice.
	+
	+	==== Kann eine abgelehnte E-Mail-Adresse doch noch in das Zertifikat aufgenommen werden? ====
	+	Eine E-Mail-Adresse, deren Aufnahme in ein Zertifikat widersprochen wurde, kann nur dann doch noch in das Zertifikat aufgenommen werden, wenn der Teilnehmerservice den Zertifikatantrag bearbeitet. Wenden Sie sich bitte an Ihren Teilnehmerservice.
	+
	+

faqtsbetrieb

Anonymous (anonymous@undisclosed.example.com) — 2024-01-19T08:45:17+00:00

2024/01/19 09:44		aktuell
Zeile 5:		Zeile 5:
	Der Teilnehmerservice übernimmt in einer PKI Aufgaben, die sinnvollerweise nur lokal durchgeführt werden können. Die wesentlichen Aufgaben sind:		Der Teilnehmerservice übernimmt in einer PKI Aufgaben, die sinnvollerweise nur lokal durchgeführt werden können. Die wesentlichen Aufgaben sind:

-	* Freischaltung von Domains, die in E-Mail-Adressen oder Servernamen in Zertifikaten aufgenommen werden sollen	+	* Freischaltung von Domains, die in E-Mail-Adressen oder Servernamen in Zertifikaten aufgenommen werden sollen
-	* Genehmigen von Zertifikatanträgen	+
-	* Sperren von Zertifikaten	+	* Genehmigen von Zertifikatanträgen
-	* Beraten von Nutzenden	+
		+	* Sperren von Zertifikaten
		+
		+	* Beraten von Nutzenden

	Einen Teilnehmerservice gibt es sowohl bei den vom DFN-Verein betriebenen PKIs (DFN-Verein Community PKI, Grid-PKI), als auch bei GÉANT TCS.		Einen Teilnehmerservice gibt es sowohl bei den vom DFN-Verein betriebenen PKIs (DFN-Verein Community PKI, Grid-PKI), als auch bei GÉANT TCS.

global

Anonymous (anonymous@undisclosed.example.com) — 2026-03-02T11:52:06+00:00

2025/11/26 09:15		aktuell
Zeile 31:		Zeile 31:
	=== Weitere Informationen ===		=== Weitere Informationen ===

-	* [[https://www.tuvit.de/fileadmin/Content/TUV_IT/zertifikate/de/67142UD.pdf\|Zertifikat für ETSI EN 319 411-1]]	+	* [[https://www.tuev-nord.de/fileadmin/Sites/TUEV_NORD/Zertifikate/Certification/IT-Zertifikate/de/67164UD.pdf\|Zertifikat für ETSI EN 319 411-1]]
	* {{:de:dfnpki:doc:archiv:aufgaben-ts-dfn-pki_v2.pdf\|Aufgaben des Teilnehmerservice (TS) in der DFN-PKI im Sicherheitsniveau Global}}		* {{:de:dfnpki:doc:archiv:aufgaben-ts-dfn-pki_v2.pdf\|Aufgaben des Teilnehmerservice (TS) in der DFN-PKI im Sicherheitsniveau Global}}

grid

Anonymous (anonymous@undisclosed.example.com) — 2025-12-15T11:13:21+00:00

2025/12/15 12:12		aktuell
Zeile 15:		Zeile 15:
	Alle aktuellen und archivierten Versionen der Zertifizierungsrichtlinie und Erklärung zum Zertifizierungsbetrieb finden sich unter https://doku.tid.dfn.de/de:dfnpki:policyarchiv#sicherheitsniveau_grid		Alle aktuellen und archivierten Versionen der Zertifizierungsrichtlinie und Erklärung zum Zertifizierungsbetrieb finden sich unter https://doku.tid.dfn.de/de:dfnpki:policyarchiv#sicherheitsniveau_grid

-	Wurzelzertifikate: https://doku.tid.dfn.de/de:dfnpki:dfnpki_root_certs#dfn-pki_grid	+	Wurzelzertifikate und Fingerprints: https://doku.tid.dfn.de/de:dfnpki:dfnpki_root_certs#dfn-pki_grid

	Validierungsdienste: https://doku.tid.dfn.de/de:dfnpki:dfnpki_crl_ocsp		Validierungsdienste: https://doku.tid.dfn.de/de:dfnpki:dfnpki_crl_ocsp

harica2025

Anonymous (anonymous@undisclosed.example.com) — 2025-06-17T13:02:29+00:00

2025/06/02 13:01		aktuell
Zeile 1:		Zeile 1:
	===== HARICA =====		===== HARICA =====

-	HARICA ist Teil des griechischen Universitätsnetzes GUnet und als Vertrauensdiensteanbieter seit vielen Jahren etabliert. https://www.harica.gr/	+	Die FAQ-Seiten für HARICA wurden umstrukturiert. Sie finden Sie nun hier [[de:dfnpki:tcs:2025\|HARICA (ab 2025)]].

-	Der aktuelle Auftrag von DFN an HARICA ist zeitlich befristet, um in der aktuellen Situation ein kontinuierliches Dienstangebot sicherstellen zu können. Wir arbeiten, auch gemeinsam mit GÉANT, daran, eine dauerhafte Lösung zu finden, die keine weiteren kurzfristigen Migrationen erfordert.

-	Die derzeitige Funktionalität der Systeme von HARICA ist für Zertifikatversorgung ausreichend. Es können aber derzeit nicht alle bisher angebotenen Workflows umgesetzt werden. HARICA arbeitet mit Hochdruck an einer Ausweitung des Angebots.
-
-
-	===== Datenschutz =====
-
-	Die Datenschutzerklärung von HARICA finden Sie hier: https://repo.harica.gr/documents/Data-Privacy-Statement-EN.pdf. Darüber hinaus müssen Antragstellende das Subscriber Agreement und die Terms of Use akzeptieren. Diese finden Sie unter https://repo.harica.gr/documents/SA-ToU.pdf.
-
-	HARICA ist die verantwortliche Stelle ("Data Controller") für die Verarbeitung der personenbezogenen Daten (vgl. Subscriber Agreement Kapitel 6.10). Die personenbezogenen Daten werden von HARICA gemäß DS-GVO Art. 6 (1) b) (Vertragserfüllung), ggf. in Kombination mit Art. 6 (1) c) (Erfüllung rechtlicher Verpflichtungen, z.B. aus der eIDAS-Verordnung), verarbeitet (vgl. Kapitel 3 der Datenschutzerklärung von HARICA).
-
-	Es wird häufiger die Frage gestellt, ob eine Auftragsverarbeitungsvereinbarung zur Nutzung des Dienstes vom DFN-Verein oder von HARICA direkt angeboten wird. Dies ist mit der folgenden Begründung nicht notwendig und wird daher auch weder vom DFN-Verein noch von HARICA angeboten:
-
-	Im Rahmen von GÉANT TCS erfolgt die vertragliche Vereinbarung über die Bereitstellung des Zertifikats direkt zwischen HARICA und dem betroffenen Angehörigen des DFN-Teilnehmers. Ausschließlich in diesem Verhältnis werden personenbezogene Daten zur Erstellung und Verwaltung des Zertifikats verarbeitet. Folglich haben weder GÉANT noch der DFN-Verein irgendeinen Zugriff oder Einfluss auf die Verarbeitung personenbezogener Daten bei HARICA. Beiden steht zudem in Bezug auf die Verarbeitung bei HARICA keinerlei Weisungsrecht zu. Das Rahmenvertragswerk zwischen DFN-Verein, GÉANT und HARICA beschränkt sich auf die wirtschaftlichen Konditionen, zu denen Angehörige von DFN-Teilnehmern Produkte von HARICA in Anspruch nehmen können. HARICA entscheidet somit allein über Art, Umfang und Dauer der Verarbeitung aufgrund des Subscriber Agreements mit dem betroffenen Angehörigen des DFN-Teilnehmers und ist somit als Verantwortlicher im Sinne des Art. 4 Nr. 7 DS-GVO anzusehen. Dies schließt die Eigenschaft als Auftragsverarbeiter aus, so dass hier gemäß Art. 28 Abs. 10 DS-GVO schon keine rechtliche Möglichkeit zum Abschluss einer Auftragsverarbeitung besteht.
-
-
-
-
-
-	===== Enrollment von Organisationen =====
-
-	Organisationen werden von der DFN-PCA im HARICA-System angelegt. Das initiale Setup erfolgt in direkter Absprache mit dfnpca@dfn-cert.de.
-
-	===== Rollen und User =====
-
-	==== User-Registrierung ====
-	User registrieren sich auf https://cm.harica.gr stets selbst. Es gibt keinen Prozess, bei dem ein Admin andere User anlegen kann. Es ist nicht möglich, die Selbst-Registrierung von Usern zu unterbinden. Ebenso gibt es auch keine Möglichkeit, User zu sperren oder zu löschen.
-
-	Die bei der Registrierung verwendete E-Mail-Adresse sorgt für die Zuordnung zu einer Einrichtung.
-
-	Es stehen die folgenden Arten der Registrierung zur Verfügung:
-	* Username/Passwort. User können sich über den Link im Text ''New to HARICA? Sign Up'' mit Username und Passwort registrieren.
-	* Über die AAI mit dem Button ''Academic Login''
-
-	Bei der Anmeldung über die AAI werden die Namensbestandteile der User derzeit mit einem Sonderzeichen ''^''dargestellt:
-	Vorname^Nachname
-
-	Dies hat keine Auswirkung auf die Funktion.
-
-	=== Voraussetzungen für die AAI-Nutzung ==
-
-	Die Konfiguration erfordert üblicherweise die Mithilfe Ihrer AAI-Administration, da die Attributfreigaben anzupassen sind.
-
-	* Die HARICA-Service-Provider sind in den eduGAIN-Metadaten enthalten.
-
-	* Ihr Identity-Provider muss in eduGAIN eingebunden sein (Unter https://met.refeds.org/met/search_service/ können Sie nach Ihrer Einrichtung suchen und sehen, ob diese an eduGAIN teilnimmt.)
-
-	* Ihr Identity-Provider muss in der Lage sein, eine ''eduPersonTargetedID'' zu erzeugen und herauszugeben. Wie dieses Attribut erzeugt werden kann, wird beschrieben unter: https://doku.tid.dfn.de/de:shibidp:config-attributes-edupersontargetedid
-
-	* Die folgende Freigabe übermittelt die notwendigen Attribute:
-
-	<!-- Release to Harica SP -->
-	<AttributeFilterPolicy id="harica">
-	<PolicyRequirementRule xsi:type="OR">
-	<Rule xsi:type="Requester" value="https://www.harica.gr/simplesamlphp/module.php/saml/sp/metadata.php/pki-grnet-sp" />
-	<Rule xsi:type="Requester" value="https://cm-stg.harica.gr/simplesamlphp/module.php/saml/sp/metadata.php/harica-cm-stg-sp" />
-	<Rule xsi:type="Requester" value="https://cm-dev.harica.gr/saml/module.php/saml/sp/metadata.php/harica-cm-dev-sp" />
-	</PolicyRequirementRule>
-	<AttributeRule attributeID="givenName" permitAny="true" />
-	<AttributeRule attributeID="sn" permitAny="true" />
-	<AttributeRule attributeID="mail" permitAny="true" />
-	<AttributeRule attributeID="eduPersonTargetedID" permitAny="true" />
-	</AttributeFilterPolicy>
-
-	* Die bei einem aktuellen AAI-Login-Vorgang vom Identity-Provider an den HARICA-Service-Provider übermittelten Attribute können unter https://cm.harica.gr/loginsaml/test.php eingesehen werden.
-
-	==== Rollen ====
-
-	Es gibt die folgenden Rollen:
-
-	* Normale User ohne erhöhte Rechte. Kann für sich Zertifikate beantragen.
-
-	* Enterprise Approver: Genehmigt gestellte Zertifikatanträge. Es gibt getrennte Rollen für S/MIME und Serverzertifikate
-
-	* Enterprise Admin: Kann Domains verwalten und die Rollen Enterprise Admin und Enterprise Approver vergeben.
-
-
-	Der erste Enterprise Admin einer Einrichtung wird von ti-services@dfn-cert.de in diese Rolle gebracht. Weitere Rollen-Zuweisungen können dann von diesem selbst durchgeführt werden, allerdings nur für User, die sich mit Mail-Adressen aus der Domain der Einrichtung registriert haben.
-
-	Enterprise Admins und Approver müssen Zwei-Faktor-Authentifizierung per TOTP in ihrem Profil angeschaltet haben. Hierzu klickt man rechts oben den eigenen Namen an, wählt Profile->Two Factor Authentication und folgt den weiteren Anweisungen.
-
-	Der DFN-Verein hat eine übergeordnete Rolle "Enterprise Manager", und kann die Organisationen im System verwalten.
-
-	==== Zuweisung von Rollen ====
-
-	Ein Enterprise Admin wählt zur Zuweisung von Rollen an andere User den Punkt "Enterprise->Admin" oben am Bildschirm aus. Anschließend den Tab "Users" und darin den zu bearbeitenden User anwählen. In der Detailansicht wählen Sie dann den Tab "Account info" an.
-
-	{{:de:dfnpki:harica:userinfo.png?500\|Bild des Dialogs UserInfo}}
-
-
-	{{:de:dfnpki:harica:accountinfo.png?500\|Bild des Dialogs AccountInfo}}
-
-	Die Schiebeschalter Enterprise Admin und Enterprise Approver stehen nur zur Verfügung, wenn der User Two-factor Authentication bei sich eingerichtet hat.
-
-	Zum Zuweisen der Rollen müssen diese Schiebeschalter betätigt werden.
-
-	**Wichtig: Anschließend muss dem Account eine "Validator group" zugewiesen werden. Hierzu den Button "Manage groups" betätigen, und die Anfangsbuchstaben des Organisatuonsnamens eingeben. In der Autovervollständigung dann auf den kompletten Namen klicken. Die Einstellungen werden durch den Button "Save" gesichert.
-	**
-
-	Achtung: Die Weboberfläche hat derzeit Refresh-Probleme. Durchgeführte Änderungen sind erst nach einem kompletten Reload der Webseite sichtbar.
-
-
-	===== Domains =====
-
-	=== Hinzufügen ===
-	Domains können von der Rolle Enterprise Admin hinzugefügt werden. Hierfür unter dem Menüpunkt "Enterprise->Admin" im Tab Enterprises die eigene Einrichtung aufrufen. Im großen Dialog steht oben rechts ein kleiner Globus dargestellt. Hierüber kann eine Datei mit neuen Domains hochgeladen werden.
-
-	Die Liste muss in einem "Pseudo-CSV"-Format gehalten werden:
-
-	Domain
-	example.org
-	example.com
-
-	Anführungszeichen (wie sie z.B. beim CSV-Export aus LibreOffice entstehen), dürfen nicht verwendet werden. Nach dem Hochladen der Domains wird eine Bestätigung per E-Mail versandt. HARICA führt zunächst eine manuelle Freigabe durch. Dabei wird auf "Hoch-Risiko-Domains" wie Namen von Finanzinstituten o.ä. geprüft.
-
-	Es ist möglich, eine Domain in Organisation A und eine Sub-Domain davon in Organisation B zu hinterlegen.
-
-	Es ist nicht möglich, eine identische Domain in mehreren Organisationen zu nutzen.
-
-	{{:de:dfnpki:harica:domains.png?600\|Bild des Dialogs Domains}}
-
-	=== Domainvalidierung ===
-
-	Nach Freigabe muss die Domainvalidierung gestartet werden. Hierzu muss ein Enterprise Admin wieder im Tab Enterprises nach Auswahl der Einrichtung den Untertab "Domains" auswählen.
-
-	{{:de:dfnpki:harica:domainvalidation.png?600\|Bild des Dialogs Domainvalidation}}
-
-	Es stehen die Methoden DNS TXT und E-Mail an hostmaster@, postmaster@, admin@, administrator@, webmaster@<domain> zur Verfügung.
-
-	Bei der Domain-Validierung wird die E-Mail-Adresse einer Person mit Account im cm.harica.gr abgefragt, die die Validierung durchführen soll. D.h., bei E-Mail-Validierung wird zunächst an eine der generischen Adressen hostmaster@ usw. ein Link übermittelt, der dann von der Person mit dem Account im HARICA-System mit Login aufgerufen werden muss.
-
-
-	=== Sub-Domains ===
-
-	Sub-Domains (z.B. ''department.example.org'') müssen und können im HARICA-System grundsätzlich nicht hinzugefügt werden, wenn die Haupt-Domain bereits in der eigenen Organisation hinterlegt ist.
-
-	Es ist aber problemlos möglich, eine Base-Domain in Organisation A und eine Sub-Domain davon in Organisation B zu hinterlegen. Beide, Base-Domain und Sub-Domain, müssen unabhängig voneinander von den zugeordneten Einrichtungen validiert werden.
-
-	=== Löschen von Domains ===
-
-	Domains können derzeit nur vom HARICA-Support ([[support-tcs@harica.gr]]) entfernt werden.
-
-	===== Organisationsvalidierung =====
-
-	Auch ohne durchgeführte Organisationsvalidierung können Zertifikate ausgestellt werden. Inbesondere können Sie S/MIME-Zertifikate des Typs ''email-only'' und Serverzertifikate des Typs ''DV'' beziehen. Diese Zertifikattypen erfüllen bereits alle funktionalen Anforderungen für S/MIME oder TLS.
-
-	Wenn Sie daüber hinaus auch Zertifikate mit Organisationsinformationen beziehen wollen, müssen Sie eine Organisationsvalidierung durchführen lassen. Hierfür müssen HARICA Dokumente über die Organisation übermittelt werden.
-
-	Mögliche Dokumente:
-	* Für Vereine und Gesellschaften wie GmbHs:
-	* Screenshot des Suchergebnisses inklusive Registernummer von https://www.handelsregister.de
-	* PDF-Ausdruck des Web-Impressums inklusive Umsatzsteuernummer
-	* Für öffentliche Hochschulen und Universitäten:
-	* PDF (Auszug) des Hochschulgesetz, das die Einrichtung begründet. Bitte heben Sie den eigenen Namen per PDF-Marker hervor.
-	* Weicht Ihr Einrichtungsname vom Hochschulgesetz ab, muss ein diese Abweichung begründendes Dokument beigelegt werden. Häufig ist dies die Grundordnung.
-	* PDF-Ausdruck des Web-Impressums inklusive Umsatzsteuernummer
-
-	Ablauf der Übermittlung:
-	* Im CertManager Enterprise->Admin wählen, dann Tab Enterprises.
-	* Eigene Einrichtung auswählen
-	* In der aufklappenden Liste noch einmal die eigene Einrichtung auswählen
-	* Im nun erscheinenden Detail-Dialog das Dokumenten-Icon oben rechts auswählen und Dokumente unter "Validity OV" per Button "Select File" auswählen.
-	* Per Button "Upload" an HARICA übermitteln
-	* Im Anschluss bitte HARICA informieren per englisch-sprachiger E-Mail an ''support-tcs@harica.gr'' mit Cc an ''ti-services@dfn-cert.de''. Z.B.:
-	<code>
-	To: support-tcs@harica.gr
-	Cc: ti-services@dfn-cert.de
-	Subject: Organisation validation for <Einrichtungsname>
-
-	Hello,
-
-	we have uploaded documents to start the organisation validation of <Einrichtungsname>
-
-	thanks,
-	</code>
-
-	Wir führen die Organisationsvalidierung auch gerne mit Ihnen gemeinsam durch. Aufgrund der möglichen Komplexität kann es hierbei zu Wartezeiten kommen.
-
-	===== Departments, Abteilungen, Institute =====
-
-	Es stehen derzeit noch keine Mechanismen für die Abbildung von Abteilungs- oder Institutsstrukturen zur Verfügung.
-
-	Der sichtbare Button "Create subunit" in der Detail-Ansicht der eigenen Organisation hat derzeit keine Funktion.
-
-	===== Ausstellen von Zertifikaten =====
-
-	==== Grundsätze ====
-
-	Zertifikate werden bis auf eine Ausnahme derzeit ausschließlich von Usern mit einem Account im System beantragt. Der Account kann durch Selbst-Registrierung erstellt werden (siehe [[de:dfnpki:harica2025#user-registrierung\|User-Registrierung]]).
-
-	Für S/MIME ist eine Lösung ohne Account über die AAI in Arbeit.
-
-	Für Serverzertifikate wird es einen ACME-Zugang geben, allerdings sind die Details noch in Absprache.
-
-	=== Kostenpflichtige Zertifikate und Services ===
-
-	User haben die Möglichkeit, im Portal kostenpflichtige Zertifikate oder Services zu bestellen. Der Bestellung endet dabei stets so, dass der User selbst einen Zahlungsprozess mit Kreditkarte durchführen muss, bevor irgendwelche weiteren Vorgänge gestartet werden.
-
-	==== S/MIME ====
-	=== User-initiiert ===
-
-	Angemeldete User können mit dem Menüpunkt "Email" (im linken Vertikal-Menü) einen Beantragungsprozes starten.
-
-	Es stehen im Antragsprozess die folgenden Zertifikattypen zur Verfügung:
-	* ''Email-only'': Das Zertifikat enthält nur die Mail-Adresse. Es muss eine Mail-Challenge beantwortet werden. Weitere Freigabeprozesse sind nicht erforderlich. Auch geeignet für Gruppen- oder Funktionsmailadressen.
-	* ''For individuals or sole proprietorships (IV)'': Nicht empfehlenswert Für individuelle Personen mit validiertem Vor- und Nachnamen ohne Organisationsinformationen. Kostenpflichtig, im Forschungsnetzumfeld nicht sinnvoll einzusetzen.
-	* ''For enterprises or organizations (OV)'': Nicht empfehlenswert Zertifikate mit Mail-Adresse und Organisationsname. Kostenpflichtig; es ist eine individuelle Organisationsvalidierung erforderlich.
-	* ''For enterprises or organizations (IV+OV)'': Derzeit nicht empfehlenswert Zertifikate für Personen mit validiertem Vor- und Nachnamen und Organisationsinformationen. Es ist eine Genehmigung durch einen Enterprise Approver erforderlich. Im Antragsprozess wird nach einem Upload von Personalausweiskopien gefragt. Aufgrund der gesetzlichen Einschränkungen bei der Verwendung von Ausweiskopien in Deutschland und der Komplexität der datenschutzrechtlichen Beurteilung raten wir davon ab, diesen Antragsweg in dieser Anfangsphase aktiv zu verwenden.
-
-
-	Im Antragsprozess wird vom HARICA-System ein Schlüsselpaar erzeugt. Der User erhält direkt eine PKCS#12-Datei zum Download.
-
-	Eine Ausstellung von S/MIME-Zertifikaten über ein Portal mit AAI-Authentifizierung ist in Vorbereitung.
-
-	=== Inititiert durch den Enterprise Approver, S/MIME CSV (Bulk) ===
-
-	Ein Enterprise Approver hat die Möglichkeit, über den Upload einer CSV-Datei mit Mail-Adressen, Personennamen und weiteren Parametern größere Mengen an S/MIME-Zertifikaten in einem Schritt ohne User-Interaktion zu erstellen.
-
-	Es können bis zu drei Mailadressen pro Zertifikat angegeben werden.
-
-	Das HARICA-System erstellt auf der Basis der CSV-Datei PKCS#12-Dateien mit privaten Schlüsseln und Zertifikaten, die direkt im Anschluss vom Enterprise Approver heruntergeladen werden. Die PKCS#12-Dateien sind mit Passphrases geschützt, die in der CSV-Datei übergeben wurden.
-
-	Der Prozess ist verfügbar unter "Admin->Enterprises->Bulk Certificates->S/MIME", Button "Start here". Eine Beispiel-CSV-Datei steht dort zur Verfügung. (Die Werte in der Spalte "FriendlyName" dürfen maximal 85 Zeichen lang sein.)
-
-	Eine Variante, bei der ein CSR übergeben werden kann und der Schlüssel eben nicht auf HARICA-Servern erzeugt wird, steht ebenfalls zur Verfügung.
-
-	=== Zertifikatablauf-Warn-E-Mails (Notifications) für S/MIME-zertifikate ===
-
-	Zertifikatablauf-Warn-E-Mails für S/MIME-Zertifikate aus einem der individuellen Antragswegen werden automatisch jeweils 30, 15, 5 und 1 Tag(e) vor Ablauf des jeweiligen Zertifikats an die im Zertifikat enthaltene(n) E-Mail-Adresse(n) geschickt. Zeiträume etc sind nicht individuell konfigurierbar.
-
-	Zertifikatablauf-Warn-E-Mails für S/MIME-Zertifikate aus dem S/MIME CSV (Bulk) Antragsweg werden automatisch 30 Tage vor Ablauf des jeweiligen Zertifikats an die im Zertifikat enthaltene(n) E-Mail-Adresse(n) geschickt. Zeiträume etc sind nicht individuell konfigurierbar. Allerdings werden mit anstehenden Software-Anpassungen in Zukunft die oben genannten Zeiträume - 30, 15, 5 und 1 Tag(e) - gelten, sobald die über den S/MIME CSV (Bulk) Antragsweg ausgestellten S/MIME-Zertifikate auch in den Standard-Zertifikatsübersichtslisten angezeigt werden.
-
-	==== Serverzertifikate ====
-
-	=== Vier-Augen-Prinzip ===
-
-	Serverzertifikate erfordern ein Vier-Augen-Prinzip: Anträge werden von einem Account mit mindestens Rolle ''User'' gestellt, und von einem anderen Account mit Rolle ''Enterprise Approver'' genehmigt. Auch ein ''Enterprise Admin'' oder ''Enterprise Approver'' kann seine eigenen Anträge nicht genehmigen, sondern benötigt einen zweiten ''Enterprise Approver''.
-
-	=== Zertifikattypen und Antragsstellung ===
-
-	Der Antragsstellende kann über den Menüpunkt "Server" links einen Antrag stellen. Es stehen die folgenden Zertifikattypen zur Verfügung:
-	* ''Domain-only (DV)'': Zertifikate ohne Organisationsnamen.
-	* ''For enterprises or organizations (OV)'': Zertifikate mit Organisationsnamen. Erst verfügbar, wenn eine [[de:dfnpki:harica2025#Organisationsvalidierung\|Organisationsvalidierung]] abgeschlossen wurde.
-	* ''For enterprises or organizations (EV)'': Nicht empfehlenswert Extended-Validation-Zertifikate, wie sie vor einigen Jahren z.B. für Online-Banking gebräuchlich waren. Kein Mehrwert ggü OV. Kostenpflichtig.
-
-	Die Antragstellung sollte weitestgehend selbsterklärend sein.
-
-	Hinweis 1: Die Erzeugung von 4096-Bit-Schlüsseln im Browser dauert manchmal mehrere Minuten und erscheint dabei wie eine "hängenden" Webseite.
-
-	Hinweis 2: Wird ein eigener CSR per Copy&Paste in den Antrag aufgenommen, ist darauf zu achten, dass keine zusätzlichen Leerzeichen oder Leerzeilen etc mit in das Eingabefeld für den CSR kopiert oder eingegeben werden. Diese können zur Ablehnung von Anträgen mittels diverser Fehlermeldungen oder später zu hängenden Anträgen führen.
-
-	Hinweis 3: Wird ein selbsterstellter CSR hochgeladen und erscheint daraufhin der Hinweis "''This public key can not be used.''", so liegt das an mindestens einem der folgenden Gründe: (i) ein anderer HARICA-Account hat bereits den gleichen Schlüssel in einem Zertifikatantrag benutzt; (ii) der Schlüssel ist HARICA als kompromittiert gemeldet; (iii) der Schlüssel genügt nicht (mehr) den aktuell gültigen technischen Anforderungen aus dem HARICA CP/CPS.
-
-	=== Zertifikatablauf-Warn-E-Mails (Notifications) für Serverzertifikate ===
-
-	Sobald das Serverzertifikat ausgestellt ist, können durch den das Zertifikat beantragenden HARICA-Account im Cert Manager in den Serverzertifikat-Details unter dem Tab "Notifications" weitere E-Mail-Adressen zusätzlich zur immer vorhandenen Account-E-Mail-Adresse angegeben werden, um Zertifikatablauf-Warn-E-Mails jeweils 15, 5 und 1 Tag(e) vor dem Zertifikatsablauf zu erhalten.
-
-	=== Limitierung SANs ===
-
-	Die Anzahl der SubjectAlternativeNames ist derzeit auf 100 begrenzt. Das eine Erweiterung notwendig ist, ist HARICA bekannt.
-
-	=== Genehmigung ===
-
-	Der Enterprise Approver kann die Liste der offenen Anträge über "Admin->SSL Request" einsehen. Über das Icon ''Show details'' neben jedem Antrag wird dieser eingesehen und genehmigt. Zur Genehmigung muss in dem Dialog zunächst ein Text in das Feld "Message" eingegeben werden, bevor der Button "Accept" bedient werden kann.
-
-	Die Buttons ''Open File'' und ''<Choose File> no file chosen'' haben keine Bedeutung.
-
-	{{:de:dfnpki:harica:ssl-approve.png?500\|Bild des Dialogs SSL Show details}}
-
-	=== Download und Bezug der Zertifikatkette ===
-
-	Der Antragsstellende kann das Zertifikat über "My Dashboard" herunterladen. Hierzu muss das Download-Icon neben dem Zertifikat angewählt werden. Mit dem Button ''PEM bundle'' im anschließenden Dialog erhält man eine Datei, die für Webserver wie Apache oder nginx direkt verwendbar ist.
-
-	{{:de:dfnpki:harica:ssl-download-user.png?500\|Bild des Dialogs Certificate Download}}
-
-	Hinweis: Der Enterprise Approver hat den Button ''PEM bundle'' in seiner Übersicht unter "Enterprise->SSL Certificates" nicht zur Verfügung. Hier gibt es nur ''Download as PEM'', ''Download as DER'' und ''Download as PKCS#7''.
-
-	=== PKCS#7 zu PEM bundle ===
-	Um aus einer PKCS#7-Datei ein PEM bundle für Apache oder nginx zu erstellen, kann die folgende Befehlszeile verwendet werden:
-
-	openssl pkcs7 -in Cert_chain.p7b -print_certs > Cert_pem_bundle.pem
-
-
-	=== High Risk Anträge ===
-
-	Bestimmte Server-Namen werden als "Hochrisiko-Anträge" markiert. Dies ist eine Vorgabe vom CA/Browser-Forum. Betroffen sind zum einen bekannte Namen wie "google", aber auch "haricatest".
-
-	Um den Aufwand auf HARICA-Seite zu vermindern, bitten wir drum, Experimente nicht mit dem Schlüsselwort "harica" durchzuführen.
-
-	===== ACME =====
-	HARICA unterstützt im Prinzip bereits ACME. Zur Zeit steht dieses Feature aber nicht in einer Form zur Verfügung, die für einen regulären Einsatz geeignet ist. Insbesondere fehlt eine Verwaltung von Accounts für das External Account Binding von prevalidierten Domains.
-
-
-	===== CAA-Records =====
-
-	=== harica.gr ===
-	Wichtig: Wenn keinerlei CAA-Records im DNS gesetzt sind, funktioniert der Zertifikatbezug ohne jede Einschränkung. CAA-Records sind eine zusätzliche Maßnahme für Einrichtungen, die sich bewusst dafür entscheiden.
-
-	Wenn Sie CAA-Records im DNS setzen möchten, um die Ausstellung von Zertifikaten auf bestimmte CAs einzuschränken, verwenden Sie für GÉANT-TCS-Zertifikate von HARICA den ''issue''-Wert ''harica.gr''.
-
-	Für alle aktuell unter GÉANT TCS ausgestellte Zertifikate ist ausschließlich der Wert ''harica.gr'' notwendig, sofern denn CAA-Records gesetzt sind. Vormals für GÉANT TCS genutzte andere Werte können entfernt werden.
-
-	Beispiel:
-
-	<code>
-	muster-uni.de. IN CAA 0 issue "harica.gr"
-	muster-uni.de. IN CAA 0 issue "pki.dfn.de"
-	</code>
-
-	=== CNAMEs und CAA-Records ===
-
-	Ist für eine betrachtete Domain (Alias-Domain) ein CNAME im DNS definiert, so müssen die CAA-Records für den CNAME die Ausstellung von Zertifikaten durch TCS erlauben:
-
-	<code>
-	muster-uni.edu. IN CNAME muster-uni.de.
-
-	muster-uni.de. IN CAA 0 issue "harica.gr"
-	muster-uni.de. IN CAA 0 issue "pki.dfn.de"
-	</code>
-
-	===== APIs =====
-
-	HARICA bietet ein API an, mit dem Teile der Prozesse gesteuert werden können.
-
-	Dokumentation:
-	* https://guides.harica.gr/docs/Guides/Developer/
-	* https://developer.harica.gr
-
-	Beispiele:
-	* Bash: https://www.uni-muenster.de/CA/harica-sh.txt
-	* Go: https://github.com/hm-edu/harica via https://github.com/hm-edu#pki-management
-	* Java: https://poll.hs-kempten.de/harica/
-	* Perl: https://www.math.uni-bonn.de/people/ef/harica/
-	* Perl: https://software.nikhef.nl/experimental/tcstools/tcsg5/
-	* PHP: https://www.uni-muenster.de/CA/harica-php.txt
-	* Python: https://gitlab.hrz.tu-chemnitz.de/tud-cert/harica
-	* Python https://gitlab.mpi-klsb.mpg.de/pcernko/tud-cert-harica
-	* Javascript (FE) & Python (BE) https://gitlab.mpi-klsb.mpg.de/pcernko/smimereq
-
-	Seit Januar 2025 gibt es eine DFN-PKI-Softwarentwicklungsmailingliste: https://www.listserv.dfn.de/sympa/info/dfnpki-dev und [[de:dfnpki:contact#mailingliste_softwareentwicklung\|DFN-PKI Kontakte und Mailinglisten]]
-
-
-	===== Weitere Dokumentation =====
-
-	Generische Anleitungen finden sich unter https://guides.harica.gr
-
-	Diese sind in vielen Fällen aber nicht auf den Anwendungsfall einer großen Organisation zugeschnitten.
-
-	===== Support =====
-
-	Wir helfen auch bei technischen Schwierigkeiten gerne weiter: ti-services@dfn-cert.de
-
-	HARICA selbst ist unter support-tcs@harica.gr zu erreichen.
-
-	Es ist zu empfehlen, vor einer direkten Kontaktaufnahme zum HARICA-Support mit uns zu sprechen.

interne_cas

Anonymous (anonymous@undisclosed.example.com) — 2024-09-13T15:36:08+00:00

2024/09/13 17:31		aktuell
Zeile 5:		Zeile 5:
	Die DFN-Verein Community PKI bietet ein DFN-übergreifendes Vertrauensniveau und damit einen geregelten Rahmen. Dies führt zu einigen wenigen Einschränkungen: So können beispielweise keine Zertifikate für interne Namen ("*.local") ausgestellt werden. Mit einer lokalen oder internen CA bestehen diese Einschränkungen nicht mehr.		Die DFN-Verein Community PKI bietet ein DFN-übergreifendes Vertrauensniveau und damit einen geregelten Rahmen. Dies führt zu einigen wenigen Einschränkungen: So können beispielweise keine Zertifikate für interne Namen ("*.local") ausgestellt werden. Mit einer lokalen oder internen CA bestehen diese Einschränkungen nicht mehr.

-	Allerdings haben Zertifikate aus einer frei definierte PKI ohne einen geregelten Rahmen möglicherweise eine zu geringe Aussagekraft. Vor dem Einsatz sollte daher eine sorgfältige Abwägung getroffen werden.	+	Allerdings haben Zertifikate aus einer frei definierten PKI ohne einen geregelten Rahmen möglicherweise eine zu geringe Aussagekraft. Vor dem Einsatz sollte daher eine sorgfältige Abwägung getroffen werden.

	Eine selbst betriebene CA kann beispielsweise in einem Active Directory aufgebaut oder als Bestandteil von Konfigurationsmanagementsystemen umgesetzt werden. Die DFN-PCA kann aber auch auf Wunsch den technischen Betrieb von einrichtungsspezifischen internen CAs übernehmen, die dann mit den bekannten Werkzeugen und dem SOAP-API bedient werden können. Die Prozesse und weitere Parameter wie die Laufzeit können dabei frei gewählt werden.		Eine selbst betriebene CA kann beispielsweise in einem Active Directory aufgebaut oder als Bestandteil von Konfigurationsmanagementsystemen umgesetzt werden. Die DFN-PCA kann aber auch auf Wunsch den technischen Betrieb von einrichtungsspezifischen internen CAs übernehmen, die dann mit den bekannten Werkzeugen und dem SOAP-API bedient werden können. Die Prozesse und weitere Parameter wie die Laufzeit können dabei frei gewählt werden.

	Im Regelfall bietet sich allerdings die Nutzung der DFN-Verein Community PKI an, wenn Bedarf nach nicht im Browser oder Betriebssystem verankerten Zertifikaten besteht.		Im Regelfall bietet sich allerdings die Nutzung der DFN-Verein Community PKI an, wenn Bedarf nach nicht im Browser oder Betriebssystem verankerten Zertifikaten besteht.

oid

Anonymous (anonymous@undisclosed.example.com) — 2025-07-18T09:45:11+00:00

2024/08/12 11:31		aktuell
Zeile 49:		Zeile 49:
	\|1.3.6.1.4.1.22177.300.1.1.4.13 \|Major Version 13: Zertifizierungsrichtlinie der DFN-PKI - Sicherheitsniveau Global - Version 13 \|		\|1.3.6.1.4.1.22177.300.1.1.4.13 \|Major Version 13: Zertifizierungsrichtlinie der DFN-PKI - Sicherheitsniveau Global - Version 13 \|
	\|1.3.6.1.4.1.22177.300.1.1.4.14 \|Major Version 14: Zertifizierungsrichtlinie der DFN-PKI - Sicherheitsniveau Global - Version 14 \|		\|1.3.6.1.4.1.22177.300.1.1.4.14 \|Major Version 14: Zertifizierungsrichtlinie der DFN-PKI - Sicherheitsniveau Global - Version 14 \|
		+	\|1.3.6.1.4.1.22177.300.1.1.4.15 \|Major Version 15: Zertifizierungsrichtlinie der DFN-PKI - Sicherheitsniveau Global - Version 15 \|
	\| \| \|		\| \| \|
	\| \| \|		\| \| \|
Zeile 89:		Zeile 90:
	\|1.3.6.1.4.1.22177.300.2.1.4.13 \|Major Version 13: Erklärung zum Zertifizierungsbetrieb der DFN-PKI - Sicherheitsniveau Global - Version 13 \|		\|1.3.6.1.4.1.22177.300.2.1.4.13 \|Major Version 13: Erklärung zum Zertifizierungsbetrieb der DFN-PKI - Sicherheitsniveau Global - Version 13 \|
	\|1.3.6.1.4.1.22177.300.2.1.4.14 \|Major Version 14: Erklärung zum Zertifizierungsbetrieb der DFN-PKI - Sicherheitsniveau Global - Version 14 \|		\|1.3.6.1.4.1.22177.300.2.1.4.14 \|Major Version 14: Erklärung zum Zertifizierungsbetrieb der DFN-PKI - Sicherheitsniveau Global - Version 14 \|
		+	\|1.3.6.1.4.1.22177.300.2.1.4.15 \|Major Version 15: Erklärung zum Zertifizierungsbetrieb der DFN-PKI - Sicherheitsniveau Global - Version 15 \|
	\| \| \|		\| \| \|
	\| \| \|		\| \| \|

pkifaq

Anonymous (anonymous@undisclosed.example.com) — 2023-05-15T15:53:56+00:00

2021/12/09 12:53		aktuell
Zeile 2:		Zeile 2:
	Hier finden Sie aktuell folgende Informationen:		Hier finden Sie aktuell folgende Informationen:
	* [[de:dfnpki:pkifaq:sigsie_faq\|Rechtliche Grundlagen elektronischer Signaturen]]		* [[de:dfnpki:pkifaq:sigsie_faq\|Rechtliche Grundlagen elektronischer Signaturen]]
		+	* {{ :de:dfnpki:dokumentensignatur_2022.pdf \|Technische und rechtliche Aspekte bei Dokumentensignaturen}}

policyarchiv

Anonymous (anonymous@undisclosed.example.com) — 2025-11-03T16:39:40+00:00

2025/07/29 09:01		aktuell
Zeile 11:		Zeile 11:

	^Datum ^Version ^CP ^CPS ^		^Datum ^Version ^CP ^CPS ^
		+	\|26.11.2025 \| 16\|{{de:dfnpki:doc:archiv:dfn-pki_cp_v16-en.pdf\|authoritative English version}}, {{de:dfnpki:doc:archiv:dfn-pki_cp_v16.pdf\|CP}}, {{de:dfnpki:doc:archiv:dfn-pki_cp_v16_redline.pdf\|Redline}} \|{{de:dfnpki:doc:archiv:dfn-pki_cps_v16-en.pdf\|authoritative English version}}, {{de:dfnpki:doc:archiv:dfn-pki_cps_v16.pdf\|CPS}}, {{de:dfnpki:doc:archiv:dfn-pki_cps_v16_redline.pdf\|Redline}} \|
	\|29.07.2025 \| 15\|{{de:dfnpki:doc:archiv:dfn-pki_cp_v15-en.pdf\|authoritative English version}}, {{de:dfnpki:doc:archiv:dfn-pki_cp_v15.pdf\|CP}}, {{de:dfnpki:doc:archiv:dfn-pki_cp_v15_redline.pdf\|Redline}} \|{{de:dfnpki:doc:archiv:dfn-pki_cps_v15-en.pdf\|authoritative English version}}, {{de:dfnpki:doc:archiv:dfn-pki_cps_v15.pdf\|CPS}}, {{de:dfnpki:doc:archiv:dfn-pki_cps_v15_redline.pdf\|Redline}} \|		\|29.07.2025 \| 15\|{{de:dfnpki:doc:archiv:dfn-pki_cp_v15-en.pdf\|authoritative English version}}, {{de:dfnpki:doc:archiv:dfn-pki_cp_v15.pdf\|CP}}, {{de:dfnpki:doc:archiv:dfn-pki_cp_v15_redline.pdf\|Redline}} \|{{de:dfnpki:doc:archiv:dfn-pki_cps_v15-en.pdf\|authoritative English version}}, {{de:dfnpki:doc:archiv:dfn-pki_cps_v15.pdf\|CPS}}, {{de:dfnpki:doc:archiv:dfn-pki_cps_v15_redline.pdf\|Redline}} \|
	\|22.08.2024 \| 14\|{{de:dfnpki:doc:archiv:dfn-pki_cp_v14-en.pdf\|authoritative English version}}, {{de:dfnpki:doc:archiv:dfn-pki_cp_v14.pdf\|CP}}, {{de:dfnpki:doc:archiv:dfn-pki_cp_v14_redline.pdf\|Redline}} \|{{de:dfnpki:doc:archiv:dfn-pki_cps_v14-en.pdf\|authoritative English version}}, {{de:dfnpki:doc:archiv:dfn-pki_cps_v14.pdf\|CPS}}, {{de:dfnpki:doc:archiv:dfn-pki_cps_v14_redline.pdf\|Redline}} \|		\|22.08.2024 \| 14\|{{de:dfnpki:doc:archiv:dfn-pki_cp_v14-en.pdf\|authoritative English version}}, {{de:dfnpki:doc:archiv:dfn-pki_cp_v14.pdf\|CP}}, {{de:dfnpki:doc:archiv:dfn-pki_cp_v14_redline.pdf\|Redline}} \|{{de:dfnpki:doc:archiv:dfn-pki_cps_v14-en.pdf\|authoritative English version}}, {{de:dfnpki:doc:archiv:dfn-pki_cps_v14.pdf\|CPS}}, {{de:dfnpki:doc:archiv:dfn-pki_cps_v14_redline.pdf\|Redline}} \|

sigsie_faq

Anonymous (anonymous@undisclosed.example.com) — 2021-12-09T11:28:41+00:00

start

Anonymous (anonymous@undisclosed.example.com) — 2024-09-16T12:36:55+00:00

2024/02/02 15:28		aktuell
Zeile 9:		Zeile 9:
	* [[:de:dfnpki:dfnvereincommunitypki\|DFN-Verein Community PKI]]: Nicht verankerte PKI für Anwendungsfälle, bei denen die Nachteile der öffentlichenPKI nicht eingegangen werden sollen		* [[:de:dfnpki:dfnvereincommunitypki\|DFN-Verein Community PKI]]: Nicht verankerte PKI für Anwendungsfälle, bei denen die Nachteile der öffentlichenPKI nicht eingegangen werden sollen

-	* Betrieb einer internen/lokalen CA für Einrichtungen	+	* [[:de:dfnpki:interne_cas\|Betrieb von internen/lokalen CA]]

	* [[:de:dfnpki:grid\|Ausstellung von Grid Zertifikaten]]		* [[:de:dfnpki:grid\|Ausstellung von Grid Zertifikaten]]

tcs

Anonymous (anonymous@undisclosed.example.com) — 2025-06-17T10:22:33+00:00

2025/02/21 08:48		aktuell
Zeile 3:		Zeile 3:
	TCS (Trusted Certificate Service) ist ein PKI-Angebot, das der DFN-Verein über GÉANT bezieht. GÉANT realisiert den Dienst mit Hilfe von externen Anbietern, die über regelmäßige Ausschreibungen gefunden werden.		TCS (Trusted Certificate Service) ist ein PKI-Angebot, das der DFN-Verein über GÉANT bezieht. GÉANT realisiert den Dienst mit Hilfe von externen Anbietern, die über regelmäßige Ausschreibungen gefunden werden.

-	Der aktuelle Dienstleister ist [[de:dfnpki:harica2025\|HARICA]].	+	Der aktuelle Dienstleister ist [[de:dfnpki:tcs:2025\|HARICA]].

tcs2020

Anonymous (anonymous@undisclosed.example.com) — 2026-04-01T10:08:35+00:00

2025/02/21 09:10		aktuell
Zeile 3:		Zeile 3:
	TCS (Trusted Certificate Service) ist ein PKI-Angebot, das der DFN-Verein über GÉANT bezieht. GÉANT realisiert den Dienst mit Hilfe von externen Anbietern, die über regelmäßige Ausschreibungen gefunden werden. Von 2020 bis 10.01.2025 wurde der Dienst von Sectigo erbracht.		TCS (Trusted Certificate Service) ist ein PKI-Angebot, das der DFN-Verein über GÉANT bezieht. GÉANT realisiert den Dienst mit Hilfe von externen Anbietern, die über regelmäßige Ausschreibungen gefunden werden. Von 2020 bis 10.01.2025 wurde der Dienst von Sectigo erbracht.

-	===== Möglicheiten zum Sperren von Zertifikaten aus dem Sectigo-System =====	+	===== Möglichkeiten zum Sperren von Zertifikaten aus dem Sectigo-System =====

	Auch nach dem Ende der Leistungserbringung durch Sectigo ist der lesende Zugriff auf das Sectigo Certificate Manager Portal (SCM) möglich. Es können aber weder neue Zertifikate ausgestellt, noch bestehende Zertifikate gesperrt werden.		Auch nach dem Ende der Leistungserbringung durch Sectigo ist der lesende Zugriff auf das Sectigo Certificate Manager Portal (SCM) möglich. Es können aber weder neue Zertifikate ausgestellt, noch bestehende Zertifikate gesperrt werden.

tcsfaq

Anonymous (anonymous@undisclosed.example.com) — 2025-06-05T11:40:15+00:00

2024/04/15 16:13		aktuell
Zeile 28:		Zeile 28:

	Hinweise zum Datenschutz und der vertraglichen Konstruktion:		Hinweise zum Datenschutz und der vertraglichen Konstruktion:
-	[[de:dfnpki:tcs:datenschutz\|Datenschutz]]	+	[[de:dfnpki:tcs:2020:datenschutz\|Datenschutz]]

	=====Funktionsüberblick=====		=====Funktionsüberblick=====
Zeile 49:		Zeile 49:

	In SCM gibt es verschiedene Rollen und Möglichkeiten zur Anmeldung. Es können Abteilungen ("Departments") angelegt werden:		In SCM gibt es verschiedene Rollen und Möglichkeiten zur Anmeldung. Es können Abteilungen ("Departments") angelegt werden:
-	[[de:dfnpki:tcs:scmrollenundanmeldung\|Rollen, Anmeldung, Abteilungen]]	+	[[de:dfnpki:tcs:2020:scmrollenundanmeldung\|Rollen, Anmeldung, Abteilungen]]

	===== Tipps und Tricks in SCM =====		===== Tipps und Tricks in SCM =====

-	[[de:dfnpki:tcs:scmtipstricks\|Tipps und Tricks für SCM]]	+	[[de:dfnpki:tcs:2020:scmtipstricks\|Tipps und Tricks für SCM]]


	=====Zugriff per AAI=====		=====Zugriff per AAI=====

-	Viele Funktionen im cert-manager können auch nach einem Login über die DFN-AAI genutzt werden. Hierzu müssen Voraussetzungen erfüllt sein: [[de:dfnpki:tcs:zugriffperaai\|Zugriff per AAI]]	+	Viele Funktionen im cert-manager können auch nach einem Login über die DFN-AAI genutzt werden. Hierzu müssen Voraussetzungen erfüllt sein: [[de:dfnpki:tcs:2020:zugriffperaai\|Zugriff per AAI]]

	=====Benachrichtigungen=====		=====Benachrichtigungen=====

-	Um Benachrichtigungen über Ereignisse wie den Ablauf von Zertifikaten oder der Gültigkeit von Domain-Valididierungen zu erhalten, können Benachrichtigungen konfiguriert werden: [[de:dfnpki:tcs:scm_notifications\|Benachrichtigungen in SCM]]	+	Um Benachrichtigungen über Ereignisse wie den Ablauf von Zertifikaten oder der Gültigkeit von Domain-Valididierungen zu erhalten, können Benachrichtigungen konfiguriert werden: [[de:dfnpki:tcs:2020:scm_notifications\|Benachrichtigungen in SCM]]

	=====Domains und IPv4-Adressen in Zertifikaten=====		=====Domains und IPv4-Adressen in Zertifikaten=====

	Um Zertifikate zu erhalten, müssen die entsprechenden Domains oder IPv4-Adressen vorab bei Sectigo im System eingetragen werden.		Um Zertifikate zu erhalten, müssen die entsprechenden Domains oder IPv4-Adressen vorab bei Sectigo im System eingetragen werden.
-	Eine detaillierte Beschreibung ist verfügbar unter: [[de:dfnpki:tcs:domains\|Domains und IPv4-Adressen in Zertifikaten]]	+	Eine detaillierte Beschreibung ist verfügbar unter: [[de:dfnpki:tcs:2020:domains\|Domains und IPv4-Adressen in Zertifikaten]]


	=====Zertifikate erstellen=====		=====Zertifikate erstellen=====

-	[[de:dfnpki:tcs:servercert\|Serverzertifikate]]	+	[[de:dfnpki:tcs:2020:servercert\|Serverzertifikate]]

-	[[de:dfnpki:tcs:servercert_acme\|Serverzertifikate per ACME]]	+	[[de:dfnpki:tcs:2020:servercert_acme\|Serverzertifikate per ACME]]

-	[[de:dfnpki:tcs:usercert\|Client-Zertifikate]]	+	[[de:dfnpki:tcs:2020:usercert\|Client-Zertifikate]]

-	[[de:dfnpki:tcs:documentsigning\|Document Signing]]	+	[[de:dfnpki:tcs:2020:documentsigning\|Document Signing]]

-	[[de:dfnpki:tcs:codesigning\|Code Signing]]	+	[[de:dfnpki:tcs:2020:codesigning\|Code Signing]]

-	[[de:dfnpki:tcs:restapi\|REST API]]	+	[[de:dfnpki:tcs:2020:restapi\|REST API]]


Zeile 95:		Zeile 95:
	Wenn Sie CAA-Records im DNS setzen möchten, um die Ausstellung von Zertifikaten auf bestimmte CAs einzuschränken:		Wenn Sie CAA-Records im DNS setzen möchten, um die Ausstellung von Zertifikaten auf bestimmte CAs einzuschränken:

-	[[de:dfnpki:tcs:caa\|CAA]]	+	[[de:dfnpki:tcs:2020:caa\|CAA]]

	=====Zertifikate sperren (Revoke, Revocation)=====		=====Zertifikate sperren (Revoke, Revocation)=====
Zeile 101:		Zeile 101:
	Zertifikate sollen üblicherweise von einem RAO oder DRAO in https://cert-manager.com/customer/DFN gesperrt werden.		Zertifikate sollen üblicherweise von einem RAO oder DRAO in https://cert-manager.com/customer/DFN gesperrt werden.

-	Die [[de:dfnpki:tcs:servercert_acme#acme-zertifikate_sperren\|Sperrmechanismen von ACME]] (z.B. mit certbot revoke) stehen für per ACME ausgestellte Zertifikate ebenfalls zur Verfügung.	+	Die [[de:dfnpki:tcs:2020:servercert_acme#acme-zertifikate_sperren\|Sperrmechanismen von ACME]] (z.B. mit certbot revoke) stehen für per ACME ausgestellte Zertifikate ebenfalls zur Verfügung.

	Unter der folgenden URL steht ein Sperrinterface bereit, in dem Sperranträge gestellt werden können:		Unter der folgenden URL steht ein Sperrinterface bereit, in dem Sperranträge gestellt werden können:
Zeile 136:		Zeile 136:

	===Support-Tickets für die Validierung (DCV) von IP-Adressen===		===Support-Tickets für die Validierung (DCV) von IP-Adressen===
-	Sofern Sie ein Ticket für den speziellen [[de:dfnpki:tcs:domains#ip-adressen_in_zertifikaten\|DCV-Vorgang zur Validierung von IP-Adressen]] erstellen wollen, wählen Sie bitte für das Ticket //Case type: "Technical Support"// und //Case reason: "Sectigo Certificate Manager (SCM)"// aus, damit das Ticket gleich in die korrekte Supportschlange eingestellt wird.	+	Sofern Sie ein Ticket für den speziellen [[de:dfnpki:tcs:2020:domains#ip-adressen_in_zertifikaten\|DCV-Vorgang zur Validierung von IP-Adressen]] erstellen wollen, wählen Sie bitte für das Ticket //Case type: "Technical Support"// und //Case reason: "Sectigo Certificate Manager (SCM)"// aus, damit das Ticket gleich in die korrekte Supportschlange eingestellt wird.

	===Support-Tickets für Anträge von Code-Signing-Zertifikate===		===Support-Tickets für Anträge von Code-Signing-Zertifikate===
-	Sofern Sie ein Ticket für die Bearbeitung von [[de:dfnpki:tcs:codesigning\|Anträgen von Code-Signing-Zertifikaten]] erstellen wollen, wählen Sie bitte für das Ticket //Case type: "Validation Support"// und //Case reason: "Code Signing Certificate"// aus.	+	Sofern Sie ein Ticket für die Bearbeitung von [[de:dfnpki:tcs:2020:codesigning\|Anträgen von Code-Signing-Zertifikaten]] erstellen wollen, wählen Sie bitte für das Ticket //Case type: "Validation Support"// und //Case reason: "Code Signing Certificate"// aus.

	Die Order Number ist zwingend anzugeben. Sie ist im SCM unter ☰→Certificates→Code Signing einsehbar.		Die Order Number ist zwingend anzugeben. Sie ist im SCM unter ☰→Certificates→Code Signing einsehbar.

tcs_ca_certs

Anonymous (anonymous@undisclosed.example.com) — 2025-06-17T13:38:56+00:00

2025/05/13 19:44		aktuell
Zeile 1:		Zeile 1:
-	====== TCS Wurzel- und CA-Zertifikate ======	+	====== GÉANT TCS Wurzel- und CA-Zertifikate ======

-	In TCS werden eine Vielzahl von verschiedenen CA-Zertifikaten verwendet. Sowohl der Algorithmus des Schlüssels als auch der Verwendungszweck des Zertifikats können eine separate Zertifizierungshierarchie erfordern. Einen generellen, nicht TCS-spezifischen Überblick gibt Sectigo in: https://sectigo.com/knowledge-base/detail/Sectigo-Chain-Hierarchy-and-Intermediate-Roots/kA01N000000rgSZ	+	Die Wurzel- und CA-Zertifikate der TCS Dienstleister finden Sie unter:

-	Die hier aufgeführten Root- und CA-Zertifikate werden in TCS verwendet. Die Fingerprints können z.B. mit openssl reproduziert werden:	+	* [[de:dfnpki:tcs:2025:cacerts\|HARICA (ab 2025)]]

-	openssl x509 -in <datei.pem> -fingerprint -sha256 -noout	+	* [[de:dfnpki:tcs:2020:cacerts\|Sectigo (2020-2024)]]

-	===== Öffentlich vertraute Zertifizierungshierarchie=====
-	==== Root-Zertifikate ====
-
-	In TCS enden Zertifizierungsketten üblicherweise auf einem der beiden Root-Zertifikate "''USERTrust ...''". Diese Root-Zertifikate sind in allen aktuell verfügbaren Browsern und Betriebssystemen vorinstalliert.
-
-	Download: {{de:dfnpki:ca:tcs-root-bundle.tar}}
-	^ CommonName ^ Einsatz ^ Gültigkeitsende ^ SHA256 Fingerprint \|
-	\| ''USERTrust RSA Certification Authority'' \| Root \| Jan 18 23:59:59 2038 GMT \| E7:93:C9:B0:2F:D8:AA:13:E2:1C:31:22:8A:CC:B0:81 :19:64:3B:74:9C:89:89:64:B1:74:6D:46:C3:D4:CB:D2 \|
-	\| ''USERTrust ECC Certification Authority'' \| Root \|Jan 18 23:59:59 2038 GMT \| 4F:F4:60:D5:4B:9C:86:DA:BF:BC:FC:57:12:E0:40:0D :2B:ED:3F:BC:4D:4F:BD:AA:86:E0:6A:DC:D2:A9:AD:7A \|
-
-
-	Kompatibilität ab:
-
-	* Windows XP
-	* MacOS 10.12.1
-	* iOS 10
-	* Firefox 3.6
-	* Android 5.1
-	* Java JRE 8u51
-
-	====Root-Zertifikat AAA Certificate Services====
-
-	Eine alternative CA-Kette kann mit Cross-Zertifikaten erstellt werden, die in der Root ''AAA Certificate Services'' endet. Diese Kette wäre für sehr alte Betriebssysteme bzw. Browser notwendig.
-
-	Sectigo liefert in Chains zur Zeit üblicherweise die ''AAA Certificate Services'' aus. Diese kann problemlos eingesetzt werden.
-
-	Sectigo erläutert die ''AAA Certificate Services'': https://support.sectigo.com/articles/Knowledge/Sectigo-AddTrust-External-CA-Root-Expiring-May-30-2020
-
-	Download: {{de:dfnpki:ca:tcs-alternate-root-bundle.tar}}
-
-	^ CommonName ^ Einsatz ^ Gültigkeitsende ^ SHA256 Fingerprint \|
-	\| ''AAA Certificate Services'' \| Root \| Dec 31 23:59:59 2028 GMT \| D7:A7:A0:FB:5D:7E:27:31:D7:71:E9:48:4E:BC:DE:F7 :1D:5F:0C:3E:0A:29:48:78:2B:C8:3E:E0:EA:69:9E:F4 \|
-	\| ''USERTrust RSA Certification Authority'' \| Intermediate (Cross-CA) \| Dec 31 23:59:59 2028 GMT \| 68:B9:C7:61:21:9A:5B:1F:01:31:78:44:74:66:5D:B6 :1B:BD:B1:09:E0:0F:05:CA:9F:74:24:4E:E5:F5:F5:2B \|
-	\| ''USERTrust ECC Certification Authority'' \| Intermediate (Cross-CA) \| Dec 31 23:59:59 2028 GMT \| A6:CF:64:DB:B4:C8:D5:FD:19:CE:48:89:60:68:DB:03 :B5:33:A8:D1:33:6C:62:56:A8:7D:00:CB:B3:DE:F3:EA \|
-
-
-	Diese auf das Root-Zertifikat ''AAA Certificate Services'' endende alternative CA-Kette wird für die folgenden Systeme benötigt:
-	* Apple iOS 3
-	* Apple macOS 10.4
-	* Google Android 2.3
-	* Mozilla Firefox 1
-	* Oracle Java JRE 1.5.0_08 (auch < 8u51)
-
-
-	====Code Signing====
-
-	Dieses CA-Zertifikat ist von der ''USERTrust RSA Certification Authority'' signiert.
-
-	Download: {{de:dfnpki:ca:tcs-code-signing-ca-bundle.tar}}
-
-	^ CommonName ^ Gültigkeitsende ^ SHA256 Fingerprint \|
-	\| ''GEANT Code Signing CA 4'' \| May 1 23:59:59 2033 GMT \| D1:40:65:0B:0A:A1:FC:54:DF:92:CB:46:98:53:37:C0 :68:21:47:27:77:09:47:D6:78:85:89:A5:20:07:EA:20 \|
-
-	====Client-Zertifikate====
-
-
-	Auch die CA-Zertifikate für Client-Zertifikate sind, je nach Algorithmus des Schlüssels, von der ''USERTrust RSA Certification Authority'' oder der ''USERTrust ECC Certificate Authority'' signiert.
-
-	Download: {{de:dfnpki:ca:tcs-client-certificate-ca-bundle.tar}}
-
-	^ CommonName ^ Einsatz ^ Gültigkeitsende ^ SHA256 Fingerprint \|
-	\| ''GEANT eScience Personal CA 4'' \| Bis 08/2023: IGTF-Zertifikatprofile \| May 1 23:59:59 2033 GMT \| D0:38:2A:C5:81:9F:95:AD:10:23:8C:BE:6E:3C:4E:D3 :D8:24:1C:D9:54:D2:65:3F:EA:47:0A:C9:F3:90:CD:4D \|
-	\| ''GEANT eScience Personal ECC CA 4'' \| Bis 08/2023: IGTF-Zertifikatprofile \| May 1 23:59:59 2033 GMT \| 60:21:D4:A3:CD:EB:D9:8D:52:98:23:5F:58:81:F4:B9 :69:D7:1D:43:F3:EE:3D:F1:56:BF:23:63:0B:07:AE:3B \|
-	\| ''GEANT Personal CA 4'' \| \| May 1 23:59:59 2033 GMT \| 16:D9:DE:94:5A:42:80:11:FA:3A:08:32:3D:A0:E4:34 :74:38:F5:AF:1C:E3:E8:02:83:22:3E:25:A4:6C:2A:9E \|
-	\| ''GEANT Personal ECC CA 4'' \| \| May 1 23:59:59 2033 GMT \| B1:A8:FD:40:B4:37:DE:D9:72:F5:74:37:06:22:E2:BB :B2:F9:B9:59:3B:C0:50:4D:7E:20:30:F2:B2:4E:67:FA \|
-
-
-	====Serverzertifikate====
-
-	Diese CA-Zertifikate sind, je nach Algorithmus des Schlüssels, von der ''USERTrust RSA Certification Authority'' oder der ''USERTrust ECC Certificate Authority'' signiert.
-
-	Download: {{de:dfnpki:ca:tcs-server-certificate-ca-bundle.tar}}
-
-	^ CommonName ^ Einsatz ^ Gültigkeitsende ^ SHA256 Fingerprint \|
-	\| ''GEANT eScience SSL CA 4'' \| IGTF-Zertifikatprofile \| May 1 23:59:59 2033 GMT \| 27:7F:0F:CA:26:3E:12:85:6D:BA:A4:DD:0A:DF:04:20 :4F:7F:98:CF:D7:2C:E9:C9:38:07:E3:77:E3:4C:88:76 \|
-	\| ''GEANT eScience SSL ECC CA 4'' \| IGTF-Zertifikatprofile \| May 1 23:59:59 2033 GMT \| CA:D0:3A:58:4E:58:53:9B:89:19:2E:C4:9C:EA:7A:6D :8E:D7:24:2A:D5:DC:DF:83:F9:6D:08:7F:09:F2:32:DB \|
-	\| ''GEANT EV RSA CA 4'' \| Extended Validation; Auch über ACME (''acme.sectigo.com/v2/GEANTEV'') ausgestellte Zertifikate \| May 1 23:59:59 2033 GMT \| DB:AC:2F:AE:4F:8C:94:9B:1A:30:CF:87:1E:AB:58:95 :7F:64:20:B7:97:A5:12:55:06:B8:CE:DD:48:F5:D7:84 \|
-	\| ''GEANT EV ECC CA 4'' \| Extended Validation; Auch über ACME (''acme.sectigo.com/v2/GEANTEV'') ausgestellte Zertifikate \| May 1 23:59:59 2033 GMT \| 86:0F:8E:49:84:FC:AA:AA:78:C8:7F:07:13:F2:03:18 :1B:57:D7:B5:56:FE:D9:79:CE:14:DC:A0:1F:FA:4A:54 \|
-	\| ''GEANT OV RSA CA 4'' \| Auch über ACME (''acme.sectigo.com/v2/GEANTOV'') ausgestellte Zertifikate \| May 1 23:59:59 2033 GMT \| 37:83:4F:A5:EA:40:FB:F7:B6:11:96:95:59:62:E1:CA :05:58:87:24:35:E4:20:66:53:D3:F6:20:DD:8E:98:8E \|
-	\| ''GEANT OV ECC CA 4'' \| Auch über ACME (''acme.sectigo.com/v2/GEANTOV'') ausgestellte Zertifikate \| May 1 23:59:59 2033 GMT \| 08:37:99:E8:B2:B9:01:6E:44:70:2E:BF:9B:F3:69:CE :25:3F:E1:FB:EB:65:0E:5D:F1:0E:F4:4D:87:BF:3B:AE \|
-	\| ''Sectigo RSA Organization Validation Secure Server CA'' \| Nur über ACME (''acme.sectigo.com/v2/OV'') ausgestellte Zertifikate \| Dec 31 23:59:59 2030 GMT \| 72:A3:4A:C2:B4:24:AE:D3:F6:B0:B0:47:55:B8:8C:C0 :27:DC:CC:80:6F:DD:B2:2B:4C:D7:C4:77:73:97:3E:C0 \|
-	\| ''Sectigo ECC Organization Validation Secure Server CA'' \| Nur über ACME (''acme.sectigo.com/v2/OV'') ausgestellte Zertifikate \| Dec 31 23:59:59 2030 GMT \| 34:57:10:67:52:40:02:12:90:3A:35:45:CA:3B:2E:F3 :84:A4:56:97:2B:D9:51:D8:D8:40:C1:B0:A3:79:EF:A1 \|
-
-	=====Private Zertifizierungshierarchie für Client-Zertifikate im Grid-Computing / IGTF / Authentifizierung=====
-
-	Seit 09/2023 werden Client-Zertifikate für Grid-Computing / IGTF / Authentifizierung in einer nicht im Browser oder Betriebssystem verankerten, privaten Zertifizierungshierarchie ausgestellt.
-
-	Dies betrifft alle Zertifikate, die in den folgenden Profilen ausgestellt werden:
-	* ''GÉANT Personal authentication''
-	* ''GÉANT Personal Automated Authentication''
-	* ''GÉANT Organisation Automated Authentication''
-
-	Diese Zertifikate sind daher nicht für S/MIME oder andere Anwendungen, die eine öffentlich vertraute Zertifizierungshierarchie voraussetzen, geeignet.
-
-	Download: {{de:dfnpki:ca:tcs-research-and-education-ca-bundle.tar}}
-
-	^ CommonName ^ Einsatz ^ Gültigkeitsende ^ SHA256 Fingerprint \|
-	\| Research and Education Trust ECC Root CA \| \| Jan 17 23:59:59 2038 GMT \| 02:92:55:E6:72:5E:56:96:C7:61:84:14:5C:8D: B5:30:6F:14:F8:51:A9:A4:6B:D5:10:D4:E9:BA:A6:AF:57:46 \|
-	\| Research and Education Trust RSA Root CA \| \| Jan 17 23:59:59 2038 GMT \| A5:B5:A2:77:1D:38:18:11:C0:91:E0:26:DE:C8: CD:51:9A:16:3D:AC:F4:3A:CA:B0:62:4C:B5:5C:0F:13:47:0B \|
-	\| GEANT TCS Authentication ECC CA 4B \| \| Jan 17 23:59:59 2038 GMT \| A9:12:9F:03:86:55:EA:9C:EF:F9:35:3E:7E:87: C7:63:2F:6F:D6:29:04:52:62:48:56:21:8A:3B:90:55:18:6E \|
-	\| GEANT TCS Authentication RSA CA 4B \| \| Jan 17 23:59:59 2038 GMT \| 88:31:FE:13:CB:9C:7C:D1:EC:00:EE:E5:F6:92: 28:9D:35:E2:7E:25:37:89:26:F6:AA:80:C1:E7:F2:C4:46:B2 \|
-
-	===== GÉANT TCS (HARICA 2025) CA-Zertifikate und CA-Zertifikatsketten für Server-Zertifikate =====
-
-	CA-Zertifikats-Bundle (inkl. moderner Root-CAs (2021) und Legacy-Root-CAs (2015) mit den dann nötigen Cross-CA-Zertifikaten): {{ :de:dfnpki:ca:tcs-harica-tls-ca-cert-bundle.zip \| tcs-harica-tls-ca-cert-bundle.zip}}
-
-	==== Wurzel-CA-Zertifikate (2021 - modern) für Server-Zertifikate ====
-
-	^ CommonName ^ Einsatz ^ Gültigkeitsende ^ SHA256/SHA1 Fingerprint \| \|
-	\| \| \| \| \| \|
-	\| ''HARICA TLS RSA Root CA 2021'' \| Root-CA (2021, modern) \| Feb 13 10:55:37 2045 GMT \| D9:5D:0E:8E:DA:79:52:5B:F9:BE:B1:1B:14:D2:10:0D:32:94:98:5F:0C:62:D9:FA:BD:9C:D9:99:EC:CB:7B:1D / 02:2D:05:82:FA:88:CE:14:0C:06:79:DE:7F:14:10:E9:45:D7:A5:6D \| {{ :de:dfnpki:ca:harica-tls-root-2021-rsa.cer \| .cer}} {{ :de:dfnpki:ca:harica-tls-root-2021-rsa.pem \| .pem}} {{ :de:dfnpki:ca:harica-tls-root-2021-rsa.txt \| .txt}}\|
-	\| ''HARICA TLS ECC Root CA 2021'' \| Root-CA (2021, modern) \| Feb 13 11:01:09 2045 GMT \| 3F:99:CC:47:4A:CF:CE:4D:FE:D5:87:94:66:5E:47:8D:15:47:73:9F:2E:78:0F:1B:B4:CA:9B:13:30:97:D4:01 / BC:B0:C1:9D:E9:98:92:70:19:38:57:E9:8D:A7:B4:5D:6E:EE:01:48 \| {{ :de:dfnpki:ca:harica-tls-root-2021-ecc.cer \| .cer}} {{ :de:dfnpki:ca:harica-tls-root-2021-ecc.pem \| .pem}} {{ :de:dfnpki:ca:harica-tls-root-2021-ecc.txt \| .txt}}\|
-	==== Wurzel-CA-Zertifikate (2015 - legacy) für Server-Zertifikate ====
-
-	Alternative CA-Ketten können zusammen mit Cross-CA-Zertifikaten erstellt werden, die in der ''Hellenic Academic and Research Institutions RootCA 2015'' (RSA) bzw.
-	''Hellenic Academic and Research Institutions ECC RootCA 2015'' (ECC) enden. Diese Legacy-Ketten wären für sehr alte Betriebssysteme bzw. Browser und Java openJDK ab Version 16 notwendig.
-
-	^ CommonName ^ Einsatz ^ Gültigkeitsende ^ SHA256/SHA1 Fingerprint \| \|
-	\| \| \| \| \| \|
-	\| ''HARICA TLS RSA Root CA 2021'' \| Cross-CA (2021 -> 2015) \| Aug 31 07:41:54 2029 GMT \| 4A:CD:8D:C6:02:0A:54:5A:85:89:43:A5:53:B5:E0:F3:FC:5B:85:9A:EA:17:46:65:0D:69:CF:12:10:F9:56:D8 / 71:40:C4:0C:28:00:A5:C6:05:23:CE:BF:68:2D:13:4E:D1:7E:DB:0E \| {{ :de:dfnpki:ca:harica-tls-root-2021-rsa-cross.cer \| .cer}} {{ :de:dfnpki:ca:harica-tls-root-2021-rsa-cross.pem \| .pem}} {{ :de:dfnpki:ca:harica-tls-root-2021-rsa-cross.txt \| .txt}}\|
-	\| ''HARICA TLS ECC Root CA 2021'' \| Cross-CA (2021 -> 2015) \| Aug 31 07:44:36 2029 GMT \| 50:E2:7F:90:EB:6A:F4:95:B0:E6:EE:B6:55:CC:89:44:4C:27:D3:C9:5B:68:23:FA:02:AB:DC:95:F1:63:6A:E1 / 45:60:36:00:DC:2F:9E:51:CD:C8:7E:73:3E:70:F4:CA:6F:5F:31:BD \| {{ :de:dfnpki:ca:harica-tls-root-2021-ecc-cross.cer \| .cer}} {{ :de:dfnpki:ca:harica-tls-root-2021-ecc-cross.pem \| .pem}} {{ :de:dfnpki:ca:harica-tls-root-2021-ecc-cross.txt \| .txt}}\|
-	\| ''Hellenic Academic and Research Institutions RootCA 2015'' \| Root-CA (2015, legacy) \| Jun 30 10:11:21 2040 GMT \| A0:40:92:9A:02:CE:53:B4:AC:F4:F2:FF:C6:98:1C:E4:49:6F:75:5E:6D:45:FE:0B:2A:69:2B:CD:52:52:3F:36 / 01:0C:06:95:A6:98:19:14:FF:BF:5F:C6:B0:B6:95:EA:29:E9:12:A6 \| {{ :de:dfnpki:ca:haricarootca2015.cer \| .cer}} {{ :de:dfnpki:ca:haricarootca2015.pem \| .pem}} {{ :de:dfnpki:ca:haricarootca2015.txt \| .txt}}\|
-	\| ''Hellenic Academic and Research Institutions ECC RootCA 2015'' \| Root-CA (2015, legacy) \| Jun 30 10:37:12 2040 GMT \| 44:B5:45:AA:8A:25:E6:5A:73:CA:15:DC:27:FC:36:D2:4C:1C:B9:95:3A:06:65:39:B1:15:82:DC:48:7B:48:33 / 9F:F1:71:8D:92:D5:9A:F3:7D:74:97:B4:BC:6F:84:68:0B:BA:B6:66 \| {{ :de:dfnpki:ca:haricaeccrootca2015.cer \| .cer}} {{ :de:dfnpki:ca:haricaeccrootca2015.pem \| .pem}} {{ :de:dfnpki:ca:haricaeccrootca2015.txt \| .txt}}\|
-	====Server-Zertifikate====
-
-	Diese CA-Zertifikate sind, je nach Algorithmus des Schlüssels, von der ''HARICA TLS RSA Root CA 2021'' oder der ''HARICA TLS ECC Root CA 2021'' (bzw. deren Cross-CA-Varianten für die Ableitung auf die Legacy-Root-CAs) signiert.
-
-	Aktuell (seit dem 06.03.2025) werden alle Server-Zertifikate aus GÉANT TCS (HARICA 2025) von diesen spezifischen GÉANT TCS CAs ausgestellt, je nach Algorithmus des Schlüssels (RSA / ECC):
-
-	^ CommonName ^ Einsatz ^ Gültigkeitsende ^ SHA256/SHA1 Fingerprint \| \|
-	\| \| \| \| \| \|
-	\| ''GEANT TLS ECC 1'' \| Issuing-CA \| Dec 31 11:14:20 2039 GMT \| 6C:DF:0B:A1:71:1E:85:6D:22:8B:A0:0C:A0:4C:5C:1C:3D:79:94:4C:03:7B:71:3B:15:5A:4E:E4:B4:7E:C5:3C / CC:73:33:46:67:05:F1:43:BE:7D:76:DD:B8:E7:74:40:7A:3D:91:C8 \| {{ :de:dfnpki:ca:harica-geant-tls-e1.cer \| .cer}} {{ :de:dfnpki:ca:harica-geant-tls-e1.pem \| .pem}} {{ :de:dfnpki:ca:harica-geant-tls-e1.txt \| .txt}}\|
-	\| ''GEANT TLS RSA 1'' \| Issuing-CA \| Dec 31 11:14:59 2039 GMT \| 5B:67:8D:C4:40:95:A5:28:95:B6:3B:31:F2:72:27:F4:B3:6C:3E:34:74:91:BF:2B:FA:69:18:37:A5:FB:8C:79 / BE:7F:0B:36:F8:8A:22:DD:DE:D3:62:DB:9A:F7:9C:8E:65:82:B9:19 \| {{ :de:dfnpki:ca:harica-geant-tls-r1.cer \| .cer}} {{ :de:dfnpki:ca:harica-geant-tls-r1.pem \| .pem}} {{ :de:dfnpki:ca:harica-geant-tls-r1.txt \| .txt}}\|
-
-	Bis zum 06.03.2025 wurden alle Server-Zertifikate aus GÉANT TCS (HARICA 2025) von diesen allgemeine HARICA TLS CAs ausgestellt, je nach Algorithmus des Schlüssels (''RSA'' / ''ECC'') und der gewählten Validierungsart
-	(''OV'' - Organisation Validated / ''DV'' - Domain Validated):
-
-	^ CommonName ^ Einsatz ^ Gültigkeitsende ^ SHA256/SHA1 Fingerprint \| \|
-	\| \| \| \| \| \|
-	\| ''HARICA DV TLS ECC'' \| Issuing-CA \| Mar 15 09:22:32 2036 GMT \| 39:23:77:A7:19:E3:E6:5A:40:D8:65:1B:92:36:1D:B9:53:20:B3:9C:A3:61:07:2A:3A:3C:F4:2C:66:E0:0D:BC / E9:BA:65:6D:63:71:E4:75:50:97:D7:37:53:8E:45:4B:5D:E5:F1:5D \| {{ :de:dfnpki:ca:harica-dv-tls-sub-e1.cer \| .cer}} {{ :de:dfnpki:ca:harica-dv-tls-sub-e1.pem \| .pem}} {{ :de:dfnpki:ca:harica-dv-tls-sub-e1.txt \| .txt}}\|
-	\| ''HARICA DV TLS RSA'' \| Issuing-CA \| Mar 15 09:24:03 2036 GMT \| 28:10:1E:E3:CD:2F:F6:F2:25:FB:F0:ED:E9:4A:B5:0D:67:62:AF:DB:AB:96:4F:7C:9D:3C:CF:7F:02:EE:98:38 / 53:4A:55:0E:D7:DA:3C:97:6E:82:5D:A8:0A:8C:C2:4D:69:E9:92:F8 \| {{ :de:dfnpki:ca:harica-dv-tls-sub-r1.cer \| .cer}} {{ :de:dfnpki:ca:harica-dv-tls-sub-r1.pem \| .pem}} {{ :de:dfnpki:ca:harica-dv-tls-sub-r1.txt \| .txt}}\|
-	\| ''HARICA OV TLS ECC'' \| Issuing-CA \| Mar 15 09:33:51 2036 GMT \| 32:93:50:0C:AA:50:7B:1E:92:0A:44:1F:27:7B:AD:CB:B7:50:02:CA:EC:62:82:D2:3A:35:78:F7:81:7D:23:80 / 15:5C:A9:53:5D:FE:9B:16:3E:20:1E:71:7F:C9:B0:DE:1E:49:FD:2C \| {{ :de:dfnpki:ca:harica-ov-tls-sub-e1.cer \| .cer}} {{ :de:dfnpki:ca:harica-ov-tls-sub-e1.pem \| .pem}} {{ :de:dfnpki:ca:harica-ov-tls-sub-e1.txt \| .txt}}\|
-	\| ''HARICA OV TLS RSA'' \| Issuing-CA \| Mar 15 09:34:16 2036 GMT \| 9F:BD:88:69:45:FB:6C:B6:3E:EB:F1:10:77:DA:C9:80:E4:53:68:D2:45:8B:A5:EF:0A:8D:72:70:46:FC:D2:92 / 0E:B2:CA:9D:D9:89:CF:6E:A0:89:EF:48:10:05:80:E7:5F:E4:52:90 \| {{ :de:dfnpki:ca:harica-ov-tls-sub-r1.cer \| .cer}} {{ :de:dfnpki:ca:harica-ov-tls-sub-r1.pem \| .pem}} {{ :de:dfnpki:ca:harica-ov-tls-sub-r1.txt \| .txt}}\|
-
-
-	===== GÉANT TCS (HARICA 2025) CA-Zertifikate und CA-Zertifikatsketten für S/MIME-Zertifikate =====
-
-	CA-Zertifikats-Bundle mit moderner Root-CA (2021): {{ :de:dfnpki:ca:tcs-harica-smime-ca-cert-bundle.zip \| tcs-harica-smime-ca-cert-bundle.zip}}
-
-	==== Wurzel-CA-Zertifikate (2021) für S/MIME-Zertifikate ====
-
-	^ CommonName ^ Einsatz ^ Gültigkeitsende ^ SHA256/SHA1 Fingerprint \| \|
-	\| \| \| \| \| \|
-	\| ''HARICA Client RSA Root CA 2021'' \| Root-CA (2021, modern) \| Feb 13 10:58:45 2045 GMT \| 1B:E7:AB:E3:06:86:B1:63:48:AF:D1:C6:1B:68:66:A0 :EA:7F:48:21:E6:7D:5E:8A:F9:37:CF:80:11:BC:75:0D / 46:C6:90:0A:77:3A:B6:BC:F4:65:AD:AC:FC:E3:F7:07:00:6E:DE:6E \| {{ :de:dfnpki:ca:harica-client-root-2021-rsa.cer \| .cer}} {{ :de:dfnpki:ca:harica-client-root-2021-rsa.pem \| .pem}} {{ :de:dfnpki:ca:harica-client-root-2021-rsa.txt \| .txt}}\|
-	\| ''HARICA Client ECC Root CA 2021'' \| Root-CA (2021, modern) \| Feb 13 11:03:33 2045 GMT \| 8D:D4:B5:37:3C:B0:DE:36:76:9C:12:33:92:80:D8:27 :46:B3:AA:6C:D4:26:E7:97:A3:1B:AB:E4:27:9C:F0:0B / BE:64:D3:DA:14:4B:D2:6B:CD:AF:8F:DB:A6:A6:72:F8:DE:26:F9:00 \| {{ :de:dfnpki:ca:harica-client-root-2021-ecc.cer \| .cer}} {{ :de:dfnpki:ca:harica-client-root-2021-ecc.pem \| .pem}} {{ :de:dfnpki:ca:harica-client-root-2021-ecc.txt \| .txt}}\|
-
-	====S/MIME-Zertifikate====
-
-	Diese CA-Zertifikate sind, je nach Algorithmus des Schlüssels, von der ''HARICA Client RSA Root CA 2021'' oder der ''HARICA Client ECC Root CA 2021'' signiert.
-
-	Aktuell (seit dem 06.03.2025) werden alle S/MIME-Zertifikate aus GÉANT TCS (HARICA 2025) von diesen spezifischen GÉANT TCS S/MIME CAs ausgestellt, je nach Algorithmus des Schlüssels (''RSA'' / ''ECC''):
-
-	^ CommonName ^ Einsatz ^ Gültigkeitsende ^ SHA256/SHA1 Fingerprint \| \|
-	\| \| \| \| \| \|
-	\| ''GEANT S/MIME RSA 1'' \| Issuing-CA \| Dec 31 11:13:07 2039 GMT \| 14:9C:1F:AC:7D:B7:AF:88:68:89:7D:18:52:9E:67:98 :DA:20:C0:45:64:39:80:2B:4C:C8:22:3F:A1:E4:76:B3 / 8D:45:56:68:2A:35:09:BE:EA:90:1B:0D:C7:8C:F8:0D:C6:F0:2A:CA \| {{ :de:dfnpki:ca:harica-geant-smime-r1.cer \| .cer}} {{ :de:dfnpki:ca:harica-geant-smime-r1.pem \| .pem}} {{ :de:dfnpki:ca:harica-geant-smime-r1.txt \| .txt}}\|
-	\| ''GEANT S/MIME ECC 1'' \| Issuing-CA \| Dec 31 11:11:39 2039 GMT \| 6E:F2:FE:A6:4B:86:A6:12:03:FC:7D:53:F2:F2:12:A8 :E3:FB:E0:85:93:4D:60:A5:A8:8A:BF:46:DC:C2:11:4A / 57:B1:33:3A:E7:FB:B2:AC:53:0B:D8:FF:09:A0:2F:24:AA:19:DB:D8 \| {{ :de:dfnpki:ca:harica-geant-smime-e1.cer \| .cer}} {{ :de:dfnpki:ca:harica-geant-smime-e1.pem \| .pem}} {{ :de:dfnpki:ca:harica-geant-smime-e1.txt \| .txt}}\|
-
-	Bis zum 06.03.2025 wurden alle S/MIME-Zertifikate aus GÉANT TCS (HARICA 2025) von diesen allgemeinen HARICA S/MIME CAs ausgestellt, je nach Algorithmus des Schlüssels (RSA / ECC):
-
-	^ CommonName ^ Einsatz ^ Gültigkeitsende ^ SHA256/SHA1 Fingerprint \| \|
-	\| \| \| \| \| \|
-	\| ''HARICA S/MIME RSA'' \| Issuing-CA \| Mar 15 09:37:37 2036 GMT \| B1:3E:C3:01:E7:BF:E1:DD:B9:C5:BF:C0:71:DC:29:C5 :5E:82:EE:93:32:73:A2:31:34:94:6F:BD:FD:3A:CE:63 / E3:E5:43:9B:68:46:4C:59:DA:8A:C6:7A:54:73:71:0C:FD:11:26:8B \| {{ :de:dfnpki:ca:harica-smime-sub-r1.cer \| .cer}} {{ :de:dfnpki:ca:harica-smime-sub-r1.pem \| .pem}} {{ :de:dfnpki:ca:harica-smime-sub-r1.txt \| .txt}}\|
-	\| ''HARICA S/MIME ECC'' \| Issuing-CA \| Mar 15 09:36:57 2036 GMT \| E5:CB:D6:65:91:90:C6:18:88:97:D0:9E:1A:D6:2A:4F :B7:3C:E1:1D:87:27:A4:47:6D:3C:57:9F:0E:15:99:F9 / A5:CD:8B:53:A4:7A:BC:8F:0F:6E:CA:88:3B:2F:2D:08:48:D7:6C:B9 \| {{ :de:dfnpki:ca:harica-smime-sub-e1.cer \| .cer}} {{ :de:dfnpki:ca:harica-smime-sub-e1.pem \| .pem}} {{ :de:dfnpki:ca:harica-smime-sub-e1.txt \| .txt}}\|
-
-
-	===== Private Zertifizierungshierarchie für Client-Zertifikate im Grid-Computing / IGTF / Authentifizierung =====
-
-	Seit 05/2025 werden von HARICA im Rahmen von TCS auch Client-Zertifikate für Grid-Computing / IGTF / Authentifizierung in einer nicht im Browser oder Betriebssystem verankerten, privaten Zertifizierungshierarchie ausgestellt.
-
-	Dies betrifft alle Zertifikate, die im HARICA-System über den individuellen Antragsweg ''IGTF Client Auth'' beantragt werden.
-
-	Diese Zertifikate sind daher nicht für S/MIME oder andere Anwendungen, die eine öffentlich vertraute Zertifizierungshierarchie voraussetzen, geeignet.
-
-	CA-Zertifikats-Bundle: {{ :de:dfnpki:ca:tcs-geant-client-auth-ca-cert-bundle.zip \| tcs-geant-client-auth-ca-cert-bundle.zip}}
-
-	^ CommonName ^ Einsatz ^ Gültigkeitsende ^ SHA256/SHA1 Fingerprint \| \|
-	\| \| \| \| \| \|
-	\| ''Research and Education Trust RSA Root CA 5'' \| Private Root-CA (2025) \| Feb 5 16:55:07 2049 GMT \| 6D:F2:54:D6:12:C0:FC:70:00:E9:96:77:D7:9E:65:27:65:21:9A:27:06:26:8C:FF:EC:C1:FD:14:35:17:3E:81 / 44:9D:FA:FA:B8:F8:40:CC:1F:9D:7A:F9:BE:93:72:35:14:3C:71:0B \| {{ :de:dfnpki:ca:geant-tcs-root-r5.cer \| .cer}} {{ :de:dfnpki:ca:geant-tcs-root-r5.pem \| .pem}} {{ :de:dfnpki:ca:geant-tcs-root-r5.txt \| .txt}}\|
-	\| ''Research and Education Trust ECC Root CA 5'' \| Private Root-CA (2025) \| Feb 5 16:53:16 2049 GMT \| 48:4E:E1:8D:FD:24:EB:31:4C:54:C8:DD:6C:F2:48:05:79:C8:E2:A9:67:22:2B:E5:DA:6B:2F:0F:CF:3C:6A:20 / 2D:1F:B8:B8:78:5B:03:2B:C0:E4:0A:43:83:5E:6F:A2:48:AB:75:2B \| {{ :de:dfnpki:ca:geant-tcs-root-e5.cer \| .cer}} {{ :de:dfnpki:ca:geant-tcs-root-e5.pem \| .pem}} {{ :de:dfnpki:ca:geant-tcs-root-e5.txt \| .txt}}\|
-	\| ''GEANT TCS Authentication RSA CA 5'' \| Private Issuing-CA \| Feb 8 17:00:17 2040 GMT \| 9D:BE:96:FF:77:20:23:62:51:4A:DE:0C:33:77:7C:A9:BB:D7:17:F3:B4:F0:6C:67:6B:DC:9C:32:49:18:B9:D3 / 3E:5A:BA:94:11:1B:54:A3:86:19:1F:42:69:AD:1A:59:58:ED:0E:3D \| {{ :de:dfnpki:ca:geant-tcs-client-auth-r5.cer \| .cer}} {{ :de:dfnpki:ca:geant-tcs-client-auth-r5.pem \| .pem}} {{ :de:dfnpki:ca:geant-tcs-client-auth-r5.txt \| .txt}}\|
-	\| ''GEANT TCS Authentication ECC CA 5'' \| Private Issuing-CA \| Feb 8 16:57:54 2040 GMT \| 3B:DD:A1:14:FC:6D:52:28:95:22:26:D5:77:5C:CC:F7:AA:6F:AE:64:ED:BF:D7:96:12:04:E6:B6:34:35:69:49 / 95:45:0E:B1:BB:D3:E0:DE:5A:FC:BE:86:01:12:52:08:00:F7:7A:85 \| {{ :de:dfnpki:ca:geant-tcs-client-auth-e5.cer \| .cer}} {{ :de:dfnpki:ca:geant-tcs-client-auth-e5.pem \| .pem}} {{ :de:dfnpki:ca:geant-tcs-client-auth-e5.txt \| .txt}}\|

tcs_smimebr_changes

Anonymous (anonymous@undisclosed.example.com) — 2025-06-05T11:40:16+00:00

2023/11/17 15:33		aktuell
Zeile 3:		Zeile 3:
	Die folgenden Punkte sind zu beachten, wenn Sie bereits in GÉANT TCS User-Zertifikate ausstellen. Voraussetzung für die Anwendung dieser Anleitung ist, dass Ihre Organisation bereits nach den neuen Regeln revalidiert wurde. Ob dies bereits der Fall ist, können Sie nicht selbstständig im Sectigo System SCM sehen. Die DFN-PCA informiert Einrichtungen, wenn die Revalidierung abgeschlossen ist.		Die folgenden Punkte sind zu beachten, wenn Sie bereits in GÉANT TCS User-Zertifikate ausstellen. Voraussetzung für die Anwendung dieser Anleitung ist, dass Ihre Organisation bereits nach den neuen Regeln revalidiert wurde. Ob dies bereits der Fall ist, können Sie nicht selbstständig im Sectigo System SCM sehen. Die DFN-PCA informiert Einrichtungen, wenn die Revalidierung abgeschlossen ist.

-	Wenn Sie eine Anleitung für die erste Einrichtung von User-Zertifikaten suchen, schauen Sie bitte in die [[de:dfnpki:tcs:usercert\|FAQ zu Nutzerzertifikaten]]	+	Wenn Sie eine Anleitung für die erste Einrichtung von User-Zertifikaten suchen, schauen Sie bitte in die [[de:dfnpki:tcs:2020:usercert\|FAQ zu Nutzerzertifikaten]]

	=====Zertifikate für sichere E-Mail - S/MIME=====		=====Zertifikate für sichere E-Mail - S/MIME=====
Zeile 26:		Zeile 26:
	Es gibt von Sectigo derzeit keine konkreten zusätzlichen Verfahrensanweisungen, um einen Validation Type 'HIGH' zu setzen.		Es gibt von Sectigo derzeit keine konkreten zusätzlichen Verfahrensanweisungen, um einen Validation Type 'HIGH' zu setzen.

-	Die Anforderungen, die im TCS CPS an die Identifizierung und die Dokumentation festgehalten sind, gelten weiterhin. Siehe hierzu [[de:dfnpki:tcs:usercert#identifizierung_und_dokumentation\|Identifizierung und Dokumentation]] in der FAQ.	+	Die Anforderungen, die im TCS CPS an die Identifizierung und die Dokumentation festgehalten sind, gelten weiterhin. Siehe hierzu [[de:dfnpki:tcs:2020:usercert#identifizierung_und_dokumentation\|Identifizierung und Dokumentation]] in der FAQ.

	====GÉANT Organisation email signing====		====GÉANT Organisation email signing====

verzeichnisdienst

Anonymous (anonymous@undisclosed.example.com) — 2024-09-13T15:45:25+00:00

2024/06/04 15:24		aktuell
Zeile 15:		Zeile 15:
	* Gültige Nutzerzertifikate aus der [[de:dfnpki:global#einfuehrung\|DFN-PKI Global]], deren Veröffentlichung bei der Beantragung zugestimmt wurde. Abgelaufene und gesperrte Zertifikate werden entfernt.		* Gültige Nutzerzertifikate aus der [[de:dfnpki:global#einfuehrung\|DFN-PKI Global]], deren Veröffentlichung bei der Beantragung zugestimmt wurde. Abgelaufene und gesperrte Zertifikate werden entfernt.

-	* S/MIME-Zertifikate aus [[de:dfnpki:tcs\|GÉANT TCS]], deren Einrichtungen sicherstellen, dass diese veröffentlicht werden dürfen und die mit uns eine Vereinbarung getroffen haben. Achtung: Aufgrund dieser speziellen Bedingungen wird der Großteil der S/MIME-Zertifikate nicht in Verzeichnis veröffentlicht.	+	* S/MIME-Zertifikate aus [[de:dfnpki:tcs\|GÉANT TCS]], deren Einrichtungen sicherstellen, dass diese veröffentlicht werden dürfen und die mit uns eine Vereinbarung getroffen haben. Achtung: Aufgrund dieser speziellen Bedingungen wird der Großteil der S/MIME-Zertifikate nicht in diesem Verzeichnis veröffentlicht.

	Zertifikate aus der [[de:dfnpki:dfnvereincommunitypki\|DFN-Verein Community PKI]] werden nicht veröffentlicht, da diese aufgrund der fehlenden Verankerung in E-Mail-Programmen nicht vorrangig für S/MIME-Nutzung vorgesehen sind.		Zertifikate aus der [[de:dfnpki:dfnvereincommunitypki\|DFN-Verein Community PKI]] werden nicht veröffentlicht, da diese aufgrund der fehlenden Verankerung in E-Mail-Programmen nicht vorrangig für S/MIME-Nutzung vorgesehen sind.

zeitstempeldienst

Anonymous (anonymous@undisclosed.example.com) — 2026-04-29T11:45:01+00:00

2026/04/29 13:44		aktuell
Zeile 5:		Zeile 5:
	Der Zeitstempelserver ist zu erreichen unter: <code>https://zeitstempel.dfn.de/</code>		Der Zeitstempelserver ist zu erreichen unter: <code>https://zeitstempel.dfn.de/</code>

-	Wichtige anstehende Änderung: Ab dem 23.06.2026 wird das Signier-Zertifikat des Dienstes aus der DFN-Verein Community-PKI stammen, und nicht mehr aus der DFN-PKI Global	+	Wichtige anstehende Änderung: Ab dem 23.06.2026 wird das Signier-Zertifikat des Dienstes aus der DFN-Verein Community-PKI stammen, und nicht mehr aus der DFN-PKI Global.

2024/02/01 15:51		aktuell
Zeile 7:		Zeile 7:

	* {{:de:dfnpki:dokumentensignatur_2022.pdf \|Technische und rechtliche Aspekte bei Dokumentensignaturen}}		* {{:de:dfnpki:dokumentensignatur_2022.pdf \|Technische und rechtliche Aspekte bei Dokumentensignaturen}}
-
-	* [[:de:dfnpki:tcs:documentsigning\|Dokumentensignatur in GÉANT TCS]]

	* [[:de:dfnpki:dfnvereincommunitypki:documentsigning\|Dokumentensignatur in der DFN-Verein Community-PKI]]		* [[:de:dfnpki:dfnvereincommunitypki:documentsigning\|Dokumentensignatur in der DFN-Verein Community-PKI]]

2024/08/12 11:31		aktuell
Zeile 49:		Zeile 49:
	\|1.3.6.1.4.1.22177.300.1.1.4.13 \|Major Version 13: Zertifizierungsrichtlinie der DFN-PKI - Sicherheitsniveau Global - Version 13 \|		\|1.3.6.1.4.1.22177.300.1.1.4.13 \|Major Version 13: Zertifizierungsrichtlinie der DFN-PKI - Sicherheitsniveau Global - Version 13 \|
	\|1.3.6.1.4.1.22177.300.1.1.4.14 \|Major Version 14: Zertifizierungsrichtlinie der DFN-PKI - Sicherheitsniveau Global - Version 14 \|		\|1.3.6.1.4.1.22177.300.1.1.4.14 \|Major Version 14: Zertifizierungsrichtlinie der DFN-PKI - Sicherheitsniveau Global - Version 14 \|
		+	\|1.3.6.1.4.1.22177.300.1.1.4.15 \|Major Version 15: Zertifizierungsrichtlinie der DFN-PKI - Sicherheitsniveau Global - Version 15 \|
	\| \| \|		\| \| \|
	\| \| \|		\| \| \|
Zeile 89:		Zeile 90:
	\|1.3.6.1.4.1.22177.300.2.1.4.13 \|Major Version 13: Erklärung zum Zertifizierungsbetrieb der DFN-PKI - Sicherheitsniveau Global - Version 13 \|		\|1.3.6.1.4.1.22177.300.2.1.4.13 \|Major Version 13: Erklärung zum Zertifizierungsbetrieb der DFN-PKI - Sicherheitsniveau Global - Version 13 \|
	\|1.3.6.1.4.1.22177.300.2.1.4.14 \|Major Version 14: Erklärung zum Zertifizierungsbetrieb der DFN-PKI - Sicherheitsniveau Global - Version 14 \|		\|1.3.6.1.4.1.22177.300.2.1.4.14 \|Major Version 14: Erklärung zum Zertifizierungsbetrieb der DFN-PKI - Sicherheitsniveau Global - Version 14 \|
		+	\|1.3.6.1.4.1.22177.300.2.1.4.15 \|Major Version 15: Erklärung zum Zertifizierungsbetrieb der DFN-PKI - Sicherheitsniveau Global - Version 15 \|
	\| \| \|		\| \| \|
	\| \| \|		\| \| \|

2024/06/04 15:24		aktuell
Zeile 15:		Zeile 15:
	* Gültige Nutzerzertifikate aus der [[de:dfnpki:global#einfuehrung\|DFN-PKI Global]], deren Veröffentlichung bei der Beantragung zugestimmt wurde. Abgelaufene und gesperrte Zertifikate werden entfernt.		* Gültige Nutzerzertifikate aus der [[de:dfnpki:global#einfuehrung\|DFN-PKI Global]], deren Veröffentlichung bei der Beantragung zugestimmt wurde. Abgelaufene und gesperrte Zertifikate werden entfernt.

-	* S/MIME-Zertifikate aus [[de:dfnpki:tcs\|GÉANT TCS]], deren Einrichtungen sicherstellen, dass diese veröffentlicht werden dürfen und die mit uns eine Vereinbarung getroffen haben. Achtung: Aufgrund dieser speziellen Bedingungen wird der Großteil der S/MIME-Zertifikate nicht in Verzeichnis veröffentlicht.	+	* S/MIME-Zertifikate aus [[de:dfnpki:tcs\|GÉANT TCS]], deren Einrichtungen sicherstellen, dass diese veröffentlicht werden dürfen und die mit uns eine Vereinbarung getroffen haben. Achtung: Aufgrund dieser speziellen Bedingungen wird der Großteil der S/MIME-Zertifikate nicht in diesem Verzeichnis veröffentlicht.

	Zertifikate aus der [[de:dfnpki:dfnvereincommunitypki\|DFN-Verein Community PKI]] werden nicht veröffentlicht, da diese aufgrund der fehlenden Verankerung in E-Mail-Programmen nicht vorrangig für S/MIME-Nutzung vorgesehen sind.		Zertifikate aus der [[de:dfnpki:dfnvereincommunitypki\|DFN-Verein Community PKI]] werden nicht veröffentlicht, da diese aufgrund der fehlenden Verankerung in E-Mail-Programmen nicht vorrangig für S/MIME-Nutzung vorgesehen sind.

2021/12/09 12:27		aktuell
Zeile 6:		Zeile 6:
	====== Fortgeschrittene elektronische Signatur =====		====== Fortgeschrittene elektronische Signatur =====
	Die fortgeschrittene elektronische Signatur muss dagegen bestimmte Anforderungen i.S.d. Art. 26 eIDAS erfüllen. Diese wird dem oder der Unterzeichnenden eindeutig zugeordnet und ermöglicht die Identifizierung dieser Person. Darüber hinaus muss die unterzeichnende Person die Signatur unter Verwendung elektronischer Signaturerstellungsdaten erstellen, die nur von dieser Person genutzt werden können. In der Praxis wird dies beispielsweise durch eine TAN-Abfrage über die persönliche Mobilfunknummer erreicht. Diese Signaturdaten werden so mit dem elektronischen Dokument verbunden, dass eine nachträgliche Veränderung auch von Dritten erkannt werden kann. Durch diese Anforderungen erhöht sich die Beweiskraft im Rechtsverkehr, weshalb sie sich für sämtlichen Rechtsverkehr ohne spezielle Formanforderungen eignet, wie z.B. Angebote oder Verträge.		Die fortgeschrittene elektronische Signatur muss dagegen bestimmte Anforderungen i.S.d. Art. 26 eIDAS erfüllen. Diese wird dem oder der Unterzeichnenden eindeutig zugeordnet und ermöglicht die Identifizierung dieser Person. Darüber hinaus muss die unterzeichnende Person die Signatur unter Verwendung elektronischer Signaturerstellungsdaten erstellen, die nur von dieser Person genutzt werden können. In der Praxis wird dies beispielsweise durch eine TAN-Abfrage über die persönliche Mobilfunknummer erreicht. Diese Signaturdaten werden so mit dem elektronischen Dokument verbunden, dass eine nachträgliche Veränderung auch von Dritten erkannt werden kann. Durch diese Anforderungen erhöht sich die Beweiskraft im Rechtsverkehr, weshalb sie sich für sämtlichen Rechtsverkehr ohne spezielle Formanforderungen eignet, wie z.B. Angebote oder Verträge.
-	===== Qualifizierte elektronische Signatur =====	+	====== Qualifizierte elektronische Signatur ======
	Die qualifizierte elektronische Signatur ist gemäß Art. 3 Nr. 12 eIDAS-VO „eine fortgeschrittene elektronische Signatur, die von einer qualifizierten elektronischen Signaturerstellungseinheit erstellt wurde und auf einem qualifizierten Zertifikat für elektronische Signaturen beruht.“ Damit ist zusätzlich zu den Anforderungen der fortgeschrittenen Signatur (s.o.) eine sichere Signaturerstellungseinheit bei der Erstellung zu verwenden und die Signatur muss auf einem qualifizierten Zertifikat beruhen. Dieses Zertifikat muss von einer unabhängigen Zertifizierungsstelle ausgestellt werden. Diese Zertifizierungsstellen werden vom Bundesamt für Sicherheit in der Informationstechnik (BSI) bzw. im europäischen Ausland von einer gleichwertigen Stelle kontrolliert. Mit dem qualifizierten Zertifikat und dessen privaten Schlüssel kann mit Hilfe einer Signaturkarte oder per Fernsignatur die vorzunehmende elektronische Signatur von der unterzeichnenden Person eingesetzt werden.		Die qualifizierte elektronische Signatur ist gemäß Art. 3 Nr. 12 eIDAS-VO „eine fortgeschrittene elektronische Signatur, die von einer qualifizierten elektronischen Signaturerstellungseinheit erstellt wurde und auf einem qualifizierten Zertifikat für elektronische Signaturen beruht.“ Damit ist zusätzlich zu den Anforderungen der fortgeschrittenen Signatur (s.o.) eine sichere Signaturerstellungseinheit bei der Erstellung zu verwenden und die Signatur muss auf einem qualifizierten Zertifikat beruhen. Dieses Zertifikat muss von einer unabhängigen Zertifizierungsstelle ausgestellt werden. Diese Zertifizierungsstellen werden vom Bundesamt für Sicherheit in der Informationstechnik (BSI) bzw. im europäischen Ausland von einer gleichwertigen Stelle kontrolliert. Mit dem qualifizierten Zertifikat und dessen privaten Schlüssel kann mit Hilfe einer Signaturkarte oder per Fernsignatur die vorzunehmende elektronische Signatur von der unterzeichnenden Person eingesetzt werden.
	Eine qualifizierte elektronische Signatur hat zunächst die gleiche Rechtswirkung wie eine handschriftliche Unterschrift (Art. 25 Abs. 2 eIDAS-VO). Im digitalen Rechtsverkehr ist sie jedoch nur erforderlich, sofern ein Schriftformerfordernis (§§ 126 f. BGB) vorliegt oder das Gesetz eine solche verlangt (z.B. § 130a Abs. 3 ZPO). Soweit keine besonderen Formerfordernisse vorliegen, ist bei einer digitalen Unterzeichnung keine besondere Form der Signatur vorzunehmen. Doch wie schon oben beschrieben, ist es aufgrund der Beweiskraft zu empfehlen, eine fortgeschrittene bzw. qualifizierte elektronische Signatur zu verwenden.		Eine qualifizierte elektronische Signatur hat zunächst die gleiche Rechtswirkung wie eine handschriftliche Unterschrift (Art. 25 Abs. 2 eIDAS-VO). Im digitalen Rechtsverkehr ist sie jedoch nur erforderlich, sofern ein Schriftformerfordernis (§§ 126 f. BGB) vorliegt oder das Gesetz eine solche verlangt (z.B. § 130a Abs. 3 ZPO). Soweit keine besonderen Formerfordernisse vorliegen, ist bei einer digitalen Unterzeichnung keine besondere Form der Signatur vorzunehmen. Doch wie schon oben beschrieben, ist es aufgrund der Beweiskraft zu empfehlen, eine fortgeschrittene bzw. qualifizierte elektronische Signatur zu verwenden.
Zeile 18:		Zeile 18:
	* Widerspruch gegen die Kündigung von Mietverträgen (§ 574b Abs. 1 BGB)		* Widerspruch gegen die Kündigung von Mietverträgen (§ 574b Abs. 1 BGB)
	* Schriftform für befristete Arbeitsverhältnisse (§ 12 Abs. 1 AÜG)		* Schriftform für befristete Arbeitsverhältnisse (§ 12 Abs. 1 AÜG)
-	===== Siegel =====	+	====== Siegel ======
	Von elektronischen Signaturen zu unterscheiden sind elektronische Siegel. Diese gibt es ebenso wie elektronische Signaturen in drei verschiedenen Stufen (einfach, fortgeschritten, qualifiziert). Doch ist bei einem elektronischen Siegel nicht eine natürliche Person, sondern eine juristische Person Unterzeichner. Dies statuiert Art. 3 Nr. 24 eIDAS-VO. Elektronische Siegel sind dann zu verwenden, wenn das Unternehmen oder die Behörde ohne den Einsatz ihrer Vertreter unterzeichnen will. Das elektronische Siegel entspricht damit dem analogen Stempel einer Einrichtung und bescheinigt im Rechtsverkehr lediglich, dass ein bestimmtes Dokument von einer bestimmten Organisation ausgestellt wurde, das Dokument echt ist und die Informationen des Dokuments nicht nachträglich verändert wurden.		Von elektronischen Signaturen zu unterscheiden sind elektronische Siegel. Diese gibt es ebenso wie elektronische Signaturen in drei verschiedenen Stufen (einfach, fortgeschritten, qualifiziert). Doch ist bei einem elektronischen Siegel nicht eine natürliche Person, sondern eine juristische Person Unterzeichner. Dies statuiert Art. 3 Nr. 24 eIDAS-VO. Elektronische Siegel sind dann zu verwenden, wenn das Unternehmen oder die Behörde ohne den Einsatz ihrer Vertreter unterzeichnen will. Das elektronische Siegel entspricht damit dem analogen Stempel einer Einrichtung und bescheinigt im Rechtsverkehr lediglich, dass ein bestimmtes Dokument von einer bestimmten Organisation ausgestellt wurde, das Dokument echt ist und die Informationen des Dokuments nicht nachträglich verändert wurden.
	Elektronische Siegel können im Gerichtsverfahren als Beweismittel herangezogen werden (Art. 35 eIDAS-VO). Zudem entstehen mittlerweile mehr und mehr gesetzliche Regelungen, welche die Verwendung eines elektronischen Siegels vorsehen. Zum Beispiel sieht § 53 Vergabeordnung vor, dass Interessenbekundungen, Interessenbestätigungen, Teilnahmeanträge und Angebote mit einem fort- geschrittenen oder qualifizierten elektronischen Siegel zu versehen sind, wenn dies der öffentliche Auftragsgeber verlangt. Unabhängig von gesetzlichen Vorgaben können in der Praxis Siegel beispielsweise auch auf Rechnungen verwendet werden, um die Authentizität dieser zu bescheinigen und Betrugsfällen vorzubeugen, da dem Empfangenden eine Verifikation des Siegels möglich ist.		Elektronische Siegel können im Gerichtsverfahren als Beweismittel herangezogen werden (Art. 35 eIDAS-VO). Zudem entstehen mittlerweile mehr und mehr gesetzliche Regelungen, welche die Verwendung eines elektronischen Siegels vorsehen. Zum Beispiel sieht § 53 Vergabeordnung vor, dass Interessenbekundungen, Interessenbestätigungen, Teilnahmeanträge und Angebote mit einem fort- geschrittenen oder qualifizierten elektronischen Siegel zu versehen sind, wenn dies der öffentliche Auftragsgeber verlangt. Unabhängig von gesetzlichen Vorgaben können in der Praxis Siegel beispielsweise auch auf Rechnungen verwendet werden, um die Authentizität dieser zu bescheinigen und Betrugsfällen vorzubeugen, da dem Empfangenden eine Verifikation des Siegels möglich ist.
-	===== Zusammenfassung =====	+	====== Zusammenfassung ======
	Schlussendlich ist es Sache des Einzelfalls, welche elektronische Signatur (oder Siegel) in welcher Situation erforderlich ist. Maßgeblich sind zunächst stets Formvorschriften. Soweit solche nicht bestehen, obliegt es der unterzeichnenden Person, welche Form der elektronischen Signatur verwendet werden soll.		Schlussendlich ist es Sache des Einzelfalls, welche elektronische Signatur (oder Siegel) in welcher Situation erforderlich ist. Maßgeblich sind zunächst stets Formvorschriften. Soweit solche nicht bestehen, obliegt es der unterzeichnenden Person, welche Form der elektronischen Signatur verwendet werden soll.
	Zu empfehlen ist daher eine Prüfung im Einzelfall in drei Schritten:		Zu empfehlen ist daher eine Prüfung im Einzelfall in drei Schritten: