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
|
set_var EASYRSA_CRL_DAYS 180
|
||||||
\end{lstlisting}
|
\end{lstlisting}
|
||||||
Sind alle Änderungen durchgeführt worden, ist die Konfiguration der CA damit vollständig abgeschlossen.
|
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}
|
\section{Initialisierung der CA}
|
||||||
Als nächstes muss die Verzeichnisstruktur der CA initialisiert werden und das Wurzelzertifikat erzeugt werden.
|
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.
|
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.
|
Durch das Anhängen des Arguments \texttt{nopass} den Passwortschutz für den privaten Schlüssel zu deaktivieren.
|
||||||
|
|
||||||
|
Die erzeugte \texttt{*.csr}-Datei muss dann an die CA übergeben werden, um ein gültiges Zertifikat zu erhalten.
|
||||||
\begin{lstlisting}
|
|
||||||
|
|
||||||
\end{lstlisting}
|
|
||||||
|
|
||||||
\chapter{Ausstellen von Zertifikaten}
|
\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}
|
\begin{lstlisting}
|
||||||
# Request importieren (erfordert einen eindeutigen Namen - hier "timmeja")
|
./easyrsa import-req /tmp/example.req entityName
|
||||||
./easyrsa import-req /tmp/EasyRSA-3.0.4/pki/reqs/jpt-client.req timmeja
|
\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.
|
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.
|
||||||
# Sonst kann kein neues Zertifikat mit gleicher CN ausgestellt werden.
|
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.
|
||||||
# (optional)
|
|
||||||
./easyrsa revoke timmeja
|
|
||||||
|
|
||||||
# Request signieren mit Client-Rolle (erfordert Passwort für privaten Schlüssel der CA)
|
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.
|
||||||
./easyrsa sign-req client timmeja
|
Ist der private Schlüssel der CA mit einem Passwort geschützt, so wird bei diesem Schritt danach verlangt.
|
||||||
|
\begin{lstlisting}
|
||||||
# Zertifikat inspizieren und an Antragsteller übergeben
|
./easyrsa revoke entityName
|
||||||
openssl x509 -in pki/issued/timmeja.crt -noout -text
|
|
||||||
|
|
||||||
# (optional?)
|
|
||||||
./easyrsa update-db
|
|
||||||
|
|
||||||
# CRL erzeugen und an OpenVPN-Server übergeben
|
|
||||||
./easyrsa gen-crl
|
|
||||||
\end{lstlisting}
|
\end{lstlisting}
|
||||||
|
|
||||||
\textbf{Achtung:} Wenn die CRL ausgelaufen ist, muss sie neu generiert werden. Das kann den VPN-Server im Betrieb blockieren.
|
Nun kann der importierte Zertifikatsantrag als Client- oder Serverzertifikat signiert werden.
|
||||||
Daher ist eine hohe Gültigkeitsdauer mit on-demand-replacement eine Option.
|
Ist der private Schlüssel der CA mit einem Passwort geschützt, so wird bei diesem Schritt danach verlangt.
|
||||||
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.
|
\begin{lstlisting}
|
||||||
In der Serverkonfiguration: \texttt{verify-crl /path/to/crl.pem}
|
# 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}
|
||||||
|
|
||||||
|
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.
|
||||||
Die Gültigkeitsdauer kann in begründeten Einzelfällen (z.B. für Serverzertifikate) auf 730 Tage (etwa 2 Jahre) 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}
|
\begin{lstlisting}
|
||||||
EASYRSA_CERT_EXPIRE=730 ./easyrsa sign-req server aither.inform.hs-hannover.de
|
EASYRSA_CERT_EXPIRE=730 ./easyrsa sign-req server aither.inform.hs-hannover.de
|
||||||
\end{lstlisting}
|
\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