Page 1 of 1

webmail.panelurl.tld statt panelurl.tld/webmail

Posted: Tue 4. Oct 2022, 19:42
by 24unix
In Bezug auf diesen Thread: viewtopic.php?t=11748

fände ich es schön, wenn webmail per se eine eigene subdomain wird.

Und, Wildcard-certs wären dann auch praktisch.

Re: webmail.panelurl.tld statt panelurl.tld/webmail

Posted: Wed 5. Oct 2022, 09:31
by Alexander
fände ich es schön, wenn webmail per se eine eigene subdomain wird.
Das hatte ich denk ich bereits an anderer Stelle zu dem Thema bestätigt, das es so kommen wird. Es wird ein "besonderer" Typ von subdomain.
Und, Wildcard-certs wären dann auch praktisch.
Das setzt im schlimmsten fall die Kommunikation von KeyHelp mit externen Domain-Providern (und damit zahlreichen APIs für jeden Anbieter, die immer gepflegt sein wollen) voraus. Deswegen sträub ich mich noch.

Re: webmail.panelurl.tld statt panelurl.tld/webmail

Posted: Wed 5. Oct 2022, 09:41
by BloodOfPanda
Alexander wrote: Wed 5. Oct 2022, 09:31 Das setzt im schlimmsten fall die Kommunikation von KeyHelp mit externen Domain-Providern (und damit zahlreichen APIs für jeden Anbieter, die immer gepflegt sein wollen) voraus. Deswegen sträub ich mich noch.
Aber doch nur wenn man es automatisieren möchte oder?
Ansonsten muss man doch nur einen TXT DNS Eintrag mit "Verifizierung Zeichenkette" setzen, ähnlich wie es aktuell beim DKIM ist, wenn man externe DNS-Server nutzt.

Grüße Marcel // Panda

Re: webmail.panelurl.tld statt panelurl.tld/webmail

Posted: Wed 5. Oct 2022, 11:21
by Alexander
Let's Encrypt ist ja auf Automatisierung ausgelegt. So müsste man sonst alle 60 Tage an den DNS Einstellungen Änderungen vornehmen.

Ich mein, man könnte natürlich auch so rangehen: Wenn Nutzer, externe DNS + LE Wildcard nutzen möchten, müssen Sie sich das halt selbst automatisieren.

(Wenn DNS von KeyHelp verwaltet wird, ist das natürlich kein Problem)

Re: webmail.panelurl.tld statt panelurl.tld/webmail

Posted: Wed 5. Oct 2022, 11:38
by 24unix
Alexander wrote: Wed 5. Oct 2022, 09:31 Das setzt im schlimmsten fall die Kommunikation von KeyHelp mit externen Domain-Providern (und damit zahlreichen APIs für jeden Anbieter, die immer gepflegt sein wollen) voraus. Deswegen sträub ich mich noch.
Mir persönlich würde schon reichen, wenn es nur funktioniert, wenn man auch KeyKelp für DNS verwendet.

Alles andere dürfte viel zu aufwändig werden.

Re: webmail.panelurl.tld statt panelurl.tld/webmail

Posted: Wed 5. Oct 2022, 11:40
by 24unix
BloodOfPanda wrote: Wed 5. Oct 2022, 09:41
Alexander wrote: Wed 5. Oct 2022, 09:31 Das setzt im schlimmsten fall die Kommunikation von KeyHelp mit externen Domain-Providern (und damit zahlreichen APIs für jeden Anbieter, die immer gepflegt sein wollen) voraus. Deswegen sträub ich mich noch.
Aber doch nur wenn man es automatisieren möchte oder?
Ansonsten muss man doch nur einen TXT DNS Eintrag mit "Verifizierung Zeichenkette" setzen, ähnlich wie es aktuell beim DKIM ist, wenn man externe DNS-Server nutzt.
Auch das könnte man wohl automatisieren.
Eigentlich jeder Registrar bietet eine API.

So einen Aufruf könnte man ggf. mit wenig Aufwand triggern lassen.

Re: webmail.panelurl.tld statt panelurl.tld/webmail

