# ISP3 + SSL



## hahni (23. Dez. 2017)

Hallo zusammen,
ich möchte meine ISPC3-Installation auf Port 8080 nun nur noch mit SSL laufen lassen. Es ist die neueste Version installiert und Lets Encrypt läuft auch schon für ausgewählte Webseiten. Wo finde ich denn für dieses Szenario eine passende Anleitung?
LG
Hahni


----------



## Till (24. Dez. 2017)

https://www.howtoforge.com/communit...l-port-8080-with-lets-encrypt-free-ssl.75554/


----------



## hahni (24. Dez. 2017)

Für mich ist nur der Eintrag *[Changing ISPConfig 3 Control Panel (Port 8080)] relevant, richtig?*


----------



## hahni (2. Jan. 2018)

Ich verstehe leider aufgrund der Erklärung leider nichts.


----------



## oOHawkOo (2. Jan. 2018)

Zitat von hahni:


> Ich verstehe leider aufgrund der Erklärung leider nichts.


Das ist ein "klein wenig" zu allgemein. Was davon verstehst Du nicht? Punkt 1-6 ist das was Du sucht...
ggf. hilft Dir
Let‘s Encrypt Zertifikat für ISPConfig Web-Interface und PureFTPD
im unterem Teil zu finden.
https://www.niih.de/teil-2-der-web-...er-mit-web-mail-datenbank-ns1-und-ns2-server/


----------



## hahni (6. Jan. 2018)

Habe es hinbekommen. Allerdings nicht ganz, denn wenn ich server.domain.tld:8080 aufrufe, kommt folgende Fehlermeldung:

--
*Bad Request*
Your browser sent a request that this server could not understand.
Reason: You're speaking plain HTTP to an SSL-enabled server port.
Instead use the HTTPS scheme to access this URL, please.
--

Ein Redirect ist mir bisher nicht gelungen auf https://server.domain.tld:8080. Egal, was ich als Weiterleitung im Panel einstelle, es bleibt im Gegensatz zu den Webseiten ohne Funktion.


----------



## Till (6. Jan. 2018)

Zitat von hahni:


> Ein Redirect ist mir bisher nicht gelungen auf https://server.domain.tld:8080. Egal, was ich als Weiterleitung im Panel einstelle, es bleibt im Gegensatz zu den Webseiten ohne Funktion.


Einen Redirect kann es ja auch nicht geben bei Diensten die euf einem anderen Port als 80 und 443 laufen. Du musst halte einfach https://.... eingeben im Browser.


----------



## hahni (6. Jan. 2018)

Trotzdem hätte ich gerne eine Weiterleitung. Ist das ohne Wenn und Aber nicht möglich?


----------



## hahni (7. Jan. 2018)

Also wirklich kein Redirect auch seitens Apache möglich?


----------



## alhazred (11. Jan. 2018)

Das sollte über die vhost Config gehen. Wie auch bei den normalen Domains.
Das sollte so funktionieren. 
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}/$1 [R=301,L]


----------



## Till (11. Jan. 2018)

Das geht meiner Meinung nach nicht bei Diensten auf custom ports, sondern nur wenn die website port 80 und 443 nutzt denn damit es geht muss es eine Möglichket geben den vhost ohne ssl zu erreichen, kannst Du ja ausprobieren. Der Grund dafür ist dass erst die https verbindung aufgebaut wird und dies schlägt fehl, der non ssl request erreicht also nie den vhost und kann somit nicht umgeleitet werden.


----------



## hahni (11. Jan. 2018)

Also ich habe das unter Optionen -> Apache Direktiven versucht. Wenn das die richtige Stelle ist, dann muss ich leider sagen, dass es nicht funktioniert hat.


----------



## Zwirni (14. Jan. 2018)

Ich denke eher du müsstest manuell (ohne ispconfig) einen Vhost anlegen der auf Port 8080 lauscht und alle Anfragen auf deine SSL-Seite von ispconfig weiterleitet.


----------



## hahni (15. Jan. 2018)

Hast du da für mich einen Link zu einer Anleitung, wie man dies bewerkstelligen könnte? Das jedenfalls wäre auch das, was ich suchen würde.


