Du kannst eine Subdomain mit dem Namen * anlegen. Deren Einstellungen gelten für alle nicht definierten Subdomains. Ggf. musst du noch dafür sorgen, dass passende Wildcard-DNS-Records existieren (A und AAAA oder CNAME), damit der Webbrowser die Domain findet. Ein Wildcard-Zertifikat für TLS bekommst du bei Netcup aber nicht automatisch. Wirklich elegant ist das deshalb nur mit einem Server lösbar, nicht mit einem Webhostingpaket.
Mit *-Wildcards arbeiten, wird aber in jedem Fall angenehmer als eigener Server, wenn sich diese Frage stellt. Das wäre praktisch vom Regen in die Traufe.
Allgemein sollte man nicht so viel mit Subdomains im Webhosting machen, zumindest wenn es um Zertifikate geht. Das ist auch gar nicht nötig, weil Du das logisch genauso im Verzeichnis abbilden kannst. Prinzipiell organisiert man ja eher grundlegend andere Dienste über Subdomains, die sich vom Webserver (oder zumindest dem normalen Seiten) unterscheiden. Z.B. http://www.deinedomain.de, mail.deinedomain.de, ntp.deinedomain.de (oder zumindest shop.deinedomain.de)
Die logische Untergliederung von Webseiten wird dagegen nach hinten über die Verzeichnisstruktur vorgenommen, z.B. http://www.deinedomain.de/verzeichnis/nocheinverzeichnis/. So hat dann auch Dein Zertifikat keine Probleme.
Allgemein sollte man nicht so viel mit Subdomains im Webhosting machen, zumindest wenn es um Zertifikate geht.
Magst Du das erläutern? Ich habe Subdomains im Webhosting mit eigenen LE-Zertifikaten (die sich automatisch verlängern) und bin mir keiner Schuld bewusst. Warum sollte man das nicht machen?
Unabhängig von der Verzeichnisstruktur im httpdocs-Ordner sind Subdomains häufig besser zu kommunizieren und können auch zum Separieren ein sinnvoller Mittel sein: Um Scriptausführungen zu limitieren, separate (PHP-) Settings zu setzen oder…
Was übersehe ich?
Was übersehe ich?
Gar nichts – du hast vollkommen recht.
Magst Du das erläutern? Ich habe Subdomains im Webhosting mit eigenen LE-Zertifikaten (die sich automatisch verlängern) und bin mir keiner Schuld bewusst. Warum sollte man das nicht machen?
Was Du machst oder nicht machst, ist ganz allein Dir überlassen, allerdings ist die traditionelle Konvention bzw die "eingebürgerte Verfahrensweise" bei Subdomains, dass man darüber unterschiedliche Dienste bereitstellt. Beispiele hatte ich bereits dargestellt. Mailserver, Zeitserver, Webserver. Und gelegentlich soll es helfen, solche (alt hergebrachten) Konventionen auch (immernoch) einzuhalten. Ob Du das machen möchtest oder nicht, obliegt natürlich allein Dir.
Allerdings würde das auch einem Webhosting-Kunden einiges erleichtern so zu verfahren. Deshalb schlage ich das auch vor. ,)
Edit: Im Übrigens würfelst Du mit der Vermengung mit einer Programmiersprache die Paket-Organisationsstruktur hier auch noch mit rein (was ja historisch betrachtet erst später kam und sich diese Möglichkeit zu Nutze gemacht hat). Das wird jemandem, der erstmal nur seine Seite organisieren möchte, nicht helfen und das braucht man hier nicht berücksichtigen.
Was Du machst oder nicht machst, ist ganz allein Dir überlassen, allerdings ist die traditionelle Konvention bzw die "eingebürgerte Verfahrensweise" bei Subdomains, dass man darüber unterschiedliche Dienste bereitstellt.
Es ist doch absolut Gang und Gäbe, dass man über verschiedene Subdomains auch verschiedene Webseiten ausliefern kann. Wüsste auch absolut nichts was dagegen spricht. Zumal man dann auch verschiedene Hostingeinstellungen je Subdomain fahren kann (PHP-Version, usw). Klar sollte man aufpassen, dass man hier nicht mit bestehenden Einträgen wie db. mail. usw. in Konflikt gerät, aber in Verbindung mit Zertifikaten, und darum ging es ja hier im Thema, gibt es absolut keine Probleme in den Webhostings.
Es ist doch absolut Gang und Gäbe, dass man über verschiedene Subdomains auch verschiedene Webseiten ausliefern kann. Wüsste auch absolut nichts was dagegen spricht. Zumal man dann auch verschiedene Hostingeinstellungen je Subdomain fahren kann (PHP-Version, usw). Klar sollte man aufpassen, dass man hier nicht mit bestehenden Einträgen wie db. mail. usw. in Konflikt gerät, aber in Verbindung mit Zertifikaten, und darum ging es ja hier im Thema, gibt es absolut keine Probleme in den Webhostings.
Ja, heute ist diese Konvention so nicht mehr gebräuchlich, was nicht heißt, dass sie keinen Sinn ergibt oder dass man sich so nicht das Leben erleichtern kann, wenn es sich um die homogene Organisation von Webcontent handelt.
Es ging bei dem Vorschlag auch nur darum Probleme von vornherein für jemanden zu vermeiden, der Probleme mit den Subdomains hat und aufgrund eingeschränkter Möglichkeiten bei der Generierung von Zertifikaten das Leben erheblich zu erleichtern. Und das ist eine Erleichterung gleich so zu verfahren statt unbedingt eine logische Untergliederung über Subdomains vorzunehmen. ,)
Es geht bei der Anfrage nicht darum, ob man Subdomains verwendet. Das ist bereits der Fall: "verschiedene Domains und diese haben teilweise noch mehrere Subdomains".
Gutgut, macht Ihr mal weiter, denn ich habe keine Ahnung mehr wie eingeschränkt man da als Webhosting-Kunde bei der Zertifikate-Erstellung ist oder nicht. Ich glaube nur nicht, dass der Hinweis für den Threadersteller hilfreicher ist, dass man mit VPS diese Einschränkungen nicht hat, er sich dann eine VPS zulegt und sich damit dann größere Probleme ans Bein bindet, weil er das erst Recht nicht gehandelt bekommt.
Ich habe deshalb eine (klassische) Organisationsstruktur vorgeschlagen, die Problemen mit Subdomains einfsch ganz aus dem Weg geht. Dass man anders verfahren kann (und verständlicher Weise auch oft möchte), ist ja völlig unbenommen, weil ich nicht gesagt habe, dass man zwingend so verfahren müsste. Klar kann (und will) man das oft aus unterschiedlichen Gründen anders, aber man muss halt auch nicht Subdomains verwenden (oder gleich eine VPS buchen), wenn man damit ohnehin nur homogenen Webcontent organisiert und damit Probleme auftreten. Gelegentlich soll so eine klassische Konvention ja doch noch irgendwie Sinn machen. Vorallem wenn man sich stattdessen nicht alternativ die Administration einer VPS ans Bein bindet.