Posted: Thu 6. Oct 2022, 16:13
by Jolinar
24unix wrote: Wed 5. Oct 2022, 11:40 Auch das könnte man wohl automatisieren.
Eigentlich jeder Registrar bietet eine API.
Da ich schon seit Ewigkeiten nur einen Regsitrar verwende, kann ich da nicht aus Erfahrung sprechen...Aber sind diese API-Schnittstellen bei den Registraren überhaupt standardisiert oder hat da jeder Anbieter sein individuelles Konzept?
Wenn das nicht standardisiert ist, dann würde eine Einbindung ins Panel und die Automatisierung schwierig, das Panel kann ja nicht jeden Registrar weltweit berücksichtigen... :?

Re: webmail.panelurl.tld statt panelurl.tld/webmail

Posted: Thu 6. Oct 2022, 16:27
by 24unix
Jolinar wrote: Thu 6. Oct 2022, 16:13
24unix wrote: Wed 5. Oct 2022, 11:40 Auch das könnte man wohl automatisieren.
Eigentlich jeder Registrar bietet eine API.
Da ich schon seit Ewigkeiten nur einen Regsitrar verwende, kann ich da nicht aus Erfahrung sprechen...Aber sind diese API-Schnittstellen bei den Registraren überhaupt standardisiert oder hat da jeder Anbieter sein individuelles Konzept?
Wenn das nicht standardisiert ist, dann würde eine Einbindung ins Panel und die Automatisierung schwierig, das Panel kann ja nicht jeden Registrar weltweit berücksichtigen... :?
Nein, sind sie nicht, ich denke, das meinte Alex.

Das würde dann etwa so aussehen:
dns.png
Das ist ziemlicher Aufwand.

Wenn es leicht umzusetzen sein soll, dann muss es generisch aufgebaut sein.

Felder für:

Api-URL
ggf. Header
ggf Body

Dann kann sich jeder das für seinen Registrar zusammenbasteln.

Re: webmail.panelurl.tld statt panelurl.tld/webmail

Posted: Thu 6. Oct 2022, 16:33
by Jolinar
24unix wrote: Thu 6. Oct 2022, 16:27 Das ist ziemlicher Aufwand.
Sowas hatte ich befürchtet... :cry:

24unix wrote: Thu 6. Oct 2022, 16:27 Wenn es leicht umzusetzen sein soll, dann muss es generisch aufgebaut sein.
Wäre es vielleicht eine Option, wenn das Panel ein Eingabefeld anbietet, wo der Admin für die jeweilige Domain seinen API-Aufruf zusammenbastelt und einträgt...Oder wäre das zu fehleranfällig?

Re: webmail.panelurl.tld statt panelurl.tld/webmail

Posted: Thu 6. Oct 2022, 16:42
by 24unix
Jolinar wrote: Thu 6. Oct 2022, 16:33
24unix wrote: Thu 6. Oct 2022, 16:27 Das ist ziemlicher Aufwand.
Sowas hatte ich befürchtet... :cry:

24unix wrote: Thu 6. Oct 2022, 16:27 Wenn es leicht umzusetzen sein soll, dann muss es generisch aufgebaut sein.
Wäre es vielleicht eine Option, wenn das Panel ein Eingabefeld anbietet, wo der Admin für die jeweilige Domain seinen API-Aufruf zusammenbastelt und einträgt...Oder wäre das zu fehleranfällig?
Ja, so in der Art hatte ich mir das vorgestellt.

Fehleranfällig, naja.
Man kann sich das mit Postman zusammenbauen, und das Panel könnte einen Testaufruf starten, der muss fehlerfrei sein.
Das ist standardisiert.
Ggf. müsste man dann noch den zu erwartenden result code ins Panel eintragen, wenn der je nach Registrar variiert.

Üblich ist 200 für fehlerfreie Aktion, oder 204 für no content, aber wenn jemand sein eigenes Süppchen kocht könnte man das so abfangen.

Re: webmail.panelurl.tld statt panelurl.tld/webmail

