Je krijgt een SSL-certificaat gratis bij WordPress hostingpakket van Vevida. Zodra jouw hostingpakket is opgeleverd, wordt het SSL-certificaat geïnstalleerd. Hier hoef je zelf niets extra’s voor te doen. In dit artikel leggen we je uit hoe je daarna gebruikmaakt van dat SSL-certificaat om jouw website te beveiligen en de privacy van jouw bezoekers te garanderen. Wil jij meer weten over SSL voor WordPress? Lees dan snel verder.

Als je een WordPress hostingpakket bij Vevida afneemt, dan voeren wij deze handelingen voor jou uit. Registreer je een nieuwe domeinnaam, dan wordt het SSL-certificaat automatisch geïnstalleerd en in WordPress geactiveerd.

Verhuis je een WordPress website naar Vevida? Dan nemen we eerst even contact met je op om te informeren wat precies de bedoeling is. Wil je het SSL-certificaat zelf activeren? Prima. Anders regelen wij dat en hebben wij tijdelijk de adminrechten nodig van jouw WordPress Dashboard.

Wat is SSL en waarom wil ik HTTPS (SSL) voor WordPress?

Door middel van een SSL-certificaat wordt de verbinding tussen twee computers (webserver en bezoeker) versleuteld en dus beveiligd. Hierdoor weten beide computers zeker dat de andere partij ook daadwerkelijk de andere partij is. Het is vrijwel onmogelijk deze verbinding te kapen.

Een SSL-certificaat is dus belangrijk voor de beveiliging: de verbinding is versleuteld, privacy én vertrouwen zijn gewaarborgd. Je weet zeker dat je met jouw doel communiceert. Je leest meer over SSL-certificaten in ons helpartikel SSL-certificaat.

Een SSL-certificaat voor WordPress aanvragen

Zoals gezegd, heb jij een WordPress hostingpakket bij Vevida, dan nemen wij jou al deze zorgen uit handen. Wil je de SSL-instellingen graag zelf instellen? Prima! Je regelt snel en eenvoudig zelf een SSL-certificaat, hiervoor hebben wij de volgende informatie van je nodig:

  • Wat is de hostnaam waarop het certificaat moet draaien? Dus welke URL wil je beveiligd hebben?
  • Waar moet de beveiligde website komen te staan? Vaak is dit de gewone /www map van de website op de server. Als je wilt kunnen wij dit aanpassen, zodat de beveiligde inhoud bijvoorbeeld in een map genaamd /www-secure komt te staan.

Omdat een SSL-certificaat standaard geldt voor twee hostnamen: example.com en www.example.com, adviseren wij het volgende:

  • Vraag een SSL-certificaat aan voor jouw domeinnaam zónder www, dan kun je altijd bepalen welke van de twee vormen je gaat gebruiken. Gebruik slechts één van de twee, dat is makkelijker in het onderhoud en voorkomt dubbele content in Google.

Een SSL-certificaat op een subdomein, bijvoorbeeld voor een webshop op shop.example.com kan uiteraard ook, maar dan kun je dit certificaat niet meer gebruiken op (www.)example.com. Je hebt dan twee aparte websites te onderhouden.

Zodra het certificaat door ons is geïnstalleerd, ontvang je hierover een bericht. Je kunt meteen daarna beginnen met het instellen van de SSL-omgeving in WordPress.

Een beveiligde SSL-omgeving instellen in WordPress