----------



## Till (15. Jan. 2018)

Zitat von Zwirni:


> Ich denke eher du müsstest manuell (ohne ispconfig) einen Vhost anlegen der auf Port 8080 lauscht und alle Anfragen auf deine SSL-Seite von ispconfig weiterleitet.


Das wird kaum funktionieren, denn auf port 8080 läuft ja schon ISPConfig. Was Hahni möchte wenn ich ihn richtig verstanden habe ist http und https gleichzeitig auf dem selben port (8080) im apache damit er http auf https umleiten kann und das ist nunmal nicht möglich, auch nicht manuell, wie ich bereits in #7 geschrieben hatte.


----------



## hahni (15. Jan. 2018)

Ich möchte ISPConfig 3 auf 8080 nur über HTTPS erreichbar haben. Wenn es nach mir geht, müsste HTTP gar nicht funktionieren...


----------



## Till (15. Jan. 2018)

Das hast Du ja bereits, siehe post #6. Im Moment läuft ISPConfig bei Dir nur per HTTPS.


----------



## hahni (15. Jan. 2018)

Ja. Aber da kommt ein Warnhinweis. Und ich will stattdessen direkt HTTPS ausliefern.


----------



## Till (15. Jan. 2018)

Richtig, und zwar weil nur HTTPS unterstützt wird wie Du es haben möchtest, siehe Dein Post #16. Und jetzt liest Du Dir nochmal Post #11 und #15 durch, dann weißt Du warum das so ist und warum Du bei einem custom Port wie 8080 nicht von HTTP auf HTTPS umleiten kannst.


----------



## hahni (15. Jan. 2018)

Zuvor wurde doch geschrieben, dass man das direkt mit Apache geht und ISPC das leider nicht kann.


----------



## alhazred (15. Jan. 2018)

Du kann es ggf. mit mod_rewrite oder vielleicht einen reverseproxy Eintrag versuchen. Das Problem ist hier wirklich der Custom Port von ISP. Das ist so im Apache nicht vorgesehen (der Redirect).


----------



## Till (15. Jan. 2018)

Zitat von hahni:


> Zuvor wurde doch geschrieben, dass man das direkt mit Apache geht und ISPC das leider nicht kann.


Mit ISPConfig hat das hier nichts direkt zu tun sondern mit einem non standard vhost port im Apache.  Ich lerne immer gern was dazu, dann zeigt mir doch mal wie ihr einem apache ssl vhost auf port 8080 beibringt dass er einen http zu https redirect auf dem selben port durchführen soll.

Nginx kann das übrigens, aber meines Wissens nach der Apache halt nicht. Im Nginx geht es so: https://stackoverflow.com/questions...affic-that-comes-in-on-an-ssl-port-with-nginx


----------



## Till (15. Jan. 2018)

Ich beantworte mal meine Frage selbst, es geht nicht mit rewrites, wie ich es schon mehrfach ausgeführt habe. Es gibt aber einen anderen Workaround  der mit aktuellen Apache 2.4er Versionen geht, ähnlich wie bei nginx, indem man ein Error Dokument dafür benutzt und stattd es Dokumentes eine URL angibt.

ErrorDocument 400 https://deinserver.tld:8080


----------



## hahni (15. Jan. 2018)

Das klingt doch fein, Till! Also nehme ich das Error-Dokument, welches im VHost für deinserver.tld liegt und hinterlege dort die Code-Zeile?


----------



## Till (16. Jan. 2018)

Nein, es geht hier um den ispconfig.vhost (port 8080) und nicht um eine website (port 80 bzw. 443).


----------



## hahni (16. Jan. 2018)

Coole Sache! Funktioniert so, wie ich es möchte. Allerdings nur im Chrome und Firefox. Beim IE wird gefragt, ob ein Programm geöffnet werden soll.


----------



## hahni (16. Jan. 2018)

Bei ISPC 3.1.10 ging noch Sites > Website > Add new website. Bei 3.1.11 hingegen werden nur Domains aus einer Auswahlliste zugelassen, die als Webdomain hinterlegt sind. Wie geht man denn da dann richtig vor? Erst eine Kunden-Domain anlegen?


