WordPress auf SSL umstellen

Blog­ger, die ihren Blog selbst hos­ten, sehen sich irgend­wann mit dem The­ma SSL kon­fron­tiert. Such­ma­schi­nen bevor­zu­gen Sei­ten, die ver­schlüs­selt sind und die neue Daten­schutz­ver­ord­nung ver­langt eine siche­re Ver­bin­dung, wenn Kun­den­da­ten über­tra­gen wer­den, wie zum Bei­spiel eine Mail­adres­se in den Kom­men­ta­ren. Nicht zuletzt wer­den ver­schlüs­sel­te Sei­ten von Brow­sern schnel­ler über­tra­gen und die Surf­ge­schwin­dig­keit erhöht.

Ein SSL-Zer­ti­fi­kat kos­tet aber lei­der deut­lich mehr als die Domain und der Web­space. In mei­nem Fall ist der Pro­vi­der Host­eu­ro­pe und ein SSL-Zer­ti­fi­kat kos­tet mal eben das Dop­pel­te wie Domain und Web­space. Das Geld möch­te ich lie­ber in Bücher oder ande­re Soft­ware aus­ge­ben und grei­fe zur kos­ten­frei­en Vari­an­te.

Ehr­lich gesagt sind die meis­ten Anlei­tun­gen im Netz, die mir begeg­net sind, wenig hilf­reich, weil nicht im Detail erklärt wird, wie ich einen Word­Press-Blog auf SSL umstel­le. Gera­de bei der Erstel­lung des SSL-Zer­ti­fi­kats bin ich immer wie­der hän­gen­ge­blie­ben, weil nicht erklärt wur­de, wel­che Datei ich nun wohin kopie­ren soll.

Des­we­gen kommt hier nun eine wei­te­re Anlei­tung, wie ein Word­Press-Blog auf SSL umge­stellt wer­den kann.

Kostenfreies SSL-Zertifikat

Da gibt es im Grun­de genom­men ledig­lich einen Anbie­ter, näm­lich Lets Encrypt, der ein kos­ten­frei­es Zer­ti­fi­kat mit einer Gül­tig­keit von 90 Tagen zur Ver­fü­gung stellt. Wer denkt, er bräuch­te nur auf die Home­page gehen, um sich dort ein Zer­ti­fi­kat her­un­ter­zu­la­den, der sieht sich mit vie­len mehr oder weni­ger kryp­ti­schen Anlei­tun­gen kon­fron­tiert, die selbst die Blog­ger über­for­dern, die schon etwas län­ger dabei sind.

Aber es gibt eine Lösung. Min­des­tens zwei Web­sei­ten habe ich gefun­den, auf denen man sich etwas ein­fa­cher und beque­mer ein SSL-Zer­ti­fi­kat erstel­len las­sen kann. Auf zerossl fin­de ich den Weg zum Zer­ti­fi­kat etwas müh­sa­mer, so dass ich hier den Weg von sslfor­free zei­ge.

Das erstell­te Zer­ti­fi­kat ist für drei Mona­te gül­tig, so dass man die Pro­ze­dur vier Mal im Jahr durch­füh­ren muss. Ich den­ke, dass die­ser Auf­wand die recht hohen Kos­ten der alter­na­ti­ven SSL-Zer­ti­fi­ka­te durch­aus recht­fer­tigt.

Schritt für Schritt Anleitung

Für die Erstel­lung des SSL-Zer­ti­fi­kats muss der Brow­ser Chro­me oder Fire­fox ver­wen­det wer­den, da mit ande­ren Brow­sern eine Feh­ler­mel­dung bei der Erstel­lung des Zer­ti­fi­kats erscheint!

