Zertifikate werden bis auf eine Ausnahme derzeit ausschließlich von Usern mit einem Account im System beantragt. Der Account kann durch Selbst-Registrierung erstellt werden (siehe User-Registrierung).

Für Serverzertifikate wird es einen ACME-Zugang geben, allerdings sind die Details noch in Absprache.

User haben die Möglichkeit, im Portal kostenpflichtige Zertifikate oder Services zu bestellen. Der Bestellung endet dabei stets so, dass der User selbst einen Zahlungsprozess mit Kreditkarte durchführen muss, bevor irgendwelche weiteren Vorgänge gestartet werden.

Serverzertifikate erfordern ein Vier-Augen-Prinzip: Anträge werden von einem Account mit mindestens Rolle User gestellt, und von einem anderen Account mit Rolle Enterprise Approver genehmigt. Auch ein Enterprise Admin oder Enterprise Approver kann seine eigenen Anträge nicht genehmigen, sondern benötigt einen zweiten Enterprise Approver.

Der Antragsstellende kann über den Menüpunkt „Server“ links einen Antrag stellen. Es stehen die folgenden Zertifikattypen zur Verfügung:

• Domain-only (DV): Zertifikate ohne Organisationsnamen.
• For enterprises or organizations (OV): Zertifikate mit Organisationsnamen. Erst verfügbar, wenn eine Organisationsvalidierung abgeschlossen wurde.
• For enterprises or organizations (EV): Nicht empfehlenswert Extended-Validation-Zertifikate, wie sie vor einigen Jahren z.B. für Online-Banking gebräuchlich waren. Kein Mehrwert ggü OV. Kostenpflichtig.

Die Antragstellung sollte weitestgehend selbsterklärend sein.

Hinweis 1: Die Erzeugung von 4096-Bit-Schlüsseln im Browser dauert manchmal mehrere Minuten und erscheint dabei wie eine „hängenden“ Webseite.

Hinweis 2: Wird ein eigener CSR per Copy&Paste in den Antrag aufgenommen, ist darauf zu achten, dass keine zusätzlichen Leerzeichen oder Leerzeilen etc mit in das Eingabefeld für den CSR kopiert oder eingegeben werden. Diese können zur Ablehnung von Anträgen mittels diverser Fehlermeldungen oder später zu hängenden Anträgen führen.

Hinweis 3: Wird ein selbsterstellter CSR hochgeladen und erscheint daraufhin der Hinweis „This public key can not be used.“, so liegt das an mindestens einem der folgenden Gründe: (i) ein anderer HARICA-Account hat bereits den gleichen Schlüssel in einem Zertifikatantrag benutzt; (ii) der Schlüssel ist HARICA als kompromittiert gemeldet; (iii) der Schlüssel genügt nicht (mehr) den aktuell gültigen technischen Anforderungen aus dem HARICA CP/CPS.

Sobald das Serverzertifikat ausgestellt ist, können durch den das Zertifikat beantragenden HARICA-Account im Cert Manager in den Serverzertifikat-Details unter dem Tab „Notifications“ weitere E-Mail-Adressen zusätzlich zur immer vorhandenen Account-E-Mail-Adresse angegeben werden, um Zertifikatablauf-Warn-E-Mails jeweils 15, 5 und 1 Tag(e) vor dem Zertifikatsablauf zu erhalten.

Die Anzahl der SubjectAlternativeNames ist derzeit auf 100 begrenzt. Das eine Erweiterung notwendig ist, ist HARICA bekannt.

Der Enterprise Approver kann die Liste der offenen Anträge über „Admin→SSL Request“ einsehen. Über das Icon Show details neben jedem Antrag wird dieser eingesehen und genehmigt. Zur Genehmigung muss in dem Dialog zunächst ein Text in das Feld „Message“ eingegeben werden, bevor der Button „Accept“ bedient werden kann.

Die Buttons Open File und <Choose File> no file chosen haben keine Bedeutung.

Der Antragsstellende kann das Zertifikat über „My Dashboard“ herunterladen. Hierzu muss das Download-Icon neben dem Zertifikat angewählt werden. Mit dem Button PEM bundle im anschließenden Dialog erhält man eine Datei, die für Webserver wie Apache oder nginx direkt verwendbar ist.

Hinweis: Der Enterprise Approver hat den Button PEM bundle in seiner Übersicht unter „Enterprise→SSL Certificates“ nicht zur Verfügung. Hier gibt es nur Download as PEM, Download as DER und Download as PKCS#7.

Um aus einer PKCS#7-Datei ein PEM bundle für Apache oder nginx zu erstellen, kann die folgende Befehlszeile verwendet werden:

  openssl pkcs7 -in Cert_chain.p7b -print_certs > Cert_pem_bundle.pem

Bestimmte Server-Namen werden als „Hochrisiko-Anträge“ markiert. Dies ist eine Vorgabe vom CA/Browser-Forum. Betroffen sind zum einen bekannte Namen wie „google“, aber auch „haricatest“.

Um den Aufwand auf HARICA-Seite zu vermindern, bitten wir drum, Experimente nicht mit dem Schlüsselwort „harica“ durchzuführen.

HARICA unterstützt im Prinzip bereits ACME. Zur Zeit steht dieses Feature aber nicht in einer Form zur Verfügung, die für einen regulären Einsatz geeignet ist. Insbesondere fehlt eine Verwaltung von Accounts für das External Account Binding von prevalidierten Domains.

Wichtig: Wenn keinerlei CAA-Records im DNS gesetzt sind, funktioniert der Zertifikatbezug ohne jede Einschränkung. CAA-Records sind eine zusätzliche Maßnahme für Einrichtungen, die sich bewusst dafür entscheiden.

Wenn Sie CAA-Records im DNS setzen möchten, um die Ausstellung von Zertifikaten auf bestimmte CAs einzuschränken, verwenden Sie für GÉANT-TCS-Zertifikate von HARICA den issue-Wert harica.gr.

Für alle aktuell unter GÉANT TCS ausgestellte Zertifikate ist ausschließlich der Wert harica.gr notwendig, sofern denn CAA-Records gesetzt sind. Vormals für GÉANT TCS genutzte andere Werte können entfernt werden.

Beispiel:

muster-uni.de.       IN    CAA    0 issue "harica.gr"
muster-uni.de.       IN    CAA    0 issue "pki.dfn.de"

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:

muster-uni.edu.      IN    CNAME muster-uni.de.

muster-uni.de.       IN    CAA    0 issue "harica.gr"
muster-uni.de.       IN    CAA    0 issue "pki.dfn.de"