Wenn man bei CAcert angemeldet ist, liegt es nahe, sich auch für den eisfair-Server zu Haus ein passendes Zertifikat ausstellen zu lassen. Voraussetzung dafür ist folgendes:

• eisfair-Server mit den installierten Paketen apache2 und certs
• Account bei CAcert und genügend Punkte zum Erstellen eigener Server-Zertifikate

Sind alle Voraussetzungen erfüllt, geht man wie folgt vor. Zunächst ruft man auf dem eisfair-Server das Setup-Menü auf und geht ins Service-Menü von certs. Dort wählt man den Punkt Manage certificates. Daraufhin ändert man über 1 den key type auf web server. Als nächstes wählt man Punkt 10 (create a new key or select an exiting one [apache]), sonst schlägt der folgende Punkt fehl. Nun wählt man Punkt 11 (create certificate request), das verlangt CAcert nämlich später beim Erstellen des Zertifikats. Bei den Eingaben kann man sich weitestgehend an die Vorgaben halten. Wichtig: Als Common Name die Domain (FQDN) angeben, unter der der Server später erreichbar sein soll, beispielsweise www.example.dyndns.org, wenn man das später von draußen so im Browser eintippt, um den Heimserver zu erreichen. Als Challenge passwort gibt man einen einfachen Punkt ein.

Der Certification Request liegt jetzt unter /var/certs/ssl/csr/apache.csr. Den Inhalt dieser Datei benötigt man, um nun auf der Webseite von CAcert sein Zertifikat zu beantragen. Also kopiert man den Inhalt der Datei und loggt sich bei CAcert ein. Dort wählt man auf der rechten Seite Server Zertifikate und Neu. Nach einem langen, wichtigen Text gibt es unten ein großes Eingabefeld, in das man nun den Inhalt der Zwischenablage beziehungsweise den Certification Request einfügt. Anschließend auf Abschicken klicken, nochmal den Common Name gegenprüfen und nochmal Abschicken klicken.

Daraufhin zeigt die CAcert-Webseite das neue Zertifikat an. Das kopiert man und speichert es auf dem eisfair-Server in eine Datei mit der Endung .pem, beispielsweise www_example_dyndns_org.pem. Diese Datei kopiert man nun mit root-Rechten nach /var/certs/ssl/certs/. Anschließend ruft man ebenfalls mit root-Rechten einmal das Skript /usr/bin/ssl/c_rehash auf.

Mit einem aktuellen apache2 (probiert mit 1.3.4) wird man bei Aktivierung der Option APACHE2_SSL in der Konfiguration beim ersten Aktivieren einmal durch die komplette Zertifikat-Erstellungsprozedur geschickt, die genutzt wird, wenn der eisfair-Server selbst eigene Zertifikate ausstellt. Da wurstelt man sich einmal durch. Anschließend muss man dem Apache aber noch das CAcert-Zertifikat unterschieben. Wenn vHosts verwendet werden, gibt man den oben vergebenen Dateinamen einfach ohne Endung in der Variablen APACHE2_VHOST_?_SSL_CERT_NAME an. Verwendet man keine vHosts ist noch etwas Trickserei erforderlich. Der Apache erwartet das Zertifikat dann in /usr/local/ssl/certs/apache.pem bzw. (da /usr/local/ssl nur noch ein Symlink auf /var/certs/ssl ist) /var/certs/ssl/certs/apache.pem.

Jetzt gibt’s mehrere Möglichkeiten: apache.pem mit der neuen Datei überschreiben, einen symbolischen Link mit dem Namen apache.pem auf die neue Datei setzen oder den entsprechenden Teil aus der neuen Datei im Editor kopieren und in apache.pem ersetzen. Die zweite Variante (root-Rechte):

cd /var/certs/ssl/
mv apache.pem apache.pem.bak
ln -s www_example_dyndns_org.pem apache.pem
/usr/bin/ssl/c_rehash

Anschließend den Webserver nochmal neu starten, fertig. Der Apache ist fortan über https://www.example.dyndns.org mit einem von CAcert signierten Zertifikat erreichbar.

Die meisten Einträge befassen sich damit, wie man das htpasswd-Tool benutzt, mit dem sich solche Dateien über die Kommandozeile bearbeiten lassen. Ich möchte aber wissen, ob und wie ich dort Kommentare einfügen kann.

Letztendlich habe ich einfach mal probiert und war damit erfolgreich, vor die betroffene Zeile eine Raute zu setzen (#), also so zu kommentieren, wie in shell-Scripten.

Aber eine fundierte Lösung wäre mir natürlich lieber. Falls jemand etwas hat: Ab in die Kommentare damit!

Seit wir das Antiblau-Blog mit einem Cache versehen haben, bekomme ich regelmäßig E-Mails von dem Script, das sich normalerweise um die Korrektur der Berechtigungen in den WWW-Verzeichnissen kümmert (die Struktur lässt sich mit den Standardmechanismen der Unix-Dateiberechtigungen nicht mehr abbilden und ACLs habe ich nicht). Der Grund ist, dass die Cache-Dateien mit der Gruppe des Apache, statt mit der Gruppe des Webspaces, und mit den falschen Zugriffsrechten erzeugt wurden.

Die Gruppenberechtigung lässt sich leicht korrigieren, indem das Gruppen-Stickybit des übergeordneten Verzeichnisses gesetzt wird:

chmod g+s cache

Schwieriger ist die Anpassung der Zugriffsrechte von 640 auf 660. Hierfür muss der Apache so konfiguriert werden, dass auch Gruppen Schreibrechte erhalten. Das geschieht über die umask-Variable (umasks legen fest, welche Berechtigungen bei einem chmod wieder gelöscht werden), die in der envvars-Konfiguration angegeben werden.

Dazu habe ich in die Datei

/etc/apache2/envvars

den Eintrag

umask 002

eingefügt, den Apache neu gestartet und schon war das Problem behoben.