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}
|
||||
\item Beschaffung der gewünschten Version von EasyRSA + Verifikation
|
||||
\item Integration der eigenen Anleitungen und Konfiguration
|
||||
\item Verpacken für Clients/Server und CA selbst
|
||||
\item Installation von easy-rsa
|
||||
\end{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.
|
||||
In diesem Dokument wird beschrieben, wie die Zertifizierungsstelle aufgebaut und konfiguriert wird.
|
||||
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.
|
||||
Für die Zertifizierungsstelle ist eine Anleitung enthalten, anhand derer Zertifikate für eingereichte Zertifikatsanträge ausgestellt werden können.
|
||||
|
||||
Voraussetzung: openssl muss bereits installiert sein und im Pfad eingetragen sein.
|
||||
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.
|
||||
Mehr dazu unter https://github.com/OpenVPN/easy-rsa/blob/v3.0.4/distro/windows/README-Windows.txt
|
||||
\todo{Improve this section}
|
||||
|
||||
\chapter{Einrichtung der CA}
|
||||
|
||||
|
||||
|
||||
\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}
|
||||
# Diese Zeile ist unter Windows notwendig.
|
||||
set_var EASYRSA_OPENSSL "C:/Program Files/OpenVPN/bin/openssl.exe"
|
||||
# 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{Konfiguration der CA}
|
||||
|
||||
\begin{lstlisting}
|
||||
# Vorgeschlagene Einstellungen, die in der vars-Datei getätigt werden sollten.
|
||||
set_var EASYRSA_DN "org"
|
||||
|
|
@ -39,74 +51,14 @@ set_var EASYRSA_CERT_EXPIRE 180
|
|||
set_var EASYRSA_CRL_DAYS 180
|
||||
\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}
|
||||
cp vars.example vars
|
||||
vim vars
|
||||
# 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}
|
||||
|
||||
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{Initialisierung der CA}
|
||||
|
||||
|
||||
\begin{lstlisting}
|
||||
|
|
@ -117,7 +69,34 @@ Gültigkeitsdauer der CRL - falls Zertifikate überhaupt zurückgezogen werden s
|
|||
./easyrsa build-ca
|
||||
\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}
|
||||
# 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.
|
||||
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?
|
||||
--> 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}
|
||||
|
||||
\paragraph{Planung der Umsetzung mit dem IT-Team der Abteilung Informatik}
|
||||
|
|
|
|||
Loading…
Reference in New Issue