masterthesis/Dokumentation-CA.tex

\section{Aufbau einer CA für den VPN-Dienst}

\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}

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

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.

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
# * 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).


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}
# Verzeichnisstruktur erzeugen (löscht bereits existierende Struktur!)
./easyrsa init-pki

# CA-Zertifikat erzeugen, Passwort für privaten Schlüssel wird verlangt
./easyrsa build-ca

# Regelbetrieb der CA
# Benutzer erzeugt Request
# z.B. mit openssl req -utf8 -new -newkey rsa:4096 -keyout /tmp/cert.key -out /tmp/cert.req -subj "/CN=foobar" [-nodes] ?

# Request importieren (erfordert einen eindeutigen Namen - hier "timmeja")
./easyrsa import-req /tmp/EasyRSA-3.0.4/pki/reqs/jpt-client.req timmeja

# 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

# CRL erzeugen und an OpenVPN-Server übergeben
./easyrsa gen-crl
\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}