Zertifikat für Serverdienste festlegen [GELÖST]

[vertexino0]

Hallo zusammen.

Wenn ich über den Menüpunkt SSL-Zertifikate "Zertifikat für Serverdienste festlegen" -> dort Lets Encrypt auswählen werden zwar die Zertifikate geholt und installiert (zu sehen in den Logs) aber nicht benutzt. Es werden weiterhin die Zertifikate von KH verwendet. Woran kann das liegen? Oder dauert es einfach eine gewisse Zeit bis die Änderung aktiv ist?

Vielen Dank und Grüße

[Alexander]

Hallo,

kannst du bitte einmal die entsprechenden Auszüge aus dem Log hier posten.

Weiterhin: Was gibt der folgende Befehl aus?

Code: Select all

ls -la /etc/ssl/keyhelp/

[vertexino0]

Hallo Alexander.

Hier die Logs:
(update.log)
====
[24-Nov-2017 15:03:01] INFO --> load tasks ... 1 found
[24-Nov-2017 15:03:01] DEBUG --> task type IDs: 810
[24-Nov-2017 15:03:01] INFO --> CRON_SSL_REFRESHSERVICE
[24-Nov-2017 15:03:01] DEBUG --> params: - no params -
[24-Nov-2017 15:03:02] DEBUG --> service certificates refreshed
[24-Nov-2017 15:03:02] DEBUG --> Apache: applyAllConfigChanges()
[24-Nov-2017 15:03:02] DEBUG --> Apache: checkDirectories()
[24-Nov-2017 15:03:02] DEBUG --> Apache: cleanAll()
[24-Nov-2017 15:03:02] DEBUG --> Apache: cleanVhosts()
[24-Nov-2017 15:03:02] DEBUG --> Apache: cleanCustomVhosts()
[24-Nov-2017 15:03:02] DEBUG --> Apache: cleanPhpFpmPools()
[24-Nov-2017 15:03:02] DEBUG --> Apache: cleanHtpasswd()
[24-Nov-2017 15:03:02] DEBUG --> Apache: getUserIdsWithModifiedDomains()
[24-Nov-2017 15:03:02] DEBUG --> Apache: no config file is marked for refresh, we have nothing more to do...
[24-Nov-2017 15:03:02] DEBUG --> Apache: reloadApache()
[24-Nov-2017 15:03:02] DEBUG --> Apache: syntax ok
[24-Nov-2017 15:03:02] DEBUG --> Apache: reloading apache
[24-Nov-2017 15:03:02] DEBUG --> Apache: reloadPhpFpm()
[24-Nov-2017 15:03:02] DEBUG --> PHP-FPM (php7.0-fpm): syntax ok
[24-Nov-2017 15:03:02] DEBUG --> PHP-FPM (php7.0-fpm): reloading php-fpm
[24-Nov-2017 15:03:02] DEBUG --> PHP-FPM (keyhelp-php56-fpm): syntax ok
[24-Nov-2017 15:03:02] DEBUG --> PHP-FPM (keyhelp-php56-fpm): reloading php-fpm
====

(ssl-maintenance.log)
====
[24-Nov-2017 15:06:01] DEBUG --> starting ssl certification maintenance
[24-Nov-2017 15:06:01] DEBUG --> checking (normal) ssl certificates
[24-Nov-2017 15:06:01] DEBUG --> ... skipped
[24-Nov-2017 15:06:01] DEBUG --> checking lets encrypt certificates
[24-Nov-2017 15:06:01] DEBUG --> remove unused accounts / certificates
[24-Nov-2017 15:06:01] INFO --> check domain "curzi-gmbh.de'
[24-Nov-2017 15:06:01] DEBUG --> certificate is valid to 2018-02-19 18:48:11 (87 days left)
[24-Nov-2017 15:06:01] INFO --> check domain "www.curzi-gmbh.de'
[24-Nov-2017 15:06:01] DEBUG --> certificate is valid to 2018-02-19 18:48:16 (87 days left)
[24-Nov-2017 15:06:01] INFO --> check domain "www.curzi.de'
[24-Nov-2017 15:06:01] DEBUG --> certificate is valid to 2018-02-19 18:48:33 (87 days left)
[24-Nov-2017 15:06:01] INFO --> check domain "curzi.de'
[24-Nov-2017 15:06:01] DEBUG --> certificate is valid to 2018-02-19 18:48:26 (87 days left)
[24-Nov-2017 15:06:01] INFO --> check domain "www.wasserwacht-nuernberg.de'
[24-Nov-2017 15:06:01] DEBUG --> certificate is valid to 2018-02-19 18:48:50 (87 days left)
[24-Nov-2017 15:06:01] INFO --> check domain "wasserwacht-nuernberg.de'
[24-Nov-2017 15:06:01] DEBUG --> certificate is valid to 2018-02-19 18:48:43 (87 days left)
[24-Nov-2017 15:06:01] INFO --> check domain "mail.curzi.de'
[24-Nov-2017 15:06:01] DEBUG --> certificate is valid to 2018-02-19 18:46:09 (87 days left)
[24-Nov-2017 15:06:01] DEBUG --> finished
====

