Dokumentation DFN-AAI, DFN-PKI und eduroam

spconfig

Wolfgang Pempe (wolfgang@dfn.de@undisclosed.example.com) — 2026-08-27T20:52:52+00:00

2026/08/27 20:50		aktuell
Zeile 25:		Zeile 25:
	\| schacHomeOrganization \| org_domain \| \|		\| schacHomeOrganization \| org_domain \| \|
	\| eduPersonAffiliation \| eduperson_affiliation \| \|		\| eduPersonAffiliation \| eduperson_affiliation \| \|
-	\| voPersonExternalAffiliation \| voperson_external_affiliation \| \|	+	\| voPersonExternalAffiliation \| voperson_external_affiliation \| (ab Q4 2026 verfügbar) \|
	\| eduPersonAssurance \| eduperson_assurance \| \|		\| eduPersonAssurance \| eduperson_assurance \| \|
	\| mail \| email \| \|		\| mail \| email \| \|

idpconfig

Wolfgang Pempe (wolfgang@dfn.de@undisclosed.example.com) — 2026-08-25T08:10:55+00:00

2026/08/25 08:10		aktuell
Zeile 7:		Zeile 7:
	===== Attributfreigabe =====		===== Attributfreigabe =====

-	Folgende Attribute müssen - sofern verfügbar - für die SP-Komponente des edu-ID-System freigegeben werden:	+	Folgende Attribute müssen - sofern verfügbar - für die SP-Komponente des edu-ID-Systems freigegeben werden:

	<file xml ./conf/attribute-filter.xml>		<file xml ./conf/attribute-filter.xml>

upgrade5 - [Upgrade auf Shibboleth IdP 5.x]

Andreas Borm (borm@dfn.de@undisclosed.example.com) — 2026-08-17T09:18:02+00:00

2024/08/28 12:47		aktuell
Zeile 1:		Zeile 1:
-	====== Upgrade auf Shibboleth IdP 5.x ======	+	====== Upgrade auf Shibboleth IdP 5.2.x ======

	==== Workshop IdP 5.x Upgrade, Juni 2024 ====		==== Workshop IdP 5.x Upgrade, Juni 2024 ====

zeitstempel - gelöscht - Externe Bearbeitung (Unbekanntes Datum)

Anonymous (anonymous@undisclosed.example.com) — 2026-08-15T04:07:26+00:00

2018/06/07 10:07		aktuell
Zeile 1:		Zeile 1:
-	~~NOTOC~~
-	===== FAQ Zeitstempeldienst =====

