Frequently Asked Questions
Allgemein
TCS Zusatzvereinbarung
- Informationen zu Beilage 1 (Nachweis der Rechtspersönlichkeit)
- Informationen zu Beilage 2 (Details zur Teilnehmerorganisation)
- Informationen zu Beilage 3 (Autorisierte Vertreter des Teilnehmers)
Admins im SCM (Sectigo Certificate Manager)
RAOs
DRAOs
Management von Domains
- Anlegen von Domains (Add)
- Delegieren von Domains (Delegate)
- Bestätigen von Domains (Approve)
- Validieren von Domains (DCV)
- Löschen von Domains (Delete)
TLS/SSL Zertifikate
- Zertifikatsprofile
- Erstellen eines "keypairs"
- Beantragung von TLS-Zertifikaten für Nutzerinnen, die nicht *RAOs sind
- EV (Extended Validation) Zertifikate
Email bzw. Client Zertifikate
Grid bzw. IGTF Zertifikate
API Verwendung
- 'WS API use only' Verwendung
- Was ist der 'customerUri'
- Zertifikate per API beantragen
- einfaches curl Beispiel
Allgemein
Was ist TCS?
TCS steht für Trusted Certificate Service.
GEANT, der Verband europäischer Wissenschaftsnetze, hat einen Rahmenvertrag über die Vergabe und Verwaltung von X.509 Zertifikaten mit der Firma Sectigo als CA (Certificate Authority) abgeschlossen und stellt dieses Service als Trusted Certificate Service (TCS) allen teilnehmenden Wissenschaftsnetzen zur Verfügung.
ACOnet ist diesem Vertrag ebenfalls beigetreten und stellt Zertifikate für ACOnet Teilnehmer unentgeltlich und in unlimitierter Anzahl zur Verfügung. ACOnet Teilnehmerorganisationen können, auf Basis der Zusatzvereinbarung zur ACOnet‐Teilnahmevereinbarung betreffend die Nutzung des Trusted Certificate Service, TCS Zertifikate beantragen. Die Zusatzvereinbarung muss von einer für die teilnehmende Institution zeichnungsberechtigten Person im Original unterfertigt und mit den geforderten Beilagen per Post an ACOnet gesendet werden, siehe auch http://tcs.aco.net/.
Der Vertrag mit Sectigo gilt ab dem 01.05.2020, initial für 2 Jahre und kann dann jährlich, bis zu einer Gesamtlaufzeit von 10 Jahren, verlängert werden.
Was ist ein TCS-Admin?
Jede ACOnet Teilnehmerorganisation die das Zertifikatsservice nutzen will, muss zumindest eine/n, sollte aber mehr als eine/n, TCS Administrator/in angeben und diese/n in die Zusatzvereinbarung eintragen. Für entsprechend authentifizierte und autorisierte TCS AdministratorInnen haben im Portal die Möglichkeit, beantragte Zertifikate ihrer eigenen Organisation zu sehen, zu bestätigen, abzulehnen oder zu widerrufen. Im Portal von Sectigo werden diese Admins als RAO (Registration Authority Officer) bezeichnet.
Was ist DCV (Domain Control Validation)?
Bei der Registrierung einer neuen Domain, wird mittels DCV automatisiert überprüft, ob die Person, die die Validierung einer Domain angestossen hat (TCS-Admin), auch "Kontrolle" über den bzw die Domain-Namen hat.
Es gibt 3 Möglichkeiten:
- DNS CNAME
- HTTP/HTTPS File
1. Email:
Hierzu sendet der DCV Mechanismus ein E-Mail mit einem jeweils eindeutigen Code an einen definierten Satz von Adressen. Dieser Code wird durch den/die Empfänger dieser DCV Mails zur Validierung auf einer Webseite validiert (Email Challenge-Response Verfahren).
Erst nach dieser Validierung (bei Multi-Domain-Zertifikaten je Domain) wird das Zertifikat ausgestellt.
Folgende 5 generischen Email-Adressen stehen immer zur Verfügung:
- hostmaster@domain_name
- postmaster@domain_name
- webmaster@domain_name
- administrator@domain_name
- admin@domain_name
Zusätzlich kann das DCV Mail auch an alle Email-Adressen, die im 'whois-record' der Domain als tech- oder admin-contact gelistet sind, gesandt werden. Viele Domain Registrierungsstellen erlauben die Abfrage von Email-Adressen via whois allerdings nicht mehr. Der Grund dafür sind die strengen Richtlinien der DSGVO, wodurch personenbezogene Daten, wie Email-Adressen, nicht mehr abfragbar sind.
Die Email-Adressen (generich oder via whois)sind nicht nur für den Domainnamen des Zertifikats verfügbar, sondern auch für Domains "darüber":
z.B. um ein Zertifikat für www.bla.muh.ac.at zu erhalten, stehen folgende Mail-Domains für die DCV Bestätigung zur Verfügung:
- @www.bla.muh.ac.at
- @bla.muh.ac.at
- @muh.ac.at
2. DNS CNAME
Es wird ein hash erzeugt, der als DNS CNAME record für die Domain eingetragen werden muss und überprüft wird.
3. HTTP/HTTPS File
Es wird ein .txt File erzeugt, das im 'root' des Webservers abrufbar sein muss.
TCS Zusatzvereinbarung
Informationen zu Beilage 1 (Nachweis der Rechtspersönlichkeit)
- Bei Körperschaften öffentlichen Rechts und ähnlichen, auf Grund von Gesetzen (z.B. FOG) existierenden Organisationen, hier bitte einen Verweis auf das entsprechende Gesetz, wenn geht paragraphengenau, angeben.
- Für Kapitalgesellschaften ersuchen wir um einen aktuellen Firmenbuchauszug, aus dem die Zeichnungsberechtigung des Unterfertigers der Zusatzvereinbarung für den Teilnehmer hervorgeht. Bei Abweichungen der Zeicnungsberechtigungen vom Firmenbuch benötigen wir auch eine Kopie einer notariell beglaubigten Vollmacht, aus der die Zeichnungsberechtigung für den Abschluß eines derartigen Rechtsgeschäftes eindeutig hervorgeht.
- Bei Vereinen bitte um eine ZVR-Zahl.
Informationen zu Beilage 2 (Details zur Teilnehmerorganisation)
Die Beilage 2 dient zum Anlegen einer Organisation bei Sectigo. Folgende Dinge sind dabei zu beachten:
- Die Informationen (Name, Adressdaten) müssen jenen Informationen entsprechen, die sich auch in den in Beilage 1 beigebrachten Dokumenten wiederfinden. Diese sollten auch als QIS (Qualified Information Source) dem Validierungsantrag der Organisation beigefügt werden (siehe Validierung der Organisation).
- Auswahlboxen 'key recovery': Sectigo bietet die Möglichkeit, den privaten Schlüssel von über das Sectigo Portal (SCM, Sectigo Certificate Manager) beantragten persönlichen Zertifikaten, verschlüsselt zu speichern (siehe Details zum Erstellen des Schlüssel). Diese privaten Schlüssel werden in einem "elektronischen Safe" hinterlegt und können im Notfall, ie. wenn damit verschlüsselte Daten gebraucht werden, der/die Mitarbeiterin oder der private Schlüssel aber nicht mehr greifbar sind, ausgelesen werden. Sobald dies geschieht, wird das jeweilige persönliche Zertifikat allerdings sofort widerrufen und kann nicht mehr zur Verschlüsselung und/oder Signierung verwendet werden.
Ob ein solcher "elektronischer Safe" für eine Organisation erstellt wird oder nicht muss allerdings beim Anlegen der Organisation festgelegt werden und kann nachträglich nicht mehr verändert werden.
Weiters muss vor Beantragung des ersten persönlichen Zertifikats der Schlüssel für diesen Safe erstellt werden (siehe Details zum Erstellen des Schlüssel). Wenn dieser Schlüssel verloren geht, gibt es keine Möglichkeit auf den Safe und damit auf die privaten Schlüssel zuzugreifen.
Informationen zu Beilage 3 (Autorisierte Vertreter des Teilnehmers)
siehe auch Was ist ein TCS-Admin?
In der Beilage 3 sind uns die Organisations Administratoren, RAOs (Registration Authority Officer) in Sectigo Nomenklatur, zu nennen. Diese Adminstratoren haben unter anderem folgende Berechtigungen:
- Validierung bzw. Revalidierung der Organisation anstossen
- Domains anlegen und DCV (siehe DCV) anstossen
- Departments und zugehörige Administratoren anlegen
- Domains an Departments delegieren
- Zertifikatsanträge genehmigen
Admins im SCM (Sectigo Certificate Manager)
RAOs
Anlegen der initialen Admins
Die initialen Admins werden auf Grund der Informationen in der Beilage 3 der TCS Zusatzvereinbarung angelegt. Siehe auch Informationen zu Beilage 3.
Anlegen weiterer Admins
Für das Anlegen bzw. Berechtigen weiterer RAOs gibt es 3 Möglichkeiten:
- Sie schicken uns eine weitere, ausgefüllte und unterschrieben Beilage 3 mit den neuen RAOs. Hier genügt eine elektronische Version per Mail an tcs@aco.net.
- Ein bestehender TCS Admin (RAO) schickt uns per Mail die notwendigen Informationen (wie in Beilage 3) zum Anlegen eines weiteren RAOs per Mail an tcs@aco.net.
- Ein bestehender 'Department Admin' (DRAO, siehe Anlegen von 'Department Admins') kann vom ACOnet Team die Berechtigungen konfiguriert bekommen, um als RAO zu funktionieren. Dazu genügt ebenfalls ein Mail eines bestehenden TCS Admin (RAO) an tcs@aco.net.
DRAOs
Anlegen von 'Department Admins'
Management von Domains
Anlegen von Domains
Bevor sie Zertifikate beantragen können, müssen sie die entsprechenden Domains angelegt und validiert haben.
Wenn sie Domains anlegen müssen sie immer die eigentliche Domain und die dazu gehörige 'Wildcard Domain' anlegen, z.B. example.at und *.example.at
Diese 'Eigenheit' bei Sectigo ist notwendig, um beliebige Subdomains bzw. Hostnamen in Zertifikaten verwenden zu können (z.B. foo.bar.example.at, aber auch www.example.at).
Es kann sein, dass die Validierung der 'Wildcard Domain' länger braucht, sobald jedoch die Hauptdomain erfolgreich validiert ist, können sofort Zertifikate beantragt werden, auch für Subdomains bzw. beliebige Hostnamen.
Wählen sie im SCM Settings → Domains → Add. Sie können an dieser Stelle auch gleich die Delegierung der Domain erledigen.
Delegieren von Domains
Wählen sie im SCM Settings → Domains, dann erscheinen 2 Schaltflächen → Delegations & DCV → Delegations wählen, dann die Domain wählen, die sie delegieren wollen → Delegate klicken und Organisation bzw. Department für den jeweiligen Zertifikatstyp anhaken.
Bestätigen von Domains
Vor der Validierung der Domain, muss die Delegierung bestätigt werden. Wählen sie dazu im SCM Settings → Domains → View. Dann die Organisation (oder Department) wählen und Approve klicken.
Tipp 1: Man braucht nur *.domain bestätigen, domain wird dann automatisch auch bestätigt.
Tipp 2: Falls die Domain an ein Department delegiert ist, braucht man nur die Delegierung ans Department bestätigen, die darüber liegende Organisation wird automatisch auch bestätigt.
Validieren von Domains
CAA record
Überprüfen sie, ob ein CAA record für die entsprechende Domain existiert, der die Ausstellung von Zertifikaten durch Sectigo für diese Domain verhindert. Falls dem so ist, kann Sectigo keine Zertifikate für diese Domain ausstellen.
Einfacher check: dig caa <domain>
oder diverse online tools
siehe auch Sectigo CAA info
Starten der Validierung:
Wählen sie im SCM Settings → Domains, dann erscheinen 2 Schaltflächen → Delegations & DCV → DCV wählen, dann die Domain wählen, die sie validieren wollen → DCV button → Methode wählen
Löschen von Domains
Domains können nur selbst gelöscht werden, bevor sie bestätigt sind (siehe Bestätigen von Domains).
Sobald die Bestätigung erfolgt ist, können Domains nicht mehr selbst gelöscht werden. Falls eine Domain gelöscht werden soll, bitte den Sectigo Support, am besten via Ticket unter https://sectigo.com/support-ticket um die Löschung ersuchen.
TLS/SSL Zertifikate
Zertifikatsprofile
GÉANT OV Multi-Domain
-> wenn SANs gebraucht werden. Wir empfehlen allerdings, auch ohne SANs dieses Profil zu nehmen, Erklärung siehe GÉANT OV SSL
GÉANT OV SSL
-> wenn nur CN, kein(e) SAN(s) gebraucht werden - allerdings wird bei diesem Profil automatisch ein SAN in der Form www.<CN> hinzugefügt. Wenn man das nicht will, auch für diesen Fall GÉANT OV Multi-Domain verwenden
GÉANT Wildcard SSL
-> wenn sie ein Zertifikat für *.domain brauchen
GÉANT EV Multi-Domain
-> können nicht direkt beantragt werden, siehe EV (Extended Validation) Zertifikate
GÉANT EV SSL
-> können nicht direkt beantragt werden, siehe EV (Extended Validation) Zertifikate
Erstellen eines "keypairs"
siehe Erstellen des Keypairs.
Beantragung von TLS-Zertifikaten für Nutzerinnen, die nicht *RAOs sind
Sie können Personen, die keine Admins im SCM sind, erlauben, Zertifikate anzufordern.
Gehen Sie dazu zu Settings → Organizations, wählen Sie Ihre Organisation aus und klicken sie Edit. (Oder, wenn dies nur für eine Abteilung (Department) gelten soll, verwenden Sie nach der Auswahl der Organisation die Schaltfläche Departments, wählen Sie die Abteilung aus und klicken Sie stattdessen Edit).
Haken Sie auf der Registerkarte SSL-Certificate das Feld Self Enrollment an und geben Sie einen selbst gewählten Access Code ein und kopieren Sie die unter diesem Feld angezeigte URL.
Sie können diese URL nun an Personen weitergeben, die sie zusammen mit dem Access Code verwenden können, um auf die 'Certificate Enrollment' Seite für Nicht-Administratoren zuzugreifen. Der Domain-Teil der angegebenen E-Mail Adresse muss dabei einer validierten Domain in der entsprechenden Organisation entsprechen, ansonsten wird der Zugriff verweigert.
Falls sie Teilnehmer an der ACOnet Identity Federation sind und einen dementsprechenden IdP betreiben, können Sie auch Self Enrollment via SAML aktivieren und die URL unter dem Feld Token an die Benutzer aushändigen (den oben gewählten Access Code können sie dann geheim halten). Nutzerinnen müssen sich dann bei ihrem IdP authentifizieren, bevor sie zu der gleichen 'Certificate Enrollment' Seite wie oben kommen. Der Domain-Teil der E-Mail-Adresse, die von ihrem IdP mitgeschickt wird, muss dabei einer validierten Domain in der entsprechenden Organisation entsprechen, ansonsten wird der Zugriff verweigert.
No Auto Approve
EV (Extended Validation) Zertifikate
EV Zertifikate haben auf Grund der Entscheidung der Browser Hersteller eigentlich keinen signifikanten Vorteil im Vergleich zu OV (Organization Validated) Zertifikaten (Google Chrome Announcement, Mozilla Firefox Announcement) mehr. Sollten sie trotzdem ein Extended Validation Zertifikat beziehen wollen, ersuchen wir sie, mit uns via tcs@aco.net in Verbindung zu treten. Vor der Beantragung und Ausstellung eines EV Zertifikats, ist die Beantragung eine 'EV anchor certificates' notwendig, wofür die Mithilfe des ACOnet Teams nötig ist.
Den Ablauf zur Beantragung eines 'EV Anchor Certificate' finden sie im Sectigo EV anchor and SCM Manual
Empfang und Verwendung der Zertifikate von Sectigo
Anmerkung
Ziel ist natürlich, dass Sectigo die pem
Dateien in einer Form zur Verfügung stellt, in der sie direkt verwendet werden können. Bis es soweit ist, helfen eventuell folgende Tipps.
Prinzipiell brauchen sie bei Webservern das Leaf-Zertifikat und nur das GEANT Intermediate Zertifikat als Chain-Zertifikat zu verwenden - das Root-Zertifikat finden die Web-Browser und andere clients selbst (in ihrem 'truststore').
Je nachdem welche 'Version' des pem
Files sie herunterladen, sind unterschiedliche Zertifikate enthalten. Was allen Arten gleich ist, ist die falsche Reihenfolge der Zertifikate, ie. Leaf Zertifikat als unterstes, darüber eventuell ein oder mehrere Intermediate Zertifikate und darüber, als oberstes, das Root Zertifikat.
Fast alle devices brauchen die Zertifikate allerdings in umgekehrter Reihenfolge, ie. Leaf Zertifikat zu oberst, darunter das Intermediate Zertifikat.
Eine Möglichkeit ist das manuelle 'umsortieren' der notwendigen und gleichzeitige 'entsorgen' der unnötigen Zertifikate. Eine andere Möglichkeit, ist die folgende:
Email bzw. Client Zertifikate
SAML Self Service Portal
Erreichbar ist das SAML Self Service Portal für Client Zertifikate unter https://cert-manager.com/customer/ACOnet/idp/clientgeant
Voraussetzung für die Verwendung ist die Teilnahme an der ACOnet Identity Federation und darüberhinaus an edugain. Weitere Informationen zur korrekten Konfiguration ihres Shibboleth IDP finden sie unter TCS Personal Certs.
Abschliessend muss im SCM noch der korrekte Wert für schacHomeOrganization konfiguriert werden. Dazu bei den Einstellungen ihrer Organisation (Settings -> Organizations -> Org. wählen -> Edit) im Reiter 'General' den Wert, der als schacHomeOrganization mitgeschickt wird, unter 'Academic code (SCHAC Home Organization)' eintragen.
Grid bzw. IGTF Zertifikate
Secondary Organization Name
Für die Verwendung von IGTF Zertifikaten ist ein Organisationsname Voraussetzung, der nur ASCII Zeichen enthält. Dafür gibt es den 'Secondary Organization Name', wo die 'asciified' Version des Organisationsnamen eingetragen werden kann. Auch dieser Name muss erneut validiert werden (siehe auch Spalte 'SECONDARY VALIDATION' in der Übersicht).
Nur wenn es diesen 'Secondary Organization Name' gibt, stehen IGTF Zertifikate in der Auswahl der möglichen Zertifikate zur Verfügung.
API Verwendung
Infos zur Verwendung des SCM REST API bei Sectigo
'WS API use only' Verwendung
Prinzipiell kann jeder Benutzer im SCM auch die API Funktionalität verwenden. Es ist jedoch aus Sicherheitsgründen sinnvoll, für das API einen eigenen Benutzer anzulegen und diesen auf die Benutzung des API einzuschränken. Dazu dient der Parameter 'WS API use only' bei den Privileges eines Benutzers. Auf Grund der Art der Benutzerverwaltung bei Sectigo ist es jedoch auch bei einem solchen Benutzer notwendig, dass bei der Anlage gesetzte Passwort, nach erstmaligem Login zu ändern. Es empfielt sich somit folgender Ablauf:
- API Account anlegen bzw. vom ACOnet Team anlegen lassen, falls er auf Organisationsebene funktionieren soll (siehe oben), 'WS-API use only' noch nicht wählen
- Mit dem API Account im SCM anmelden - Passwort ändern
- Dann 'WS-API use only' wählen bzw. dem ACOnet-Team Bescheid geben, dass wir das tun sollen.
- Ab dann funktioniert der User per API, kann sich aber nicht mehr im SCM anmelden.
Was ist der 'customerUri'
Customer aus Sectigo Sicht ist immer ACOnet, der korrekte Wert ist also 'customerUri: ACOnet'
Zertifikate per API beantragen
Um Zertifikate (Client oder SSL) per API beantragen zu können ist es notwendig, die Option 'Web API' im jeweiligen Register anzuhaken. Es ist auch notwendig, einen 'Secret Key' zu vergeben, welcher allerdings für das REST-API nicht in Verwendung ist (dieser Key würde für die alte SOAP API verwendet werden).
einfaches curl Beispiel
Anzeigen der eigenen Organisation(en) ink. dazugehöriger Informationen:
curl 'https://cert-manager.com/api/organization/v1' -i -X GET -H 'customerUri: ACOnet' -H 'login: <login>' -H 'password: <password>'