Vóórdat je jouw beveiligde SSL-omgeving in WordPress instelt, is het belangrijk jezelf een aantal belangrijke vragen te stellen:

  1. Wil ik mijn website beschikbaar maken op het adres met of zonder www? Dus https://example.com, of https://www.example.com. Dit is van belang, niet alleen voor jouw WordPress site, maar ook Google Search Console (preferred domain) en eventuele andere externe diensten waarvan je gebruikmaakt.
  2. Maak ik in mijn website-content / blogartikelen gebruik van volledige http-adressen in interne links (links naar artikelen in dezelfde website) of van relatieve links? Als je volledige http-adressen gebruikt in jouw content, bijvoorbeeld <a href=”http://www.example.com/blog/artikel2″>lees meer</a>, dan moet je alle voorkomingen van http overal veranderen in https. Anders krijg je “mixed content” waarschuwingen, en dat wijzigen kan nogal een klus zijn. Gebruik je relatieve URL’s: <a href=”/blog/artikel2″>lees meer</a>, dan hoef je niets te doen.
  3. Hetzelfde als bij vraag 2, maar dan voor afbeeldingen en andere content.
  4. Kunnen thema’s en plugins overweg met SSL-adressen, of zijn hiervoor wijzigingen nodig? Zie ook het kopje “Thema code-aanpassingen“.

Hierna kun je eenvoudig WordPress omzetten naar de SSL-omgeving. In het WordPress Dashboard ga naar Settings > General en wijzig WordPress Address (URL) en Site Address (URL) naar https://.

In het wp-config.php configuratiebestand van WordPress kun je nu opnemen:

define('FORCE_SSL_ADMIN', true);

Hiermee zorg je ervoor dat alle WordPress logins en admin-sessies over SSL verlopen. Je vindt informatie hierover in de WordPress Codex Administration Over SSL.

Veel WordPress thema’s gebruiken intern deze WordPress “site_url” gegevens, andere thema’s ook niet. Heeft jouw thema een eigen options menu, dan vind je daarin vaak ook URL-gegevens terug. Daar moet je deze http-adressen ook nog even aanpassen naar https.

Redirect niet-SSL naar SSL, en niet-www naar www (of andersom)

Nu je een SSL-certificaat met HTTPS-adres voor jouw site hebt ingesteld, wil je natuurlijk graag dat bezoekers hier automatisch op terechtkomen zonder dat zij zelf https:// voor jouw domeinnaam moeten typen. Dat kan gelukkig eenvoudig door het herschrijven van URL’s.

Door URL’s te herschrijven kun je er, op de achtergrond, voor zorgen dat een bezoeker op https:// uitkomt als hij naar http:// gaat. Erg handig!

Wil je hierover meer weten? Kijk dan eens naar onze helpartikelen HTTPS-verbinding voor alle pagina’s, Eigen website voor doorgeschakeld domein en Subdomein een website geven. Deze artikelen geven je wat meer informatie over het principe URL-herschrijven, in het engels: URL Rewrite.

In deze voorbeelden gaan we uit van twee zaken:

  1. We gebruiken altijd HTTPS voor onze website
  2. Onze website is bereikbaar via www.example.com (vervang example.com overal door jouw eigen domeinnaam)

IIS URL Rewrite met web.config

Op onze Windows Server webservers kun je gebruikmaken van het web.config-bestand voor het instellen van de benodigde rewrites. Als je dit bestand via FTP downloadt, en je hebt Permalinks ingeschakeld, dan zie je de volgende standaard rewrites er al staan:


<rewrite>
  <rules>
    <rule name="WordPress: http://www.example.com" patternSyntax="Wildcard">
      <match url="*"/>
      <conditions>
        <add input="{REQUEST_FILENAME}" matchType="IsFile" negate="true"/>
        <add input="{REQUEST_FILENAME}" matchType="IsDirectory" negate="true"/>
      </conditions>
      <action type="Rewrite" url="index.php"/>
    </rule>
  </rules>
</rewrite>

Deze ene rewrite rule matcht op alle URL’s (*), en zolang het request niet gericht is op een bestaand bestand of bestaande map wordt het request doorgestuurd naar het index.php-bestand van WordPress. WordPress heeft namelijk interne logica voor het herschrijven naar mooie Permalinks.

De rewrite regel die we toevoegen (we maken er één aan om HTTP-verkeer naar HTTPS door te sturen, én om niet-www naar www door te sturen – te redirecten), voegen we toe tussen <rules> en <rule name="WordPress: ...">.

Let erop dat elke name van een rule uniek moet zijn.