-	{{INLINETOC 3}}
-
-	====1. Was ist ein Zeitstempel?====
-
-	Ein Zeitstempel ist eine "Elektronische Bescheinigung einer (vertrauenswürdigen) Stelle, dass ihr bestimmte elektronische Daten zu einem bestimmten Zeitpunkt vorgelegen haben. Es ist dabei im Allgemeinen nicht erforderlich, dass diese Stelle den Inhalt der Daten zur Kenntnis nimmt." (Quelle: http://www.bsi.bund.de). Häufig, wie z.B. beim Time Stamp Protocol aus [RFC3161], werden Zeitstempel unter Einsatz digitaler Signaturen erstellt.
-
-	====2. Wie funktioniert der DFN Zeitstempeldienst?====
-
-	Der DFN-Verein betreibt im Rahmen des Zeitstempeldienstes einen Zeitstempelserver, der für Anwendungen einen signierten Zeitstempel ausstellt. Die Anwendung schickt dafür den Hashwert des Dokuments (+ Nonce) an den DFN Zeitstempelserver, der von einer Funkuhr die aktuelle Zeit ermittelt. Die Zeitangabe und der Hashwert des Dokuments werden mit dem Zertifikat des DFN Zeitstempelservers signiert und an die Anwendung zurück gesendet. Der Austausch der Daten erfolgt nach RFC 3161.
-
-	====3. Wie kann ich den DFN Zeitstempeldienst nutzen?====
-
-	Der DFN Zeitstempeldienst kann nur mit einer geeigneten Anwendung und nicht direkt durch Angabe der URL im Webbrowser genutzt werden. Geeignete Anwendungen sind Programme, die eine Anfrage an einen Zeitserver stellen und dessen Antwort entgegen nehmen können. Das sind z.B. Adobe Acrobat, openssl ab Version 1.0 und Komponenten von Microsoft bzw. Java (signtool/jarsigner).
-
-	Die Bibliothek BouncyCastle, die für Java und C# erhältlich ist, bietet ebenfalls Unterstützung für Zeitstempel.
-
-	====4. Wie kann das Zertifikat des Zeitstempelservers automatisch geprüft werden?====
-
-	Der DFN Zeitstempelserver verwendet ein Zertifikat der DFN-PKI Global, das im Adobe Acrobat nicht automatisch bekannt ist. Deshalb muss vor der ersten Nutzung des Zeitstempeldienstes
-
-	* die Zertifikatkette des Zeitstempelservers im Windows-Zertifikatspeicher installiert werden und
-	* die Windows-Integration von Zertifikaten in Adobe Acrobat aktiviert werden.
-
-	Lesen Sie dazu bitte Zeitstempel in der DFN-PKI. Die Zertifikatkette des Zeitstempelservers können Sie über diese URL beziehen.
-
-	====5. Wer kann den Zeitstempeldienst nutzen?====
-
-	Jeder kann den Dienst im Rahmen der DFN-Satzung mit einer geeigneten Anwendung nutzen. Eine Anmeldung oder das Ausfüllen von Formularen ist nicht notwendig.

dfnaai - gelöscht - Externe Bearbeitung (Unbekanntes Datum)

Anonymous (anonymous@undisclosed.example.com) — 2026-08-14T18:41:15+00:00

2018/06/07 10:01		aktuell
Zeile 1:		Zeile 1:
-	~~NOTOC~~
-	===== Fragen und Antworten zu Zertifikaten in der DFN-PKI =====

-	{{INLINETOC 3}}
-
-	====1. Wofür werden Zertifikate in der DFN-AAI eingesetzt?====
-
-	In der DFN-AAI kommen Zertifikate an verschiedenen Stellen zum Einsatz:
-
-	* Betrieb von Shibboleth: Zertifikate müssen für die gegenseitige Authentifizierung von Identity Providern und Service Providern sowie für die Signatur der Metadaten, die wichtige betriebliche Daten über die DFN-AAI enthalten, eingesetzt werden.
-	* Authentifizierung der Webserver: Alle Webserver der Service Provider und Identity Provider in der DFN-AAI müssen zur Authentifizierung Zertifikate verwenden.
-	* Authentifizierung der Nutzer: Derzeit verwenden Nutzer zur Authentifizierung meistens Username/Password. Alternativ kann die Authentifizierung auch per Nutzerzertifikat erfolgen. So kann zukünftig auf Basis der Stärke der
-	* Authentifizierung die Nutzung von Diensten geregelt werden, z.B. der Zugriff auf „kritische Dienste“ nur bei starker, zertifikatbasierter Authentifizierung.
-
-	====2. Welche Zertifikate können in der DFN-AAI verwendet werden?====
-
-	In der DFN-AAI können Zertifikate der folgenden Hierarchien verwendet werden:
-
-	* DFN-Verein PCA Global - G01
-	* DFN-Verein PCA Classic - G01
-	* DFN-Verein PCA Grid - G01
-
-	* Fraunhofer Root CA (R-CA)
-	* GridKa-CA - GermanGrid
-
-	Darüber hinaus können Zertifikate genutzt werden, die in alle wesentlichen Standardbrowser (insb. Firefox, IE) verlinkt sind und deren Gültigkeitsdauer maximal 5 Jahre beträgt. Die Nutzung von Wildcards in Zertifikaten ist nicht erlaubt.
-
-	Wenn Sie ein Zertifikat nutzen möchten, das in keine dieser Kategorien fällt, nehmen Sie bitte mit uns unter hotline@aai.dfn.de Kontakt auf.

oidc-proxy - [Liste der angeschlossenen Dienste]

Wolfgang Pempe (wolfgang@dfn.de@undisclosed.example.com) — 2026-08-14T06:54:15+00:00

2026/07/08 13:22		aktuell
Zeile 35:		Zeile 35:
	\| [[https://forum.lifbi.de/\|Forum4MICA]] \| Forum4MICA ist eine Informations- und Diskussionsplattform rund um die Datenbestände der vom RatSWD akkredierten Forschungsdatenzentren und darüber hinaus. \| [[https://www.lifbi.de/de-de/\|Leibniz Institut für Bildungsverläufe]] \| fdz@lifbi.de \| https://forum.lifbi.de/privacy \| sub, family_name, given_name, name, email, schac_home_organization \|		\| [[https://forum.lifbi.de/\|Forum4MICA]] \| Forum4MICA ist eine Informations- und Diskussionsplattform rund um die Datenbestände der vom RatSWD akkredierten Forschungsdatenzentren und darüber hinaus. \| [[https://www.lifbi.de/de-de/\|Leibniz Institut für Bildungsverläufe]] \| fdz@lifbi.de \| https://forum.lifbi.de/privacy \| sub, family_name, given_name, name, email, schac_home_organization \|
	\| [[https://www.schleswig-holstein.de/DE/landesregierung/themen/digitalisierung/linux-plus1/Projekt\|Dataport OSFS]] \| Anbindung an den Dataport OSFS für die Nutzung der Telefonielösung NTSH \| [[https://www.dataport.de\|Dataport AöR]] \| dataportfederationservice@dataport.de \| https://www.dataport.de/datenschutz/ \| sub, family_name, given_name, name, email \|		\| [[https://www.schleswig-holstein.de/DE/landesregierung/themen/digitalisierung/linux-plus1/Projekt\|Dataport OSFS]] \| Anbindung an den Dataport OSFS für die Nutzung der Telefonielösung NTSH \| [[https://www.dataport.de\|Dataport AöR]] \| dataportfederationservice@dataport.de \| https://www.dataport.de/datenschutz/ \| sub, family_name, given_name, name, email \|
		+	\| [[https://www.secanda.com/de/loesungen/digital_campus/\|SECANDA App Digital Campus]] \| Digital campus platform for students and university staff, providing digital identification and access to campus services such as access control, payments and other university services. \| [[https://www.secanda.com/de/\|SECANDA AG]] \| juanjo.albiach@secanda.com, c.bartl@secanda.com \| https://www.secanda.com/de/datenschutz/ \| sub, family_name, given_name, name, email, schac_home_organization, organization_name, eduperson_affiliation \|
	</datatables>		</datatables>

metadata

Wolfgang Pempe (wolfgang@dfn.de@undisclosed.example.com) — 2026-08-13T14:52:35+00:00

2026/03/12 09:46		aktuell
Zeile 1:		Zeile 1:
	====== Metadaten ======		====== Metadaten ======
	<callout color="#ff9900" title="Wichtige Hinweise">		<callout color="#ff9900" title="Wichtige Hinweise">
-	* HTTPS wird unterstützt, aber nicht erzwungen, da die Signaturen der Datensätze ohnehin IdP-/SP-seitig validiert werden müssen.	+	* HTTPS wird unterstützt, aber nicht erzwungen, da die Signaturen der Datensätze ohnehin IdP-/SP-seitig anhand des u.g. Zertifikats validiert werden müssen.
	* Hier finden Sie [[de:production#metadataprovider\|Konfigurationsbeispiele]] für Shibboleth IdP und SP.		* Hier finden Sie [[de:production#metadataprovider\|Konfigurationsbeispiele]] für Shibboleth IdP und SP.
	</callout>		</callout>

caa - gelöscht - Externe Bearbeitung (Unbekanntes Datum)

Anonymous (anonymous@undisclosed.example.com) — 2026-08-13T08:14:01+00:00

2018/06/01 11:00		aktuell
Zeile 1:		Zeile 1:
-	~~NOTOC~~
-	===== Fragen und Antworten zu CAA RRs =====

-	{{INLINETOC 3-4}}
-
-	===1. Was ist CAA?===
-
-	CAA (RFC 6844, Certification Authority Authorization) ist ein Mechanismus, bei dem im DNS hinterlegt werden kann, welche PKI für die Domain Zertifikate ausstellen darf. Die CAA Resource Records werden von allen im Browser verankerten PKIs, die sich an die Baseline Requirements des CA/Browser Forums halten, ausgewertet.
-
-	Weitere Informationen finden Sie auch in den folgenden Artikeln aus unserem Blog:
-
-	https://blog.pki.dfn.de/2017/03/rfc-6844-certification-authority-authorization-caa/\\
-	https://blog.pki.dfn.de/2017/09/caa-rrs-reihenfolge-im-dns/
-
-	===2. Wie sehen CAA RRs aus?===
-
-	CAA definiert drei Properties:
-
-	* issue enthält als Wert die Domain der PKI, die für die Domain, in der die CAA RRs definiert sind, Zertifikate ausstellen darf.
-	* issuewild wird wie issue gesetzt, wird aber für Wildcard-Zertifikate ausgewertet. Ist kein issuewild gesetzt, wird auch für Wildcard-Zertifikate issue ausgewertet
-	* iodef spezifiziert Kontaktadressen des Domain-Inhabers, unter denen Probleme oder Verletzungen der CAA-Policy gemeldet werden können. Hinweis: Die DFN-PKI verschickt aktuell keine automatischen iodef-Meldungen.
-
-	Ein Beispiel-Eintrag für die DFN-PKI:
-
-	<code>$ORIGIN hs-musterstadt.de
-	. CAA 0 issue "pki.dfn.de"</code>
-
-	===3. Können mehrere PKIs mit CAA authorisiert werden?===
-
-	Ja. Die issue- oder issuewild-Properties können mehrfach angegeben werden.
-
-	===4. Wie werden CAA RRs im DNS gesucht?===
-
-	Bei der Prüfung von CAA RRs suchen PKIs im DNS von links nach rechts nach CAA RRs. Sub-Domains können also die CAA-Policy der übergeordneten Domain überschreiben.
-
-	Siehe hierzu auch https://blog.pki.dfn.de/2017/09/caa-rrs-reihenfolge-im-dns/.
-
-	===5. Was sind gültige Werte für die DFN-PKI?===
-
-	Für die DFN-PKI ist folgender Wert zu setzen:
-
-	. CAA 0 issue "pki.dfn.de"
-
-	„dfn.de” wird ebenfalls akzeptiert.
-
-	===6. Wie werden DNS-Server konkret konfiguriert?===
-
-	Für bind >= 9.9.6 können CAA RRs direkt spezifiziert werden:
-
-	hs-musterstadt.de. IN CAA 0 issue "pki.dfn.de"
-
-	Für ältere bind-Versionen muss auf die RFC 3597-Darstellung zurückgegriffen werden:
-
-	hs-musterstadt.de. IN TYPE257 \# 17 00056973737565706B692E64666E2E6465
-
-	Für Windows Server 2016 muss ebenfalls RFC 3597 verwendet werden:
-
-	Add-DnsServerResourceRecord -Name hs.musterstadt.de -RecordData
-	00056973737565706b692e64666e2e6465 -Type 257 -ZoneName hs-musterstadt.de
-
-	===7. Zu welchem Zeitpunkt werden CAA RRs ausgewertet?===
-
-	CAA RRs werden unmittelbar vor der Ausstellung von Server-Zertifikaten ausgewertet. In der DFN-PKI wird dies über eine (selbstverständlich server-seitige) Prüfung beim Betätigen des Buttons „Genehmigen” realisiert. CAA RRs sind nicht dafür vorgesehen, nachträglich im zeitlichen Abstand zur Ausstellung eines Server-Zertifikats geprüft zu werden.

datenschutzerklaerung - gelöscht - Externe Bearbeitung (Unbekanntes Datum)

Anonymous (anonymous@undisclosed.example.com) — 2026-08-12T22:29:38+00:00

2018/05/07 09:19		aktuell
Zeile 1:		Zeile 1:
-	FIXME WORK IN PROGRESS FIXME
-
-	====== Informationen über die Verarbeitung personenbezogener Daten gemäß Art. 12 Absatz 1 Satz 1 EU-Datenschutz-Grundverordnung ======
-
-	Art. 12 Absatz 1, Satz 1 der EU-Datenschutz-Grundverordnung (EU-DS-GVO), regelt: „Der Verantwortliche trifft geeignete Maßnahmen, um der betroffenen Person alle Informationen gemäß den Artikeln 13 und 14 (…) in präziser, transparenter, verständlicher und leicht zugänglicher Form in einer klaren und einfachen Sprache zu übermitteln; (…).“ Dieser Verpflichtung kommt der
-
-	<code>
-	Verein zur Förderung eines Deutschen Forschungsnetzes e.V.
-	Alexanderplatz 1
-	10178 Berlin
-
-	E-Mail: dfn@dfn.de
-	Telefon: +4930 884299 0
-	</code>
-
-	als Verantwortlicher mit der nachfolgenden Information nach.
-
-	Hinweise für die Nutzung:
-
-	Dieser Webauftritt stellt Seiten für die Beantragung von Zertifikaten in der DFN-PKI zur Verfügung. Beim Zugriff werden folgende Protokolldaten erhoben:
-
-	* verkürzte IP-Adresse (bei IPv4 werden die letzten 2 Byte durch .0 und bei IPv6 die letzten 10 Bytes durch :: . ersetzt)
-	* Datum und Uhrzeit
-	* URL und übertragene Datenmenge
-	* Statuscode, d.h. die Meldung, ob der Zugriff/Abruf erfolgreich war
-	* zugreifender Webbrowser (sofern vom Client übermittelt)
-	* Referrer
-
-	Eine Zusammenführung dieser Daten mit anderen Datenquellen wird nicht vorgenommen. Die Protokolldaten werden fortlaufend ausgewertet, um Angriffe erkennen und entsprechend reagieren zu können. Bei Störungen, Fehlern und Sicherheitsvorfällen erfolgt unter Umständen eine manuelle Analyse dieser Daten.
-
-	Besondere Hinweise für Antragsteller von Zertifikaten: Zur Ausstellung von Zertfikaten sind weitere Daten erforderlich. Hierbei werden zusätzlich folgende Daten erhoben und gespeichert:
-
-	* Vollständiger Name
-	* E-Mail-Adresse
-
-	Diese Daten werden dauerhaft auf in den Systemen der DFN-PKI gespeichert und dienen ausschließlich der gesicherten und Ausstellung und Verwaltung von Zertifikaten.
-
-	Zugriffsmöglichkeiten auf vorhandene Daten haben Mitarbeiter im DFN-Vereins, die mit der Erbringung des Dienstes betraut sind sowie damit beauftragte Dienstleister.
-
-	Hinweise zum Umgang mit Cookies:
-
-	Cookies werden nur gesetzt, wenn der Nutzer dies in den Einstellungen seines Browsers zulässt und dies zur Nutzung der Webseite notwendig ist. Es kommen ausschließlich Sitzungscookies zum Einsatz, die keine personenbezogenen Daten enthalten. Sie dienen der eindeutigen Zuordnung der Anfragen mehrerer zeitgleich angemeldeter Nutzer sowie dem Vorhalten einiger vom Nutzer getroffener Konfigurationsoptionen und werden mit Schließen des Browsers automatisch gelöscht. Ohne die Annahme von Sitzungscookies ist die Nutzung der Webseite nicht möglich. Rechte betroffener Personen:
-
-	Art. 15 DSGVO regelt ein Auskunftsrecht, und damit das Recht einer betroffenen Person, eine Bestätigung zu verlangen, ob sie betreffende personenbezogene Daten ver¬arbeitet werden, und gegebenenfalls auf Auskunft über diese Daten und über Informationen unter anderem über die Verarbeitungszwecke, deren Herkunft, Empfänger, über die Dauer der Speicherung sowie über ihre Rechte.
-
-	Art. 16 DSGVO eröffnet das Recht, die Berichtigung sowie im Hinblick auf den Zweck die Vervollständigung sie betreffender unzutreffender personenbezogener Da¬ten zu verlangen.
-
-	Art. 17 Abs. 1 DSGVO statuiert - mit bestimmten Ausnahmen - das Recht, die Löschung von Daten zu verlangen. Art. 17 Abs. 2 DSGVO regelt ein „Recht auf Vergessenwerden“, wenn die verantwortliche Stelle die zu löschenden Daten öffentlich gemacht hat.
-
-	In bestimmten Fällen kann nach Art. 18 DSGVO auch die Einschränkung der Verarbeitung verlangt werden – zum Beispiel, wenn der Verantwortliche die Daten nicht mehr, die betroffene Person sie jedoch zur Geltendmachung, Ausübung oder Verteidigung von Rechtsansprüchen benötigt.
-
-	Das Recht auf Datenübertragbarkeit nach Art. 20 DSGVO gibt unter bestimmten Voraussetzungen einen Anspruch, eine Kopie von personenbezogenen Daten in einem üblichen und maschinenlesbaren Dateiformat zu erhalten.
-
-	Nach Art. 77 EU-DS-GVO hat jede betroffene Person das Recht auf Beschwerde bei einer Aufsichtsbehörde, wenn sie der Ansicht ist, dass die Verarbeitung ihrer personenbezogenen Daten gegen die DSGVO verstößt.
-
-	Kontaktdaten der Datenschutzbeauftragten im DFN-Verein:
-
-	<code>
-	Verein zur Förderung eines Deutschen Forschungsnetzes e.V.
-	Datenschutzbeauftragter
-	Alexanderplatz 1
-	10178 Berlin
-
-	E-Mail: datenschutz@dfn.de
-	Telefon: +4930 884299 9103
-	</code>
-

windows - gelöscht - Externe Bearbeitung (Unbekanntes Datum)

Anonymous (anonymous@undisclosed.example.com) — 2026-08-12T18:40:29+00:00

2018/05/31 13:48		aktuell
Zeile 1:		Zeile 1:
-	~~NOTOC~~
-	===== Fragen und Antworten zu Zertifikaten in Mozilla Anwendungen =====

-	{{INLINETOC 3-4}}
-
-	Bitte beachten Sie auch unsere FAQ zum Thema "Was ist beim Code-Signing in Microsoft Windows zu beachten?".
-
-	===1. Wie werden Zertifikate in Windows Systemen gespeichert?===
-
-	Auf Windows Systemen gibt es einen systemweiten Zertifikatspeicher, der von allen Microsoft Anwendungen benutzt wird. Wird diesem systemweiten Zertifikatspeicher ein neues Zertifikat hinzugefügt, so ist es für alle entsprechenden Anwendungen (z.B. Internet Explorer, Outlook Express/Windows Mail) verfügbar.
-
-	===2. Wo sind die Zertifikate zu finden?===
-
-	Auf Windows Systemen findet man die Zertifikate unter "Einstellungen" -> "Systemsteuerung" -> "Internetoptionen" und dort unter dem Karteireiter "Inhalte" -> "Zertifikate".
-
-	===3. Wie kann ich ein beliebiges Zertifikat (ohne privaten Schlüssel) exportieren?===
-
-	Öffnen Sie zunächst das Fenster mit den Zertifikaten und markieren Sie das Zertifikat, das Sie exportieren möchten. Drücken Sie nun den Knopf "Exportieren". Dadurch öffnet sich der "Zertifikatsexport-Assistent", der Sie durch die nächsten Schritte führt.
-
-	===4. Wie kann ich mein Zertifikat (mit meinem privaten Schlüssel) exportieren?===
-
-	Zu Ihren eigenen Zertifikaten besitzen Sie auch das zugehörige Schlüsselpaar und dabei insbesondere den geheim zu haltenden privaten Schlüssel, auf dessen Basis Sie sich z.B. im Internet ausweisen können. Es kann erforderlich sein, ein eigenes Zertifikat mit eigenem privaten Schlüssel zu exportieren, z.B. um dieses in einer anderen Anwendung zu nutzen oder um eine Sicherheitskopie zu erzeugen.
-
-	Öffnen Sie zunächst das Fenster mit den Zertifikaten und markieren Sie unter dem Karteireiter "Eigene Zertifikate" das Zertifikat, das Sie exportieren möchten. Drücken Sie den Knopf "Exportieren". Dadurch öffnet sich der "Zertifikatsexport-Assistent", der Sie durch die nächsten Schritte führt.
-
-	Wichtig: Sie müssen die Datei mit einem "Zertifikats-Backup-Passwort" versehen, da diese Datei auch Ihren privaten Schlüssel enthält.
-
-	===5. Wo ist das Telekom-Wurzelzertifikat unter Windows Vista/7?===
-
-	Unter Windows Vista/7 sind im Auslieferungszustand nur wenige Wurzelzertifikate enthalten. Auf Grund einer neuen Sicherheitsstrategie von Microsoft werden die Stammzertifizierungsstellen wie z.B. auch die "Deutsche Telekom Root CA2" bei Bedarf von Microsoft nachgeladen. Dieses Nachladen der Wurzelzertifikate erfolgt automatisch im Hintergrund, wenn z.B. eine Seite im Internet Explorer angewählt wird, die ein Zertifikat aus dem Sicherheitsniveau "Global" der DFN-PKI besitzt (wie z.B. diese Seite mit dem FAQ der DFN-PKI). Es erscheint dabei kein Hinweis, d.h. das Nachfragen bei Microsoft erfolgt transparent! Wenn das Wurzelzertifikat auf diesem Weg einmal automatisch installiert wurde, ist zukünftig keine weitere Verbindungsaufnahme mit Microsoft nötig und das Zertifikat ist lokal gespeichert.
-
-	===6. Können Zertifikatanträge im Internet Explorer signiert werden?===
-
-	Das Signieren von Zertifikatanträgen durch den TS mit dem Windows IE ist grundsätzlich nicht möglich, da entsprechende Mechanismen (Zugriff auf die CAPICOM Bibliothek) in Windows nicht durchgängig unterstützt werden. Statt dessen kann die [[https://www.pki.dfn.de/die-cas-im-dfn/ra-oberflaeche/\|grafische RA-Oberfläche]] der DFN-PKI genutzt werden, mit der sich die Aufgaben einer Registrierungsstelle einfacher durchführen lassen.

start

Wolfgang Pempe (wolfgang@dfn.de@undisclosed.example.com) — 2026-08-12T16:08:28+00:00

2026/08/10 06:49		aktuell
Zeile 5:		Zeile 5:
	Here you'll find information on [[en:dfnaai:start\|DFN-AAI]], the [[de:dfnpki:start\|DFN-PKI]] (German) and [[de:eduroam:start\|eduroam]] (German).		Here you'll find information on [[en:dfnaai:start\|DFN-AAI]], the [[de:dfnpki:start\|DFN-PKI]] (German) and [[de:eduroam:start\|eduroam]] (German).

-	<callout type="danger" title="Maintenance">
-	due to maintenance work, the DFN Trust & Identity Wiki (https://doku.tid.dfn.de) will be temporarily unavailable on Wednesday, 12 August, from 14:00 CEST. The maintenance measures are expected to be completed by 15:00 CEST. \\
-	Also affected by the maintenance work are the websites https://download.aai.dfn.de and https://tools.aai.dfn.de.
-	</callout>

start

Wolfgang Pempe (wolfgang@dfn.de@undisclosed.example.com) — 2026-08-12T16:08:13+00:00

2026/08/10 06:48		aktuell
Zeile 2:		Zeile 2:

	Hier findet sich die [[de:dfnaai:start\|Online Dokumentation der DFN-AAI]] sowie die Dokumentation zur [[de:dfnpki:start\|DFN-PKI]] und [[de:eduroam:start\|eduroam]].		Hier findet sich die [[de:dfnaai:start\|Online Dokumentation der DFN-AAI]] sowie die Dokumentation zur [[de:dfnpki:start\|DFN-PKI]] und [[de:eduroam:start\|eduroam]].
-
-	<callout type="danger" title="Wartungsarbeiten">
-	Aufgrund von Wartungsarbeiten wird das DFN Trust & Identity Wiki (https://doku.tid.dfn.de) am Mittwoch, 12. August, ab ca. 14:00 nicht erreichbar sein. Die Wartung wird voraussichtlich bis 15:00 abgeschlossen sein. \\
-	Ebenfalls von der Wartung betroffen sind die Websites https://download.aai.dfn.de und https://tools.aai.dfn.de.
-	</callout>

	Änderungsfeed: https://doku.tid.dfn.de/feed.php		Änderungsfeed: https://doku.tid.dfn.de/feed.php

sha2 - gelöscht - Externe Bearbeitung (Unbekanntes Datum)

Anonymous (anonymous@undisclosed.example.com) — 2026-08-12T15:44:24+00:00

2018/06/07 09:23		aktuell
Zeile 1:		Zeile 1:
-	~~NOTOC~~
-	===== Fragen und Antworten zur Umstellung von SHA-1 auf SHA-2 in der DFN-PKI =====

-	{{INLINETOC 3}}
-	====1. Welche Bedeutung haben Hash-Algorithmen in SSL-Zertifikaten?====
-
-	Zertifikate werden von einer Zertifizierungsstelle unter Verwendung eines bestimmten Algorithmus signiert. Bestandteil des Algorithmus ist dabei üblicherweise ein Hash-Verfahren. Lange Zeit wurde für das Signieren von Zertifikaten das SHA-1-Hash-Verfahren mit RSA als Verschlüsselungsalgorithmus (sha1WithRSAEncryption) verwendet.
-
-	Aktueller Stand der Technik ist der Nachfolger SHA-2 (mit RSA als sha256WithRSAEncryption).
-
-	====2. Ab wann gibt es in der DFN-PKI SHA-2-Zertifikate?====
-
-	Bereits seit Ende 2014 wird für das Signieren von Zertifikaten in der DFN-PKI der SHA-2-Hash-Algorithmus (in der Variante SHA-256) mit RSA als Verschlüsselungsalgorithmus (sha256WithRSAEncryption) verwendet. Bis Ende 2015 konnte auf Anfrage in Ausnahmefällen noch SHA-1 genutzt werden.
-
-	====3. Gibt es in der DFN-PKI noch neue SHA-1-Zertifikate?====
-
-	Die DFN-PKI ist komplett auf SHA-2 umgestellt und es gibt seit dem 1.1.2016 keine neuen SHA-1-Zertifikate mehr. Ausgenommen von dieser Regelung sind spezielle Zertifizierungsstellen, die ausschließlich für den internen Gebrauch vorgesehen sind und dabei nicht unter den bekannten DFN-PKI Hierarchien (Global, Classic, Basic, Grid bzw. SLCS) betrieben werden.
-
-	====4. Was passiert mit alten SHA-1-Zertifikaten aus der DFN-PKI?====
-
-	Alte SHA-1-signierte Zertifikate behalten aus technischer Sicht ihre Gültigkeit bis diese abläuft oder die Zertifikate gesperrt werden. Allerdings führen alte SHA-1-signierte Server- und Zwischen-Zertifizierungsstellen-Zertifikate immer häufiger zu SSL-Verbindungsproblemen in Web-Browsern.
-
-	Auch alte SHA-1-signierte Nutzerzertifikate werden in absehbarer Zeit zu Problemen führen.
-
-	Deswegen sollten diese alten Zertifikate durch neue SHA-2-signierte Zertifikate ausgetauscht werden.
-
-	====5. Warum meldet ein Web-Browser, dass eine SSL-Verbindung wegen SHA-1-Zertifikaten unsicher ist oder gar nicht zustande kommt?====
-
-	Wahrscheinlich nutzt der Web-Server noch ein altes SHA-1-signiertes Server-Zertifikat oder die vom Web-Server beim SSL-/TLS-Verbindungsaufbau mit ausgelieferten Zertifizierungsstellen-Zertifikate (CA-Kette) enthalten noch ein oder mehrere alte SHA-1-signierte Zwischen-Zertifizierungsstellen-Zertifikate. Ein Wurzel/Stamm-Zertifizierungsstellen-Zertifikat darf noch SHA-1-signiert mit der CA-Kette ausgeliefert werden. Ein Austausch der betroffenen SHA-1-signierten Server- und Zwischen-Zertifizierungsstellen-Zertifikate durch neue SHA-2-signierte Zertifikate bringt Abhilfe.
-
-	Ist der Web-Server aus dem öffentlichen Internet unter Port 443 zu erreichen, so ist der SSL-Server-Test von SSLlabs ebenfalls hilfreich, um SSL-Problemen auf die Spur zu kommen.
-
-	====6. Müssen auch Wurzel/Stamm-Zertifizierungsstellen-Zertifikate SHA-2-signiert vorliegen?====
-
-	Nein, denn der verwendete Hash-Algorithmus für die Selbst-Signatur von Wurzel/Stamm-Zertifizierungsstellen-Zertifikaten hat keine sicherheitskritische Bedeutung und kann somit beliebig sein. Daher gibt es das "Deutsche Telekom Root CA 2"-Zertifikat weiterhin ausschließlich als SHA-1-signiertes Wurzel/Stamm-Zertifizierungsstellen-Zertifikat.
-
-	Technisch wird das Zertifikatformat mit der Selbst-Signatur von Wurzel/Stamm-Zertifizierungsstellen-Zertifikaten nur als Container für die öffentlichen Schlüssel der Wurzel/Stamm-Zertifizierungsstellen genutzt und die darin enthaltene Signatur ist einfach ein Bestandteil des Zertifikatformats.
-
-	Die Gewissheit, dass es sich bei einem Wurzel/Stamm-Zertifizierungsstellen-Zertifikaten um das authentische Zertifikat handelt, muss sich von demjenigen, der das Wurzel/Stamm-Zertifizierungsstellen-Zertifikat in ein System integriert (also vom Software/Betriebssystem-Hersteller oder Nutzer) oder die Authentizität eines vorhandenen Wurzel/Stamm-Zertifizierungsstellen-Zertifikats überprüft, über den Abgleich eines digitalen Fingerabdrucks des Zertifikats verschafft werden. Hierzu wird z.B. der SHA-2-Fingerabruck des im System befindlichen Zertifikats (nicht zu verwechseln mit z.B. einer SHA-1-Selbst-Signatur im Zertifikat) mit dem von der Zertifizierungsstelle veröffentlichten (oder anderweitig authentisch übermittelten) SHA-2-Fingerabruck Wurzel/Stamm-Zertifizierungsstellen-Zertifikats abgeglichen.

about

Wolfgang Pempe (wolfgang@dfn.de@undisclosed.example.com) — 2026-08-12T15:38:24+00:00

2023/01/12 16:04		aktuell
Zeile 1:		Zeile 1:
	~~NOTOC~~		~~NOTOC~~
	====== Einführung ======		====== Einführung ======
-	{{INLINETOC 2}}	+
	===== Was ist die (DFN-)AAI? =====		===== Was ist die (DFN-)AAI? =====
	Technisch gesehen geht es bei der DFN-AAI um eine bestimmte Spielart des webbasierten Single Sign-On (Web-SSO). Dieses Verfahren erlaubt es Anwendern, sich mit den Benutzer-Credentials, mit denen sie bei ihrer Heimateinrichtung registriert sind (i.d.R. Nutzername und Passwort), bei internen und externen Diensten anzumelden (Authentifizierung) und – entsprechende Berechtigungen vorausgesetzt (Autorisierung) – diese zu nutzen. Die hierfür erforderliche Infrastruktur, AAI (= Authentication and Authorization Infrastructure), wird traditionell im Rahmen nationaler [[https://refeds.org/federations\|Föderationen]] realisiert und in der Regel von den jeweiligen Forschungsnetzen betrieben. Im Fall der Bundesrepublik Deutschland ist dies der [[https://www.dfn.de\|DFN-Verein]].		Technisch gesehen geht es bei der DFN-AAI um eine bestimmte Spielart des webbasierten Single Sign-On (Web-SSO). Dieses Verfahren erlaubt es Anwendern, sich mit den Benutzer-Credentials, mit denen sie bei ihrer Heimateinrichtung registriert sind (i.d.R. Nutzername und Passwort), bei internen und externen Diensten anzumelden (Authentifizierung) und – entsprechende Berechtigungen vorausgesetzt (Autorisierung) – diese zu nutzen. Die hierfür erforderliche Infrastruktur, AAI (= Authentication and Authorization Infrastructure), wird traditionell im Rahmen nationaler [[https://refeds.org/federations\|Föderationen]] realisiert und in der Regel von den jeweiligen Forschungsnetzen betrieben. Im Fall der Bundesrepublik Deutschland ist dies der [[https://www.dfn.de\|DFN-Verein]].

email - gelöscht - Externe Bearbeitung (Unbekanntes Datum)

Anonymous (anonymous@undisclosed.example.com) — 2026-08-12T15:12:07+00:00

2018/06/07 13:26		aktuell
Zeile 1:		Zeile 1:
-	~~NOTOC~~
-	===== Fragen und Antworten zu Zertifikaten in der DFN-PKI =====

-	{{INLINETOC 3}}
-
-	====1. 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.
-
-	====2. 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.
-
-	====3. 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.
-
-	====4. 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.

allgemein - gelöscht - Externe Bearbeitung (Unbekanntes Datum)

Anonymous (anonymous@undisclosed.example.com) — 2026-08-12T14:15:21+00:00

2018/05/31 12:47		aktuell
Zeile 1:		Zeile 1:
-	~~NOTOC~~
-	===== Fragen und Antworten zu Zertifikaten in der DFN-PKI =====

-	{{INLINETOC 3}}
-
-	==== 1. Was sind die Pflichten von Zertifikatinhabern? ====
-	Jeder Zertifikatinhaber muss Sorge tragen, dass sein privater Schlüssel angemessen geschützt ist und dass das Zertifikat in Übereinstimmung mit der Policy der DFN-PKI eingesetzt wird. Das Zertifikat ist unverzüglich zu sperren, wenn die Angaben des Zertifikats nicht mehr korrekt sind oder wenn der private Schlüssel abhanden gekommen, gestohlen oder möglicherweise kompromittiert wurde. Eine Darstellung dieser Pflichten findet sich im Dokument [[https://www.pki.dfn.de/fileadmin/PKI/Info-fuer-Zertifikatinhaber.pdf\|"Informationen für Zertifikatinhaber in der DFN-PKI"]].
-
-	==== 2. Wie sieht ein korrekter Zertifikatname (DN - Distiguished Name) aus? ====
-	Der Zertifikatname darf keine Umlaute und andere Sonderzeichen enthalten. Erlaubt sind a-z A-Z 0-9 ' ( ) , - . / : und Leerzeichen. Auf Groß- und Kleinschreibung ist zu achten. Dies gilt für alle Komponenten (Attribute) des Zertifikatnamens.
-
-	Der Zertifikatname muss der Namensform entsprechen, die im CPS Ihrer Zertifizierungsstelle festgelegt ist. Hierbei ist insbesondere auf die dort erlaubten bzw. festgelegten Attribute zu achten. Bei Beantragung eines Nutzerzertifikats über die Webschnittelle der Zertifizierungsstelle werden die festlegten Attribute automatisch übernommen. Regeln für den "Common Name" (Attribut CN) im Zertifikatnamen finden Sie unter Frage 3.
-
-	Bei Beantragung eines Serverzertifikats muss der Zertifikatname in einem PKCS#10 Zertifikatrequest übermittelt werden. Hinweise zur Erzeugung eines PKCS#10 Zertifikatrequests mit korrektem Zertifikatnamen finden Sie in der [[https://www.pki.dfn.de/fileadmin/PKI/anleitungen/Anleitung_Nutzung_OpenSSL.pdf\|Anleitung zur Nutzung von OpenSSL]].
-
-	==== 3. Was ist beim CN (Common Name) – Eintrag im Zertifikatnamen zu beachten? ====
-	Neben den allgemeinen Regeln für Zertifikatnamen (s. Frage 1) ist beim CN-Eintrag folgendes zu beachten:
-
-	* Nutzerzertifikate: Der CN eines Nutzerzertifikats muss Vornamen und Nachnamen enthalten. Ausnahmen sind Gruppenzertifikate (CN=GRP:... oder GRP - ...) und Pseudonymzertifikate (CN=PN:... oder PN - ...). Namenszusätze, die im amtlichen Ausweispapier geführt werden (z.B. "Dr."), können in den CN aufgenommen werden. Darin nicht aufgeführte Namenszusätze (z.B. "Prof.") dürfen im CN nicht verwendet werden.
-	* Server-/Maschinenzertifikate: Der CN eines Serverzertifikats muss immer den voll qualifizierten Hostnamen (FQDN), z.B. server1.uni-musterstadt.de enthalten. Die Second-Level-Domain (im Beispiel uni-musterstadt) muss offiziell bei einer Domain-Registratur (z.B. DENIC) registriert sein und der Einrichtung, die das Zertifikat beantragt, gehören.
-
-	IP-Adressen dürfen im CN nicht angegeben werden.
-
-	==== 4. Was ist bei Verwendung von Subject Alternative Names (SaN) zu beachten? ====
-	Falls aus bestimmten Gründen ein nicht registrierter oder nicht voll qualifizierter Hostname verwendet werden muss, kann dieser als Subject Alternative Name (SaN) in der Zertifikaterweiterung "subjectAlternativeName" mit dem Typ "DNS" eingetragen werden. IP-Adressen können ebenfalls als "subjectAlternativeName" mit dem Typ "IP" eingetragen werden. Bitte beachten Sie, dass neuere Versionen des Internet Explorers IP-Adressen im Subject Alternative Name nicht akzeptieren.
-
-	Der Eintrag von SaNs kann in der Regel nur von der Registrierungsstelle vorgenommen werden, indem ein vorliegender Zertifikatantrag bearbeitet wird. Sollten die für SaNs vorgesehenen freien Felder in der Bearbeitungsmaske der RA-Webschnittstelle nicht ausreichen, muss der Antrag nach dem Ausfüllen der vorhandenen Felder abgespeichert werden und die Bearbeitung anschließend fortgeführt werden. Es werden dann zusätzliche freie Felder für weitere SaNs angezeigt.
-
-	Bei Verwendung eines alternativen Namens sollte der voll qualifizierte Hostname aus dem CN immer auch zusätzlich als ein weiterer "subjectAlternativeName" angegeben werden. Das hilft vielen Browsern/Clients, Warnmeldungen wegen nicht zum Zertifikat passender Server-Namen zu vermeiden.
-
-	Der Eintrag eines "subjectAlternativeName" in einem PKCS#10 Zertifikatrequest, der über die Webschnittstelle für Nutzer und Administratoren übermittelt wird, wird in der DFN-PKI grundsätzlich übernommen. Ausnahme: Die Einrichtung hat für ihre CA die Ignorierung des "subjectAlternativeName" explizit vereinbart.
-
-	==== 5. Können interne Domainnamen oder reservierte IP-Adressen verwendet werden? ====
-	Im Sicherheitsniveau Global dürfen interne Domainnamen wie z.B. "mail.local " oder reservierte IP-Adressen wie z.B. 192.168.6.1 seit Herbst 2015 nicht mehr in Zertifikaten verwendet werden.
-
-	Eine ausführliche Beschreibung und weitere Hinweise zu dieser Problematik finden Sie im Dokument "Interne Namen in Serverzertifikaten in der DFN-PKI."
-
-	==== 6. Welches Zertifikatprofil soll ich wählen? ====
-	Wenn Sie über die Webschnittstelle Ihrer Zertifizierungsstelle ein Zertifikat unter der Registerkarte "Serverzertifikat" beantragen, müssen Sie ein Zertifikatprofil auswählen, das zu dem Einsatzzweck dieses Zertifikats passt. Welches Zertifikatprofil für welche Einsatzzwecke geeignet ist, finden Sie in der Liste DFN-PKI Zertifikatprofile (technische Beschreibung der Profile).
-
-	=== 7. Wie erzeuge ich einen PKCS#10 Zertifikatrequest (CSR - Certificate Signing Request)? ===
-	Zum Beantragen eines Serverzertifikats über die Webschnittstelle Ihrer Zertifizierungsstelle müssen die Zertifikatdaten in einer PKCS#10 Datei im .pem-Format übermittelt werden. Dazu geben Sie in der Webschnittstelle an entsprechender Stelle den Namen der Datei an.
-
-	Die Datei kann auf verschiedene Weise erzeugt werden, z.B. mit Hilfe der entsprechenden Server-Software. Lesen Sie dazu bitte die Dokumentation Ihrer Server-Software und folgen Sie den Anweisungen.
-
-	Eine PKCS#10 Datei kann auch mit Hilfe der Open Source Software OpenSSL (http://www.openssl.org ) erzeugt werden. Lesen Sie dazu bitte die Anleitung zur Nutzung von OpenSSL.
-
-	==== 8. Welche Bedingungen muss ein PKCS#10 Zertifikatrequest (CSR - Certificate Signing Request) erfüllen? ====
-	Ein CSR für ein Zertifikat in der DFN-PKI muss folgende Bedingungen erfüllen:
-
-	Er gehört zu einem mindestens 2048 Bit langem RSA Schlüssel, der z.B. als Datei oder innerhalb der Anwendung vorliegt und ggf. mit einem Passwort geschützt ist.
-	Er ist von dem enthaltenen Schlüssel selbstsigniert.
-	Der im CSR beantragte Zertifikatname (Distinguished Name, DN) genügt den Regeln für Zertifikatnamen (s. Frage 1) und entspricht der in Ihrem CPS festgelegten Namensform. Hierbei ist insbesondere auf die dort erlaubten bzw. festgelegten Attribute zu achten. Lesen Sie dazu bitte in der Anleitung zur Nutzung von OpenSSL das Kapitel 4 „Zertifikatnamen“.
-	Zur Erzeugung eines PKCS#10 Zertifikatrequests lesen Sie bitte die Anleitung zur Nutzung von OpenSSL.
-
-	==== 9. Wie kann ich einen PKCS#10 Zertifikatrequest überprüfen? ====
-	Wenn Sie die Datei mit Ihrem PKCS#10 Zertifikatantrag vor dem Hochladen in die Webschnittstelle überprüfen möchten, können Sie dazu OpenSSL benutzen. Mit der Befehlszeile
-
-	openssl req -text -verify -in request.pem
-
-	zeigt Ihnen OpenSSL den Inhalt der CSR Datei „request.pem“ in lesbarer Form an und verifiziert auch gleich die Selbstsignatur des CSR.
-
-	Lesen Sie ggf. auch die Anleitung zur Nutzung von OpenSSL.
-
-	==== 10. Wie wird der Public Key Fingerprint des PKCS#10 Zertifikatrequests berechnet? ====
-	Wenn Sie den PKCS#10 Zertifikatrequest als Datei vorliegen haben, so können Sie mit openssl den Public Key Fingerprint berechnen, indem Sie die folgende Befehlszeile nutzen:
-
-	openssl req -in <PKCS#10 Datei> -pubkey -noout \| openssl rsa -pubin -text -noout \| sed -e '/Modulus:$/d' \| sed -e 's/Public-Key: ($.*$)/Modulus (\1):/' \| openssl sha1
-
-	==== 11. Wie erzeuge ich eine PKCS#12 Datei? ====
-	Zum Import eines Zertifikats in eine Anwendung benötigen Sie in der Regel das Zertifikat zusammen mit dem privaten und öffentlichen Schlüssel und ggf. mit der gesamten Zertifikatkette in einer PKCS#12-Datei (Extension .p12). Wenn Sie das Schlüsselpaar in Ihrem Browser erzeugt und das Zertifikat in den Browser importiert haben, können Sie eine PKCS#12-Datei aus dem Browser heraus exportieren. Siehe dazu FAQ-Mozilla, Frage 5 bzw. FAQ-Windows, Frage 4.
-
-	Wenn Ihr privater Schlüssel und Ihr Zertifikat an anderer Stelle auf Ihrem Rechner abgelegt sind (in der Regel bei Serverzertifikaten), können Sie mit Hilfe von OpenSSL eine PKCS#12-Datei erzeugen, die das Zertifikat, den privaten und öffentlichen Schlüssel und die CA-Zertifikatkette enthält.
-	Lesen Sie dazu bitte die Anleitung zur Nutzung von OpenSSL.
-
-	==== 12. Was bedeutet die Verlängerung eines Zertifikats? ====
-	Da Zertifikate ein Gültigkeitsende haben, müssen sie regelmäßig erneuert oder verlängert werden. Unter einer Zertifikatverlängerung versteht man das Ausstellen eines neuen Zertifikats mit demselben Distinguished Name eines bereits existierenden Zertifikats. Neues und altes Zertifikat unterscheiden sich immer mindestens im Gültigkeitszeitraum und der Seriennummer.
-
-	==== 13. Welche Arten von Zertifikatverlängerung gibt es? ====
-	Technisch lässt sich die Zertifikatverlängerung auf zwei Arten durchführen: Entweder mit Austausch des geheimen und öffentlichen Schlüssels oder unter Beibehaltung des alten Schlüsselpaars.
-
-	Grundsätzlich sollte der erste Weg mit Austausch gewählt werden, was einer Neuausstellung entspricht. Dabei muss auf jeden Fall das alte Schlüsselpaar aufbewahrt werden, da sonst verschlüsselte Daten wie z.B. E-Mails nicht mehr gelesen werden können. Eine Ausnahme bilden Zertifikate für Webserver, die niemals zum persistenten Verschlüsseln von Daten verwendet wurden. Hier kann eine Zertifikatverlängerung auch ohne Schlüsseltausch problemlos durchgeführt werden.
-
-	Die Zertifikatverlängerung ohne Schlüsseltausch hat theoretisch zwar Vorteile, ist in der Praxis jedoch problematisch: Die meiste Software identifiziert Schlüssel anhand des dazugehörigen Zertifikats, so dass ein unbedachtes Löschen von abgelaufenen Zertifikaten auch hier dazu führen kann, dass verschlüsselte Daten nicht mehr zugänglich sind.
-
-	==== 14. Wie kann ein Zertifikat in der DFN-PKI verlängert werden? ====
-	Für eine Verlängerung ist in der DFN-PKI wie beim Erstantrag vorzugehen. Der Antragsteller ruft die Antragsseiten seiner Zertifizierungsstelle auf, erstellt einen Antrag unter Beibehaltung seiner Angaben aus dem alten Zertifikat und druckt diesen Antrag aus. Der Antrag muss anschließend der Registrierungsstelle übermittelt werden, die die weitere Bearbeitung übernimmt.
-
-	==== 15. Was bedeutet die Veröffentlichung von Zertifikaten? ====
-	Bei der Veröffentlichung von Zertifikaten muss grundsätzlich zwischen Nutzer- und Serverzertifikaten unterschieden werden.
-
-	Für Nutzerzertifikate gilt: Wenn Sie der Veröffentlichung Ihres Nutzerzertifikats zustimmen, wird dieses zum Verzeichnisdienst der DFN-PKI hinzugefügt, der im Internet frei zugänglich ist. Der Vorteil einer Veröffentlichung besteht darin, dass jeder, der Ihnen eine verschlüsselte E-Mail senden möchte, dies leicht tun kann, da das entsprechende Zertifikat frei verfügbar ist. Da Nutzerzertifikate den Namen und die E-Mail Adresse des Zertifikatnehmers enthalten, sind diese Daten bei einer Zustimmung zur Veröffentlichung frei verfügbar.
-
-	Die Veröffentlichung eines Nutzerzertifikats ist vergleichbar mit einer Telefonnummer, die Sie in ein öffentliches Telefonverzeichnis eintragen lassen können. Stimmen Sie der Eintragung zu, so kann jeder (ob gewünscht oder ungewünscht) Sie ohne vorherige Kontaktaufnahme telefonisch erreichen.
-
-	Bitte beachten Sie:
-	* Sie können Ihre Zustimmung zur Veröffentlichung Ihres Zertifikats jederzeit mit Wirkung für die Zukunft durch eine E-Mail an dfnpca@dfn-cert.de widerrufen. Nennen Sie uns in der E-Mail bitte die Seriennummer des Zertifikats und die ausstellende Zertifizierungsstelle. Diese Informationen sind aus den Zertifikatdetails ersichtlich.
-	* Wenn Sie der Veröffentlichung Ihres Nutzerzertifikats nicht zustimmen, kann dies nachträglich nicht geändert werden. Sie müssen dann ein neues Zertifikat beantragen und dafür der Veröffentlichung zustimmen.
-
-	Für Serverzertifikate gilt:
-	Serverzertifikate werden in der DFN-PKI in Certificate Transparency Logs veröffentlicht. Dies sind von Dritten betriebene Systeme, die der Transparenz und damit der Sicherheit der Web-PKI dienen. Ohne die Veröffentlichung wären Serverzertifikate nicht mehr in Google Chrome funktionsfähig.
-
-	Die Veröffentlichung von Serverzertifikaten kann nicht zurückgenommen werden. Certificate Transparency Logs werden von Dritten betrieben, auf die der DFN keinen Einfluss hat. Darüber hinaus basiert Certificate Transparency auf Datenstrukturen, die durch digitale Signaturen inhärent gegen nachträgliche Änderungen gesichert ist.
-
-	Weitere Erläuterungen finden Sie im Blog der DFN-PKI.
-
-	==== 16. Wie erreiche ich den Verzeichnisdienst der DFN-PKI? ====
-	Der Verzeichnisdienst der DFN-PKI für Nutzerzertifikate im Sicherheitsniveau Global ist durch folgenden LDAP-Server realisiert:
-
-	Hostname: ldap.pca.dfn.de
-	Basis-DN: ou=DFN-PKI,o=DFN-Verein,c=de
-	Port: 389
-	Suchfilter: (objectclass=*)
-	Für Nutzerzertifikate im Sicherheitsniveau Grid benutzen Sie statt dessen den
-
-	Basis-DN: o=GridGermany,c=de
-
-	==== 17. Was sind "Extended Validation" Zertifikate? ====
-	Greift man mit einem Browser auf eine zertifikatgeschützte Webseite zu, erhält man einen Hinweis auf das Sicherheitsniveau, unter dem das entsprechende Zertifikat ausgestellt wurde. "Extended Validation (EV)" Zertifikate enthalten einen Verweis auf die Zertifizierungsrichtlinie des Ausstellers und können dadurch von Browsern speziell dargestellt werden, falls diese Zertifizierungsrichtlinie einer "strikteren" Prüfung unterliegt (so wird z.B. die URL-Leiste grün gefärbt und es erscheint der Name des Ausstellers in grün).
-
-	"Extended Validation" Zertifikate können in der DFN-PKI zur Zeit nicht ausgestellt werden. Das liegt u.a. daran, dass noch nicht abschließend klar ist, ob EV-Zertifikate in der Praxis wirklich Sicherheitsvorteile bringen oder ob diese doch eher unter kommerziellen Gesichtspunkten eingeführt wurden (ein EV-Zertifikat kostet derzeit mehrere hundert US$ pro Jahr). Gleichzeitig tragen die Browserhersteller zur Verunsicherung der Nutzer bei, indem bei Seiten ohne EV-Zertifikate Meldungen wie "Diese Website wird betrieben von (unbekannt)" angezeigt werden.
-
-	Der DFN-Verein beobachtet die Entwicklung zu EV-Zertifikaten und plant diese anzubieten, wenn sicherheitstechnischer Mehrwert und Kosten in einem angemessenen Gleichgewicht stehen.
-
-	==== 18. Was sind PGP-Zertifikate? ====
-	Neben den im DFN als Standard etablierten X.509 Zertifikaten gibt es als Alternative PGP-Zertifikate. Zwischen beiden Strukturen existiert u.a. ein wesentlicher Unterschied: Erfolgt die Vertrauensbildung bei X.509 über ein hierarchisches System von Zertifizierungs- und Registrierungsstellen, so wird dies bei PGP über ein sogenanntes "Web of Trust" gebildet.
-
-	In der DFN-PKI werden aufgrund der Anforderungen der DFN-Anwender ausschließlich X.509 Zertifikate ausgestellt. Es bleibt jedem Nutzer unbenommen, sich sein eigenes PGP-Schlüsselpaar zu erzeugen und sich über das Web of Trust mit Zertifikaten zu versorgen.
-
-	==== 19. Wie überprüfe ich den Fingerprint eines Wurzelzertifikats? ====
-	Den Fingerprint eines Wurzelzertifikats können Sie über den OpenSSL-Befehl
-
-
-
-	openssl x509 -in <Dateiname des Wurzelzertifikats> -noout -fingerprint
-
-
-	ausgeben. Vergleichen Sie den Fingerprint mit dem von der CA veröffentlichten Fingerprint. Diese müssen gleich sein. Den von der CA veröffentlichten Fingerprint sollten Sie über einen anderen Weg beziehen als das Wurzelzertifikat - beispielsweise per Telefon.
-
-	==== 20. Was sind Wildcard-Zertifikate? ====
-	Wildcard-Zertifikate sind spezielle Serverzertifikate, bei denen der FQDN im CN oder in einem alternativen Namen vom Typ 'DNS' an der am weitesten links stehenden Domain-Komponente einen Stern ("*") - die Wildcard - enthält.
-
-	Beispiel: CN=*.pki.dfn.de
-
-	Dadurch kann dieses Zertifikat für alle FQDNs unterhalb von pki.dfn.de verwendet werden, z.B. für pki1.pki.dfn.de und pki2.pki.dfn.de, allerdings nicht für längere FQDNs wie etwa www.pki1.pki.dfn.de oder kürzere wie pki.dfn.de selbst.
-
-	==== 21. Wie können Wildcard-Zertifikate in der DFN-PKI genutzt werden? ====
-	Da Wildcard-Zertifikate für eine ganze Subdomain verwendet werden können, ist der potentielle Schaden bei einer Kompromittierung des privaten Schlüssels deutlich höher als bei Zertifikaten für genau spezifizierte FQDNs.
-
-	Daher dürfen Wildcard-Zertifikate in der DFN-PKI ausschließlich verwendet werden, wenn das Einsatzszenario dies technisch erzwingt. Beispielsweise gibt es Softwaresysteme, die dynamisch Host-Namen erzeugen (gerade im Bibliotheksumfeld), die mit herkömmlichen Zertifikaten schlicht nicht funktionieren. Beispiele für solche Software: EZProxy, Netman/HAN
-
-	Ein und dasselbe Wildcard-Zertifikat darf nicht auf verschiedenen Servern mit unterschiedlichen Diensten, Einsatzzwecken oder Schutzklassen verwendet werden. Aufgrund des höheren Schadenspotentials bei Kompromittierung sind Wildcard-Zertifikate kein probates Mittel der Arbeitsersparnis bei der Zertifikatbeantragung.
-
-	Wildcard-Zertifikate werden nur unterhalb von Sub-Domains oder Second-Level-Domains ausgestellt, die ausschließlich für einen klar abgegrenzten Zweck genutzt werden, also beispielsweise entweder für ".roaming.dfn.de" oder für ".dfnroaming.de", nicht aber für "*.dfn.de"
-
-	==== 22. Wie können Wildcard-Zertifikate in der DFN-PKI beantragt werden? ====
-	Aufgrund des erhöhten Schadenspotentials können Wildcard-Zertifikate in der DFN-PKI nur auf Anfrage von handlungsberechtigten Personen bei der DFN-PCA [[dfnpca@dfn-cert.de]] beantragt werden.
-
-	==== 23. Auf welchen Certificate Transparency Logs werden Serverzertifikate der DFN-PKI veröffentlicht? ====
-	Mit Stand Februar 2018 werden die folgenden Logs verwendet:
-
-	plausible.ct.nordu.net
-	mammoth.ct.comodo.com
-	sabre.ct.comodo.com
-	ct.googleapis.com/rocketeer
-	ct.googleapis.com/pilot

codesigning - gelöscht - Externe Bearbeitung (Unbekanntes Datum)

Anonymous (anonymous@undisclosed.example.com) — 2026-08-12T13:06:02+00:00

2018/06/01 12:56		aktuell
Zeile 1:		Zeile 1:
-	~~NOTOC~~
-	===== Fragen und Antworten zum Code-Signing mit Zertifikaten aus der DFN-PKI =====
-
-	{{INLINETOC 3-4}}
-
-	===1. Was ist Code-Signing und Object-Signing?===
-
-	Code-Signing oder auch Object-Signing ist das Signieren von Programm- oder Skript-Code, um dessen Integrität und Authentizität sicherzustellen. Welche Programme oder Skripte signiert werden können und welche Werkzeuge verwendet werden müssen, hängt von der dazugehörigen Umgebung ab.
-	Code-Signing gibt es für Java Applets, Java Web-Start-Applikationen, Microsoft Office Macros, VBScript bzw. Powershell-Skripte, Windows Treiber, Android Apps und viele weitere.
-
-	===2. Welche Code-Signing Umgebungen unterstützt die DFN-PKI?===
-
-	In der DFN-PKI wird Java Code-Signing im Sicherheitsniveau „Global” voll unterstützt.
-
-	Microsoft Windows Code-Signing (egal für welchen Einsatzzweck) wird nicht direkt unterstützt, da das Wurzelzertifikat der DFN-PKI „Global” in Microsoft Windows für diesen Zweck nicht freigeschaltet ist. Weitere Hinweise finden Sie unter Punkt 5.
-
-	Android Apps werden insbesondere für den Google Play Store mit selbst-signierten Zertifikaten signiert, die direkt durch die Entwicklerwerkzeuge generiert werden. Daher gibt es keine Notwendigkeit, hierfür die DFN-PKI zu verwenden. Weitere Erläuterungen finden Sie unter Punkt 6.
-
-	===3. Wie wird ein Code-Signing Zertifikat beantragt?===
-
-	Code-Signing-Zertifikate können folgendermaßen über die CA Ihrer Einrichtung bezogen werden:
-
-	* Beantragen Sie das Code-Signing Zertifikat mit Ihrem Webbrowser über den Antragsweg „Nutzerzertifikat”. Wählen Sie als Namen im Zertifikat //„PN: <Vorname Nachname> - CodeSigning”//, und verwenden Sie gegebenenfalls eine rollenbasierte E-Mail-Adresse. Wir empfehlen, das Zertifikat nicht veröffentlichen zu lassen. Merken Sie sich die von Ihnen vergebene (Sperr-)PIN sehr gut, denn Sie benötigen diese zum späteren Import des ausgestellten Zertifikats in Ihren Webbrowser.
-	* Duch die Beantragung wird in Ihrem Webbrowser ein privater Schlüssel erzeugt.
-	* Teilen Sie Ihrem Teilnehmerservice bei Abgabe des unterschriebenen Papier-Antrages mit, dass Sie ein Code-Signing Zertifikat benötigen, damit der Teilnehmerservice das korrekte Zertifikatsprofil setzen kann.
-	* Nach der Ausstellung des Code-Signing Zertifikats erhalten Sie eine E-Mail. Folgen Sie der Anleitung in der E-Mail, um alle CA-Zertifikate und das neue Zertifikat korrekt in Ihren Webbrowser zu importieren.
-	* Exportieren Sie das Zertifikat zusammen mit dem privaten Schlüssel über den Zertifikatmanager des Browsers als PKCS#12-Datei. Wählen Sie dabei ein starkes Passwort, und speichern Sie die PKCS#12-Datei möglichst auf einem externen, nicht dauerhaft an Ihren Rechner angeschlossenen Medium wie einen USB-Stick.
-	* Löschen Sie anschließend das Zertifikat aus dem Zertifikatmanager Ihres Browsers.
-
-	===4. Wie wird ein Code-Signing Zertifkat für das Signieren von Java-Code verwendet?===
-
-	Zum Signieren von Java-Code werden die Werkzeuge keytool und jarsigner benötigt, die im Java SDK enthalten sind. Wir empfehlen die Verwendung von Schlüsseln in PKCS#12-Dateien (siehe voriger Abschnitt), da die Arbeit mit dem nativen Java-Keystore (über das Werkzeug „keytool”) komplizierter und fehleranfälliger ist.
-	Bevor Sie eine PKCS#12-Datei zum Signieren verwenden können, müssen Sie den Parameter „<Alias>” in Erfahrung bringen. Hierzu verwenden Sie den folgenden Befehl
-
-	keytool -list -keystore <PKCS#12-Datei> -storetype pkcs12
-
-	Sie erhalten die folgende Ausgabe, in der Sie vor dem Zertifikat-Fingerprint den Alias finden:
-
-	<code>Keystore-Typ: PKCS12
-	Keystore-Provider: SunJSSE
-
-	Keystore enthält 1 Eintrag
-
-	<Alias>, 20.02.2015, PrivateKeyEntry,
-	Zertifikat-Fingerprint (SHA1):\\
-	48:B5:50:C5:18:48:9E:29:59:30:B2:1C:7A:A0:15:7E:CF:85:46:93</code>
-
-	Das Signieren erfolgt mit folgendem Aufruf:
-
-	<code>jarsigner -tsa zeitstempel.dfn.de -keystore <PKCS#12-Datei> -storetype pkcs12 <Zu signierendes JAR> '<Alias>'</code>
-
-	Optional kann, entgegen teilweise anzutreffender Dokumentation, ein Proxy für den Zeitstempelserver angegeben werden. Die zusätzlichen Parameter hierfür sind:
-
-	<code>-J-Dhttp.proxyHost=<ProxyHost> -J-Dhttp.proxyPort=<ProxyPort></code>
-
-	Online-Resourcen zum Thema finden sich unter folgenden Links:
-
-	http://www.oracle.com/technetwork/java/javase/tech/java-code-signing-1915323.html\\
-	http://docs.oracle.com/javase/8/docs/technotes/guides/deploy/manifest.html#A1148525
-
-	===5. Was ist beim Code-Signing in Microsoft Windows zu beachten?===
-
-	Die beiden Wurzel-CA-Zertifikate der alten DFN-PKI Hierarchie "Deutsche Telekom Root CA 2" und der neuen DFN-PKI Hierarchie "T-TeleSec GlobalRoot Class 2" sind im Windows-Zertifikatsspeicher nicht für den Zertifikatszweck "Codesignatur" freigeschaltet.
-
-	Obwohl es technisch nicht vollkommen ausgeschlossen ist, die Zertifikate der DFN-PKI „Global” für Code-Signing unter Windows zu verwenden, empfehlen wir dies nicht.
-
-	Damit Windows-Systeme die Code-Signing-Zertifikate der DFN-PKI als solche akzeptieren, muss auf den Windows-Systemen im Windows-eigenen Zertifikatmanager in den Eigenschaften des "Deutsche Telekom Root CA 2" Zertifikats bzw. "T-TeleSec GlobalRoot Class 2" Zertifikats der Zertifikatszweck "Codesignatur" aktiviert werden.
-
-	Diese Änderung kann auf jedem betroffenen Windows-System manuell durchgeführt werden. Da Microsofts Auto-Update-Mechanismen diese manuell gemachte Einstellung unserer Erfahrung nach sporadisch (ohne erkennbares Muster) zurücksetzen, wird nicht empfohlen, dieses Vorgehen zu wählen.
-
-	Diese Einstellung kann darüber hinaus über eine Windows-Gruppenrichtlinie an alle Mitglieder einer vorhandenen Windows-Domäne verteilt werden. In diesem Fall wird die Einstellung nicht automatisch zurückgesetzt. Für Windows-Systeme, die nicht Mitglied in einer entsprechenden zentral verwalteten Windows-Domäne sind, ist dieses Vorgehen allerdings nicht möglich.
-
-	Vorsicht mit automatischen kritischen Prozessen, die diese signierten Programme/Skripte/Macros benutzen und ggf. nicht mehr laufen, falls sich der Zertifikatszweck (unbemerkt) zurückgesetzt hat.
-
-	===6. Was ist beim Code-Signing von Android Apps für Google Play zu beachten?===
-
-	Obwohl es technisch nicht vollkommen ausgeschlossen ist, die Zertifikate der DFN-PKI „Global” für Code-Signing unter Android zu verwenden, empfehlen wir dies nicht.
-
-	Zum Signieren von Android Apps für Google Play werden selbst-signierte Zertifikate mit einer sehr langen Laufzeit verwendet. Diese selbst-signierten Zertifikate werden üblicherweise direkt von den Android Entwicklertools erzeugt.
-
-	Das Zertifikat hat bei Android keine Sicherheitsfunktion bzgl. Identifizierung. Das Signieren und die Verwendung von Zertifikaten dient ausschließlich dazu, Updates sicher zu einer Ursprungs-App zurück zu verfolgen, und nicht, um den Entwickler zu identifizieren. Die Nutzung von Zertifikaten aus einer PKI bringt daher keine Vorteile. Die Verwendung von selbst-signierten Zertifikaten ist, wenn auch ungewohnt, sicherheitstechnisch angemessen.
-
-	Wie man sich ein selbst-signiertes Zertifikat mit Android Studio erzeugt, ist auf der folgenden Seite beschrieben:
-
-	http://developer.android.com/tools/publishing/app-signing.html#studio

faq - gelöscht - Externe Bearbeitung (Unbekanntes Datum)

Anonymous (anonymous@undisclosed.example.com) — 2026-08-12T12:56:32+00:00

2018/06/07 10:04		aktuell
Zeile 1:		Zeile 1:
-	====== Häufig gestellte Fragen zur DFN-PKI (FAQ) ======	+
-	- [[de:dfnpki:faq:allgemein\|Allgemeine Fragen und Antworten zu Zertifikaten in der DFN-PKI]]	+
-	- [[de:dfnpki:faq:gen2\|Fragen und Antworten zur Einführung der 2. Generation der DFN-PKI Global]]	+
-	- [[de:dfnpki:faq:ts-betrieb\|Fragen und Antworten zum Betrieb eines Teilnehmerservice (TS)]]	+
-	- [[de:dfnpki:faq:mozilla\|Fragen und Antworten zu Zertifikaten in Mozilla Anwendungen]]	+
-	- [[de:dfnpki:faq:caa\|Fragen und Antworten zu CAA RRs]]	+
-	- [[de:dfnpki:faq:windows\|Fragen und Antworten zu Zertifikaten in Windows Systemen und im Internet Explorer]]	+
-	- [[de:dfnpki:faq:software\|Fragen und Antworten zu Zertifikaten in spezieller Software (z.B. Cisco, Apache, Novell, Lotus)]]	+
-	- [[de:dfnpki:faq:codesigning\|Fragen und Antworten zum Thema Code- und Object-Signing mit Zertifikaten aus der DFN-PKI]]	+
-	- [[de:dfnpki:faq:sha2\|Fragen und Antworten zur Umstellung von SHA-1 auf SHA-2]]	+
-	- [[de:dfnpki:faq:grid\|Fragen und Antworten zu Grid Zertifikaten (z.B. Robot, SLSC) insbesondere in der DFN-AAI]]	+
-	- [[de:dfnpki:faq:dfnaai\|Fragen und Antworten zu Zertifikaten in der DFN-AAI]]	+
-	- [[de:dfnpki:faq:zeitstempel\|Fragen und Antworten zum DFN Zeitstempeldienst]]	+
-	- [[de:dfnpki:faq:email\|Fragen und Antworten zur Bestätigung von E-Mail-Adressen]]	+

dfn-verein_community_pki_cps.pdf

Juergen Brauckmann (brauckmann@dfn-cert.de@undisclosed.example.com) — 2026-06-22T05:53:09+00:00

1685720758	aktuell

dfn-verein_community-pki_cps_v2_redline.pdf

Juergen Brauckmann (brauckmann@dfn-cert.de@undisclosed.example.com) — 2026-06-18T16:21:07+00:00

1781799255	aktuell

2026/08/27 20:50		aktuell
Zeile 25:		Zeile 25:
	\| schacHomeOrganization \| org_domain \| \|		\| schacHomeOrganization \| org_domain \| \|
	\| eduPersonAffiliation \| eduperson_affiliation \| \|		\| eduPersonAffiliation \| eduperson_affiliation \| \|
-	\| voPersonExternalAffiliation \| voperson_external_affiliation \| \|	+	\| voPersonExternalAffiliation \| voperson_external_affiliation \| (ab Q4 2026 verfügbar) \|
	\| eduPersonAssurance \| eduperson_assurance \| \|		\| eduPersonAssurance \| eduperson_assurance \| \|
	\| mail \| email \| \|		\| mail \| email \| \|

2018/06/07 10:04		aktuell
Zeile 1:		Zeile 1:
-	====== Häufig gestellte Fragen zur DFN-PKI (FAQ) ======	+
-	- [[de:dfnpki:faq:allgemein\|Allgemeine Fragen und Antworten zu Zertifikaten in der DFN-PKI]]	+
-	- [[de:dfnpki:faq:gen2\|Fragen und Antworten zur Einführung der 2. Generation der DFN-PKI Global]]	+
-	- [[de:dfnpki:faq:ts-betrieb\|Fragen und Antworten zum Betrieb eines Teilnehmerservice (TS)]]	+
-	- [[de:dfnpki:faq:mozilla\|Fragen und Antworten zu Zertifikaten in Mozilla Anwendungen]]	+
-	- [[de:dfnpki:faq:caa\|Fragen und Antworten zu CAA RRs]]	+
-	- [[de:dfnpki:faq:windows\|Fragen und Antworten zu Zertifikaten in Windows Systemen und im Internet Explorer]]	+
-	- [[de:dfnpki:faq:software\|Fragen und Antworten zu Zertifikaten in spezieller Software (z.B. Cisco, Apache, Novell, Lotus)]]	+
-	- [[de:dfnpki:faq:codesigning\|Fragen und Antworten zum Thema Code- und Object-Signing mit Zertifikaten aus der DFN-PKI]]	+
-	- [[de:dfnpki:faq:sha2\|Fragen und Antworten zur Umstellung von SHA-1 auf SHA-2]]	+
-	- [[de:dfnpki:faq:grid\|Fragen und Antworten zu Grid Zertifikaten (z.B. Robot, SLSC) insbesondere in der DFN-AAI]]	+
-	- [[de:dfnpki:faq:dfnaai\|Fragen und Antworten zu Zertifikaten in der DFN-AAI]]	+
-	- [[de:dfnpki:faq:zeitstempel\|Fragen und Antworten zum DFN Zeitstempeldienst]]	+
-	- [[de:dfnpki:faq:email\|Fragen und Antworten zur Bestätigung von E-Mail-Adressen]]	+