Hier die Ausgabe von "ls -la /etc/ssl/keyhelp/"

root@mail:~# ls -la /etc/ssl/keyhelp/
total 48
drwxr-xr-x 5 root root 4096 Nov 24 15:03 .
drwxr-xr-x 5 root root 4096 Nov 4 03:05 ..
drwx------ 2 keyhelp keyhelp 4096 Sep 1 09:50 files
lrwxrwxrwx 1 root root 60 Nov 24 15:03 ftp-ca.crt -> /etc/ssl/keyhelp/letsencrypt/keyhelp/mail.curzi.de/chain.pem
lrwxrwxrwx 1 root root 63 Nov 24 15:03 ftp.pem -> /etc/ssl/keyhelp/letsencrypt/keyhelp/mail.curzi.de/complete.pem
lrwxrwxrwx 1 root root 60 Nov 24 15:03 keyhelp-ca.crt -> /etc/ssl/keyhelp/letsencrypt/keyhelp/mail.curzi.de/chain.pem
lrwxrwxrwx 1 root root 63 Nov 24 15:03 keyhelp.pem -> /etc/ssl/keyhelp/letsencrypt/keyhelp/mail.curzi.de/complete.pem
drwx------ 6 root root 4096 Nov 21 19:48 letsencrypt
lrwxrwxrwx 1 root root 60 Nov 24 15:03 mail-ca.crt -> /etc/ssl/keyhelp/letsencrypt/keyhelp/mail.curzi.de/chain.pem
lrwxrwxrwx 1 root root 63 Nov 24 15:03 mail.pem -> /etc/ssl/keyhelp/letsencrypt/keyhelp/mail.curzi.de/complete.pem
drwx------ 2 root root 4096 Sep 1 09:50 pem
-rw------- 1 root root 2358 Sep 1 09:50 root-ca.crt
lrwxrwxrwx 1 root root 37 Nov 24 15:03 webmail-ca.crt -> /etc/ssl/keyhelp/files/default-ca.crt
lrwxrwxrwx 1 root root 32 Nov 24 15:03 webmail.pem -> /etc/ssl/keyhelp/pem/default.pem
root@mail:~#

Ich hoffe die Ausgaben helfen.

Danke und Gruß

[Alexander]

Okay, als nächstes wären die folgenden Informationen interessant:

1) Wie schaut die Datei /etc/apache2/keyhelp/keyhelp.conf aus

2) Was wurden für Einstellungen am Server vorgenommen. Wie ich sehen kann wurde das derzeit aktive Default Zertifikat auf m6677.contaboserver.net ausgestellt aber der derzeitige Hostname ist mail.curzi.de.
- Wurde die Umbenennung über die entsprechende KeyHelp Funktion durchgeführt?
- Wurden wurden vorhandene Apache-Configs geändert / zusätzliche Apache Configs hinzugefügt?

[vertexino0]

Hallo Alexander.

Hier die Datei (in txt umbenannt)

keyhelp.txt

(4.38 KiB) Downloaded 176 times

Die Umbenennung wurde via KH durchgeführt. Ich musste dies ändern wegen Zustellproblemen mit GMX/WEB.

Vorhandene Configs wurden nicht geändert.
Ich habe zudem 4 zusätzliche Entwicklungswebseiten via Apache konfiguriert. Diese sind mit einem selbst signierten Zertifikat abgesichert.

Gruß

[Alexander]

Ich habe zudem 4 zusätzliche Entwicklungswebseiten via Apache konfiguriert. Diese sind mit einem selbst signierten Zertifikat abgesichert.

Laut der geposteter Konfiguration und den Logs ist von KeyHelp Seite her alles okay. Ich würde jetzt vermuten, das Problem liegt in den Konfigurationen dieser 4 zusätzlichen Seiten. Könntest du deren Konfiguration auch noch einmal zur Verfügung stellen (ggf. per PM)?

[vertexino0]

Hallo zusammen.

Entschuldigung für die späte Rückmeldung.
Hier die Konfiguration einer der 4 Entwicklungsseiten:

<VirtualHost *:83>
DocumentRoot /var/www/hp-entw/wasserwacht

ErrorLog /var/log/apache2/wasserwacht-entw-error_log
CustomLog /var/log/apache2/wasserwacht-entw-access_log combined

SSLEngine On
SSLOptions +StrictRequire
SSLCertificateFile /etc/apache2/ssl/wasserwacht.pem
SSLCertificateKeyFile /etc/apache2/ssl/wasserwacht.key
</VirtualHost>

Die Konfigurationen sind zu finden unter /etc/apache2/sites-available.
Alle Konfigurationen sind nach dem selben Muster aufgebaut. Jede Entwicklungsseite hat Ihr eigenes selbst signiertes SSL-Zertifikat.
Ich kann mir aber nicht vorstellen, das es daran liegt.

Vielen Dank und Grüße.

[vertexino0]

Hallo zusammen.

Hat hier niemand eine Idee warum das nicht geht?
Habe leider auch selbst noch keine Lösung gefunden.