----------



## Till (16. Jan. 2018)

Es geht beides in beiden versionen. Du hast einfach nur das Domain Limit Modul angeschaltet und daher musst Du jetzt Domains erst unter Kunden anlegen.


----------



## hahni (16. Jan. 2018)

Stimmt. Das hatte ich wohl damals eingeschaltet. Aber ich weiß leider nicht mehr, wo das temporär abgeschaltet werden kann?


----------



## hahni (21. Mai 2018)

Ich bin nach der Anleitung vorgegangen. ISPConfig läuft ja nun schon seit einigen Wochen über SSL. Aber beim Mail gibt es scheinbar noch Probleme. Angeblich - so die Kunden - erscheint nun die Meldung, dass das Zertifikat ungültig sei. Aber genau das sollte doch nicht mehr erscheinen, wenn ich für Postfix und Dovecot LE hinterlege?


----------



## florian030 (21. Mai 2018)

Wenn Dovecot ein neues / geändertes Zertifikat bekommt, musst Du Dovecot einmal neu starten.


----------



## hahni (21. Mai 2018)

Das habe ich schon gemacht, Florian. Jedenfalls so, wie es im HowTo beschrieben wurde


----------



## hahni (6. Juni 2018)

Noch ein neues Problem:
Beim pureFTP erscheint nun, dass das SSL-Zertifikat abgelaufen ist. In der Oberfläche von ISPConfig aber erscheint es mit einer längeren Laufzeit. Eigentlich aber dachte ich doch, dass pureFTP und ISPConfig das gleiche LE-Cert haben?


----------



## Till (6. Juni 2018)

Hast Du incron installiert und das auto renewal script aufgesetzt wie hier beschrieben?

https://www.howtoforge.com/communit...l-port-8080-with-lets-encrypt-free-ssl.75554/

wenn nicht, dann wird das neue kombinierte SSL cert für pure-ftpd nicht erstellt und somit behält er das abgelaufene cert.


----------



## hahni (7. Juni 2018)

Optimal. Habe ich gerade eingerichtet und angepasst. Mir war nicht klar, dass der Teil der Anleitung auch noch benötigt wird. Scheint aber optimal zu funktionieren. Vielen Dank für die schnelle Rückmeldung !


----------



## hahni (15. Juni 2018)

Ich erhalte insbesondere von iPhone-Benutzern die Rückmeldung, dass bei den Geräten kein Versand von Mails möglich ist. Empfang geht - beim Versand hingegen erscheint, dass das Zertifikat ungültig ist. Was könnte da falsch laufen? Angeblich soll ein Workaround sein, dass Zertifikat lokal am Smartphone zu installieren. Wenn ja: welche Zertifikat-Datei kann ich da guten Gewissens bereitstellen? Noch besser wäre natürlich, wenn das Problem beim iPhone gar nicht erst auftreten würde. Hast du da eine Idee für mich, Till?


----------



## florian030 (15. Juni 2018)

IPhones sind per se etwas eigenwillig. Hast Du im Zertifikat das Bundle mit drin?


----------



## hahni (15. Juni 2018)

Hallo Florian,

was meinst du mit der Frage, ob ich das Zertifikat im Bundle mit drinnen habe?

LG

Hahni


----------



## florian030 (15. Juni 2018)

Umgekehrt  Hast Du nur das Cert oder ist da das Bundle mit drin?


----------



## hahni (15. Juni 2018)

Auch die Frage kann ich leider nicht beantworten. Ich bin genau nach dem HowTo vorgegangen. Da stand auch nichts von einem Bundle


----------



## hahni (15. Juni 2018)

Vielleicht kannst du mir doch noch bei meinen offenen Fragen behilflich sein?


----------



## Zwirni (17. Juni 2018)

Hier findest Du ein Beispiel:
https://knowledge.digicert.com/solution/SO17759.html

Auch ein Blick ins dovecot Manual sollte hilfreich sein: https://wiki.dovecot.org/SSL/DovecotConfiguration


----------