HTTP naar HTTPS, de nette en juiste manier:
Als je een redirect wilt instellen van jouw HTTP adres naar HTTPS, dan moet je het volgende in het achterhoofd houden: een site die luistert op poort 80 moet alleen redirecten naar dezelfde resource op HTTPS.

In het begin van dit artikel heb je gelezen dat een SSL-certificaat bij Vevida geldt voor jouw domeinnaam mét en zonder www. Dus wil deze bovenstaande richtlijn zeggen: als je het goed wilt doen, dan moet je http://example.com éérst redirecten naar https://example.com, en dan pas naar https://www.example.com. En http://www.example.com kan logischerwijs in één keer door naar https://www.example.com.

Dit staat uitgelegd op Mozilla’s Web Security Guidelines, en schematisch ziet dit er als volgt uit:

http://example.com > 301 > https://example.com
https://example.com > 301 > https://www.example.com
http://www.example.com > 301 > https://www.example.com

Om dit in jouw web.config-bestand te regelen neem je daarin het volgende op:

<rule name="example.com domein naar niet-www https" patternSyntax="ECMAScript" stopProcessing="true">
	<match url="(.*)" ignoreCase="true" />
	<conditions logicalGrouping="MatchAll">
		<add input="{HTTP_HOST}" pattern="^example\.com$" />
		<add input="{HTTPS}" pattern="off" />
		<add input="{URL}" pattern="(.+)" />
	</conditions>
	<action type="Redirect" url="https://example.com/{R:1}" redirectType="Permanent" />
</rule>
<rule name="example.com https niet-www naar www https" patternSyntax="ECMAScript" stopProcessing="true">
	<match url="(.*)" ignoreCase="true" />
	<conditions logicalGrouping="MatchAll">
		<add input="{HTTP_HOST}" pattern="^example\.com$" />
		<add input="{HTTPS}" pattern="on" />
		<add input="{URL}" pattern="(.+)" />
	</conditions>
	<action type="Redirect" url="https://www.example.com/{R:1}" redirectType="Permanent" />
</rule>
<rule name="www.example.com http naar https" patternSyntax="ECMAScript" stopProcessing="true">
	<match url="(.*)" ignoreCase="true" />
	<conditions logicalGrouping="MatchAll">
		<add input="{HTTP_HOST}" pattern="^www\.example\.com$" />
		<add input="{HTTPS}" pattern="off" />
		<add input="{URL}" pattern="(.+)" />
	</conditions>
	<action type="Redirect" url="https://www.example.com/{R:1}" redirectType="Permanent" />
</rule>

Dit ziet er ingewikkeld uit, maar de logica erachter is dat gelukkig niet. Heb je hierover vragen? Neem gerust contact op met onze klantenservice. Wij helpen je graag hiermee.

.htaccess

Je kunt met een .htaccess-bestand hetzelfde bewerkstelligen als met een web.config-bestand. Let er wel op dat je .htaccess– en web.config-bestanden niet gemengd gebruikt. Gebruik de één of de ander.

Heeft jouw website wél een .htaccess-bestand, maar geen web.config? Je ziet dan het volgende in het .htaccess-bestand staan:


  # BEGIN WordPress
  <IfModule mod_rewrite.c>
  RewriteEngine On
  RewriteBase /
  RewriteRule ^index\.php$ - [L]
  RewriteCond %{REQUEST_FILENAME} !-f
  RewriteCond %{REQUEST_FILENAME} !-d
  RewriteRule . /index.php [L]
  </IfModule>
  # END WordPress

