JPT
/
masterthesis
0
0
Fork 0
Code Issues Pull Requests Activity

Improve CA documentation

This commit is contained in:
Jan Philipp Timme 2018-09-13 14:35:47 +02:00
parent 598c87bb57
commit 47cdeddb3c
1 changed files with 11 additions and 10 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

21
CA-DOC-Inhalt.tex
View File

@ -16,6 +16,7 @@ Dies geschieht auf Basis von EasyRSA, welches von den OpenVPN-Entwicklern zur Ve
EasyRSA ist eine Sammlung von Skripten, die unter Verwendung von OpenSSL den Funktionsumfang einer Zertifizierungsstelle bieten.
Durch die Kapselung von OpenSSL-Befehlen und die Verwendung einer übersichtlichen Konfigurationsdatei ermöglicht EasyRSA das komfortable und sichere Verwalten einer CA.
Der Aufbau der Zertifizierungsstelle wurde für die Umsetzung unter Debian 9 konzipiert.
Für die Durchführung aller Schritte dieser Anleitung werden die folgenden Programme benötigt.
\begin{itemize}
\item \texttt{openssl}
@ -110,14 +111,14 @@ Im Anschluss kann das Wurzelzertifikat der CA erzeugt werden.
./easyrsa build-ca
\end{lstlisting}
\textbf{Hinweis}: Besteht der begründete Wunsch, den privaten Schlüssel der CA \textbf{nicht} mit einem Passwort zu schützen, so kann das Argument \texttt{nopass} an den Befehl \texttt{build-ca} angehängt werden.
\textbf{Hinweis 1}: Besteht der begründete Wunsch, den privaten Schlüssel der CA \textbf{nicht} mit einem Passwort zu schützen, so kann das Argument \texttt{nopass} an den Befehl \texttt{build-ca} angehängt werden.
Dies kann nützlich sein um die regelmäßige Ausstellung einer CRL zu automatisieren.
Sollte der private Schlüssel in die Hände eines Angreifers gelangen, so kann dieser beliebige Zertifikate durch die CA ausstellen.
Ein Passwortschutz wird ausdrücklich empfohlen sofern keine sonstigen Maßnahmen zum Schutz des privaten Schlüssels der CA vor unbefugtem Zugriff getroffen werden!
Im Rahmen der Erzeugung des Wurzelzertifikats werden Angaben zum Zertifikat abgefragt.
\textbf{Hinweis 2}: Im Rahmen der Erzeugung des Wurzelzertifikats werden Angaben zum Zertifikat abgefragt.
Hier muss ein passender CN angegeben werden, wie zum Beispiel \enquote{IPv6-VPN CA}.
Alle weiteren Vorgaben werden übernommen.
Alle weiteren Vorgaben werden unverändert übernommen.
\section{Bereitstellung der CA-Konfiguration für Benutzer} \label{cpt:provide_ca_config}
@ -192,15 +193,15 @@ Für die Beantragung eines \textbf{Clientzertifikats} muss der Platzhalter \text
Für die Beantragung eines \textbf{Serverzertifikats} muss der Platzhalter \texttt{entityName} durch dessen vollqualifizierten Domainnamen des Servers ersetzt werden.
Dieser kann beispielsweise \texttt{aither.inform.hs-hannover.de} lauten.
\textbf{Hinweis}: Besteht der begründete Wunsch, den erzeugten, privaten Schlüssel \textbf{nicht} mit einem Passwort zu schützen, so kann das Argument \texttt{nopass} an den Befehl \texttt{gen-req} angehängt werden.
\textbf{Hinweis 1}: Besteht der begründete Wunsch, den erzeugten, privaten Schlüssel \textbf{nicht} mit einem Passwort zu schützen, so kann das Argument \texttt{nopass} an den Befehl \texttt{gen-req} angehängt werden.
Dies kann nützlich sein um den privaten Schlüssel ohne zusätzliche Passworteingabe zu benutzen - zum Beispiel zum Betrieb eines OpenVPN-Servers oder zum automatischen Verbindungsaufbau mit einem OpenVPN-Client.
Sollte der private Schlüssel in die Hände eines Angreifers gelangen, so kann dieser ebenfalls das dazugehörige Zertifikat missbrauchen.
Ein Passwortschutz wird ausdrücklich empfohlen sofern keine sonstigen Maßnahmen zum Schutz des privaten Schlüssels vor unbefugtem Zugriff getroffen werden!
Wurde zuvor bereits ein Zertifikatsantrag mit dem selben \texttt{entityName} erzeugt worden sein, so kann dieser inklusive dem dazugehörigen privaten Schlüssel \textbf{überschrieben} werden.
\textbf{Hinweis 2}: Wurde zuvor bereits ein Zertifikatsantrag mit dem selben \texttt{entityName} erzeugt worden sein, so kann dieser inklusive dem dazugehörigen privaten Schlüssel \textbf{überschrieben} werden.
Dafür ist die Bestätigung der Sicherheitsabfrage durch die Eingabe von \texttt{yes} erforderlich.
Im Rahmen der Erzeugung des Zertifikatsantrags werden zusätzliche Angaben abgefragt.
\textbf{Hinweis 3}: Im Rahmen der Erzeugung des Zertifikatsantrags werden zusätzliche Angaben abgefragt.
Hier sind keine Änderungen notwendig, alle Vorgaben werden unverändert übernommen.
In diesem Schritt wurden nun zwei neue Dateien erzeugt:
@ -234,19 +235,19 @@ Ist der private Schlüssel der CA mit einem Passwort geschützt, so wird bei die
Nun kann der importierte Zertifikatsantrag als Client- oder Serverzertifikat signiert werden.
\begin{lstlisting}
# Clientzertifikat ausstellen
./easyrsa sign-req client username
./easyrsa sign-req client entityName
# Serverzertifikat ausstellen
./easyrsa sign-req server aither.inform.hs-hannover.de
./easyrsa sign-req server entityName
\end{lstlisting}
Ist der private Schlüssel der CA mit einem Passwort geschützt, so wird bei diesem Schritt danach verlangt.
\textbf{Hinweis}: Die Gültigkeitsdauer kann nach Ermessen der CA-Betreiber in begründeten Einzelfällen über den vorgegebenen Standardwert hinaus gewählt werden.
\textbf{Hinweis}: Die Gültigkeitsdauer kann nach Ermessen der CA-Betreiber in begründeten Einzelfällen über den vorgegebenen Standardwert hinaus gewählt werden, indem die Umgebungsvariable \texttt{EASYRSA\_CERT\_EXPIRE} auf die gewünschte Gültigkeitsdauer in Tagen gesetzt wird.
Insbesondere bei der Ausstellung von Serverzertifikaten ist dieser Schritt sinnvoll.
Bei der Wahl einer erhöhten Gültigkeitsdauer wird empfohlen, eine maximale Gültigkeitsdauer von 730 Tagen (etwa 2 Jahren) nicht zu überschreiten.
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
EASYRSA_CERT_EXPIRE=730 ./easyrsa sign-req server entityName
\end{lstlisting}