## hahni (18. Juni 2018)

Der erste Eintrag scheint sich ja auf RapidSSL beziehen. Wir aber setzen LE ein. Und bei der Anleitung von Dovecot: ist nicht eigentlich alles in der Anleitung von HowToForge abgehandelt? Ich würde es so verstehen, dass alles nach Durchführung der Anleitung einwandfrei funktionieren sollte?


----------



## hahni (23. Juni 2018)

Ich komme immer noch nicht klar. Ich habe sogar irgendwo gelesen, dass das LE-Cert nicht für Mail-Server gehen soll. Macht doch aber dann kein Sinn, ein HowTo zu machen. Daher glaube ich das eigentlich nicht. Doch irgendwie muss ich doch diese iPhone-Thematik hin bekommen.


----------



## Till (25. Juni 2018)

LE certs gehen auch für mail.


----------



## hahni (25. Juni 2018)

So dachte ich mir das auch aufgrund deiner tollen Beschreibung und Konfigurationsanleitung. Woran aber könnte es dann liegen, dass bei iPhones eben gerade beim Versand der Mails der Fehler kommt, dass die Nachrichten nicht versendet werden können, weil der Server nicht vertrauenswürdig sei?


----------



## Zwirni (25. Juni 2018)

Was steht im mail.log denn dazu?


----------



## florian030 (27. Juni 2018)

Ich würde eher darauf tippen, dass für den Ausgangsserver ein falscher Name eingetragen ist. Das muss schon der Name sein, der im Zertifikat enthalten ist und nicht sowas wie mail.kunden.de


----------



## hahni (27. Juni 2018)

Hm. Also das könnte eine heiße Spur sein. Wenn der Eintrag beim SMTP bisher mail.kundendomain.de war, wäre das nicht möglich, wenn das Zertifikat auf server.provider.de ausgestellt wäre? Ohne SSL wäre dies ja kein Problem... Vielleicht ist das sogar die Ursache?


----------



## Zwirni (27. Juni 2018)

Das sollte im mail.log ersichtlich sein.


----------



## hahni (28. Juni 2018)

Angeblich ist es wohl laut meinem Reseller nun so, dass er bei seinen Kunden das IMAP-Konto neu einrichtet und plötzlich soll es funktionieren. Mich hatte ohnehin gewundert, dass dies speziell ein Problem mit iPhones ist. Aber ich prüfe das auch noch einmal sicherheitshalber im Log. Vielen Dank, dass du dir die Zeit genommen hast, mich mit Lösungsansätzen zu versorgen.


----------



## hahni (12. Sep. 2018)

Zitat von Till:


> Hast Du incron installiert und das auto renewal script aufgesetzt wie hier beschrieben?
> 
> https://www.howtoforge.com/communit...l-port-8080-with-lets-encrypt-free-ssl.75554/
> 
> wenn nicht, dann wird das neue kombinierte SSL cert für pure-ftpd nicht erstellt und somit behält er das abgelaufene cert.


Hallo Till,

vor dem Update von 14.04 auf 16.04 ist mir schon aufgefallen, dass das icron-Skript scheinbar nicht läuft (Vermutung). Seit dem Update auf 16.04 sind heute die Zertifikate der ersten Webseiten abgelaufen und wurden nicht erneuert. Ich bin nach dem Ubuntu-Update noch einmal alle nötigen Schritte durchgegangen. Unter anderem auch die Installation von Lets Encrypt. Ich weiß aber nicht mehr, wie ich LE auf 14.04 installiert hatte, weil ich da glaube ich noch nicht auf die LE-Tools zurückgreifen konnte, weil die nicht in der Dist enthalten waren. Fakt ist, dass die Zertifikate nicht erneuert werden und ich nicht weiß, wie ich das wieder zum laufen bekomme. Das icron-Skript kann die Ursache ja nicht sein. Es kopiert ja nur die Zertifikate um. Aber es generiert ja keine neuen, richtig? Wie bekomme ich das denn zum Laufen.

Besten Dank für deine Mithilfe!

LG von

Hahni


----------



## hahni (12. Sep. 2018)