Neem volgende op op de regel direct onder RewriteEngine On:


  # http://example.com > 301 > https://example.com
  RewriteCond %{HTTP_HOST} ^example\.com$ [NC]
  RewriteCond %{HTTPS} Off [NC]
  RewriteRule (.*) https://%{HTTP_HOST}/ [L,R=301]

  # https://example.com > 301 > https://www.example.com
  RewriteCond %{HTTP_HOST} ^example\.com$ [NC]
  RewriteCond %{HTTPS} On [NC]
  RewriteRule (.*) https://www.%{HTTP_HOST}/$1 [L,R=301]

  # http://www.example.com > 301 > https://www.example.com
  RewriteCond %{HTTP_HOST} ^www\.example\.com$ [NC]
  RewriteCond %{HTTPS} Off [NC]
  RewriteRule (.*) https://www.%2/$1 [L,R=301]

Nu deze 301 redirects op zijn plek staan, kun je beginnen met het doorvoeren van zogenoemde URL-verhuizingen. Je moet onder andere Google Search Console, Analytics en alle andere online diensten op de hoogte stellen van dit nieuwe HTTPS-adres.

Thema code-aanpassingen

Tip: gebruik altijd een child-theme om wijzigingen te maken!

Soms laadt een thema JavaScript of fonts vanaf externe adressen. Bijvoorbeeld vanaf googleapis.com voor jQuery of een mooi Google font. Een minder goed thema herken je dan vaak aan het feit dat er enkel een http-adres wordt gebruikt in de wp_register_script() functie:

wp_register_script( 'jquery',
  'http://ajax.googleapis.com/ajax/libs/jquery/2.1.4/jquery.min.js', false, '2.1.4', true );

Hierdoor wordt jQuery via een http-adres geladen, wat mixed-content waarschuwingen geeft. Dit soort slechtere code moet vervangen worden door óf https-adressen:

wp_register_script( 'jquery',
  'https://ajax.googleapis.com/ajax/libs/jquery/2.1.4/jquery.min.js', false, '2.1.4', true );

óf een controle op het gebruikte protocol http of https:

$prefix  = is_ssl() ? "https" : "http";
wp_register_script( 'jquery',
  $prefix.'://ajax.googleapis.com/ajax/libs/jquery/2.1.4/jquery.min.js', false, '2.1.4', true );

Altijd HTTPS gebruiken heeft de voorkeur, het geeft geen problemen om vanaf een HTTP-website SSL-content via HTTPS te laden. Andersom dus wel.

“Mixed Content” als HTTP en HTTPS gemengd worden

Bij Vevida bieden wij ondersteuning op het oplossen van zogenoemde mixed content waarschuwingen. Die treden op bij pagina’s waar zowel HTTP als HTTPS bronnen geladen worden. Echter, onze ondersteuning hierop reikt maar zo ver… Sommige thema’s zitten zo ingewikkeld in elkaar dat het ondoenlijk is dit te verhelpen en je kunt dan beter contact opnemen met de makers van dat thema.

Best practice(s) – Geavanceerd, voor als je het écht goed wilt doen

Jij vindt beveiliging, van jouw WordPress website en de privacy van je bezoekers dus belangrijk. Mooi. Je vindt hierom nog een aantal aandachtspunten waaraan je moet denken:

  • Altijd HTTPS gebruiken, voor de gehele WordPress website
  • HTTP Strict-Transport-Security (HSTS) reactieheader inschakelen
  • Andere server HTTP-reactieheaders configureren

Ze worden hieronder verder uitgelegd:

Altijd HTTPS gebruiken

Strikt genomen: als je een SSL-certificaat geïnstalleerd hebt op jouw website, maak dan altijd gebruik van HTTPS-adressen.

HTTP Strict-Transport-Security, HSTS, reactieheader

HTTP Strict Transport Security (HSTS) is een beveiligingsmaatregel die SSL-beveiligde websites beschermt tegen zogenoemde “downgrade aanvallen”. Door het uitvoeren van een “downgrade aanval” kan een kwaadwillende ervoor zorgen dat er van een minder goede beveiliging gebruik wordt gemaakt en zou hij communicatie met de website kunnen afluisteren.

Het is hierom verstandig een HSTS-reactieheader op te nemen. Je doet dit eenvoudig in het web.config-bestand van jouw website. Je vindt meer informatie over wat HSTS is in ons speciale helpartikel HTTP Strict-Transport-Security (HSTS) inschakelen. Hier staat ook uitgelegd hoe je dit in jouw web.config bestand instelt.