Zuerst muss man auf der Sei­te sslforfree.com sei­ne Domain und Sub­do­mains ange­ben (also fl‑e.de und nicht http://fl‑e.de) und klickt auf »Crea­te Free SSL Cer­ti­fi­ca­te«.

Es soll wohl auch mit Wild­cards funk­tio­nie­ren (also Stern­chen, so dass alle Sub­do­mains mit erfasst wer­den), aber bei mir blieb der Ver­such erfolg­los, so dass ich zwei Domains ein­ge­tra­gen habe. In mei­nem Fall hät­te der Ein­trag »*.fl‑e.de fl‑e.de« zum Erfolg füh­ren sol­len. Ich weiß nicht so recht, was schief gelau­fen ist.

Im nächs­ten Schritt ste­hen dem User drei Mög­lich­kei­ten zur Ver­fü­gung, wie er die Veri­fi­zie­rung durch­füh­ren kann.

• Die auto­ma­ti­sche Veri­fi­zie­rung (»Auto­ma­tic FTP Veri­fi­ca­ti­on«) funk­tio­niert nur dann, wenn die Web­site im ftp-Ver­zeich­nis des Pro­vi­ders nicht in Unter­ver­zeich­nis­sen liegt.
• Die manu­el­le Veri­fi­ka­ti­on (»Manu­al Veri­fi­ca­ti­on (DNS)«) über einen DNS-Ein­trag kann rela­tiv lang­wie­rig sein, weil die Ände­run­gen in den DNS-Ein­trä­gen erst nach ein oder zwei Tagen von den Pro­vi­dern umge­setzt wer­den.
• Des­halb emp­feh­le ich die Nut­zung der manu­el­len Veri­fi­ka­ti­on mit­tels Datei­en (»Manu­al Veri­fi­ca­ti­on«).

Anschlie­ßend wird unter­halb eine kur­ze Anlei­tung ein­ge­blen­det mit Hin­wei­sen dar­über, wel­che Ports offen sein müs­sen. Mit einem Klick auf »Manu­al­ly Veri­fy Domain« geht es wei­ter.

1. Nun müs­sen ein oder meh­re­re Down­load-Files her­un­ter­ge­la­den wer­den. Pro ange­ge­be­ner Domain wird eine Datei ange­ge­ben. Bei die­sen Datei­en han­delt es sich um Text­schnip­sel ohne Inhalt.
2. In den Pfa­den der ange­ge­be­nen Domains muss auf der obers­ten Level­ebe­ne die Ord­ner ».well-known/ac­me-chall­enge« ange­legt wer­den. Dafür ver­wen­det man ein­fach ein ftp-Pro­gramm (mit dem der Blog­ger auch die Wrd­press-Files hoch­ge­la­den hat).
3. In die­sen Ord­ner legt man die eben her­un­ter­ge­la­de­nen Datei­en.
4. Durch einen Klick auf die ange­zeig­ten Links (im Unter­punkt 5.) soll­te der Upload getes­tet wer­den. Kommt eine Feh­ler­mel­dung, ist etwas falsch gelau­fen und man soll­te die Ord­ner­struk­tur und die Datei­na­men prü­fen. Wird die kryp­ti­schen Zei­chen­fol­ge ange­zeigt, ist alles okay.
5. Nun kön­nen die Zer­ti­fi­ka­te mit einem Klick auf »Down­load SSL Cer­ti­fi­ca­te« erstellt und her­un­ter­ge­la­den wer­den.
6. Bei mir kam es hin und wie­der zu einem “Timeout”-Fehler. In die­sem Fall haben die Ser­ver zu lan­ge gebraucht, um zu ant­wor­ten. Dann im Brow­ser die Sei­te neu laden (und auf Daten erneut sen­den kli­cken).
7. Es emp­fiehlt sich, ein Benut­zer­kon­to anzu­le­gen, damit eine Ver­län­ge­rung bzw. eine Erneue­rung des Zer­ti­fi­kats ein­fa­cher von der Hand geht.

Nun hat man drei Datei­en:

1. ca_bundle.crt
2. certificate.crt
3. private.key

Falls dies nicht funk­tio­niert, soll­te noch­mals geprüft wer­den, wel­cher Brow­ser ver­wen­det wird. Die Erstel­lung des SSL-Zer­ti­fi­kats funk­tio­niert nur mit Chro­me oder Fire­fox! Bei ande­ren Brow­sern erscheint eine Feh­ler­mel­dung.

Bei einer Ver­län­ge­rung des Zer­ti­fi­kats wird genau der glei­che Weg gegan­gen. Hat man ein Benut­zer­kon­to ange­legt, muss man ledig­lich auf “Renew” kli­cken und man gelangt genau zu den oben gezeig­ten Fens­tern. Die Pro­ze­dur bleibt iden­tisch.

Die­se Datei­en müs­sen nun manu­ell hoch­ge­la­den wer­den. Wie das funk­tio­niert ist natür­lich vom Pro­vi­der abhän­gig. Für gewöhn­lich gibt es mitt­ler­wei­le für jeden Pro­vi­der eine Anlei­tung, wie dies funk­tio­niert. Ich zei­ge die Vor­ge­hens­wei­se anhand des KIS (Kun­den­in­for­ma­ti­ons­sys­tem) von Host­eu­ro­pe.

---

---

Hochladen des Zertifikats

Nach dem erfolg­rei­chen Erstel­len des Zer­ti­fi­kats müs­sen nun drei Datei­en vor­lie­gen, die nun beim Pro­vi­der hoch­ge­la­den wer­den. Ich zei­ge es hier am Bei­spiel von Host­eu­ro­pe, wobei das Pro­ze­de­re bei den Pro­vi­dern ähn­lich ist.

Zuerst loggt man sich im KIS von Host­eu­ro­pe ein und wech­selt zum Web­hos­ting. Dort fin­det sich der Menü­punkt »Sicherheit&SSL« mit dem Unter­punkt »SSL admi­nis­trie­ren«.

Nun muss auf »Zuwei­sen« oder wie auf dem Screen­shot zu sehen »Erset­zen« geklickt wer­den (falls schon ein Zer­ti­fi­kat hoch­ge­la­den wur­de). In bei­den Fäl­len öff­net sich die glei­che Ein­ga­be­mas­ke.

In die­ser Mas­ke muss mit einem Klick auf »Datei aus­wäh­len« hin­ter »Zer­ti­fi­kat« die Datei »certificate.crt« aus­ge­wählt wer­den und mit einem Klick auf »Datei aus­wäh­len« hin­ter »Key« die Datei »private.key«. In mei­nem Fall muss­te ich noch die Datei »ca_bundle.crt« hoch­la­den, damit das SSL-Zer­ti­fi­kat von allen Diens­ten akzep­tiert wur­de. Wenn ich das rich­tig ver­stan­den habe, wird mit die­ser Datei die Zer­ti­fi­zie­rungs­stel­le ange­ge­ben. Mit einem Klick auf »Absen­den« wird das Zer­ti­fi­kat hoch­ge­la­den.

Es kann bis zu 48 Stun­den dau­ern, bis das Zer­ti­fi­kat funk­tio­niert. Bei ande­ren Pro­vi­dern muss nun zusätz­lich bei den Domains die SSL-Ver­bin­dung akti­viert wer­den. Bei Host­eu­ro­pe ist dies nicht der Fall und das glo­ba­le Zer­ti­fi­kat wird auto­ma­tisch allen Domains zuge­wie­sen.

Ob es funk­tio­niert erkennt man dar­an, dass die Sei­te über https erreich­bar ist. Es sind nach dem Upload also bei­de Vari­an­ten aktiv – sowohl http als auch https. Das wird nun für die Dau­er der Umstel­lung auch so blei­ben und ist nicht wei­ter tra­gisch, auch wenn das bedeu­tet, dass die Sei­te im Goog­le-Ran­king kurz­fris­tig sinkt.

Kei­ne Sor­ge: Am Ende der Umstel­lung wird der Blog nur noch über die siche­re Ver­bin­dung erreich­bar sein. Dafür wird die .htac­cess-Datei modi­fi­ziert, was aller­dings der aller­letz­te Schritt bei der SSL-Umstel­lung ist.

Backup des Blogs

Es emp­fiehlt sich auch unab­hän­gig von der SSL-Umstel­lung ein regel­mä­ßi­ges Back­up des Blogs durch­zu­füh­ren. Ich per­sön­lich nut­ze dafür das Plug­in Updraft­Plus Backup/Restore und las­se die Back­ups in einer Cloud spei­chern. Das geschieht bei mir in regel­mä­ßi­gen Abstän­den. Vor der SSL-Umstel­lung emp­fiehlt es sich, ein fri­sches Back­up durch­zu­füh­ren.

Wie sinn­voll die­ser Tipp ist, hat sich bei mei­ner Umstel­lung gezeigt, denn ich habe mir bei­de Blogs zer­schos­sen und konn­te die­se nur durch die Back­ups wie­der­her­stel­len. Was genau pas­siert ist, ver­mag ich gar nicht mal zu sagen – auf ein­mal war der eine Blog gar nicht mehr sicht­bar, beim ande­ren kam ich nicht mehr ins Backend.

Es half nur, die Daten­bank und die Datei­en auf den Ser­vern zu löschen, Word­Press neu zu instal­lie­ren und das Back­up wie­der ein­zu­spie­len.

Also noch­mals die drin­gen­de Emp­feh­lung, vor der Umstel­lung des Blogs, ein Back­up zu erstel­len!

Blog auf https umstellen

Im Backend des Blogs unter »Ein­stel­lun­gen« – »All­ge­mein« die URL von http nach https umstel­len.

Nun wer­den alle Besu­cher des Blogs zur siche­ren Sei­te umge­lei­tet, was kein Pro­blem dar­stellt, da sowohl die siche­re als auch die unsi­che­re Ver­si­on des Blogs aktiv ist. Wer in die­ser Pha­se auf den Blog zugreift, bekommt eine Feh­ler­mel­dung, dass unsi­che­re Ele­men­te vor­han­den sind (o.ä.), die im nächs­ten Schritt eli­mi­niert wer­den.

Wer an die­ser Stel­le einen Feh­ler gemacht hat, der Blog noch nicht über die siche­re Ver­bin­dung erreich­bar ist oder man sich schlicht­weg ver­tippt hat, dem kann gehol­fen wer­den. Im nächs­ten Abschnitt zei­ge ich wie. Alle ande­ren kön­nen sich nun den unsi­che­ren Ele­men­ten des Blogs küm­mern.

Dafür wird das Plug­in »Bet­ter Search Replace« ver­wen­det, das recht zuver­läs­sig die Daten­ban­ken nach den ent­spre­chen­den Ein­trä­gen durch­sucht und ersetzt. Es wird gesucht nach den http-Links die durch das https-Pen­dand ersetzt wer­den. Dabei müs­sen alle Tabel­len mar­kiert sein und der Haken bei Test­lauf ent­fernt wer­den.

Die­ser Schritt soll­te nur dann durch­ge­führt wer­den, wenn ein Back­up erstellt wur­de!

 

Damit ist die Umstel­lung fast fer­tig. Bevor ich auf die Ände­rung in der .htac­cess-Datei kom­me, ein kur­zer Hin­weis zur URL-Umstel­lung.

 

URL zu früh oder falsch umgestellt

Ja, das ist mir dann tat­säch­lich pas­siert. Ich habe die URL im Blog schon auf https umge­stellt, das Zer­ti­fi­kat wur­de vom Hos­ter aber noch nicht bereit­ge­stellt. Die­se Umstel­lung kann bis zu 48 Stun­den dau­ern. Auch Tipp­feh­ler schlei­chen sich schon mal ger­ne ein, so dass der Blog anschlie­ßend nicht mehr erreich­bar ist. Der User kann sich also nicht mehr in sei­nen Blog ein­log­gen, weil er dau­ernd auf die https-Ver­si­on des Blogs umge­lei­tet wird, die ja nicht funk­tio­niert oder eben zu dem Link mit dem Tipp­feh­ler.

Der User braucht aber nur kurz ver­zwei­feln, denn es gibt eine Lösung. Man kann die URL des Blogs näm­lich in der Datei wp-config.php hän­disch fest­le­gen. Dafür muss über ein ftp-Pro­gramm die­se Datei auf den hei­mi­schen Rech­ner her­un­ter­ge­la­den wer­den und mit einem Text­edi­tor geöff­net wer­den.

Unter kei­nen Umstän­den darf ein Text­ver­ar­bei­tungs­pro­gramm wie Micro­soft Word ver­wen­det wer­den, da die­se Pro­gram­me ihren eige­nen Code in die Datei schrei­ben!

In der Datei sucht man die Zei­le

/* That’s all, stop editing! Hap­py blog­ging. */

Dar­über muss fol­gen­der Code ein­ge­fügt wer­den

/* Cus­tom Word­Press URL. */
defi­ne( ‘WP_SITEURL’, ‘https://fl‑e.de’ );
defi­ne( ‘WP_HOME’, ‘https://fl‑e.de’ );

Selbst­ver­ständ­lich muss die eige­ne URL an der ent­spre­chen­den Stel­le ein­ge­fügt wer­den. Mit die­sem Ein­trag ist der Blog nun wie­der erreich­bar. Gleich­zei­tig ist eine Umstel­lung der URL in den Ein­stel­lun­gen des Blogs nicht mehr mög­lich. Die Fel­der sind nun aus­ge­graut. Dies ist ein rela­tiv siche­rer Schutz gegen ver­se­hent­li­ches Ändern der URL.

.htaccess anpassen

Hier lag einer der gröbs­ten Schnit­zer in den Anlei­tun­gen, die ich im Netz gefun­den hat­te. Nie wäre ich auf die Idee gekom­men, dass in die­sem Code der Feh­ler gele­gen haben könn­te, weil die­ser von mei­nem Pro­vi­der (feh­ler­haft) ange­ge­ben wur­de. Das führ­te schluss­end­lich dazu, dass ich mei­ne Blogs zer­schos­sen hat­te, so dass die­se nicht mehr erreich­bar waren und ich die­se aus den Back­ups zurück­spie­len muss­te.

Wozu das Gan­ze? Es exis­tie­ren im Netz unzäh­li­ge Links auf den Blog, aber noch mit der http-Adres­se. Damit die­se auf die ent­spre­chen­de https-Vari­an­te umge­lei­tet wer­den, bedarf es einen Code. Bei mei­nen Blogs muss­te der Code am Anfang (und nicht am Ende!) der Datei ein­ge­tra­gen wer­den. Außer­dem funk­tio­nier­te er nur in der Form, wie ich ihn hier zitie­re. Im Netz gibt es ande­re For­men des Codes, die nur schein­bar iden­tisch sind. Denn manch­mal fehlt ein Satz­zei­chen, das ent­schei­dend sein kann.

Rewri­teEn­gi­ne On
Rewri­te­Cond %{HTTPS} !=on
Rewri­te­Rule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Die­se Anpas­sung ist zwin­gend not­wen­dig und soll­te ganz zum Schluss erfol­gen.

Damit ist die Umstel­lung des Blogs auf https fer­tig­ge­stellt und die­ser soll­te nur noch über die siche­re Ver­bin­dung erreich­bar sein, auch wenn die unsi­che­re http-URL in die Adress­leis­te des Brow­sers ein­ge­ge­ben wird.

 

---