Posted: Thu 6. Oct 2022, 16:47
by Jolinar
24unix wrote: Thu 6. Oct 2022, 16:42 Fehleranfällig, naja.
Man kann sich das mit Postman zusammenbauen, und das Panel könnte einen Testaufruf starten, der muss fehlerfrei sein.
Das ist standardisiert.
Ggf. müsste man dann noch den zu erwartenden result code ins Panel eintragen, wenn der je nach Registrar variiert.

Üblich ist 200 für fehlerfreie Aktion, oder 204 für no content, aber wenn jemand sein eigenes Süppchen kocht könnte man das so abfangen.
Wobei man die Fehleranfälligkeit möglicherweise mit so etwas wie einer Vorlage für die wichtigsten Registrare weiter minimieren könnte ;)

Re: webmail.panelurl.tld statt panelurl.tld/webmail

Posted: Thu 6. Oct 2022, 17:04
by 24unix
Jolinar wrote: Thu 6. Oct 2022, 16:47
24unix wrote: Thu 6. Oct 2022, 16:42 Fehleranfällig, naja.
Man kann sich das mit Postman zusammenbauen, und das Panel könnte einen Testaufruf starten, der muss fehlerfrei sein.
Das ist standardisiert.
Ggf. müsste man dann noch den zu erwartenden result code ins Panel eintragen, wenn der je nach Registrar variiert.

Üblich ist 200 für fehlerfreie Aktion, oder 204 für no content, aber wenn jemand sein eigenes Süppchen kocht könnte man das so abfangen.
Wobei man die Fehleranfälligkeit möglicherweise mit so etwas wie einer Vorlage für die wichtigsten Registrare weiter minimieren könnte ;)
Wo wir wieder beim Aufwand wären.

Aber: Der Screenshot oben ist von OPNSense, man könnte mal gucken, wie Aufwändig das in der Realität ist.

Re: webmail.panelurl.tld statt panelurl.tld/webmail

Posted: Sat 17. Dec 2022, 12:17
by space2place
Alexander wrote: Wed 5. Oct 2022, 09:31
fände ich es schön, wenn webmail per se eine eigene subdomain wird.
Das hatte ich denk ich bereits an anderer Stelle zu dem Thema bestätigt, das es so kommen wird. Es wird ein "besonderer" Typ von subdomain.
Und, Wildcard-certs wären dann auch praktisch.
Das setzt im schlimmsten fall die Kommunikation von KeyHelp mit externen Domain-Providern (und damit zahlreichen APIs für jeden Anbieter, die immer gepflegt sein wollen) voraus. Deswegen sträub ich mich noch.
Moin Alex..
hatte gerade den Fall für einen Kunden und hab es hiermit gelöst:
https://github.com/alexzorin/certbot-dns-multi

Das Addon nutzt dies hier:
https://github.com/go-acme/lego/
https://go-acme.github.io/lego/dns/

Weiss halt nicht wie das in Euren Code reinpasst.
Gruß
Sascha

Re: webmail.panelurl.tld statt panelurl.tld/webmail

Posted: Tue 3. Jan 2023, 10:01
by bernhard
Bin hier gerade zufällig gelandet und für mich wären Wildcard Zertifikate auch super. Ich mach das jetzt immer von Hand...

Es wäre aus meiner Sicht absolut ausreichend, das Feature so anzubieten, dass das nur funktioniert, wenn auch DNS per KeyHelp gesteuert wird. So wie auch bei DKIM.

Eine Draufgabe könnte sein, dass ein standardisierter Webhook getriggert wird, wo dann jeder User selbst eine Schnittstelle zu seinem Provider bauen kann. Wenn man das gut macht und zB ne PHP basis-Klasse zur Verfügung stellt, die HTTP requests senden und den Status prüfen kann, dann wäre das mit ein bisschen Dokumentation sicherlich für jeden machbar.

Eventuell könnte man da einfach die Community diverse Schnittstellen bauen lassen? Ich wäre dabei! Ich weiß natürlich nicht, ob das gewünscht wäre und in die Unternehmensstrategie passt, aber ich wollte es einfach angesprochen haben :)

Jedenfalls danke für das tolle Panel - bin super happy damit!!