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

caa

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

2025/06/05 13:25	aktuell
Zeile 1:	Zeile 1:
	+
	+	=====CAA-Records=====
	+
	+	Wenn Sie CAA-Records im DNS setzen möchten, um die Ausstellung von Zertifikaten auf bestimmte CAs einzuschränken, verwenden Sie für TCS den ''issue''-Wert ''sectigo.com'':
	+
	+	<code>
	+	muster-uni.de. IN CAA 0 issue "sectigo.com"
	+	muster-uni.de. IN CAA 0 issue "pki.dfn.de"
	+	</code>
	+
	+	Der CAA-Record muss bereits zum Zeitpunkt der Domain-Freischaltung passen, nicht erst zum Zeitpunkt der konkreten Zertifikatausstellung.
	+
	+	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 "sectigo.com"
	+	muster-uni.de. IN CAA 0 issue "pki.dfn.de"
	+	</code>

cacerts

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

2026/05/03 16:25	aktuell
Zeile 1:	Zeile 1:
	+	====== GÉANT TCS (Sectigo 2020-2024) 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 hier aufgeführten Root- und CA-Zertifikate werden in TCS verwendet. Die Fingerprints können z.B. mit openssl reproduziert werden:
	+
	+	openssl x509 -in <datei.pem> -fingerprint -sha256 -noout
	+
	+	===== Ö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 \|
	+

codesigning

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

