Anforderungen

Mit der eben erstellten CA kann der Administrator nun die ersten Arbeiten für ein neues Zertifikat durchführen. Dazu erstellt er eine neue Anforderung, da heißt einen Schlüssel in einem bestimmten Format (…). Ein Rechtsklick im Feld »Anforderungen | Neue Anforderung« öffnet den Dialog für eine neue Anforderung. Wichtig ist der »Common Name (CN)« , die Mailadresse, die als Attribute im Zertifikat später wieder auftauchen. Über den Common Name wird der Benutzer des Zertifikats später identifiziert.

Das Passwort schützt den privaten Schlüssel. Es wird benötigt, um das Zertifikat später für die Authentifizierung nutzen zu können. Passwörter für Schlüssel, die später in Server – Zertifikaten eingesetzt werden sind problematisch, da Dienste normalerweise automatisch starten und keine Passwortabfrage bieten. Nur wenn es die Konfiguration eines Dienstes zulässt, ein Passwort zum öffnen des Schlüssels zu hinterlegen, sollte an dieser Stelle ein Passwort eingegeben werden (siehe Abbildung 2).

Abbildung 2: Die Eingabemaske, um ein neues Zertifikat anzufordern.

Die übrigen Felder sind schon ausgefüllt und passen zu den Daten der CA. Sie sollten nicht verändert werden, da diese Daten bei der Authentifizierung mit den Daten der CA verglichen werden. Bei Abweichungen kann es passieren, dass der Benutzer abgewiesen wird. Sobald die Anforderung abgeschlossen ist, erstellt TinyCA den Schlüssel und die Anforderung dazu. Sie tauchen in den entsprechenden Feldern der GUI auf.

Falls der Benutzer den Schlüssel selbst erzeugen will, muss er dem Administrator nur die Anforderung im PKCS#10-Format, schicken, die dieser dann per »Import« einlesen kann. Diese Variante hat den Vorteil, dass nur der Benutzer das Passwort für den Schlüssel kennt.

Signatur

Um aus der Anforderung nun ein Zertifikat zu erzeugen klickt der Administrator einfach wiederum mit der rechten Maustaste auf den entsprechenden Reqeust und dann »Anforderung Signieren« . Jetzt darf er entscheiden, ob ein Zertifikat für einen Server oder einen Benutzer erstellt wird. Aufgrund dieser Entscheidung tauchen im Zertifikat später die entsprechenden Attribute auf. TinyCA fragt nun, nach dem Passwort für die CA und der Gültigkeit des neuen Zertifikats (siehe Abbildung 3).

Abbildung 3: TinyCA fragt das Passwort für die CA und die Gültigkeit des neuen Zertifikats ab.

Die Gültigkeit sollte auch wiederum nicht zu knapp bemessen werden. Allerdings kann man ein abgelaufenes Zertifikat wieder erneuern. Es bleibt der Umstand, das neue Zertifikat dem Benutzer zuzusenden und auf dessen Rechner anstelle des Alten zu installieren. Nachdem das neue Zertifikat erstellt ist, taucht es auch im entsprechenden Abschnitt von TinyCA auf. Ein Rechtsklick auf das Zertifikat und die Auswahl »Zertifikat Detail« enthüllt alle Details zu dem Zertifikat. Hier kann man auch die Gültigkeit noch einmal nachprüfen (siehe Abbildung …)

Abbildung 4: Auf Wunsch zeigt TinyCA alle wichtigen Details eines Zertifikats an.
comments powered by Disqus

Artikel der Woche

Eigene Registry für Docker-Images

Wer selber Docker-Images herstellt, braucht auch eine eigene Registry. Diese gibt es ebenfalls als Docker-Image, aber nur mit eingeschränkter Funktionalität. Mit einem Auth-Server wird daraus ein brauchbares Repository für Images. (mehr)
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Ausgabe /2021