Mein Provider bietet seit einiger Zeit die Möglichkeit kostenlos SSL/TLS-Zertifikate für (Sub-)Domains einzubinden, so dass diese direkt per https erreichbar sind. ein Workaround per SSL-PRoxy ist daher nicht erforderlich (siehe auch “Echtes SSL bei All-Inkl” und “WordPress auf SSL umstellen“).
Dieser Artikel wurde mehrfach aktualisiert:

  1. Update 06.08.2013: Problem bei internen Verlinkungen
  2. Update 27.12.2013: Problem: Falsche RewriteBase in .htaccess nach WP-Update
  3. Update 08.01.2014: Hinweis: Vorgehen funktioniert nur bei Installation in /
  4. Update 29.01.2015: Hinweis: SSL/TLS ohne PRoxy bei All-Inkl möglich
Die hier vorgestellte Lösung funktioniert (zumindest ohne Anpassungen) nur dann, wenn das Blog nicht in ein Unterverzeichnis der Domäne installiert wurde. Es muss also über http://www.irgendeinedomain.de und nicht über http://www.irgendeinedomain.de/pfad erreichbar sein.

WordPress kann so konfiguriert werden, dass die Administration über SSL erzwungen wird. Die Standardoptionen “FORCE_SSL_LOGIN” und “FORCE_SSL_ADMIN” benötigen dazu aber ein eigenes SSL-Zertifikat, so dass das Blog direkt unter https erreichbar ist(siehe codex.wordpress.org). Bei vielen Providern muss dafür allerdings ein Aufpreis gezahlt werden. Alternativ stellen sie jedoch meistens einen Zugriff per SSL-Proxy zur Verfügung  Dabei wird auf das Blog üblicherweise über eine andere Adresse (z.B. https://klein-gedruckt.de) zugegriffen.  Will man die kostengünstigere SSL-Proxy-Variante verwendet werden, so ist eine einfache Aktivierung der SSL-Verschlüsselung leider nicht möglich.

Mit folgenden Änderungen kann ich jedoch bei mir die SSL-Verschlüsselung via Proxy bei meinem Provider all-inkl erzwingen.

Zugriff auf /wp-admin per SSL-Proxy ermöglichen

Zunächst muss die WordPress-Konfiguration in der Datei wp-config.php angepasst werden. Da beim Zugriff über den SSL-Proxy das Blog unter einer anderen URL angesprochen wird, mache ich hier einen Unterschied, ob ein direkter unverschlüsselter Zugriff, oder eine Zugriff über den SSL-Proxy erfolgt. Daher habe ich folgende Änderungen an den Anfang der wp-config.php eingefügt:

/* Zugriff über SSL-Proxy ermöglichen */
if( isset( $_SERVER['HTTP_X_FORWARDED_SERVER'] ) ) { 
# Zugriff mit SSL-Proxy
    $_SERVER['HTTPS']='on';
    $_SERVER['HTTP_HOST'] = 'ssl-account.com';
    $_SERVER['REQUEST_URI']='/klein-gedruckt.de'. $_SERVER['REQUEST_URI'];
    define('COOKIE_DOMAIN', 'ssl-account.com');
    define('COOKIEPATH', '/klein-gedruckt.de/');
    define('WP_SITEURL', 'https://klein-gedruckt.de');
    define('WP_HOME', 'https://klein-gedruckt.de');
} else {
# Zugriff ohne SSL-Proxy
    define('COOKIE_DOMAIN', 'klein-gedruckt.de');
    define('WP_SITEURL', 'https://klein-gedruckt.de');
    define('WP_HOME', 'https://klein-gedruckt.de');
}

Hier müssen natürlich überall da wo klein-gedruckt.de auftaucht die tatsächliche URL des jeweiligen Blogs eingetragen werden. Nach diesen Änderungen sollte das Blog sowohl unverschlüsselt als auch per SSL-Proxy verschlüsselt korrekt aufgerufen und administriert werden können.

Erzwingen der Administration per SSL-Proxy

Damit nun nicht versehentlich die unverschlüsselte Variante genutzt wird, sollte die Verschlüsselung bei der Administration bzw. beim Login entsprechend erzwungen werden. Dazu wird folgende Rewrite-Rule in der .htaccess vor der Zeile “# BEGIN WordPress” hinzugefügt:

 Anmerkung: Nach diesen Änderungen ist die XMLRPC-Schnittstelle des Blogs nur noch über HTTPS erreichbar. Diese Schnittstelle wird beispielsweise von der WordPress-App verwendet. Daher muss für alle Anwendungen, die per XMLRPC-Schnittstelle Änderungen am Blog vornehmen die Konfiguration so angepasst werden, dass sie per SSL-Proxy auf die Schnittstelle zugreifen.
<IfModule mod_rewrite.c>
	RewriteEngine on
	RewriteBase /

	# wp-(admin|login|register)* auf HTTPS umleiten
	RewriteCond %{HTTPS} off
	RewriteCond %{HTTP:X-FORWARDED-SERVER} !^ssl-account\.com$ [NC]
	RewriteCond %{REQUEST_FILENAME} -f [OR]
	RewriteCond %{REQUEST_FILENAME} -d
	RewriteRule ^wp-(admin|login|register)(.*) https://klein-gedruckt.de/wp-$1$2 [L]

	# xmlrpc* auf HTTPS umleiten
	RewriteCond %{HTTPS} off
	RewriteCond %{HTTP:X-FORWARDED-SERVER} !^ssl-account\.com$ [NC]
	RewriteRule ^xmlrpc(.*) https://klein-gedruckt.de/xmlrpc$1 [R=301,L]
</IfModule>

Update 06.08.2013: Nach einem Kommentar von Tino habe ich nochmal ein Kapitel zum Thema interne Verlinkungen spendiert

Problem: Interne Verlinkungen

Werden die Änderungen wie oben beschrieben durchgeführt und die Administration per SSL-Proxy erzwungen, so wird man relativ schnell feststellen, dass die internen Links alle über den SSL-Proxy referenziert werden, wenn beispielsweise ein anderer Artikel im Blog verlinkt wird (siehe auch den Kommentar von Tino. Auf der anderen Seite sind die Verlinkungen in bereits geschriebenen Artikeln bisher immer ohne SSL-Proxy eingefügt worden.

Dies führt dazu, dass der User nicht mehr immer im gleiche Kontext bleibt, sondern er zwischendurch per SSL-Proxy auf das Blog zugreift, obwohl er eigentlich unverschlüsselt darauf zugreifen will oder umgekehrt. Der Wechsel zwischen unverschlüsselten und verschlüsselten Bereichen ist unschön, zumal sich bei der Verwendung eines SSL-Proxies auch immer die Domäne ändert.

Es gibt drei Lösungsansätze wie man dies umgehen kann:

  1. Interne Links werden immer manuell eingefügt oder so angepasst, dass sie immer auf die URL ohne SSL-Proxy verweisen. So ist zumindest gewährleistet, dass die Nutzer, die ohne SSL-Proxy auf dem Blog surfen nicht an den SSL-Proxy weitergeleitet werden. Die SSL-User werden bei dieser Lösung allerdings ggf. auf unverschlüssetlte Seiten umgeleitet.
  2. Ein ähnliches Ergebnis hat Tino erreicht, indem er die oben beschriebene Konfiguration etwas abgeändert hat (siehe Kommentar unten). Dabei setzt er in der wp-config.phph die Konstante WP_HOME auch beim Zugriff über den SSL-Proxy auf die unverschlüsselte URL des Blogs (z.B. mit dem Kommando define(‘WP_HOME’,’https://klein-gedruckt.de’);). Ich habe diese Lösung nicht selber ausprobiert, aber sie dürfte zum gleichen Ergebnis führen wie in Punkt 1 beschrieben. Ich bin mir allerdings nicht sicher, ob das Ändern der Konstanten WP_HOME nicht noch weitere unerwünschte Nebenwirkungen mit sich bring (z.B. das unverschlüsselte Nachladen von Inhalten bei der Administration).
  3. Da ich meinen Usern sowohl den unverschlüsselten als auch den verschlüsselten Zugriff durchgängig ermöglichen möchte, habe ich ein Plugin-geschrieben, dass abhängig vom Aufruf des USers die Links in den Artikeln und Seiten dynamisch angepasst werden. Dabei werden alle Links auf den SSL-Proxy umgebogen, wenn der User per SSL-Proxy surft. Greift er unverschlüsselt auf das Blog zu, werden alle Links entsprechend angepasst, so dass der Zugriff ohne Proxy erfolgt. Details zum Plugin “SSL-Proxy URL Fixer” findet ihr in einem eigenen Artikel.

Update 27.12.2013: Nachdem meine Blog-Artikel nach dem letzten WordPress-Update nicht mehr erreichbar waren, bitte folgenden Hinweis beachten:

Problem: Falsche RewriteBase in .htaccess nach WP-Update

Wird das Admin-Interface über den SSL-Proxy aufgerufen, so wird es bei meinem Provider all-inkl.com über den ssl-account.com im Pfad <domainname.com> aufgerufen. Dies kann dazu führen, dass bei einem Update die RewriteBase in der .htaccess des WP-Basis-Verzeichnis entsprechend verändert wird. Dies wührt dazu, dass die Artikel beim Aufruf ohne SSL-Proxy nicht mehr erreichbar sind und es zu einem internen Server Error kommt. Durch eine einfache Anpassung sind die Artikel aber wieder schnell erreichbar:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /your-domain.de/
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /your-domain.de/index.php [L]
</IfModule>
# END WordPress
Anmerkung: In diesem Beispiel wird davon ausgegangen, dass das Blog üblicherweise direkt unter your-domain.de erreichbar ist. Liegt das Blog in einem Unterverzeichnis, so muss dieses natürlich entsprechend angepasst werden.