2025/06/05 13:26	aktuell
Zeile 1:	Zeile 1:
	+	=====Code Signing-Zertifikate=====
	+
	+	Prinzipiell stehen zwei verschiedene CodeSigning-Zertifikattypen zur Verfügung:
	+
	+	* OV Code Signing für die Signatur von Java JARs und MS Office Macros.
	+	* Beantragung per E-Mail-Einladung aus SCM heraus
	+	* Voraussetzung: Sie müssen einen Yubikey 5 FIPS besitzen
	+	* Manueller Prozess auf Seiten von Sectigo mit Verzögerungen von wenigen Stunden bis mehrere Tagen. Bitte Support-Ticket mit "Order Number" erstellen.
	+
	+	* EV Code Signing für Signaturen, die in Microsoft SmartScreen per Default ein höheres Vertrauen besitzen
	+	* Kostenpflichtiger Prozess außerhalb von SCM
	+
	+	==== OV Code Signing ====
	+
	+	===Vorbereitung der E-Mail-Einladung===
	+
	+	Für die Erstellung von OV-Code Signing-Zertifikaten in SCM ist eine gewisse Vorbereitung notwendig. Insbesondere muss ein Account in einem ''Code Signing certificate enrollment form'' angelegt werden:
	+
	+	- Im SCM unter ☰->Enrollment->Enrollment Forms
	+	- Mit dem grünen Button "+" oben rechts ein neues nur Ihrer Einrichtung zugehöriges Enrollment Form erzeugen
	+	- Einen sprechenden Namen vergeben, der auf Ihre Einrichtung hinweist
	+	- Als Typ "Code Signing certificate enrollment form" setzen
	+	- Im folgenden Dialog unter Tab "Details" eine URI Extension setzen oder generieren lassen. Diese URI Extension definiert die URL, unter der später Zertifikate beantragt werden kann: ''%%https://cert-manager.com/customer/DFN/cs/<URI Extension>%%''
	+	- Mit "Save" abspeichern
	+	- Oben auf "Accounts" klicken.
	+	- Im daraufhin geöffneten Popup-Fenster über mit dem grünen "+"-Button einen neuen "Code Signing Web Form Account" hinzufügen.
	+	- Einen sprechenden Namen für den Code Signing Web Form Account vergeben, der auf Ihre Einrichtung hindeutet.
	+	- Als "Organization" Ihre Einrichtung aus der Drop-Down-Liste auswählen (und ggf. auch ein Department setzen, wenn der Code Signing Web Form Account ausschließlich auf Department-Level eingerichtet werden soll).
	+	- Als Zertifikatprofile stehen ''GÉANT OV Code Signing (Key Attestation) - 1 year'', ''GÉANT OV Code Signing (Key Attestation) - 2 years'' und ''GÉANT OV Code Signing (Key Attestation) - 3 years'' zur Auswahl. Das gewählte Zertifikatsprofil beeinflusst die Zertifikatlaufzeit.
	+	- Gewünschtes Zertifikatprofil aus der Drop-Down-Liste auswählen.
	+	- Als "CSR Generation Method" den Wert "Provided by user" auswählen.
	+	- Mit "Save" abspeichern.
	+
	+	Bitte keine fremden ''Enrollment Forms'' löschen!
	+
	+	Alte Enrollment Forms und darin bestehende Code Signing Web Form Accounts sollten nur nach sorgfältiger Abwägung gelöscht werden, da diese unter ihrer URL noch Selbstverwaltungsmöglichkeiten (insb. Sperrung) der bereits unter diesen Enrollment Forms und Account ausgestellten Code Signing-Zertifikate bieten.
	+
	+	Dann zum manuellen Auslösen der einzelnen Einladungs-Mails durch (D)RAOs unterhalb von ☰->Certificates->Code Signing Certificates:
	+
	+	- Mit dem "Invitations"-Button oben rechts wird ein Popup-Fenster mit einer Übersicht über die ausstehenden Einladungen für die Beantragung von Code Signing-Zertifikaten angezeigt.
	+	- Mit dem grünen "+"-Button in dem Popup-Fenster kann eine einzelne Person (bestimmt durch eine E-Mail-Adresse) zur Beantragung eines Code Signing-Zertifikats per E-Mail eingeladen werden.
	+	- Es muss die E-Mail-Adresse angegeben werden, an die die Einladungs-E-Mail verschickt wird.
	+	- Es muss der "Enrollment Endpoint" ausgewählt werden, der im obigen Schritt angelegt worden ist. Hinweis: Die Liste der angezeigten Enrollment Endpoints kann zur Zeit unter Umständen leider auch fremde Endpoints anderer Einrichtungen enthalten.
	+	- Es muss einer der vorher von der Einrichtung/Department angelegten "Code Signing Web Form Accounts" ausgewählt werden.
	+	- Abschließend auf den "Send"-Button klicken, um die Einladungs-E-Mail zu versenden.
	+
	+	Die eingegangenen Zertifikatanträge für Code Signing-Zertifikate bzw. die ausgestellten Code Signing-Zertifikate sind im SCM unterhalb von ☰->Certificates->Code Signing Certificates sichtbar und werden automatisch von Sectigo bearbeitet.
	+
	+	===Vorgehen bei der Beantragung===
	+
	+	Die Einladungs-E-Mail muss dann folgendermaßen bearbeitet werden:
	+
	+	0. Bei der Beschaffung: Unbedingt die Variante Yubikey 5 FIPS wählen. Yubikeys ohne den Zusatz FIPS können die erforderliche Key Attestation nicht erzeugen.
	+
	+	1. Yubikey vorbereiten:
	+	* PIN setzen. Achtung: Es gibt Werkzeuge, die das Setzen von PINs mit einer Länge von mehr als 8 Zeichen erlauben. Diese werden von der PKCS11-Library ykcs11 nicht unterstützt, dort funktionieren nur PINs mit 6-8 Zeichen.
	+	* Default PIV Management Key vom Default 010203040506070801020304050607080102030405060708 auf was "richtiges" umsetzen
	+	* PUK setzen.
	+
	+	2. Schlüssel erzeugen und den öffentlichen Teil in eine Datei ausgeben:
	+	<code>
	+	yubico-piv-tool -a generate --slot=9c --pin-policy=once -k -A ECCP384 -o PublicKeyFile.key
	+	</code>
	+
	+	''pin-policy=once'' ermöglicht die Erstellung von mehreren Signaturen hintereinander mit nur einer PIN-Eingabe. Diese Option ist insbesondere für Windows ''signtool.exe'' notwendig, wenn MSI signiert werden.
	+
	+	3. CSR erzeugen und in eine Datei ausgeben:
	+	<code>
	+	yubico-piv-tool -a verify-pin -a request-certificate --slot=9c -i PublicKeyFile.key -S <subject dn> -o request.csr
	+	</code>
	+
	+	(-S <subject_dn> mit Slash am Ende, z.B. -S "/CN=Jane Doe/")
	+
	+	Sollte ''yubico-piv-tool'' mit der Fehlermeldung ''Failed signing request.'' scheitern, kann alternativ das Werkzeug ''ykman'' verwendet werden:
	+	<code>
	+	ykman piv certificates request -s "CN=Jane Doe" 9c PublicKeyFile.key request.csr
	+	</code>
	+
	+	4. Key Attestation erzeugen:
	+	<code>
	+	yubico-piv-tool --action=attest --slot=9c > Slot9cAttestation.pem
	+	</code>
	+	(funktioniert nur für nach dieser Anleitung erzeugte Keys, nicht für anderweitig importierte)
	+
	+	5. Intermediate aus dem Yubikey auslesen
	+	<code>
	+	yubico-piv-tool --action=read-certificate --slot=f9 > intermediate.pem
	+	</code>
	+
	+	6. Attestation-Bundle für Sectigo Webinterface erzeugen
	+	<code>
	+	cat Slot9cAttestation.pem intermediate.pem > attestation_bundle.pem
	+	base64 -w 64 attestation_bundle.pem > attestation_bundle.b64
	+	</code>
	+	Oder Windows:
	+	<code>
	+	type Slot9aAttestation.pem intermediate.pem > attestation.pem
	+	certutil -encode attestation.pem attestation_bundle.pem
	+	findstr /v CERTIFICATE attestation_bundle.pem > attestation_bundle.b64
	+	</code>
	+
	+
	+	7. Antrag stellen:
	+	* Die Datei request.csr aus Schritt 3 als CSR in das per E-Mail-Einladung übermittelte Formular eingeben
	+	* Den Inhalt der Datei attestation_bundle.b64 aus Schritt 6 in das Feld "Key Attestation" eingeben
	+
	+	8. Sectigo bearbeitet den Antrag. Mit Stand 2024-01 handelt es sich um einen manuellen Prozess auf Seiten von Sectigo mit Verzögerungen von wenigen Stunden bis mehreren Tagen. Bitte erstellen Sie gegebenenfalls ein Support-Ticket nach [[de:dfnpki:tcsfaq#support\|Anleitung]]. Das Ticket muss die "Order Number" enthalten, die zu dem gestellten Antrag in SCM sichtbar ist.
	+
	+	9. Sectigo stellt das Zertifikat aus und verschickt eine E-Mail mit Links auf Zertifikatdateien
	+
	+	10. Aufspielen der von Sectigo gelieferten Zertifikatdatei aus dem Link "as Certificate only, PEM encoded:" auf den Yubikey, z.B. mit dem YubiKey Manager
	+
	+	===Code Signing mit Yubikey FIPS===
	+
	+	Windows: Anleitung von Yubico für Windows Code Signing: https://support.yubico.com/hc/en-us/articles/360016614840-Code-Signing-with-the-YubiKey-on-Windows
	+
	+	Java-Code: Signieren von Java-Code mit jarsigner:
	+	* Installation der Yubico PKCS#11-Library "ykcs11"
	+	* Abspeichern des von Sectigo gelieferten Zertifikats per Link aus der Auslieferungs-E-Mail "as Certificate (w/ issuer after)" als Datei "certchain.pem"
	+	* Datei ykcs11.conf anlegen mit Inhalt:
	+	<code>
	+	name = ykcs11
	+	library = <Pfad zur libykcs11.so>
	+	</code>
	+	* Signieren per Aufruf:
	+	<code>
	+	jarsigner -keystore NONE -certchain certchain.pem -storetype PKCS11 -providerClass sun.security.pkcs11.SunPKCS11 -providerArg ykcs11.conf <Zu signierende JAR> "X.509 Certificate for Digital Signature"
	+	</code>
	+
	+
	+
	+
	+	==== EV Code Signing ====
	+
	+	EV Code Signing-Zertifikate, denen beispielsweise in Microsoft SmartScreen sofort vertraut wird, müssen über einen separaten Antragsweg bestellt und zusätzlich bezahlt werden.
	+
	+	Die Beantragung erfolgt außerhalb des Cert-Managers. Eine Anleitung findet sich unter [[https://wiki.geant.org/display/TCSNT/TCS+2020+FAQ#TCS2020FAQ-Q:HowDoIOrderEVCodeSigningCertificates?]] (Hinter dem Link "GUIDE" versteckt sich eine ausführliche Anleitung als PDF-Dokument)

datenschutz

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

2025/06/05 13:32	aktuell
Zeile 1:	Zeile 1:
	+	=====Datenschutz=====

	+	Eine Bewertung von GÉANT zu Fragen des Datenschutzes und der DSGVO liegt vor: [[https://wiki.geant.org/display/TCSNT/TCS+2020+FAQ#TCS2020FAQ-Q:HowdoG%C3%89ANTandSectigodealwithGDPR/dataprotection?]].
	+
	+	Die Bewertung von GÉANT wurde von der Forschungsstelle Recht im DFN überprüft. Das Ergebnis der Prüfung ist hier verfügbar:
	+	{{ :de:dfnpki:tcs:20220119_stellungnahme_datenschutzhinweise_sectigo.pdf \|}}
	+
	+	Darüber hinaus wird häufiger die Frage gestellt, ob eine Auftragsverarbeitungsvereinbarung zur Nutzung des Dienstes vom DFN-Verein oder von Sectigo direkt angeboten wird. Dies ist mit der folgenden Begründung nicht notwendig und wird daher auch weder vom DFN-Verein noch von Sectigo angeboten:
	+
	+	Im Rahmen der GÉANT TCS erfolgt die vertragliche Vereinbarung (Sectigo Certificate Subscriber Agreement) über die Bereitstellung des Sectigo Certificate direkt zwischen Sectigo und dem betroffenen Angehörigen des DFN-Teilnehmers. Ausschließlich in diesem Verhältnis werden personenbezogene Daten zur Erstellung und Verwaltung des Sectigo Certificate verarbeitet. Folglich haben weder GÉANT noch der DFN-Verein irgendeinen Zugriff oder Einfluss auf die Verarbeitung personenbezogener Daten bei Sectigo. Beiden steht zudem in Bezug auf die Verarbeitung bei Sectigo keinerlei Weisungsrecht zu. Das Rahmenvertragswerk zwischen DFN-Verein, GÉANT und Sectigo beschränkt sich auf die wirtschaftlichen Konditionen, zu denen Angehörige von DFN-Teilnehmern Produkte von Sectigo in Anspruch nehmen können. Sectigo entscheidet somit allein über Art, Umfang und Dauer der Verarbeitung aufgrund des Subscriber Agreement 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.

documentsigning

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

2025/06/05 13:28	aktuell
Zeile 1:	Zeile 1:
	+	====Document Signing====
	+	===Rechtliche Grundlagen===
	+	Erläuterungen zu dem rechtlichen Aspekt finden Sie unter: [[de:dfnpki:sigsie_faq\|Rechtliche Grundlagen elektronischer Signaturen]]
	+
	+	Eine Präsentation ist verfügbar unter: {{ :de:dfnpki:dokumentensignatur_2022.pdf \|Technische und rechtliche Aspekte bei Dokumentensignaturen}}
	+
	+	===Tauglichkeit normaler Client-Zertifikate===
	+	Document Signing, z.B. in Adobe, ist mit den normalen Client-Zertifikaten zwar technisch möglich, es müssen aber recht hohe Hürden überwunden werden. Insbesondere sind bei den Prüfern der Signaturen spezielle Einstellungen zu treffen, um die Vertrauenswürdigkeit der Signaturen darzustellen. Diese Einstellungen müssen von jeder Person vorgenommen werden, die die Signaturen prüfen soll.
	+
	+	Eine sehr detaillierte Anleitung wird von der Universität Münster zur Verfügung gestellt. Deren Anwendung muss natürlich an die eigenen lokalen Gegebenheiten angepasst werden: https://www.uni-muenster.de/CA/de/howto-pdf.shtml
	+
	+	Organisationen und Personen, die mit Client-Zertifikaten aus GÉANT TCS fortgeschrittenen Signaturen gemäß eIDAS erstellen wollen, müssen darauf vorbereitet sein, dass sie die Identifizierung des Unterzeichnenden im Streitfall ggf. anhand eigener Unterlagen nachweisen müssen.
	+
	+	Die Ansprüche an qualifizierte Signaturen werden keinesfalls erfüllt.
	+
	+	Des Weiteren unterliegen die Zertifikate den Regeln des CA/Browserforums für S/MIME, wodurch sich auch sehr kurzfristig die technischen Rahmenbedingungen ändern können. Darüber hinaus sieht Sectigo den Einsatz der S/MIME-Client-Zertifikate nur für E-Mailsignatur und -verschlüsselung und nicht für andere Anwendungsfälle vor (siehe Kapitel 1.4 im Dokument "Sectigo WebPKI S/MIME Certificate Practice Statement" im [[https://www.sectigo.com/cps-repository\|CPS Repository]]).
	+
	+	Die [[de:dfnpki:dfnvereincommunitypki\|DFN-Verein Community-PKI]] ist eine Alternative, die niedrigere technische Hürden als die regulären Client-Zertifikate in GÉANT TCS hat.
	+
	+
	+
	+	===Document Signing Zertifikate===
	+	Im Rahmen von TCS können von Sectigo kostenpflichtige, rabattierte Document Signing Zertifikate bezogen werden, denen ohne weitere Konfigurationsarbeiten direkt in Adobe vertraut wird. Diese Zertifikate sind über die Adobe Approved Trust List verankert.
	+
	+	Zur rechtlichen Bewertung der mit den Document Signing Zertifikaten erzeugten Signaturen („Fortgeschritten nach eIDAS“) können wir keine Aussage treffen, da Sectigo die Prozesse nicht nach den Vorgaben von eIDAS gestaltet. Die Ansprüche an qualifizierte Signaturen werden keinesfalls erfüllt.
	+
	+	Für den Bezug dieser Zertifikate gibt es einen separaten Antragsweg außerhalb von cert-manager.
	+
	+	Die Zertifikate kosten ca. 130,- Euro für 3 Jahre. Der Betrag ist während des Antragsprozesses direkt per Kreditkarte oder PayPal zu begleichen. Neben diesem Betrag entstehen zusätzliche, weitere Kosten und Aufwände, da von Sectigo eine Identitätsbestätigung der Antragsstellenden durch eine dritte Partei (Notariate, Rechtsanwaltskanzleien o.ä) gefordert wird. Bisherige Erfahrungen zeigen, dass Sectigo bei den bestätigenden Notariaten/Kanzleien zurückruft und eine mündliche Bestätigung des Vorgangs einholen möchte. Zur Not wird für diese Nachfrage auch E-Mail verwendet. Es werden Adressdaten genutzt, die in einem Register, bspw. der Bundesrechtsanwaltskammer, aufgeführt sind.
	+
	+	Im Zuge des Antragsprozesses wird von Sectigo die Einsendung einer Kopie eines Ausweisdokumentes verlangt. Das Zertifikat wird von Sectigo auf Crypto-Token erstellt und versandt. Der DN der ausgestellten Zertifikate enthält je nach gewähltem Zertifikattyp entweder CN=<Einrichtung> (Typ "Company") oder CN=<Name des Antragsstellers> (Typ "Individual").
	+
	+	Die Beantragung und Bestellung führen Sie bitte über den von GÉANT zur Verfügung gestellten Link mit dem dort angegebenen Code aus, siehe [[https://wiki.geant.org/display/TCSNT/TCS+2020+FAQ#TCS2020FAQ-Q:AreDocumentSigningCertificatesavailableviaSectigo?]].
	+
	+	===Qualifizierte Zertifikate===
	+
	+	Sectigo hat auch ein Angebot für qualifizierte Zertifikate, die über die EU Trusted List auch in Adobe verankert sind. Dieses Angebot ist aber nicht Bestandteil des derzeitigen Leistungsumfangs von TCS und ist nicht rabattiert.
	+
	+	Auch die qualifizierten Zertifikate müssen über einen separaten Antragsweg außerhalb von cert-manager bezogen werden.

domains

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

2025/06/05 13:28	aktuell
Zeile 1:	Zeile 1:
	+	=====Domains und IPv4-Adressen in Zertifikaten=====
	+
	+
	+	Um Zertifikate zu erhalten, müssen die entsprechenden Domains oder IPv4-Adressen im SCM unter ☰->Domains eingetragen und delegiert werden. Jeder Eintrag muss über "Domain Control Validation" (DCV) validiert werden (Status muss auf "Validated" gesetzt sein).
	+
	+	Für Domains gilt: Es muss zunächst die Hauptdomain eingetragen, delegiert (Delegate) und validiert (DCV) werden, z.B. ''example.org''. Nach erfolgreicher Validierung (DCV) kann dann ein Sternchen-Eintrag ''*.example.org'' eingetragen werden. Nur mit dem Sternchen-Eintrag können später Zertifikate zu beliebigen FQDNs unterhalb der Hauptdomain erzeugt werden.
	+
	+	Wenn Sie CAA-Records im DNS verwenden, um die Zertifikatausstellung zu kontrollieren, so müssen die CAA-Records bereits zum Zeitpunkt der Domainvalidierung passen, und nicht erst zum Zeitpunkt der Ausstellung von Zertifikaten, siehe [[de:dfnpki:tcs:2020:caa\|CAA-Records]].
	+
	+	Die Validierung von IPv4-Adressen erfordert in einem etwas aufwändigeren Verfahren einen manuellen Kontakt mit dem Support. IPv6-Adressen in Zertifikaten werden im Rahmen von GÉANT TCS leider nicht unterstützt.
	+	====Domain/IPv4-Adress-Delegation====
	+
	+	===Domains/IPv4-Adressen im SCM eintragen===
	+
	+	Im SCM können Domains und IPv4-Adressen unter ☰->Domains über das grüne "+"-Symbol auf Organisations- und/oder Department-Ebene für eine beliebige Kombination von Zertifikattypen (''SSL''-Serverzertifikate, ''Client Certificates'' und ''Code Signing''-Zertifikate) hinzugefügt werden. Wird eine Domain bzw. IP-Adresse hinzugefügt löst dieses automatisch eine Delegationsanfrage bei der DFN-PCA aus. Sobald diese Anfrage genehmigt ist, können Sie mit der Domain Control Validation (DCV) weiter machen, falls die DCV nicht bereits vorher im System durchgeführt wurde und an den neuen Eintrag "vererbt" wird.
	+
	+	===Delegationen verwalten===
	+
	+	Solange für einen Domains/IP-Address-Eintrag mindestens eine Delegation an die eigene Einrichtung bzw. das eigene Department bestehen bleibt, können diese von (D)RAOs unter ☰->Domains--><Domain-Auswahl>-->[Delegate]-Button über eine Checkbox-Matrix innerhalb der Einrichtung bzw. des Departments verwaltet werden.
	+
	+	===Domains/IP-Addressen aus SCM entfernen===
	+
	+	(D)RAOs können selbständig keine Domains bzw. IP-Adressen aus dem SCM entfernen/löschen.
	+
	+	Die Entfernung einer Domain bzw. IP-Adressen impliziert die Entfernung aller dazugehörigen Delegationen.
	+
	+	Um eine bereits eingetragene Domain bzw. IP-Adresse wieder aus dem SCM zu entfernen, senden Sie bitte eine E-Mail an [[mailto:dfnpca@dfn-cert.de\|dfnpca@dfn-cert.de]].
	+
	+	====Domainvalidierung, Domain Control Validation (DCV)====
	+
	+	Um Zertifikate zu erhalten, müssen die entsprechenden Domains im SCM unter ☰->Domains eingetragen werden. Nach der Eintragung muss jede Domain über "Domain Control Validation" (DCV) validiert werden (Status muss auf "Validated" gesetzt sein).
	+
	+	Ausnahme: Wenn die eingetragene Domain ein FQDN ist und //ausschließlich// über das ACME-Protokoll mit einem Zertifikat versorgt werden soll, kann auf die Validierung (DCV) im SCM verzichtet werden. Der FQDN wird dann automatisch im Rahmen des ACME-Protokolls validiert.
	+
	+	Die Domainvalidierung muss bei Sectigo alle 365 Tage wiederholt werden. Das Ablaufdatum ist im cert-manager sichtbar.
	+
	+	Sofern die delegierte Domain eine Wildcard-Domain ist, z.B. ''*.example.org'', muss die Domainvalidierung mit einer der beiden DCV-Methoden ''E-Mail'' oder ''CNAME'' verwendet werden, damit die Wildcard-Domain voll validiert wird.
	+
	+	===Validierungsmethoden===
	+
	+	==E-Mail==
	+
	+	Domains können wie in der DFN-PKI über die Standardadressen ''hostmaster@'', ''webmaster@'', ''postmaster@'', ''admin@'' und ''administrator@'' validiert werden. Diese Standardadressen müssen in der zu validierenden Domain liegen; die zu validierende Domain muss für den E-Mail-Empfang auf diesen Adressen eingerichtet sein.
	+
	+	Die E-Mail-Adresse aus dem SOA-Record im DNS steht nicht zur Verfügung. Wenn in der zu validierenden Domain kein Mail-Empfang möglich ist, muss eine der anderen Validierungsmethoden verwendet werden.
	+
	+	==DNS bzw. CNAME==
	+
	+	Bei der CNAME-Methode muss im DNS ein von Sectigo vorgegebener CNAME für die Domain hinterlegt werden. Beispiel:
	+	<code>
	+	_230283408052380233432bdcad080132.example.org. CNAME 232187932234324bcadd98.9802843242dfa23098.sectigo.com.
	+	</code>
	+
	+	Achtung: Die zeitliche Abfolge der Schritte im DCV-Ablauf mittels CNAME ist entscheidend: Zuerst muss der vom SCM vorgegebene Alias-Name und dessen CNAME-Record von außen im DNS sichtbar sein, erst danach darf im SCM-DCV-Dialog auf "Submit" geklickt werden. (Analoges gilt für DCV mittels CNAME per REST-API.)
	+
	+	Nach dem "Submitten" werden die DNS-Resolver von TCS automatisch innerhalb der nächsten Stunde drei Mal versuchen, den Alias-Namen aufzulösen. Falls das fehlschlägt, werden keine weiteren automatischen Versuche unternommen. In so einem Fall sollte dann der DCV-Vorgang zurückgesetzt (Mülltonnen-Symbol neben "DCV Order Status" im SCM oder entsprechender REST-API-Aufruf) und neu eingeleitet werden, wobei dann vom SCM ein anderes Alias-Name/CNAME-Paar vorgegeben werden wird.
	+
	+	Nach erfolgter Validierung kann der CNAME wieder entfernt werden. Es ist davon auszugehen, dass bei einer Revalidierung (alle 365 Tage) ein anderer CNAME gesetzt werden muss.
	+
	+	==HTTP/HTTPS==
	+
	+	Bei der HTTP- bzw. HTTPS-Methode muss auf dem Webserver eine von Sectigo vorgegebene Datei unter einer vorgegebenen URL abgelegt werden.
	+
	+	Achtung: Mit dieser Methode wird nur der FQDN selbst validiert; es können keine Zertifikate für Subdomains oder Wildcards zu dem validierten Namen ausgestellt werden.
	+
	+	HTTP/HTTPS sind die einzigen zugelassenen Methoden für die Validierung von IPv4-Adressen.
	+
	+	===TCS' DNS-Resolver (DCV)===
	+
	+	Für DCV nutzt TCS DNS-Resolver, die von den Quelladressen ''91.199.212.132'', ''91.199.212.133'', ''91.199.212.151'', ''91.199.212.176'', ''91.199.212.148'' oder ''2a0e:ac00:0231:8080:d00c:12ff:fe51:5511'' aus ankommen. (Stand 01/2023)
	+
	+	====Domains und Departments====
	+
	+	Department-Administratoren (DRAOs) unterliegen keiner besonderen Beschränkung in der Domain-Verwaltung. Sie können neue Domains eintragen und abhängig vom Recht ''DCV'' auch validieren lassen.
	+
	+	Ist eine von einem DRAO eingetragene Domain bereits Ihrer Organisation zugewiesen und gibt es eine gültige Domain Control Validation, steht die Domain quasi sofort im Department zur Ausstellung von Zertifikaten zur Verfügung. Das gleiche gilt für im Department eingetragen Sub-Domains von bereits der Organisation zugewiesenen Parent-Domains.
	+
	+	Wenn Sie Domains in eingerichteten Departments kontrollieren wollen, müssen Sie sich z.B. E-Mail Benachrichtigungen über Domain-Delegationen konfigurieren (☰→Settings→Email Notifications, Typ Domain Approved)
	+
	+
	+	====Umlaut-Domains, internationalisierte Domain-Namen (IDN), Punycode====
	+
	+	Umlaut-Domains können in deren jeweiliger Punycode-Schreibweise in die Domain-Verwaltung vom SCM aufgenommen werden und dann ganz normal wie Domains ohne Umlaute behandelt werden.
	+
	+	====IP-Adressen in Zertifikaten====
	+
	+	TCS erlaubt es aktuell, ausschließlich IPv4-Adressen in Zertifikate aufzunehmen.
	+
	+	Um eine IP-Adresse in Zertifikate in den ''CommonName'' oder in den ''subjectAlternativeName'' (Typ ''ip'') aufnehmen zu können, ist wie folgt vorzugehen:
	+	- IPv4-Adresse wie eine Domain im SCM unter ☰->Domains hinzufügen. Dieses löst automatisch eine Domain-Delegationsanfrage bei der DFN-PCA aus.
	+	- Bestätigung der Domain-Delegation abwarten.
	+	- Den DCV-Prozess für die IP-Adresse mit der Methode ''HTTP'' oder ''HTTPS'' einleiten,
	+	- die dabei von Sectigo angegebene Datei mit dem angegeben Inhalt auf einen Web-Server über HTTP oder HTTPS (je nach ausgewählter DCV-Methode) unter der eingetragenen IP-Adresse und der angegeben URL zur Verfügung stellen.
	+	- Den begonnenen DCV-Vorgang wieder aufrufen und ''submitten''.
	+	- Den [[de:dfnpki:tcsfaq#support\|Sectigo-Support]] mit einem Ticket (//Case type: "Technical Support"; Case reason: "Sectigo Certificate Manager (SCM)"//) darüber informieren, dass es einen offenen DCV-Vorgang mit der Methode HTTP/HTTPS für die IP-Adresse gibt, und darum bitten, diesen zu prüfen.
	+
	+	Der Weg über den Support ist auch bei jeder turnusmäßigen, jährlichen Erneuerung der Validierung zu wiederholen.
	+
	+	Es können nur einzelne IPv4-Adressen eingetragen werden, keine Adressbereiche.
	+
	+	IPv6-Adressen in Zertifikaten werden von TCS nicht unterstützt.
	+

restapi

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

2025/06/05 13:29	aktuell
Zeile 1:	Zeile 1:
	+	=====Sectigo REST-API=====
	+
	+
	+	Die Systeme von Sectigo können per REST-API angesprochen werden. Es gibt zur Zeit (2024-05) zwei Versionen der API.
	+
	+	1. Eine ältere API mit Endpunkten unter https://cert-manager.com/
	+	* Authentifizierung per Username/Passwort eines RAO oder DRAO-Accounts im HTTP-Header
	+	* Dokumentation unter https://sectigo.com/knowledge-base/detail/Sectigo-Certificate-Manager-SCM-REST-API/kA01N000000XDkE
	+
	+	2. Eine neuere API mit Endpunkten unter https://admin.enterprise.sectigo.com/
	+	* Authentifizierung per OAUTH2 Client Credentials Grants
	+	* Anknüpfungspunkt in SCM sind spezielle RAO- und DRAO-Accounts vom Typ "API"
	+	* OAuth2 Client-ID und Client-Secret können in SCM erzeugt werden über ☰->Settings->Admins, Account vom Typ "API" auswählen und dann Button "API-Keys"
	+	* JSON-Dokumentation nach dem OpenAPI-Standard unter https://admin.enterprise.sectigo.com/api/v3/api-docs
	+
	+
	+
	+	Das REST-API kann nur dann zum Enrollment verwendet werden, wenn unter ☰->Organizations-><Auswahl> per Button Edit im Tab "Certificate Settings" in den Abschnitten "SSL Certificates" bzw. "Client Certificates" die Checkbox "Enable Web / REST API" angekreuzt ist.
	+
	+
	+	=== Beispiele für REST API Typ 1 ===
	+
	+	Es ist ein Login/Passwort eines im Cert-Manager angelegten Accounts zu übergeben. Sofern dieser Account ein "Standard"-Account ist, muss dessen
	+	Anfangspasswort bereits geändert worden sein, bevor dieser Account zum Zugriff auf das REST-API verwendet werden kann. Accounts vom Typ "API" funktionieren ausschließlich für den Zugriff mittels REST-API und bedürfen keiner initialen Passwortänderung. Die in der Dokumentation angegebene Client-Authentifizierung per Zertifikat für das REST-API ist noch nicht getestet.
	+
	+	Tipp: Man kann einen Account in seiner Rolle so einschränken, dass ausschließlich der REST-API-Zugang verwendet werden kann, siehe [[de:dfnpki:tcsfaq#admins_rollen_privilegien\|Admins, Rollen & Privilegien]]
	+
	+	Beispiel für die Beantragung von Serverzertifikaten:
	+
	+	<code>curl 'https://cert-manager.com/api/ssl/v1/enroll' -i -X POST \
	+	-H "Content-Type: application/json;charset=utf-8" \
	+	-H "login: <account>" \
	+	-H "password: <passwort>" \
	+	-H "customerUri: DFN" \
	+	-d '{"orgId":<OrgId>,"subjAltNames":"<FQDN des Servers>","certType":<Nummer des Zertifikatprofils>,"numberServers":0,"serverType":-1,"term":365,"comments":"","externalRequester":"","customFields": [],"csr":"-----BEGIN CERTIFICATE REQUEST-----\nMIICYjCCAU...N818=\n-----END CERTIFICATE REQUEST-----"}'</code>
	+
	+	Die <OrgId> (ID) ist direkt im cert-manager.com ablesbar: ☰->Organizations-><Organisationsauswahl>->Button Edit. Für DRAO-Accounts muss auf Department-Ebene die <OrgId> (ID) entsprechend vom zugehörigen Departement des DRAO-Accounts hergenommen werden: ☰->Organizations-><Organisationsauswahl>->Button Edit-><Department-Auswahl>->Button Edit.
	+
	+	Die <Nummer des Zertifikatprofils> muss einmalig mit folgendem Aufruf ermittelt werden:
	+
	+	<code>curl 'https://cert-manager.com/api/ssl/v1/types' -i -X GET \
	+	-H "Content-Type: application/json;charset=utf-8" \
	+	-H "login: <account>" \
	+	-H "password: <passwort>" \
	+	-H "customerUri: DFN" \</code>
	+
	+	Ausgestellte Zertifikate können mit folgendem Aufruf abgeholt werden:
	+
	+	<code>curl 'https://cert-manager.com/api/ssl/v1/collect/<Antragsnummer>/<Format>' -i -X GET \
	+	-H "Content-Type: application/json;charset=utf-8" \
	+	-H "login: <account>" \
	+	-H "password: <passwort>" \
	+	-H "customerUri: DFN" \</code>
	+
	+	<Antragsnummer> wurde bei einem vorherigen Aufruf von ...enroll als Rückgabewert zurückgeliefert.
	+
	+	<Format> spezifiziert das Rückgabeformat, z.B. "pem", weitere mögliche Werte siehe https://sectigo.com/knowledge-base/detail/SCM-Sectigo-Certificate-Manager-REST-API/kA01N000000XDkE
	+
	+	Für Nutzerzertifikate ist die Beantragung ähnlich aufgebaut. Die Aufrufe müssen an ''https://cert-manager.com/api/smime/v1/types'', ''.../smime/v1/enroll'' und ''.../smime/v1/collect/...'' geschickt werden. Für weitere Details zu den Parametern ist die API-Dokumentation von Sectigo heranzuziehen.
	+
	+	Beispielaufruf zur Beantragung eines Nutzerzertifikats:
	+
	+	<code>curl 'https://cert-manager.com/api/smime/v1/enroll' -i -X POST \
	+	-H "Content-Type: application/json;charset=utf-8" \
	+	-H "login: <account>" \
	+	-H "password: <passwort>" \
	+	-H "customerUri: DFN" \
	+	-d '{ "orgId":<OrgId>, "certType":<Nummer des Zertifikatprofils z.B. 21247>,\
	+	"email":"<e-mail-adresse>",\
	+	"firstName":"<vorname>", "lastName":"<nachname>",\
	+	"term":<Gültigkeit in Tagen, je Nach Zertifikatprofil entweder 365 oder 730>,\
	+	...,\
	+	"csr":"-----BEGIN CERTIFICATE REQUEST-----\nMIICYjCCAU...N818=\n-----END CERTIFICATE REQUEST-----"}</code>
	+
	+
	+	=== Beispiele für REST API Typ 2 ===
	+
	+	Für die modernere Variante des APIs sind Aufrufe mittels ''curl'' wegen der OAUTH2-Authentifizierung etwas unhandlich. Ein kleines Beispiel in Python, mit dem die angelegten Personen in SCM aufgelistet werden:
	+
	+	<code>
	+	import urllib.request
	+	from oauthlib.oauth2 import BackendApplicationClient
	+	from requests_oauthlib import OAuth2Session
	+
	+	# clientid und clientsecret über den Button "API-Keys" zu einem Admin-User im SCM erzeugt
	+	clientid=<XYZ>
	+	clientsecret=<XYZ>
	+
	+	token_url='https://auth.sso.sectigo.com/auth/realms/apiclients/protocol/openid-connect/token'
	+	client = BackendApplicationClient(client_id=clientid)
	+	oauth = OAuth2Session(client=client)
	+
	+	token = oauth.fetch_token(token_url='https://auth.sso.sectigo.com/auth/realms/apiclients/protocol/openid-connect/token',
	+	client_id=clientid, client_secret=clientsecret)
	+
	+	headers = {'Authorization': 'Bearer %s' % token.get('access_token')}
	+
	+	resp = requests.get('https://admin.enterprise.sectigo.com/api/person/v2/', headers=headers)
	+	print(resp.headers)
	+	print(resp.json())
	+	</code>

scmrollenundanmeldung

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

2025/06/05 13:29		aktuell
Zeile 47:		Zeile 47:
	Achtung: Geht das Zertifikat verloren, wird es gesperrt oder läuft es ab, ist für den RAO oder DRAO kein Zugriff mehr möglich. Eine andere Person mit gleichen oder größeren Rechten muss in dem Fall die zertifikatbasierte Authentifizierung abschalten oder ändern.		Achtung: Geht das Zertifikat verloren, wird es gesperrt oder läuft es ab, ist für den RAO oder DRAO kein Zugriff mehr möglich. Eine andere Person mit gleichen oder größeren Rechten muss in dem Fall die zertifikatbasierte Authentifizierung abschalten oder ändern.

-	Besonders tückische Falle: Die automatische Sperrung, wenn bereits Nutzerzertifikate existieren, siehe [[de:dfnpki:tcs:usercert#automatische_sperrung_von_nutzerzertifikaten\|Beschränkung der Anzahl der Zertifikate]]	+	Besonders tückische Falle: Die automatische Sperrung, wenn bereits Nutzerzertifikate existieren, siehe [[de:dfnpki:tcs:2020:usercert#automatische_sperrung_von_nutzerzertifikaten\|Beschränkung der Anzahl der Zertifikate]]
	====Anmeldung mit SAML====		====Anmeldung mit SAML====

	Über den Button "Sign in with your Institution" unterhalb der Eingabefelder für Nutzername und Passwort können sich RAOs oder DRAOs in cert-manager.com über die AAI einloggen. Eine Beschreibung der Voraussetzungen ist zu finden unter: [[https://wiki.geant.org/display/TCSNT/TCS+2020+FAQ#TCS2020FAQ-ToenableSAMLforadminaccesstoSCM:]]		Über den Button "Sign in with your Institution" unterhalb der Eingabefelder für Nutzername und Passwort können sich RAOs oder DRAOs in cert-manager.com über die AAI einloggen. Eine Beschreibung der Voraussetzungen ist zu finden unter: [[https://wiki.geant.org/display/TCSNT/TCS+2020+FAQ#TCS2020FAQ-ToenableSAMLforadminaccesstoSCM:]]

-	Weitere Voraussetzungen finden Sie unter [[de:dfnpki:tcs:zugriffperaai\|Zugriff per AAI]]	+	Weitere Voraussetzungen finden Sie unter [[de:dfnpki:tcs:2020:zugriffperaai\|Zugriff per AAI]]

	Um einen Account für das Einloggen mittels SAML/AAI vorzubereiten, gibt es zwei verschiedene Wege:		Um einen Account für das Einloggen mittels SAML/AAI vorzubereiten, gibt es zwei verschiedene Wege:

scmtipstricks

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

2025/06/05 13:30	aktuell
Zeile 1:	Zeile 1:
	+	=====Tipps und Tricks für SCM=====

	+
	+	===Fehlende Icons/Symbole===
	+
	+	Werden im SCM an einigen Stellen Alternativtexte oder Platzhalter anstatt Icons oder Symbole angezeigt, so kann das daran liegen, dass der verwendete Browser (z.B. Firefox) so konfiguriert ist, dass dieser ausschließlich "eigene" Schriftarten verwendet. Die fehlenden Icons und Symbole sind allerdings als Zeichen aus einem Symbolzeichensatz realisiert, den die Web-Seiten mitbringen. Erlauben Sie die Verwendung von eigenen Zeichensätzen der Web-Seiten unter den erweiterten Font- und Farbeinstellungen des Browsers: "[x] Allow pages to choose their own fonts, instead of your selections above".
	+
	+	===Filtereinstellungen zurücksetzen===
	+
	+	In den unterschiedlichen Übersichtslisten des SCMs können verschiedene Ansichtsfilter gesetzt werden, die auch über Login-Sessions hinweg persistent bleiben. Hat man aus Versehen einen Filter gesetzt, der zu Zeitüberschreitungsfehlern oder gar internen Server-Fehlern führt und daher nicht mehr über die normale Filterkonfiguration zurücksetzbar ist, so können über die Profil-Verwaltung des eigenen Accounts unter "My Profile" die "Grid settings" auf die Standardeinstellungen zurückgesetzt werden. Diese Funktion setzt sowohl alle Tabellenansichten (insb. die Spaltenauswahl) in den Übersichtslisten zurück als auch alle gesetzten Ansichtsfilter.
	+
	+	===Ansicht der Tabellenspalten zurücksetzen oder reparieren===
	+
	+	In den unterschiedlichen Übersichtstabellen des SCMs wird mit Spalten gearbeitet. Manchmal werden einzelne Spalten unsichtbar und können auch nicht mit dem Spaltenansichtskonfigurator der jeweiligen Tabelle selbst zurückgeholt werden. Über die Profil-Verwaltung des eigenen Accounts können unter "My Profile" fast ganz unten die "Grid settings" auf die Standardeinstellungen zurückgesetzt werden. Diese Funktion setzt sowohl alle Tabellenansichten (insb. die Spaltenauswahl) in allen Übersichtslisten zurück als auch alle gesetzten Ansichtsfilter.

scm_notifications

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

2025/06/05 13:30	aktuell
Zeile 1:	Zeile 1:

	+	====Automatische Benachrichtigungen (Notifications) durch SCM====
	+
	+	Im SCM können automatische Benachrichtigungen (Notifications) zu bestimmten Ereignissen konfiguriert werden. Die Textvorlagen dazu können zum Teil auf Organisations- und Department-Ebene angepasst werden.
	+
	+	===Aktivieren von Benachrichtigungen===
	+
	+	- Im SCM über ☰->Settings->Notifications->das grüne "+"-Symbol oben rechts eine Benachrichtigung hinzufügen,
	+	- dabei einen Namen für die Benachrichtigung vergeben und den Benachrichtigungstyp auswählen. Es stehen mehrere Benachrichtigungstypen zur Auswahl.
	+	- Wir empfehlen Benachrichtigungen für die Typen ''SSL Expiration'', ''Client Certificate Expiration'', ''Code Signing Certificate Expiration'' und ''DCV Expiration'' einzurichten.
	+	- Zu ''SSL Expiration'': Wenn ein SSL-Server-Zertifikat mit den vorgesehenen Zertifikatserneuerungs-Mechanismen vom SCM (Auto-Renewal-Mechanismus und Renew-Button) //vor dem Zeitpunkt// erneuert wird, zu dem normalerweise die Benachrichtigung über den Ablauf dieses SSL-Zertifikats ausgelöst werden würde, so wird diese Zertifikatsablauf-Benachrichtigung (SSL Certificate Expiration) nicht ausgelöst. Dabei spielt es keine Rolle, ob bei diese Art der Zertifikatserneuerung sofort automatisch ein neues Zertifikat ausgestellt wird oder erst mal nur ein offener Zertifikats-Request im System erstellt wird. In beiden Fällen wird keine Zertifikatsbenachrichtigung ausgelöst.
	+	- Im nächsten Schritt können je nach Benachrichtigungstyp unterschiedliche (Empfangs-)Optionen definiert werden.
	+	- Falls einzelne Benachrichtigungstypen nicht sichtbar sind, liegt das daran, dass Ihr (D)RAO-Account nicht über die entsprechenden Berechtigungen verfügt.
	+	- Beim Einrichten einer ''DCV ...''-Benachrichtigung, bitte nicht die Benachrichtigung für ''Owner'' aktivieren. Die Benachrichtigung der ''Owner'' erreicht nur die MRAOs/DFN-PCA.
	+	- Sofern Funktions-E-Mail-Adressen (z.B. ein Ticket-System) benachrichtigt werden sollen, können diese über ''Additional recipients'' hinzugefügt werden.
	+
	+	===Anpassen von Benachrichtigungsvorlagen===
	+
	+	Benachrichtigungstexte können in den ''Notification Templates'' angepasst werden.
	+
	+	Im SCM über ☰->Organisations-><Auswahl>->Button [Notification Templates]->das grüne "+"-Symbol oben rechts eine Vorlage hinzufügen. Dabei den Empfangstyp (in der Regel wohl ''Email'') und den Benachrichtigungstyp auswählen. Dann kann der Standardvorlagentext angepasst werden.
	+
	+	Neben der Möglichkeit, Benachrichtigungen per E-Mail zu versenden, stehen auch ''MS Teams-'', ''Webhook-'' und ''Slack-''Mechanismen zur Auswahl.

servercert

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

2025/06/05 13:31		aktuell
Zeile 11:		Zeile 11:
	===Über die AAI====		===Über die AAI====

-	Wenn Ihre Einrichtung in die DFN-AAI eingebunden ist und Ihr IdP die Voraussetzungen erfüllt (siehe [[de:dfnpki:tcs:zugriffperaai\|Zugriff per AAI]]), können Sie ein Formular aufsetzen, über das nach AAI-Authentifizierung Serverzertifikate beantragt werden können.	+	Wenn Ihre Einrichtung in die DFN-AAI eingebunden ist und Ihr IdP die Voraussetzungen erfüllt (siehe [[de:dfnpki:tcs:2020:zugriffperaai\|Zugriff per AAI]]), können Sie ein Formular aufsetzen, über das nach AAI-Authentifizierung Serverzertifikate beantragt werden können.

	- Im SCM unter ☰->Enrollment->Enrollment Forms		- Im SCM unter ☰->Enrollment->Enrollment Forms

servercert_acme

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

2025/06/05 13:31		aktuell
Zeile 22:		Zeile 22:
	Es ist zu beachten, dass einem ACME-Account keine Stern-Domains (z.B. ''*.example.org'') zugeordnet werden dürfen. Die Zuordnung von solchen Stern-Domains hat im Kontext von ACME-Accounts keinen weiteren "Wildcard-Effekt".		Es ist zu beachten, dass einem ACME-Account keine Stern-Domains (z.B. ''*.example.org'') zugeordnet werden dürfen. Die Zuordnung von solchen Stern-Domains hat im Kontext von ACME-Accounts keinen weiteren "Wildcard-Effekt".

-	Die Zuordnung von Nicht-Stern-Domains (z.B. ''example.org'') genügt im Kontext von ACME-Accounts bereits vollständig aus, um sowohl Zertifikate für die eingetragene Domain selbst (in diesem Beispiel also ''example.org'') als auch für alle unterhalb von der explizit eingetragenen Domain möglichen FQDNs (auch unter Sub-Domains) (z.B. ''www.example.org'' und ''blog.it.example.org'') per ACME auszustellen. Siehe auch [[de:dfnpki:tcs:servercert_acme#schutz_von_acme-accounts\|Schutz von ACME-Accounts]].	+	Die Zuordnung von Nicht-Stern-Domains (z.B. ''example.org'') genügt im Kontext von ACME-Accounts bereits vollständig aus, um sowohl Zertifikate für die eingetragene Domain selbst (in diesem Beispiel also ''example.org'') als auch für alle unterhalb von der explizit eingetragenen Domain möglichen FQDNs (auch unter Sub-Domains) (z.B. ''www.example.org'' und ''blog.it.example.org'') per ACME auszustellen. Siehe auch [[de:dfnpki:tcs:2020:servercert_acme#schutz_von_acme-accounts\|Schutz von ACME-Accounts]].

	Eine häufige Fehlermeldung durch einen ACME-Client im Zusammenhang mit fälschlich zugewiesenen Stern-Domains im ACME-Kontext ist ''The client lacks sufficient authorization...''. Weitere Details dazu finden sich auch in der SCM-Knowledgebase unter https://sectigo.com/knowledge-base/detail/Sectigo-Certificate-Manager-SCM-ACME-error-The-client-lacks-sufficient-authorization/kA03l00000117Sy.		Eine häufige Fehlermeldung durch einen ACME-Client im Zusammenhang mit fälschlich zugewiesenen Stern-Domains im ACME-Kontext ist ''The client lacks sufficient authorization...''. Weitere Details dazu finden sich auch in der SCM-Knowledgebase unter https://sectigo.com/knowledge-base/detail/Sectigo-Certificate-Manager-SCM-ACME-error-The-client-lacks-sufficient-authorization/kA03l00000117Sy.

usercert

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

2025/06/05 13:31		aktuell
Zeile 177:		Zeile 177:
	* Ein Konfigurationsbeispiel für Ihren Identity-Provider finden Sie unter: [[de:shibidp:config-attributes-tcs?s[]=cert&s[]=manager]]		* Ein Konfigurationsbeispiel für Ihren Identity-Provider finden Sie unter: [[de:shibidp:config-attributes-tcs?s[]=cert&s[]=manager]]
	* Insbesondere muss ein eduPersonEntitlement ''urn:mace:terena.org:tcs:personal-user'' gesetzt werden. Bitte beachten Sie die Identifizierungsvoraussetzungen, bevor Sie das Entitlement setzen: [[de:dfnpki:tcs:2020:usercert#identifizierung_und_dokumentation\|Identifizierung und Dokumentation]].		* Insbesondere muss ein eduPersonEntitlement ''urn:mace:terena.org:tcs:personal-user'' gesetzt werden. Bitte beachten Sie die Identifizierungsvoraussetzungen, bevor Sie das Entitlement setzen: [[de:dfnpki:tcs:2020:usercert#identifizierung_und_dokumentation\|Identifizierung und Dokumentation]].
-	* Die Fehlermeldung ''You are not allowed to self enroll.'' ist ein Symptom für ein nicht übertragenes eduPersonEntitlement ''urn:mace:terena.org:tcs:personal-user''. Der [[de:dfnpki:tcs:zugriffperaai#tests\|SSOCheck]] gibt Auskunft, welche Attribute tatsächlich an TCS übertragen werden.	+	* Die Fehlermeldung ''You are not allowed to self enroll.'' ist ein Symptom für ein nicht übertragenes eduPersonEntitlement ''urn:mace:terena.org:tcs:personal-user''. Der [[de:dfnpki:tcs:2020:zugriffperaai#tests\|SSOCheck]] gibt Auskunft, welche Attribute tatsächlich an TCS übertragen werden.

	Für die Schlüsselerzeugung im AAI-Workflow gibt es in dem angebotenen Formular eine Wahlmöglichkeit:		Für die Schlüsselerzeugung im AAI-Workflow gibt es in dem angebotenen Formular eine Wahlmöglichkeit:

zugriffperaai

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

2025/06/05 13:32	aktuell
Zeile 1:	Zeile 1:
	+	=====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.
	+
	+	====Voraussetzungen====
	+	Viele Funktionen im cert-manager können auch nach einem Login über die DFN-AAI genutzt werden. Hierzu müssen die folgenden Voraussetzungen erfüllt sein:
	+
	+	* In der Verwaltungsoberfläche muss unter ☰->Organizations-><Auswahl>->✎ das Feld ''Organization Alias'' gesetzt sein.
	+	* Wenn kein ''Organization Alias'' gesetzt ist, senden Sie bitte den entspr. Wert (in der Regel das vom IdP gesendete ''schacHomeOrganization''-Attribut) per E-Mail an [[dfnpca@dfn-cert.de\|dfnpca@dfn-cert.de]].
	+	* Welcher Wert zu setzen ist, können Sie evtl. schon der Ausgabe von https://cert-manager.com/customer/DFN/ssocheck/ entnehmen. Oft entspricht dieser Wert der Haupt-Domain einer Einrichtung, also z.B. ''uni-musterstadt.de''. Im Zweifel wenden Sie sich bitte an Ihre haus-interne AAI-Administration.
	+	* 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 mindestens die Attribute ''schacHomeOrganization'', ''mail'' und ''eduPersonPrincipalName'' (''ePPN'') an den Service-Provider von Sectigo ausliefern.
	+	* Für eine AttributeFilterPolicy für Ihren Identity-Provider, die die gewünschten Attribute an Sectigo überträgt, siehe https://doku.tid.dfn.de/de:shibidp:config-attributes-tcs
	+
	+	Die Konfiguration erfordert in der Regel die Mithilfe Ihrer AAI-Administration, da oft die Attributfreigaben anzupassen sind und gegebenenfalls ein Entitlement gesetzt werden muss.
	+	====Tests====
	+	Unter https://cert-manager.com/customer/DFN/ssocheck/ steht ein Test-SP von Sectigo bereit, mit dem die übergebenen Attribute eingesehen werden können.
	+
	+	Die DFN-AAI stellt in der //DFN-AAI Testföderation// ebenfalls [[https://doku.tid.dfn.de/de:functionaltest_idp\|Test-SPs]] bereit, insbesondere https://testsp3.aai.dfn.de, mit denen die übergebenen Attribute eingesehen werden können. Dabei ist zu beachten, dass sich die lokalen Attribute-Release-Regeln im IdP zwischen dem Sectigo-SP und den Test-SPs der DFN-AAI Testföderation unterscheiden können, und daher die IdP-Konfiguration für Tests sehr genau betrachtet werden muss, um aussagekräftige Testergebnisse zu bekommen.
	+
	+	====Umgang mit Multi-Valued E-Mail-Adressen====
	+
	+	Der SP von Sectigo unterstützt leider ausschließlich single-valued mail-Attribute.
	+
	+	Wenn Ihr IdP standard-mäßig multi-value mail-Attribute herausgibt, kann folgendermaßen vorgegangen werden:
	+	* Vorhalten eines Feldes "idmcertrequestmail" im Identitätsmanagement, Befüllen mit der Default-Mail-Adresse
	+	* Definition eines Attributes "singlemail" im IdP
	+	* Aufstellen einer SP-spezifischen AttributeFilterPolicy
	+	* Mappen des Attributes singlemail auf mail
	+
	+	Definition des Attributs:
	+	<code>
	+	<!-- attribute-resolver.xml -->
	+	<!-- Definition des zusätzlichen Attributes -->
	+	<AttributeDefinition id="singlemail" xsi:type="Simple">
	+	<InputDataConnector ref="myLDAP" attributeNames="idmcertrequestmail"/>
	+	</AttributeDefinition>
	+	</code>
	+
	+	Die Attribut-Filter werden der Reihe nach abgearbeitet. Falls es wie üblich schon eine allgemeine Freigabe für das E-Mail Attribut gibt, muss diese speziell für den SP ''cert-manager.com/shibboleth'' überschrieben werden:
	+
	+	<code>
	+	<!-- attribute-filter.xml -->
	+	<!-- Release some attributes to Sectigo Certificate Manager -->
	+	<AttributeFilterPolicy id="SectigoCertificateManager">
	+	<PolicyRequirementRule xsi:type="Requester" value="https://cert-manager.com/shibboleth"/>
	+
	+	<AttributeRule attributeID="mail">
	+	<DenyValueRule xsi:type="ANY"/>
	+	</AttributeRule>
	+	<AttributeRule attributeID="singlemail">
	+	<PermitValueRule xsi:type="ANY"/>
	+	</AttributeRule>
	+
	+	</AttributeFilterPolicy>
	+	</code>
	+
	+	Je nach eingesetzter IdP Version müssen an geeigneter Stelle noch die OID + Beschreibungen gesetzt werden:
	+	<code>
	+	<bean parent="shibboleth.TranscodingProperties">
	+	<property name="properties">
	+	<props merge="true">
	+	<prop key="id">singlemail</prop>
	+	<prop key="transcoder">SAML2StringTranscoder SAML1StringTranscoder</prop>
	+	<prop key="saml2.name">urn:oid:0.9.2342.19200300.100.1.3</prop>
	+	<prop key="saml1.name">urn:mace:dir:attribute-def:mail</prop>
	+	<prop key="displayName.en">E-mail</prop>
	+	<prop key="displayName.de">E-Mail</prop>
	+	<prop key="displayName.fr">Email</prop>
	+	<prop key="displayName.it">E-mail</prop>
	+	<prop key="displayName.ja">メールアドレス</prop>
	+	<prop key="description.en">E-Mail: Preferred address for e-mail to be sent to this person</prop>
	+	<prop key="description.de">E-Mail-Adresse</prop>
	+	<prop key="description.de-ch">E-Mail Adresse</prop>
	+	<prop key="description.fr">Adresse de courrier électronique</prop>
	+	<prop key="description.it">E-Mail: l'indirizzo e-mail preferito dall'utente</prop>
	+	<prop key="description.ja">メールアドレス</prop>
	+	</props>
	+	</property>
	+	</bean>
	+	</code>