Begin writing documentation for the CA
This commit is contained in:
parent
a74ef784c8
commit
93688b634e
|
|
@ -1,25 +1,37 @@
|
||||||
\chapter{Aufbau einer CA für den VPN-Dienst}
|
\chapter{Vorwort}
|
||||||
|
Dieses Dokument wurde im Rahmen der Masterarbeit \enquote{Konzeption und Umsetzung eines IPv6-VPN für die Abteilung Informatik} erzeugt.
|
||||||
|
Im Rahmen der Masterarbeit wird beschrieben, wie ein IP6-VPN-Dienst auf Basis von OpenVPN konzipiert und eingerichtet wird.
|
||||||
|
|
||||||
\begin{itemize}
|
Für den Betrieb dieses Dienst wird eine Zertifizierungsstelle (\textit{Certificate Authority, kurz CA}) benötigt, die für Benutzer und den Serverbetreiber SSL-Zertifikate ausstellt.
|
||||||
\item Beschaffung der gewünschten Version von EasyRSA + Verifikation
|
In diesem Dokument wird beschrieben, wie die Zertifizierungsstelle aufgebaut und konfiguriert wird.
|
||||||
\item Integration der eigenen Anleitungen und Konfiguration
|
Weiterhin sind Anleitungen für die Benutzer und die Serveradministratoren des VPN-Dienst enthalten, mit deren Hilfe Zertifikate bei der Zertifizierungsstelle beantragt werden können.
|
||||||
\item Verpacken für Clients/Server und CA selbst
|
Für die Zertifizierungsstelle ist eine Anleitung enthalten, anhand derer Zertifikate für eingereichte Zertifikatsanträge ausgestellt werden können.
|
||||||
\item Installation von easy-rsa
|
|
||||||
\end{itemize}
|
|
||||||
|
|
||||||
Voraussetzung: openssl muss bereits installiert sein und im Pfad eingetragen sein.
|
\todo{Improve this section}
|
||||||
Unter Windows kann das von OpenVPN mitgebrachte openssl verwendet werden - dazu kann der Ordner "bin" einfach in den Pfad eingetragen werden.
|
|
||||||
Ein Neustart des Computers ist notwendig, um die Änderung zu übernehmen.
|
\chapter{Einrichtung der CA}
|
||||||
Mehr dazu unter https://github.com/OpenVPN/easy-rsa/blob/v3.0.4/distro/windows/README-Windows.txt
|
|
||||||
|
|
||||||
|
|
||||||
|
\section{Beschaffen von EasyRSA3}
|
||||||
|
Aktuelle Releases sind unter \url{https://github.com/OpenVPN/easy-rsa/releases} zu finden.
|
||||||
|
GPG-Schlüssel zur Authentisierung der Releases sind im easy-rsa Repository unterhalb von \texttt{./release-keys/README.md} aufgeführt.
|
||||||
|
\url{https://github.com/OpenVPN/easy-rsa/tree/master/release-keys}
|
||||||
|
|
||||||
OpenSSL setzt eine Konfigurationsdatei voraus - unter Windows fehlt diese gegebenenfalls.
|
|
||||||
Unter Windows ist es ggf. möglich den Pfad der openssl.exe in der vars-Datei zu hinterlegen.
|
|
||||||
Das könnte einige Probleme lösen.
|
|
||||||
\begin{lstlisting}
|
\begin{lstlisting}
|
||||||
# Diese Zeile ist unter Windows notwendig.
|
# Aktuelles Release v3.0.4 beschaffen und den dazu passenden GPG-Key
|
||||||
set_var EASYRSA_OPENSSL "C:/Program Files/OpenVPN/bin/openssl.exe"
|
gpg --recv-keys 6F4056821152F03B6B24F2FCF8489F839D7367F3
|
||||||
|
wget https://github.com/OpenVPN/easy-rsa/releases/download/v3.0.4/EasyRSA-3.0.4.tgz
|
||||||
|
wget https://github.com/OpenVPN/easy-rsa/releases/download/v3.0.4/EasyRSA-3.0.4.tgz.sig
|
||||||
|
gpg --verify EasyRSA-3.0.4.tgz.sig EasyRSA-3.0.4.tgz
|
||||||
|
tar xzf EasyRSA-3.0.4.tgz
|
||||||
|
cd EasyRSA-3.0.4
|
||||||
\end{lstlisting}
|
\end{lstlisting}
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
\section{Konfiguration der CA}
|
||||||
|
|
||||||
\begin{lstlisting}
|
\begin{lstlisting}
|
||||||
# Vorgeschlagene Einstellungen, die in der vars-Datei getätigt werden sollten.
|
# Vorgeschlagene Einstellungen, die in der vars-Datei getätigt werden sollten.
|
||||||
set_var EASYRSA_DN "org"
|
set_var EASYRSA_DN "org"
|
||||||
|
|
@ -39,74 +51,14 @@ set_var EASYRSA_CERT_EXPIRE 180
|
||||||
set_var EASYRSA_CRL_DAYS 180
|
set_var EASYRSA_CRL_DAYS 180
|
||||||
\end{lstlisting}
|
\end{lstlisting}
|
||||||
|
|
||||||
Daher muss durch die CA mindestens diese Datei bereitgestellt werden.
|
|
||||||
In dem Zug kann man auch gleich ein vorkonfiguriertes Paket mit EasyRSA bereitstellen.
|
|
||||||
|
|
||||||
\section{Beschaffung/Installation von EasyRSA}
|
|
||||||
|
|
||||||
Aktuelle Releases sind unter \url{https://github.com/OpenVPN/easy-rsa/releases} zu finden.
|
|
||||||
GPG-Schlüssel zur Authentisierung der Releases sind im easy-rsa Repository unterhalb von \texttt{./release-keys/README.md} aufgeführt.
|
|
||||||
\url{https://github.com/OpenVPN/easy-rsa/tree/master/release-keys}
|
|
||||||
|
|
||||||
\begin{lstlisting}
|
|
||||||
# Aktuelles Release v3.0.4 beschaffen und den dazu passenden GPG-Key
|
|
||||||
gpg --recv-keys 6F4056821152F03B6B24F2FCF8489F839D7367F3
|
|
||||||
wget https://github.com/OpenVPN/easy-rsa/releases/download/v3.0.4/EasyRSA-3.0.4.tgz
|
|
||||||
wget https://github.com/OpenVPN/easy-rsa/releases/download/v3.0.4/EasyRSA-3.0.4.tgz.sig
|
|
||||||
gpg --verify EasyRSA-3.0.4.tgz.sig EasyRSA-3.0.4.tgz
|
|
||||||
tar xzf EasyRSA-3.0.4.tgz
|
|
||||||
cd EasyRSA-3.0.4
|
|
||||||
\end{lstlisting}
|
|
||||||
|
|
||||||
\section{Initialisierung der CA}
|
|
||||||
|
|
||||||
\begin{lstlisting}
|
\begin{lstlisting}
|
||||||
cp vars.example vars
|
cp vars.example vars
|
||||||
vim vars
|
vim vars
|
||||||
# Konfiguration der CA anpassen:
|
# Konfiguration der CA anpassen:
|
||||||
# * Standardgültigkeit für ausgestellte Zertifikate
|
|
||||||
EASYRSA_CERT_EXPIRE=730 ./easyrsa sign-req server aither.inform.hs-hannover.de
|
|
||||||
|
|
||||||
# * Name der CA, etc
|
|
||||||
\end{lstlisting}
|
\end{lstlisting}
|
||||||
|
|
||||||
Frage: Welche Einstellungen sind anzupassen?
|
|
||||||
|
|
||||||
RSA vs EC? (Geht das mit allen OpenVPN-Clients?)
|
\section{Initialisierung der CA}
|
||||||
* Die Wahl der Algorithmen wirkt sich höchstens auf die Dauer der Authentisierung beim Verbindungsaufbau aus, der reguläre Betrieb wird davon nicht berührt.
|
|
||||||
* Da OpenVPN-Clients für alle Plattformen den selben Code verwenden, sollte bei gleichbleibenden Versionen von OpenSSL (bzw. kompatiblen mbed-TLS-Bibliotheken) die Wahl sich nicht auf die Kompatibilität auswirken.
|
|
||||||
* RSA ist lange erprobt, Patente sind ausgelaufen. Schlüssel sind etwas größer (2-4Kbit), nicht gegen Angriffe durch Quantencomputer beständig (Primfaktorzerlegung)
|
|
||||||
* Elliptic Curve-Verfahren sind noch relativ neu (10 Jahre?). Schlüssel sind kleiner, es gab schon einen Fall mit einer Backdoor in einer Curve, nicht gegen Angriffe durch Quantencomputer beständig (diskreter Logarithmus).
|
|
||||||
Empfehlungen des BSI%\cite{bsi:tr-02102}
|
|
||||||
|
|
||||||
From man:openvpn:
|
|
||||||
--tls-cert-profile profile
|
|
||||||
OpenVPN will migrate to 'preferred' as default in the future. Please ensure that your keys already comply.
|
|
||||||
|
|
||||||
Wie groß soll der Schlüssel sein? [Welche Kurve?]
|
|
||||||
|
|
||||||
Zertifikate nur mit CN oder volles Schema?
|
|
||||||
* Eigentlich egal, keine Vorteile oder Nachteile. Volles Schema => Mehr Informationen darüber, wo der VPN-Dienst angesiedelt ist. Ändert nicht viel. Es spricht nichts gegen den Einsatz des vollen Schemas.
|
|
||||||
|
|
||||||
|
|
||||||
Welche Angaben werden für Benutzerzertifikate übernommen? Namen? Benutzerkennungen?
|
|
||||||
-> Falls es möglich sein soll, Zertifikate bei Missbrauch/Verlust/etc zu sperren, dann braucht man einen eindeutigen Identifier
|
|
||||||
* Voller Name -> Konflikte selten aber möglich, personenbezogene Daten
|
|
||||||
* E-Mail-Adresse: Eindeutig, aber personenbezogene Daten
|
|
||||||
* Benutzername/LUH-ID: Eindeutig, kein Konfliktpotential, personenbeziehbar. (Nur "alte" Studenten haben noch Benutzernamen mit Namen drin)
|
|
||||||
* Matrikelnummer (bei Studenten): Eindeutig, ggf. hat ein Student mehrere, aber das ist kein Thema. personenbeziehbar. Nachteil: Gibt es für Mitarbeiter nicht.
|
|
||||||
|
|
||||||
Laufzeit für Serverzertifikate?
|
|
||||||
* 10 Jahre ist etwas viel. Vielleicht 1 oder 2 Jahre?
|
|
||||||
|
|
||||||
Laufzeit für Clientzertifikate individuell oder je nach Zielgruppe?
|
|
||||||
* Studenten: 6 Monate (immer bis zum Ende des Semesters).
|
|
||||||
* Mitarbeiter: selbe Laufzeit würde den Prozess vereinfachen. Ansonsten vllt sogar 1-2 Jahre?
|
|
||||||
|
|
||||||
Laufzeit der CA - sinnvolle Werte?
|
|
||||||
10 Jahre ist akzeptabel. Wenn man die Laufzeit bestehender Zertifikate im Auge behält, kann der Wechsel einer CA zu einem Stichtag hin funktionieren.
|
|
||||||
|
|
||||||
Gültigkeitsdauer der CRL - falls Zertifikate überhaupt zurückgezogen werden sollen: maximal 180 Tage, kann ja vorher jederzeit aktualisiert werden (->Cronjob oder so)
|
|
||||||
|
|
||||||
|
|
||||||
\begin{lstlisting}
|
\begin{lstlisting}
|
||||||
|
|
@ -117,7 +69,34 @@ Gültigkeitsdauer der CRL - falls Zertifikate überhaupt zurückgezogen werden s
|
||||||
./easyrsa build-ca
|
./easyrsa build-ca
|
||||||
\end{lstlisting}
|
\end{lstlisting}
|
||||||
|
|
||||||
\section{Regelbetrieb der CA}
|
|
||||||
|
\section{Bereitstellung der Konfiguration für Benutzer}
|
||||||
|
Die Datei \texttt{vars} wird benötigt.
|
||||||
|
Zusätzlich wäre es für einige Benutzer ggf. hilfreich, die Windows- und Unix-Version konfiguriert zum Download anzubieten.
|
||||||
|
|
||||||
|
Daher muss durch die CA mindestens diese Datei bereitgestellt werden.
|
||||||
|
In dem Zug kann man auch gleich ein vorkonfiguriertes Paket mit EasyRSA bereitstellen.
|
||||||
|
|
||||||
|
|
||||||
|
\chapter{Beantragen von Clientzertifikaten}
|
||||||
|
Dinge, die der Benutzer auf seinem Gerät tun muss, um einen Zertifikatsantrag zu erzeugen.
|
||||||
|
|
||||||
|
Voraussetzung: Auf dem Computer ist openssl installiert.
|
||||||
|
Gegebenenfalls muss der Pfad zu openssl in der \texttt{vars}-Datei von EasyRSA hinterlegt werden.
|
||||||
|
Unter Windows kann auf das durch OpenVPN installierte OpenSSL zurückgegriffen werden\footnote{Mehr dazu unter \url{https://github.com/OpenVPN/easy-rsa/blob/v3.0.4/distro/windows/README-Windows.txt}}:
|
||||||
|
\begin{lstlisting}
|
||||||
|
set_var EASYRSA_OPENSSL "C:/Program Files/OpenVPN/bin/openssl.exe"
|
||||||
|
\end{lstlisting}
|
||||||
|
|
||||||
|
|
||||||
|
\chapter{Beantragen von Serverzertifikaten}
|
||||||
|
Dinge, die der Benutzer auf seinem Gerät tun muss, um einen Zertifikatsantrag zu erzeugen.
|
||||||
|
|
||||||
|
|
||||||
|
\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?
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
\begin{lstlisting}
|
\begin{lstlisting}
|
||||||
# Request importieren (erfordert einen eindeutigen Namen - hier "timmeja")
|
# Request importieren (erfordert einen eindeutigen Namen - hier "timmeja")
|
||||||
|
|
@ -146,3 +125,9 @@ 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.
|
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}
|
In der Serverkonfiguration: \texttt{verify-crl /path/to/crl.pem}
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Die Gültigkeitsdauer kann in begründeten Einzelfällen (z.B. für Serverzertifikate) auf 730 Tage (etwa 2 Jahre) gesetzt werden.
|
||||||
|
\begin{lstlisting}
|
||||||
|
EASYRSA_CERT_EXPIRE=730 ./easyrsa sign-req server aither.inform.hs-hannover.de
|
||||||
|
\end{lstlisting}
|
||||||
|
|
|
||||||
|
|
@ -257,6 +257,45 @@ Da für die Anfertigung von Zertifikatsanträgen einige Details beachtet werden
|
||||||
Danach: Wie funktioniert die CA mit EasyRSA?
|
Danach: Wie funktioniert die CA mit EasyRSA?
|
||||||
--> Dokumente: Benutzerdokumentation, CA-Admin-Dokumentation, Serverdokumentation
|
--> Dokumente: Benutzerdokumentation, CA-Admin-Dokumentation, Serverdokumentation
|
||||||
|
|
||||||
|
Frage: Welche Einstellungen sind anzupassen?
|
||||||
|
|
||||||
|
RSA vs EC? (Geht das mit allen OpenVPN-Clients?)
|
||||||
|
* Die Wahl der Algorithmen wirkt sich höchstens auf die Dauer der Authentisierung beim Verbindungsaufbau aus, der reguläre Betrieb wird davon nicht berührt.
|
||||||
|
* Da OpenVPN-Clients für alle Plattformen den selben Code verwenden, sollte bei gleichbleibenden Versionen von OpenSSL (bzw. kompatiblen mbed-TLS-Bibliotheken) die Wahl sich nicht auf die Kompatibilität auswirken.
|
||||||
|
* RSA ist lange erprobt, Patente sind ausgelaufen. Schlüssel sind etwas größer (2-4Kbit), nicht gegen Angriffe durch Quantencomputer beständig (Primfaktorzerlegung)
|
||||||
|
* Elliptic Curve-Verfahren sind noch relativ neu (10 Jahre?). Schlüssel sind kleiner, es gab schon einen Fall mit einer Backdoor in einer Curve, nicht gegen Angriffe durch Quantencomputer beständig (diskreter Logarithmus).
|
||||||
|
Empfehlungen des BSI\cite{bsi:tr-02102}
|
||||||
|
|
||||||
|
From man:openvpn:
|
||||||
|
--tls-cert-profile profile
|
||||||
|
OpenVPN will migrate to 'preferred' as default in the future. Please ensure that your keys already comply.
|
||||||
|
|
||||||
|
Wie groß soll der Schlüssel sein? [Welche Kurve?]
|
||||||
|
|
||||||
|
Zertifikate nur mit CN oder volles Schema?
|
||||||
|
* Eigentlich egal, keine Vorteile oder Nachteile. Volles Schema => Mehr Informationen darüber, wo der VPN-Dienst angesiedelt ist. Ändert nicht viel. Es spricht nichts gegen den Einsatz des vollen Schemas.
|
||||||
|
|
||||||
|
|
||||||
|
Welche Angaben werden für Benutzerzertifikate übernommen? Namen? Benutzerkennungen?
|
||||||
|
-> Falls es möglich sein soll, Zertifikate bei Missbrauch/Verlust/etc zu sperren, dann braucht man einen eindeutigen Identifier
|
||||||
|
* Voller Name -> Konflikte selten aber möglich, personenbezogene Daten
|
||||||
|
* E-Mail-Adresse: Eindeutig, aber personenbezogene Daten
|
||||||
|
* Benutzername/LUH-ID: Eindeutig, kein Konfliktpotential, personenbeziehbar. (Nur "alte" Studenten haben noch Benutzernamen mit Namen drin)
|
||||||
|
* Matrikelnummer (bei Studenten): Eindeutig, ggf. hat ein Student mehrere, aber das ist kein Thema. personenbeziehbar. Nachteil: Gibt es für Mitarbeiter nicht.
|
||||||
|
|
||||||
|
Laufzeit für Serverzertifikate?
|
||||||
|
* 10 Jahre ist etwas viel. Vielleicht 1 oder 2 Jahre?
|
||||||
|
|
||||||
|
Laufzeit für Clientzertifikate individuell oder je nach Zielgruppe?
|
||||||
|
* Studenten: 6 Monate (immer bis zum Ende des Semesters).
|
||||||
|
* Mitarbeiter: selbe Laufzeit würde den Prozess vereinfachen. Ansonsten vllt sogar 1-2 Jahre?
|
||||||
|
|
||||||
|
Laufzeit der CA - sinnvolle Werte?
|
||||||
|
10 Jahre ist akzeptabel. Wenn man die Laufzeit bestehender Zertifikate im Auge behält, kann der Wechsel einer CA zu einem Stichtag hin funktionieren.
|
||||||
|
|
||||||
|
Gültigkeitsdauer der CRL - falls Zertifikate überhaupt zurückgezogen werden sollen: maximal 180 Tage, kann ja vorher jederzeit aktualisiert werden (->Cronjob oder so)
|
||||||
|
|
||||||
|
|
||||||
\section{Einrichtung des VPN-Servers}
|
\section{Einrichtung des VPN-Servers}
|
||||||
|
|
||||||
\paragraph{Planung der Umsetzung mit dem IT-Team der Abteilung Informatik}
|
\paragraph{Planung der Umsetzung mit dem IT-Team der Abteilung Informatik}
|
||||||
|
|
|
||||||
Loading…
Reference in New Issue