it-swarm.com.de

SSL-Platzhalterproblem für WP-Subdomains mit mehreren Standorten

Ich habe ein Problem mit Wildcard-SSL und mein Host gibt an, dass er es nicht so zum Laufen bringen kann, wie ich es mir vorgestellt habe.

Ich habe ein Wildcard-SSL-Zertifikat gekauft, weil ich denke, dass es mit Subdomains auf einer WordPress-Multisite gut funktionieren sollte, aber das ist nicht der Fall. Jedes Mal, wenn eine Subdomain erstellt wird, muss ich meinen Host kontaktieren, damit dieser einen Symlink für jede Subdomain einrichten kann. Bei jeder Unterdomäne, bei der mein Host keine Symlinks eingerichtet hat, wird bei Verwendung von https in den Unterdomänen ein interner Fehler von 500 angezeigt. Das kann doch nicht richtig sein.

Ich kann meinen Host nicht jedes Mal kontaktieren, wenn eine neue Site auf meiner Multisite erstellt wird, da jeder eine Site auf meiner Multisite erstellen kann und viele Sites an einem Tag erstellen könnten. Ich habe ihnen das gesagt, aber sie sagen, dass sie nichts anderes tun können, als Symlinks für jede Subdomain zu erstellen.

Wie funktionieren andere beliebte WordPress-Multisites mit https, beispielsweise bei wordpress.com?

Bei Verwendung von https wird jedoch für alle Subdomains auf meiner gehosteten Multisite ein interner Fehler angezeigt, es sei denn, mein Host erstellt Symlinks für jede neue Subdomain.

Ist das ein Serverproblem? Hat jemand eine Lösung dafür? Würde ein anderer Host https für Subdomains verwenden können, ohne dass Symlinks für jede Subdomain manuell erstellt werden müssen?

Jede Hilfe dankbar.

4
user3438958

mein Name ist Daniel Kanchev und ich arbeite für SiteGround als Senior Web Apps Engineer.

Das beschriebene Problem ist ziemlich seltsam und ich habe gerade ein Test-WordPress-Netzwerk auf einem gemeinsam genutzten SiteGround-Server konfiguriert. Ich hatte keine ähnlichen Probleme und verwendete Sub-Domain-Namen mit einem Wildcard-SSL-Zertifikat. Normalerweise werden solche Probleme durch Apache VHost-Fehlkonfigurationsprobleme verursacht. Die Benutzer verwenden häufig das folgende Setup (das Standard-cPanel-Setup):

<VirtualHost 109.73.236.14:443>
    ServerName *.lumenco.ca
    ServerAlias *.lumenco.ca
    VirtualDocumentRoot /home/lumenco0/public_html/%1
    ServerAdmin [email protected]
    UseCanonicalName Off

Das Problem wird normalerweise dadurch verursacht, dass ServerName und UseCanonicalName nicht richtig festgelegt sind. Die richtige Konfiguration, die mit WordPress funktioniert, ist:

<VirtualHost 109.73.236.14:443>
    ServerName lumenco.ca
    ServerAlias *.lumenco.ca
    VirtualDocumentRoot /home/lumenco0/public_html/%1
    ServerAdmin [email protected]
    UseCanonicalName On

@Rarst, das Problem ist seltsam, aber dies wird auf gemeinsam genutzten Servern unterstützt und ich habe persönlich viele WordPress-Apps auf unseren gemeinsamen Hosting-Plänen so konfiguriert, dass sie dasselbe Setup verwenden :)

6
Daniel Kanchev