Bearbeiten von „Server/Transport Layer Security“

Die [[Server/Anwendung]]en (beim [[StuRa]]) sind seit 2016 einigermaßen ordentlich verschlüsselt verfügbar.

== zu erledigende Dinge ==
* [[aufgabe:301]]

== Geschichte ==
Sehr lange - bis 2016 - waren die Webservices gar nicht, oder nicht ordentlich verschlüsselt erreichbar.

Es fehlte dem StuRa ein X509-Zertifikat, dass auch in den Browsern verankert ist, um die Nutzerinnen nicht mit Warnungen zum Zertifikat abzuschrecken. Die Ausnahme war https://umfragen.stura.htw-dresden.de ([[Server/Umfragen]]).

; 2015:
* PT hat Wolf gebeten das aufzunehmen
* Leiter vom [[RZ]] wurde von Wolf und Norman angesprochen (Es ging um [[#Rechenzentrum HTW Dresden als Quelle für taugliche Zertifikate]].)
* Warten auf Rückmeldung [[RZ]]
* (Irgendwann erfolgte eine Rückmeldung, dass selbstverständlich Zertifikate bereitgestellt werden könnten. Eine Realisierung erfolgte (beim StuRa) nicht.)

; 2016:
* [[user:Bommix]] rockt!
* Das Zertifikat für [https://umfragen.stura.htw-dresden.de umfragen.stura.htw-dresden.de] lief 2016-04 aus.
* Es fand die Einführung (und der Ersatz) mit [[#Let's Encrypt]] statt.

== Quellen für taugliche Zertifikate ==

=== [[Rechenzentrum HTW Dresden]] als Quelle für taugliche Zertifikate ===

Möglich ist es für den Weg [[StuRa HTW Dresden]] ([[Bereich Administration Rechentechnik]]) -> [[HTW Dresden]] ([[Rechenzentrum HTW Dresden]]) -> [[DFN]] -> Telekom ordentliche Zertifikate zu bekommen. (Leider wird zur Beantragung eine verantwortliche Person benötigt, die das Zertifikat dann auch verlängert. Die Leitung vom [[RZ]] prüft beim [[DFN]], ob Körperschaften gegebenenfalls auch andere Antragswege offen stehen.)

=== [[#Let's Encrypt]] als Quelle für taugliche Zertifikate ===

[[wikipedia:de:Let's Encrypt|Let's Encrypt]] ist eine andere Möglichkeit (als Stelle mit Verfahren) für den StuRa ordentliche Zertifikate zu verwenden.

; Weblinks:
* [https://letsencrypt.org/ Let's Encrypt]

== Zweckmäßigkeit ==

; "[[wikipedia:de:State of the Art|State of the Art]]":
* Ansonsten (ohne Verschlüsselung) müssen Nutzerinnen und Nutzer berechtigt der [[Server/Anwendung]] bei der Verwendung ihres Passwortes misstrauen.
* Der [[Bereich Datenkultur]] hat selbstverständlich den Anspruch, dass möglichst jede Kommunikation verschlüsselt sein soll.

== Let's Encrypt ==


=== Entscheidung für Let's Encrypt ===

Aufgrund der schwierigen Implementierung der Zertifikate über das Rechnenzentrum wurde 2016-04 von Bommel auf Zertifikate von Let's Encrypt gesetzt.

=== Verwendung von Let's Encrypt ===

* https://letsencrypt.org/docs/client-options/

=== Installation Let's Encrypt ===

Alle [[Server/Anwedung]]en, die ein Zertifikat von Let's Encrypt besitzen sollen eine automatische Aktivierung der Verschlüsselung (header redirect to ssl) haben.

==== Installation für Let's Encrypt bei [[FreeBSD]] ====
: [[i.V.m.]] Apache als [[Server/Webserver]]
<!--
----
---- Eigentlich sollte es ja einen speziellen Abschnitt zu Apache geben (müssen), da es auch andere Lösungen, wie nginx als Webbrowser oder HAProxy als load balancer fürs Ausliefern gibt.
----
===== Einrichtung von Let's Encrypt für Apache bei [[FreeBSD]] =====
!-->

: <code>pkg install -y letsencrypt.sh openssl</code>
:: Achtung! Das [[freshports:security/letsencrypt.sh|Paket ''letsencrypt.sh'']] wurde durch [[freshports:security/dehydrated|Paket ''dehydrated'']] ersetzt!
:: Achtung! Das [[freshports:security/acme.sh | Paket ''acme.sh'']], [[freshports:security/py-certbot | Paket ''py-certbot'']] oder [[freshports:security/acme-client | Paket ''acme-client'']] können eine Alternative sein.
<pre></pre>
<pre>
New packages to be INSTALLED:
        letsencrypt.sh: 0.1.0
        openssl: 1.0.2_12
</pre>
<pre></pre>
<pre>
Message from letsencrypt.sh-0.1.0:
To use this script you should copy the examples in
/usr/local/etc/letsencrypt.sh/ and at least add a
domain and a contact mail address.

You should also copy the openssl.cnf.sample file in
/usr/local/openssl so you won't get warnings about
it missing.

In order to run the script regularly to update
the certificates add this line to /etc/periodic.conf

weekly_letsencrypt_enable="YES"

Additionally the following parameters can be added to
/etc/periodic.conf

To run the certification renenewal as a different user
weekly_letsencrypt_user="_letsencrypt"
To run a script after the renewal (as root)
weekly_letsencrypt_deployscript="/usr/local/etc/letsencrypt.sh/deploy.sh"
Message from openssl-1.0.2_12:
Copy /usr/local/openssl/openssl.cnf.sample to /usr/local/openssl/openssl.cnf
and edit it to fit your needs.
</pre>

: <code>cp /usr/local/openssl/openssl.cnf.sample /usr/local/openssl/openssl.cnf</code>
		
: <code>pw groupadd -n _letsencrypt -g 443</code>
: <code>pw useradd  -n _letsencrypt -u 443 -g 443 -d /usr/local/etc/letsencrypt.sh -w no -s /nonexistent</code>
: <code>chown root:_letsencrypt /usr/local/etc/letsencrypt.sh</code>
: <code>chmod 770               /usr/local/etc/letsencrypt.sh</code>
: <code>mkdir -p -m 775    /usr/local/www/.well-known/acme-challenge</code>
: <code>chgrp _letsencrypt /usr/local/www/.well-known/acme-challenge</code>

: <code>$EDITOR /usr/local/etc/letsencrypt.sh/domains.txt</code>
Es werden alle Hosts, getrennt durch ein Leerzeichen, eingetragen.
Bei Zeilenumbruch wird ein weiteres zusätzliches Zertifikat erstellt.
: <code>$EDITOR /usr/local/etc/letsencrypt.sh/config.sh</code>
<pre>
BASEDIR="/usr/local/etc/letsencrypt.sh"
WELLKNOWN="/usr/local/www/.well-known/acme-challenge"
alias openssl='/usr/local/bin/openssl'
</pre>

Für das automatische Aktualisieren:
: <code>$EDITOR /etc/periodic.conf</code>
<pre>
weekly_letsencrypt_enable="YES"
weekly_letsencrypt_user="_letsencrypt"
weekly_letsencrypt_deployscript="/usr/local/etc/letsencrypt.sh/deploy.sh"
</pre>


; Apache24
: <code>$EDITOR /usr/local/etc/apache24/httpd.conf</code>
<pre></pre>
<pre>
<Directory "/usr/local/www/.well-known/">
   Options None
   AllowOverride None
   Require all granted
   Header add Content-Type text/plain
</Directory>
Alias /.well-known/ /usr/local/www/.well-known/
</pre>
<pre></pre>
<pre>
<Directory "/">
</pre>
<pre></pre>

Neustarten vom Webserver (hier Apache&nbsp;2.4)
: <code>service apache24 restart</code>

Und Jetzt ausprobieren:
: <code>cd /usr/local/etc/letsencrypt.sh</code>
: <code>su -m _letsencrypt -c 'bash /usr/local/bin/letsencrypt.sh --cron'</code>
<pre>
# INFO: Using main config file /usr/local/etc/letsencrypt.sh/config.sh
Processing fsr-et.htwdd.de with alternative names: www.fsr-et.htwdd.de
 + Signing domains...
 + Generating private key...
 + Generating signing request...
 + Requesting challenge for fsr-et.htwdd.de...
 + Requesting challenge for www.fsr-et.htwdd.de...
 + Responding to challenge for fsr-et.htwdd.de...
 + Challenge is valid!
 + Responding to challenge for www.fsr-et.htwdd.de...
 + Challenge is valid!
 + Requesting certificate...
 + Checking certificate...
 + Done!
 + Creating fullchain.pem...
 + Done!
</pre>
Und freuen :D

Nun alle Zerts in die Konfiguration vom Webserver einbinden:
: Das kann in der zentralen Datei zur Konfiguration geschehen, aber auch an anderen (geeigneteren) Stellen.
: <code>$EDITOR /usr/local/etc/apache24/httpd.conf</code>
<pre></pre>
<pre>
    SSLCertificateFile /usr/local/etc/letsencrypt.sh/certs/projekt.htw.stura-dresden.de/cert.pem
    SSLCertificateKeyFile /usr/local/etc/letsencrypt.sh/certs/projekt.htw.stura-dresden.de/privkey.pem
    SSLCertificateChainFile /usr/local/etc/letsencrypt.sh/certs/wiki.stura-dresden.de/chain.pem
</pre>
<pre></pre>
<!--
<pre>
</pre>
<pre></pre>
-->
Und damit nur SSL genommen wird:
: <code>$EDITOR /usr/local/etc/apache24/httpd.conf</code>
:: im Abschnitt für das ensprechende Directory
<pre></pre>
<pre>
	RewriteEngine ON
	RewriteCond %{HTTPS} off
	RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
</pre>
<pre></pre>

: <code>$EDITOR /usr/local/etc/apache24/Includes/ssl.conf</code>
<pre>
<VirtualHost *:443>
DocumentRoot    "/usr/local/www/wordpress"
<Directory "/usr/local/www/wordpress">

AllowOverride All
</Directory>


ServerName 141.56.50.30:443

        SSLEngine on

        SSLCertificateFile /usr/local/etc/letsencrypt.sh/certs/fsr-et.htwdd.de/cert.pem
        SSLCertificateKeyFile /usr/local/etc/letsencrypt.sh/certs/fsr-et.htwdd.de/privkey.pem
        SSLCertificateChainFile /usr/local/etc/letsencrypt.sh/certs/fsr-et.htwdd.de/chain.pem


</VirtualHost>
</pre>

* ggf. Listen 443 in der httpd.conf nachtragen

===== Installation für Let's Encrypt bei [[FreeBSD]] Siehe auch =====
* [[freebsd:BernardSpil/LetsEncrypt]]
* [https://letsencrypt.readthedocs.io/en/latest/using.html#operating-system-packages letsencrypt.readthedocs.io/en/latest/using.html#operating-system-packages]
* [https://letsencrypt.readthedocs.io/en/latest/using.html#plugins letsencrypt.readthedocs.io/en/latest/using.html#plugins]


== Ändern von Domains ==

Hier Domais ändern:  <br>
<code>$EDITOR /usr/local/etc/letsencrypt.sh/domains.txt</code>  <br><br>
Das hier ausführen zum aktualisieren: <br>
<code>su -m _letsencrypt -c 'bash /usr/local/bin/letsencrypt.sh --cron'</code>

== Bekannte Probleme ==


==== Probleme beim Plone ====

Bei der Instanz mit Plone ist die ganze Sache etwas komplizierter. Dort wurde ein Weiterleitung (Redirect) aller nicht bekannten Anfragen aus dem Plone direkt gemacht.<br />
Falls es Probleme beim Erstellen der Zertifikate geben sollte, gibt es eine angepasste Konfiguration für Apache.

Für das (automatische) Laden der angepasste Konfiguration für das Erstellen eines neuen Zertifikates wurde ein kleines Skript geschrieben, das benutzt werden kann.
: <s><code>cd /usr/local/etc/apache24/ && ./dehydrated_script.sh && cd -</code></s>
: <code>cd /usr/local/etc/apache24/ && ./dehydrated_by-stura_without-proxy.sh && cd -</code>

==== fehlende Erledigung der automatisierten Tätigkeit zur notwendigen Erneuerung des Zertifikates ====
Es kann passieren, dass der [[wikipedia:de:Cron|Cron]]job (automatisierte Tätigkeit zur Erledigung der wiederkehrenden Aufgabe) nicht ausgeführt wird. Es kann daran leigen, dass etwas zu [[#Let's Encrypt]] geändert wurde und es notwendig ist,  dass das Paket zur Verwaltung von [[#Let's Encrypt]] aktualisert werden muss.

Hier zwei kleine Tutorials

; Das erste wenn sowieso die Updates gezogen werden müssen:
<pre>
pkg update 
pkg upgrade -y
cd /usr/local/etc/letsencrypt.sh/
mv certs certsalt
su -m _letsencrypt -c 'bash /usr/local/bin/letsencrypt.sh --cron'
service apache24 restart
</pre>
Wie zu sehen ist habe ich die alten Zertifikate in Certalt gelegt. Falls es klappen sollte kann der Ordner certsalt auch gelöscht werden.
<pre>
rmdir cd /usr/local/etc/letsencrypt.sh/certsalt
</pre>

; Dieses Tutorial ist nur zu verwenden, wenn keine neue Pakete via PKG gezogen werden sollen:
<pre>
pkg update 
pkg upgrade pkg
</pre>
mit y und enter bestätigen
<pre>
pkg upgrade letsencrypt.sh
</pre>
Wieder mit y und Enter bestätigen
<pre>
cd /usr/local/etc/letsencrypt.sh/
mv certs certsalt
su -m _letsencrypt -c 'bash /usr/local/bin/letsencrypt.sh --cron'
service apache24 restart
</pre>

Wie zu sehen ist habe ich die alten Zertifikate in Certalt gelegt. Falls es klappen sollte kann der Ordner certsalt auch gelöscht werden.
<pre>
rmdir cd /usr/local/etc/letsencrypt.sh/certsalt
</pre>

== Vorschläge für die beste Lösung ==
* [https://bettercrypto.org/ BetterCrypto⋅org]

== Interessierte ==
* ([[user:PaulRiegel|PaulRiegel]])
* ([[user:vv01f|vv01f]])
* [[user:Bommix|Bommix]]

== Siehe auch ==

* [[Server/Zertifikate]]
* [[Server#Zertifikate]]
* [[website:stura/ref/verwaltung/admin/zertifikate/]]

== Weblinks ==
* [[CCC]]: [https://media.ccc.de/v/eh16-62-zeitgemasse_webserver-konfiguration_--_ein_serviervorschlag Talk ''Zeitgemäße Webserver-Konfiguration -- Ein Serviervorschlag'']

[[Kategorie:Projekt]]
[[Kategorie:Rechentechnik]]
[[Kategorie:Datenschutz]]
[[Kategorie:Datenkultur]]
[[Kategorie:Rechenzentrum HTW Dresden]]
Aktuelle Version		Dein Text
Zeile 238:		Zeile 238:


	==== Probleme ~~bei~~ Plone ====		==== Probleme beim Plone ====

	Bei der Instanz mit Plone ist die ganze Sache etwas komplizierter. Dort wurde ein Weiterleitung (Redirect) aller nicht bekannten Anfragen aus dem Plone direkt gemacht.<br />		Bei der Instanz mit Plone ist die ganze Sache etwas komplizierter. Dort wurde ein Weiterleitung (Redirect) aller nicht bekannten Anfragen aus dem Plone direkt gemacht.<br />