More CA documentation
This commit is contained in:
parent
8ce00cfbd3
commit
f8d79390fe
|
@ -72,7 +72,8 @@ set_var EASYRSA_CERT_EXPIRE 180
|
|||
set_var EASYRSA_CRL_DAYS 180
|
||||
\end{lstlisting}
|
||||
Sind alle Änderungen durchgeführt worden, ist die Konfiguration der CA damit vollständig abgeschlossen.
|
||||
|
||||
TODO: Erklärung der Parameter.
|
||||
CRL - Certificate Revocation List
|
||||
|
||||
\section{Initialisierung der CA}
|
||||
Als nächstes muss die Verzeichnisstruktur der CA initialisiert werden und das Wurzelzertifikat erzeugt werden.
|
||||
|
@ -154,48 +155,61 @@ Für die Beantragung eines Clientzertifikats muss der Platzhalter \texttt{entity
|
|||
Für die Beantragung eines Serverzertifikats muss der Platzhalter \texttt{entityName} durch den vollqualifizierten Domainnamen des Servers (zum Beispiel \texttt{aither.inform.hs-hannover.de}) ersetzt werden, für den das Zertifikat beantragt werden soll.
|
||||
Durch das Anhängen des Arguments \texttt{nopass} den Passwortschutz für den privaten Schlüssel zu deaktivieren.
|
||||
|
||||
|
||||
\begin{lstlisting}
|
||||
|
||||
\end{lstlisting}
|
||||
Die erzeugte \texttt{*.csr}-Datei muss dann an die CA übergeben werden, um ein gültiges Zertifikat zu erhalten.
|
||||
|
||||
\chapter{Ausstellen von Zertifikaten}
|
||||
Ein Benutzer kommt mit einem Antrag bei der CA an. Welche Schritte werden durchlaufen, damit ein gültiges Client/Server-Zertifikat ausgestellt wird?
|
||||
|
||||
|
||||
Hat ein Benutzer einen Zertifikatsantrag erzeugt, so kann auf dessen Basis nun ein gültiges Zertifikat durch die CA erzeugt werden.
|
||||
Hierfür muss der Zertifikatsantrag zunächst aus der vom Benutzer eingereichten Datei importiert werden, und unter einem geeigneten Namen abgelegt werden.
|
||||
|
||||
\begin{lstlisting}
|
||||
# Request importieren (erfordert einen eindeutigen Namen - hier "timmeja")
|
||||
./easyrsa import-req /tmp/EasyRSA-3.0.4/pki/reqs/jpt-client.req timmeja
|
||||
./easyrsa import-req /tmp/example.req entityName
|
||||
\end{lstlisting}
|
||||
Abhängig von dem Typ des beantragten Zertifikats muss der Platzhalter \texttt{entityName} gewählt werden.
|
||||
Der \texttt{entityName} wird auch verwendet um ausgestellte Zertifikate zu widerrufen.
|
||||
|
||||
# Achtung! Falls bereits ein gültiges Zertifikat existiert, ist es notwendig dieses vorher zurückzurufen.
|
||||
# Sonst kann kein neues Zertifikat mit gleicher CN ausgestellt werden.
|
||||
# (optional)
|
||||
./easyrsa revoke timmeja
|
||||
Für die Beantragung eines Clientzertifikats muss der Platzhalter \texttt{entityName} durch den hochschulweiten Benutzernamen des Benutzers ersetzt werden, für den das Zertifikat beantragt werden soll.
|
||||
Für die Beantragung eines Serverzertifikats muss der Platzhalter \texttt{entityName} durch den vollqualifizierten Domainnamen des Servers (zum Beispiel \texttt{aither.inform.hs-hannover.de}) ersetzt werden, für den das Zertifikat beantragt werden soll.
|
||||
|
||||
# Request signieren mit Client-Rolle (erfordert Passwort für privaten Schlüssel der CA)
|
||||
./easyrsa sign-req client timmeja
|
||||
|
||||
# Zertifikat inspizieren und an Antragsteller übergeben
|
||||
openssl x509 -in pki/issued/timmeja.crt -noout -text
|
||||
|
||||
# (optional?)
|
||||
./easyrsa update-db
|
||||
|
||||
# CRL erzeugen und an OpenVPN-Server übergeben
|
||||
./easyrsa gen-crl
|
||||
Hinweis: Falls bereits ein gültiges Zertifikat mit dem selben \texttt{CN} existiert, ist es notwendig dieses vorher zurückzurufen, da sonst kein neues Zertifikat ausgestellt werden kann.
|
||||
Ist der private Schlüssel der CA mit einem Passwort geschützt, so wird bei diesem Schritt danach verlangt.
|
||||
\begin{lstlisting}
|
||||
./easyrsa revoke entityName
|
||||
\end{lstlisting}
|
||||
|
||||
\textbf{Achtung:} Wenn die CRL ausgelaufen ist, muss sie neu generiert werden. Das kann den VPN-Server im Betrieb blockieren.
|
||||
Daher ist eine hohe Gültigkeitsdauer mit on-demand-replacement eine Option.
|
||||
Ansonsten empfiehlt es sich, diesen Kram zu automatisieren. Regelmäßig eine neue CRL durch CA bereitstellen, von dieser beziehen und den VPN-Server ggf. neustarten.
|
||||
In der Serverkonfiguration: \texttt{verify-crl /path/to/crl.pem}
|
||||
Nun kann der importierte Zertifikatsantrag als Client- oder Serverzertifikat signiert werden.
|
||||
Ist der private Schlüssel der CA mit einem Passwort geschützt, so wird bei diesem Schritt danach verlangt.
|
||||
\begin{lstlisting}
|
||||
# Request signieren mit Client-Rolle
|
||||
./easyrsa sign-req client username
|
||||
|
||||
# Request signieren mit Server-Rolle
|
||||
./easyrsa sign-req server aither.inform.hs-hannover.de
|
||||
\end{lstlisting}
|
||||
|
||||
|
||||
Die Gültigkeitsdauer kann in begründeten Einzelfällen (z.B. für Serverzertifikate) auf 730 Tage (etwa 2 Jahre) gesetzt werden.
|
||||
Hinweis: Die Gültigkeitsdauer kann in nach Ermessen der CA-Betreiber in begründeten Einzelfällen (z.B. für Serverzertifikate) höher gesetzt werden.
|
||||
Eine maximale Laufzeit von 730 Tagen (etwa 2 Jahren) wird empfohlen.
|
||||
In diesem Beispiel wird ein Serverzertifikat mit einer Laufzeit von 730 Tagen ausgestellt.
|
||||
\begin{lstlisting}
|
||||
EASYRSA_CERT_EXPIRE=730 ./easyrsa sign-req server aither.inform.hs-hannover.de
|
||||
\end{lstlisting}
|
||||
|
||||
|
||||
\chapter{Erzeugen der CRL}
|
||||
Der VPN-Server verwendet die von der CA ausgestellte CRL zur Überprüfung von Clientzertifikaten.
|
||||
In der Konfigurationsdatei des OpenVPN-Servers wird die CRL-Datei durch \texttt{verify-crl /path/to/crl.pem} angegeben.
|
||||
|
||||
Somit können durch die CA widerrufene Zertifikate nicht mehr zur Anmeldung am VPN-Dienst benutzt werden.
|
||||
Die folgenden Befehle können zum Generieren der CRL verwendet werden:
|
||||
\begin{lstlisting}
|
||||
# Datenbank aktualisieren (regeneriert index.attrs.txt oder so TODO)
|
||||
./easyrsa update-db
|
||||
|
||||
# CRL erzeugen
|
||||
./easyrsa gen-crl
|
||||
\end{lstlisting}
|
||||
Ist der private Schlüssel der CA mit einem Passwort geschützt, so wird bei diesem Schritt danach verlangt.
|
||||
|
||||
\textbf{Achtung:} Der VPN-Server lehnt eine ungültige CRL-Datei ab und verweigert dann den Dienst.
|
||||
Deshalb sollte die CRL durch die CA regelmäßig erneuert werden und auf den VPN-Server übertragen werden.
|
||||
Anschließend sollte der VPN-Dienst via \texttt{systemctl reload ...} neu geladen werden.
|
||||
Eine Automatisierung dieses Vorgangs wird empfohlen.
|
||||
|
|
Loading…
Reference in New Issue