Vielen Dank

[Martin]

Hallo,

gibt es einen technischen Grund, wieso diese manuell und nicht über KeyHelp konfiguriert wurden?

[nikko]

Da ich viel KH teste (bei den verschiedenen Providern, um hier zu helfen) kann ich dazu nur sagen, dass KH bei deinem Anbieter von Hause aus anstandslos funktioniert (hat).
Meine Vorgehensweise dazu immer:
1.) Subdomain auf Server - IP routen, warten, bis diese durchs Netz verteilt wurde
2.) Os minimal Installation.
3.) Servernamen in der /etc/host und /etc/hostname anpassen (dann weiß, was ich gemacht habe und kann es kontrollieren)
4.) Reboot
5.) Installation

[nikko]

Noch eine ganz simple Idee: Mal den Browser gewechselt oder den Browsercache geleert?

[vertexino0]

Hallo Martin.

Entschuldigung für die späte Antwort.
Ich konnte in der Zwischenzeit das Problem lösen.

Nach langem Suchen habe ich festgestellt, das die Zertifikate für FTP, KH und MAIL ordnungsgemäß erstellt wurden (Files und Symbolic-Links).
Für FTP und MAIL wurden die Änderungen auch ordnungsgemäß in den entsprechenden Konfigurationsdateien der Programme übernommen.
Lediglich für KH wurde die Konfigurationsdatei /etc/apache2/keyhelp/keyhelp.conf nicht angepasst und weiterhin die von KH erstellten Zertifikate genutzt.
Nach Anpassung der Pfade und Neustart von Apache2 wurde nun das Zertifikat von Let's Encrypt verwendet.

Vielleicht wisst Ihr noch warum die Pfade nicht angepasst wurden.
Als kleine Hilfe: Es handelt sich hier um Backup Daten einer Debian 8 Installation welche in eine frische Debian 9 Installation importiert wurden.

Bezüglich der Frage, warum ich die VirtualHosts außerhalb von KH definiert habe liegt darin begründet, das es sich um Entwicklungs-Webseiten handelt. Die Live-Versionen wurden mit KH definiert. Aber für die Entwicklung (1 zu 1 Kopie) habe ich in KH keine Lösung gefunden, da hier auch keine wirkliche Domain dahinter steht. Deshalb die Definition außerhalb von KH. Wenn es eine andere Möglichkeit gibt bin ich für jeden Vorschlag offen. Ich hoffe ich konnte mich verständlich ausdrücken

Vielen Dank für die Hilfen.
Mit freundlichem Gruß

[Alexander]

Hallo,

In der Datei "/etc/apache2/keyhelp/keyhelp.conf" befindet sich nur ein Verwies auf den Sym-Link in /etc/ssl/keyhelp, der wiederum zum Zertifikat zeigt.

Das sieht immer so aus (und wird von KeyHelp auch nicht wieder angerührt):

Code: Select all

    # ssl
    SSLEngine On
    SSLCertificateFile /etc/ssl/keyhelp/keyhelp.pem
    SSLCertificateChainFile /etc/ssl/keyhelp/keyhelp-ca.crt

Bei einer Aktualisierung / Änderung der Zertifikate des Webservers wird nun nur das Ziel des Sym-Links geändert, die eigentliche Konfigurationsdatei keyhelp.conf bleibt unberührt. Anschließend wird die Apache-Konfiguration neu geladen, sofern kein Syntax-Fehler / sonstiges Problem beim Apache vorliegt (Es gab zwar unter der alten KeyHelp Version 17.2.1 unter Debian 9 ein Problem mit dem Apache, das dieser ggf. nicht neu geladen werden konnte, würde ich als Ursache damals aufgrund der Logs weiter oben ausschließen).

Was hast du genau an der keyhelp.conf geändert?

---

Zum zweiten Punkt, das wäre zum Beispiel eine Möglichkeit:

Ich würde, einen Benutzer anlegen, nennen wir ihn "mein_projekt". Dessen Webspace ist fortan über die Standard-Subdomain, die beim Benutzer erstellen angelegt wird erreichbar: "mein-projekt.mein-keyhelp.de"
Anschließend das www Verzeichnis des Benutzers mit der Verzeichnisschutzfunktion von KeyHelp vorn unberechtigtem Zugriff schützen.
Jetzt erstellt du die Website.
Am Schluss, fügst du dem Benutzer die finale Domain hinzu und ersetzt im Programmcode deiner Website / der Datenbank alle vorkommen von "mein-projekt.mein-keyhelp.de" mit "meine-finale-domain.de".

[vertexino0]

Hallo Alexander.

Ich verstehe. Komischerweise standen in meiner Datei die folgenden Pfade drin:

Code: Select all

# ssl
SSLEngine On
SSLCertificateFile /etc/ssl/keyhelp/pem/default.pem
SSLCertificateChainFile /etc/ssl/keyhelp/files/default-ca.crt

Diese habe ich an deine geschriebenen Werte angepasst.

Bezüglich dem anderen Punkt werde ich das mal testen.

Vielen Dank für die Hilfen.