Voor WordPress kun je een HTTP Strict-Transport-Security (HSTS) header terugsturen door middel van een stukje PHP-code in jouw thema functions.php bestand. Neem hierin de volgende functie op:

add_action( 'send_headers', 'vevida_add_hsts_header' );
function vevida_add_hsts_header() {
	header( 'Strict-Transport-Security: max-age=31536000; includeSubDomains; preload' );
}

Je vindt informatie over includeSubDomains en preload via eerder genoemd HTTP Strict-Transport-Security (HSTS) inschakelen artikel.

HTTP-reactieheaders

Een HTTP-reactieheader is wat de webserver terugstuurt naar de browser, voordat de content wordt getoond. Een header zie je dus niet altijd, het bevindt zich op de achtergrond. Dat wat de browser – of client – stuurt naar de webserver, heet een verzoekheader (Request header en Response header). Hierin staat veel informatie, soms te veel informatie en je kunt er veel zaken in regelen.

Hierboven heb je al gezien dat je met een HTTP Strict-Transport-Security reactieheader volledige SSL-versleuteling tussen client en server kunt forceren.

Zo is er nog een aantal headers dat aandacht behoeft:

  • X-Content-Type-Options
  • X-Frame-Options
  • X-XSS-Protection
  • Server
  • Content-Security-Policy

Ja, dit is ingewikkeld en geavanceerd (we hadden je gewaarschuwd), maar wij vinden het wél belangrijk dit te benoemen. In het kort uiteraard. Je vindt op de website van het Open Web Application Security Project (OWASP , en speciaal voor WordPress: OWASP WordPress Security Implementation Guideline) belangrijke en handige informatie over deze HTTP-headers. Na de tekstuele uitleg hieronder plaatsen we alle genoemde headers in ons web.config-bestand.

X-Content-Type-Options reactieheader

Als je de HTTP-header X-Content-Type-Options de waarde “nosniff” meegeeft dan houdt dat in dat een browser zoals Internet Explorer, en in sommige gevallen Google Chrome, niet zelf probeert te achterhalen welk type bestand wordt gestuurd. De browser moet uitgaan van het Content-Type dat de website/server terugstuurt.

X-Frame-Options reactieheader

Met X-Frame-Options kun je instellen vanaf welk domein een frame of iframe geladen mag worden. De waarde kan “deny” zijn om het laden van externe frames tegen te gaan, “sameorigin” om alleen frames vanaf hetzelfde domein – of dus jouw website – te tonen, en “allow-from: DOMAIN“, om van een specifiek domein frames te laden. Hierbij moet je DOMAIN dus vervangen door de desbetreffende domeinnaam.

Let op: WordPress zet zelf een X-Frame-Options header. Doe je dit ook met behulp van het web.config-bestand dan conflicteert dat en kun je ongewenst gedrag van jouw WordPress website verwachten. Hierom is de header uitgecommentarieerd in het voorbeeld hieronder, maar wel geplaatst ter illustratie. Je kunt deze header wél zelf plaatsen als je geen WordPress gebruikt en jouw website dit niet zelf doet.

De X-XSS-Protection header schakelt het Cross Site Scripting filter van browser in. Hiermee wordt het moeilijker gemaakt om via de browser Cross Site Scripting (of XSS) aanvallen uit te voeren op websites. Deze XSS-beveiliging staat vaak standaard ingeschakeld in browsers, maar mocht een gebruiker dit hebben gedeactiveerd, kun je het hiermee forceren. Geef het de waarde “1; mode=block” mee.

Server reactieheader

Server reactieheader: Een webserver mag vertellen op welke software hij draait, bijvoorbeeld Windows Server IIS 8.5 of Apache 2.4. Voor aanvallers kan dit heel waardevolle informatie zijn en daarom heeft het de aanbeveling om deze Server: HTTP-reactieheader te legen. Verwijderen kun je de header helaas niet, wel kun je het besturingssysteem of webserver-versie eruit verwijderen, of er zelf iets voor in de plek zetten.