Stimmt eigentlich die /etc/cron.d/certbot bei mir?

--
# /etc/cron.d/certbot: crontab entries for the certbot package
#
# Upstream recommends attempting renewal twice a day
#
# Eventually, this will be an opportunity to validate certificates
# haven't been revoked, etc.  Renewal will only occur if expiration
# is within 30 days.
SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

0 */12 * * * root test -x /usr/bin/certbot -a \! -d /run/systemd/system && perl -e 'sleep int(rand(43200))' && certbot -q renew
--


----------



## Till (12. Sep. 2018)

Kommentier mal alle Zeilen in /etc/cron.d/certbot aus, indem Du ein # vor alle Zeilen machst die nicht mit # beginnen. LE certs werden durch ISPConfig erneuert, wenn Du zusätzlich noch ein 2. certbot renew script hast, dann funktioniert die Erneuerung nicht.


----------



## hahni (12. Sep. 2018)

Dagegen ist ja nichts einzuwenden. Allerdings ging es ja vorher auch nicht? Meinst du, dass das daran lag?


----------



## hahni (13. Sep. 2018)

Hallo Till,

ich habe deinen Tipp befolgt und natürlich auch den Cron-Dienst neu gestartet. Nun stellt sich aber zwecks Kontrolle die Frage, wie ich prüfen kann, ob die Erneuerung seitens ISPConfig auch ordentlich funktioniert. Denn ich konnte ja gestern nur mit dem certbot die Zertifikate erneuern. Sonst nämlich wären sie weiterhin abgelaufen geblieben.

LG von

Björn


----------



## Zwirni (14. Sep. 2018)

Das sollte in /var/log/letsencrypt/ ersichtlich sein.


----------



## thommy (16. Sep. 2018)

Zitat von hahni:


> So dachte ich mir das auch aufgrund deiner tollen Beschreibung und Konfigurationsanleitung. Woran aber könnte es dann liegen, dass bei iPhones eben gerade beim Versand der Mails der Fehler kommt, dass die Nachrichten nicht versendet werden können, weil der Server nicht vertrauenswürdig sei?


iOS macht auch bei mir regelmäßig stress mit den LE Zertifikaten.
In aller Regel liegt das am falschen Mailserver im iOS: Wenn das cert auf "hostname.domain.tld" lautet, der Kunde aber "mail.kundendomain.tld" verwendet, ist der Server nicht vertrauenswürdig!

Auch erkennt iOS beim iPhone 6 und iPhone 7 abgelaufene Zertifikate nur als "abgelaufen", scheint aber nicht nach einem neuen Cert zu suchen. Dagegen hilft, das Mailkonto auf dem iFön neu einzurichten, was alle 90 Tage echt nervig ist. Erstaunlicherweise haben mein iPad mini 1 und mein iPad diese Probleme nicht... Alle unsere iPads (insgesamt ~10 Stück, die auf die Mails zugreifen) verwenden ungefragt auch abgelaufene Mailzertifikate.


----------



## hahni (27. Sep. 2018)

Das Problem hatte ich auch schon, thommy. Ich nehme seitdem als Mail-Server nur noch die Kundendomain, da auf diese ja auch immer das Zertifikat ausgestellt ist. Seitdem gibt es auch keine Probleme mehr mit den iPhones. Und die Sache mit dem Log beobachte ich in der Hoffnung, dass es an dem zweiten Cronjob lag.


----------



## thommy (27. Sep. 2018)

Zitat von hahni:


> Das Problem hatte ich auch schon, thommy. Ich nehme seitdem als Mail-Server nur noch die Kundendomain, da auf diese ja auch immer das Zertifikat ausgestellt ist. Seitdem gibt es auch keine Probleme mehr mit den iPhones. Und die Sache mit dem Log beobachte ich in der Hoffnung, dass es an dem zweiten Cronjob lag.


du legst also für jeden kunden die Subdomain "mail" an, nur damit der Cert-Fehler unterdrückt wird?


----------



## hahni (27. Sep. 2018)

Nein, denn die geben nun die Domain als Host an. Und damit funktioniert alles einwandfrei!


----------