Content-Security-Policy reactieheader

Content-Security-Policy, of CSP, is een heel ingewikkelde header. Hierin moet je precies aangeven welke content wel geladen mag worden op jouw website, en al het andere mag simpelweg niet. Ga je hiermee aan de gang, maak dan veelvuldig gebruik van de Chrome of Firefox hulpprogramma’s console (bereikbaar via de sneltoets F12). Omdat elke website weer anders is kunnen wij helaas geen goed voorbeeld hiervan geven, behalve een klein stukje ter illustratie (LET OP: niet overnemen in jouw website!). Zie http://w3c.github.io/webappsec-csp/ voor alle relevante technische informatie, een beter begrijpbare introductie staat op http://www.html5rocks.com/en/tutorials/security/content-security-policy/.

Hieronder volgen de web.config-voorbeelden die je over kunt nemen in het web.config-bestand van jouw website. Let er te allen tijde op dat je geldige XML-syntaxis gebruikt, het kan zijn dat je zelf de juiste locaties moet vinden of maken in het web.config-bestand om delen van het onderstaande toe te voegen.

Reactieheaders regelen in jouw web.config-bestand

X-Content-Type-Options, X-Frame-Options, X-XSS-Protection: het eerste deel van het voorbeeld is eenvoudig. In de XML node httpProtocol > customHeaders (let op de casing van hoofdletters en kleine letters) kunnen we headers verwijderen en toevoegen. Je doet dit met behulp van de headernaam en de opdracht remove of add.

Het voorbeeld zie je hieronder:

<httpProtocol>
  <customHeaders>
    <add name="X-Content-Type-Options" value="nosniff" />
    <!-- X-Frame-Options is set by WordPress, this one conflicts -->
    <!-- add name="X-Frame-Options" value="deny" / -->
    <add name="X-XSS-Protection" value="1; mode=block" />
    <add name="Content-Security-Policy" value="default-src 'self'; script-src https://cdn.example.com/scripts/; object-src 'none'; plugin-types application/pdf application/x-shockwave-flash;" />
  </customHeaders>
</httpProtocol>
Server: header verwijderen

Helaas valt de Server: reactieheader niet in de categorie customHeaders van httpProtocol in het web.config-bestand. Zoals al geschreven kun je deze header niet verwijderen, maar wel legen. En dat moet met een URL Rewrite outboundRule (een IIS URL Rewrite regel om in de output stream of uitvoerstroom van de webserver wijzigingen aan te brengen. De output stream is de reactie die de server terugstuurt naar de brower, ofwel de reactieheaders + pagina HTML-broncode).

Neem in het web.config-bestand het volgende op:

  <outboundRules rewriteBeforeCache="true">
    <rule name="Remove Server header">
      <match serverVariable="RESPONSE_Server" pattern=".+" />
      <action type="Rewrite" value="" />
    </rule>
  </outboundRules>

en wel ná de afsluiting van de WordPress Permalink rewrites:


    </rule>
  </rules>

maar vóór de afsluitende </rewrite>.

Deze outboundRule zoekt in de uitvoerstroom naar de HTTP-reactieheader “Server:” en herschrijft of vervangt de waarde – bijvoorbeeld – “Microsoft-IIS/8.5″ met niets (value=””). Als je wilt, kun je hierin jouw eigen informatie juist toevoegen, gewoon voor de fun, bijvoorbeeld:

<action type="Rewrite" value="Vevida speedy web server 1.0" />

Meer weten over SSL in WordPress?

Als je na het lezen van dit artikel graag meer informatie wilt over SSL in WordPress, of het WordPress Hosting pakket? Neem gerust contact op met onze klantenservice, wij helpen je graag.

« Terug

Klantenservice

Niet gevonden wat je zocht? Neem contact op met onze klantenservice:

We zijn je graag van dienst.