Het technische verhaal achter gratis SSL!

Afgelopen maanden hebben we achter de schermen aan iets heel gaafs gewerkt. Iets waar we al een lange tijd naar uit hebben gekeken en waar veel technische aanpassingen voor nodig waren. Het heeft ons meer dan slechts tijd en geld gekost, maar het was het dubbel en dwars waard. Dinsdag was het dan eindelijk zover: gratis SSL voor iedereen!

Gratis SSL en HTTP/2 voor iedereen, het technische verhaal

Hoe komt zoiets tot stand? In dit artikel ga ik jullie uitgebreid vertellen over onze implementatie, waarom we het op deze manier hebben aangepakt en wat de uitdagingen waren die we onderweg tegenkwamen.

Inhoudsopgave

1. Waarom gratis SSL?

De laatste jaren worden we steeds vaker wakker geschud door alarmerende berichten over afluisterpraktijken door overheden en criminelen. Cyberaanvallen worden steeds geavanceerder en de aanvallers beschikken over steeds meer middelen. Als serieuze hostingprovider kun je absoluut niet achterblijven in deze race.

Wij vinden dat privédata privé moet blijven. Het is goed om te zien dat er wettelijk steeds meer regels komen voor het beveiligen van persoonsgegevens en we zijn hierin graag een helpende hand. Vanaf afgelopen dinsdag hebben daarom alle websites die bij ons gehost worden een SSL-certificaat. Dus een nog hogere mate van basisbeveiliging, voor iedereen. En dat ook nog eens volledig gratis!

1.1 Feedback bètatest

Eind vorig jaar zijn we begonnen met een bèta, waarbij onze klanten zelf Let’s Encrypt konden activeren om websites gratis te beveiligen met een SSL-certificaat. We hebben deze functionaliteit geïmplementeerd, omdat we er regelmatig vragen over kregen en het initiatief al langer in de gaten hielden.

We wisten dat Let’s Encrypt een gewilde feature was, maar dat de populariteit ervan in korte tijd zo zou groeien, heeft ons behoorlijk verbaasd! Niet alleen de diehard techneuten gingen ermee aan de slag, maar ook gebruikers met variërende technische skills.

Gedurende de bèta kwamen een aantal uitdagingen, kleine bugs en tekortkomingen aan het licht, waarvan we overigens de meesten snel op konden lossen. Naast de waardevolle feedback van onze klanten, begonnen er tegelijk hier intern vragen te spelen als:

  • Waarom staat dit niet gewoon voor alles altijd aan?
  • Waarom is dit iets wat je per domein aan moet zetten?
  • Zou anno 2017 HTTPS niet gewoon de standaard moeten zijn?

2. Waarom niet de ‘super easy’ DirectAdmin-plugin?

Voordat we begonnen met het aanbieden van ondersteuning voor Let’s Encrypt als bètatest, kregen we van een aantal van onze trouwe klanten de volgende vraag: ‘Let’s Encrypt, dat zit toch gewoon in DirectAdmin? Dan kun je het toch ook eenvoudig aanzetten? Andere partijen bieden het ook zo aan.’

Ze hebben goed onderzoek gedaan op het internet: DirectAdmin heeft hiervoor inderdaad een plugin. Ook veel van onze concullega’s maken daar gebruik van. Toch voelden we er niet veel voor om deze plugin op ons platform te gaan gebruiken. Ik zal je zo goed mogelijk proberen uit te leggen waarom we dit niet hebben gedaan.

2.1 Security zou niet optioneel moeten zijn

Niet iedereen die een website beheert, weet alles op van het gebied van beveiliging. En dat vinden we ook niet meer dan normaal. We vinden dat we niet van al onze klanten kunnen verwachten dat ze weten wat een SSL-certificaat is, wat je ermee kunt, waarvoor het nodig is, en wat de Nederlandse wetgeving hierover zegt.

Met het implementeren van de DirectAdmin-plugin is het alsnog aan de klant om per account, per domein en per subdomein dit in of uit te schakelen. Hadden we voor de plugin gekozen, dan had dat er waarschijnlijk toe geleid dat de techneuten een SSL-certificaat zouden installeren, maar dat het grootste deel van de huis-tuin-en-keukengebruikers er niets mee zou doen. Zonde, want de hele filosofie achter Let’s Encrypt is dat alle websites SSL zouden moeten kunnen gebruiken.

2.2 We houden van eenvoud voor iedereen

Naast dat je moet weten wat SSL is en waarom het belangrijk is, moet je ook nog maar net de vaardigheden (of zin) hebben om ermee aan de slag te gaan. Bij de DirectAdmin-plugin moet je een heel formulier invullen, voordat de SSL-aanvraag kan worden verwerkt. Vreemd, want deze gegevens zijn helemaal niet nodig voor Let’s Encrypt, er wordt ook niets mee gedaan.

Het leven is complex genoeg, de hele dag door worden er al vraagstukken die keuzes vereisen op ons afgevuurd. We willen onze klanten ontzorgen, niet opzadelen met nog meer vragen, wanneer ze alleen maar een ‘groen slotje’ willen. Vragen om gegevens waar vervolgens niets mee wordt gedaan, past niet in die filosofie.

Het groene slotje inde adresbalk

We houden niet van onnodige complexiteit. In onze ogen is het vragen om welke domeinen, subdomeinen, aliassen en pointers je met SSL wil voorzien hetzelfde als vragen of je jouw mooie gloednieuwe auto graag met één band wilt of met vier. Doe maar vier.

Er is geen enkel valide argument te verzinnen om je website niet via een beveiligde verbinding beschikbaar te stellen. De functie binnen DirectAdmin vraagt je alsnog voor welke domeinen je het in wilt schakelen. Het is gratis. Beveilig gewoon alles en stel me geen vragen. Klaar.

Ter kennisneming
In een vergelijkend warenonderzoek kwamen we handleidingen tegen van wel twaalf (!) stappen. Dat is iets wat we met onze implementatie wilden voorkomen, eenvoud was het streven.

2.3 Technische limitaties

Naast dat het gebruiksgemak van de plugin van DirectAdmin niet aan onze standaard voldeed, voorzagen we ook een aantal technische limitaties bij het gebruik ervan. Zoals de meeste webhosters gebruiken we Apache als webserver, dat werkt het best met de meeste applicaties. Het valideren en het inladen van configuratiebestanden kost Apache al snel enkele seconden, wanneer je op onze schaal werkt.

Wanneer je elke website dan ook nog een SSL-configuratie gaat geven, dan loopt de tijd die hiervoor nodig is erg hard op. Gedurende deze tijd is de webserver minder of niet bereikbaar. We hebben tests gedaan door het inladen van een SSL-configuratie voor elke website, naast de normale ‘onbeveiligde’ configuratie. De tijd die nodig was om een nieuwe configuratie te laden, ging minimaal keer vier.

Hierbij komt ook nog eens dat Apache bij een reload eerst het oude webserverproces stopt, dan pas de nieuwe configuratie gaat inlezen en, wanneer hij hiermee klaar is, dan pas weer beschikbaar is om requests te verwerken. Bij elke configuratiewijziging is zo’n reload nodig. Met het toevoegen en onderhouden van SSL-certificaten komen er alleen maar meer wijzigingen bij, en dus meer reloads. Daarnaast nemen de reloads dus ook nog meer tijd in beslag.

Ter kennisneming
Wist je dat Apache maar één certificaat per website kan inladen en dat Let’s Encrypt een maximum heeft van 100 (sub)domeinen per certificaat? Het is niet ongebruikelijk dat een Apache vhost bereikbaar is onder meer dan 100 alternatieve domeinen.

2.4 Geen standaard DirectAdmin-setup

Zoals je misschien wel eens ergens hebt gelezen, draaien we niet een standaard DirectAdmin-setup. We hebben deze door de jaren behoorlijk op de schop genomen om meer beschikbaarheid, security, performance, stabiliteit en features te kunnen bieden.

Langzaam maar zeker is het platform af gaan wijken van de ‘vanilla’ DirectAdmin-setup. We hebben bijvoorbeeld geen CustomBuild en installeren al onze software vanuit standaard RPM’s. Wanneer we de DirectAdmin-plugin zouden gaan gebruiken, dan zouden we hier alsnog aanpassingen aan moeten doen om het goed met ons gehele platform te laten samenwerken.

2.5 Business continuïteit en monitoring

We houden er bij Antagonist niet van dat iets ineens ‘magisch’ werkt. We willen weten waarom iets wel of niet werkt, hierop kunnen monitoren en op anticiperen wanneer dit nodig is. Dus actie ondernemen, voordat het misgaat in plaats van erna. Wij bepalen wat er wel en niet op ons platform draait. Geen zwarte magie.

Bij het gebruik van de plugin geef je een groot deel van de controle over een vitaal onderdeel van je platform uit handen. Wij hebben liever zelf de touwtjes in handen en zijn het liefst zo min mogelijk afhankelijk van derden. Blind vertrouwen op een extern script is een grote no-no bij ons.

Ter kennisneming
Wist je trouwens dat de DirectAdmin-plugin al eens een bug heeft gehad, waardoor certificaten niet verlengd werden? Bugs blijf je houden met software, maar het is wel heel erg fijn, als je ze zelf snel kan signaleren, kan oplossen en niet hoeft te wachten op een softwareupdate van je leverancier. Touwtjes – handen – check.

3. Eigen implementatie, veel meer mogelijkheden

Zoals je misschien ondertussen al door hebt, hebben we onze eigen Let’s Encrypt-implementatie geschreven. Die biedt meer functionaliteit. Als kers op de taart kunnen we ook nog eens in een lekker tempo nieuwe features en verbeteringen toevoegen, dus kom maar op met die feature requests!

Een paar voorbeelden van concrete verbeteringen die wij hebben gemaakt ten opzichte van de standaardoplossing:

  • iedereen heeft een SSL-certificaat;
  • we kunnen HTTP/2 aanbieden en doen dit dus ook;
  • we kunnen meerdere certificaten per website inladen;
  • geen verrassingen door wijzigingen in software van en door derden;
  • volledige controle en monitoring op het verlengen van certificaten;
  • je kunt alsnog je eigen certificaat installeren via DirectAdmin;
  • ons platform geeft eigen certificaten voorrang, zolang ze geldig zijn;
  • geen Apache reload meer nodig bij elke wijziging aan een certificaat;
  • SSL-offloading doen we in HAProxy, reloads gaan hierdoor hitless.

3.1 Onze implementatie

Hopelijk heb ik je inmiddels uit kunnen leggen waarom we niet voor de gemakkelijke weg gekozen hebben. Goed, we duiken nu in hoe wij elke website hebben voorzien van gratis SSL, wat de hobbels waren die we onderweg tegenkwamen en hoe we deze hebben opgelost.

3.1.1 SSL-offloading proxy

Zoals ik eerder in dit artikel al aangaf, voelden we er niet veel voor om de certificaten van alle websites in Apache te laden. Reload times van Apache gaan minimaal keer vier. Apache gaat nog meer RAM gebruiken, er worden meer reloads gedaan (die ook nog eens trager zijn) en je hebt de limitatie van één certificaat per website.

Dit zorgde ervoor dat we gingen onderzoeken of we niet alle certificaten in een proxyserver die voor Apache draait konden inladen. Dit, zodat we de SSL-afhandeling niet meer door Apache hoefden te laten doen. Eerst viel ons oog op Hitch, de SSL-terminator die in leven is geroepen door het gebrek van SSL in Varnish.

Het is een simpel programma, zonder onnodige complexiteit. Echter, bij een proof of concept zagen we dat Hitch twee gebreken heeft:

  1. het heeft relatief veel RAM nodig;
  2. nog erger, het ondersteunt maar één backend.

We hebben op onze servers meerdere IP-adressen voor Apache, hiervoor moet je dus meerdere backends kunnen configureren in je TLS-terminator. En één Hitch serverproces per IP-adres zagen we niet zitten. Het is niet mooi genoeg, te complex en vragen om problemen.

3.1.2 HAProxy

Vervolgens viel ons oog op HAProxy. Dat we daar niet eerder aan hadden gedacht! HAProxy kan namelijk alles wat we willen:

  • ondersteuning voor HTTP/2;
  • Proxy Protocol v2 wordt ondersteund;
  • ondersteuning voor meerdere backends;
  • hitless reloads, dus geen downtime bij configuratiewijzigingen;
  • lage memory footprint (1000 certificaten serveren met 77 MB RAM).

Dat we HAProxy zouden gaan gebruiken, was daarom een no-brainer. Of toch niet? Tijdens de implementatie en het grondig testen, kwamen we er namelijk achter dat HTTP/2 toch niet helemaal lekker werkt. Hoe komt dit?

RedHat/CentOS en aanverwante besturingssystemen hebben een te oude OpenSSL-versie, waardoor ALPN niet werkt. Hierdoor kunnen de server en client niet samen besluiten of er HTTP/2 gebruikt kan worden. We hebben dit opgelost door onze eigen HAProxy package te bouwen, waarin een nieuwe versie van OpenSSL statisch gelinkt is. HAProxy gebruikt op deze manier niet de OpenSSL van het besturingssysteem.

3.2 Aanpassingen in Apache

Een SSL-terminator voor Apache zorgt er weliswaar voor dat deze de SSL-encryptie afhandelt, maar daarmee werkt niet zomaar alles out-of-the-box. Wanneer je niet de nodige wijzigingen in Apache aanbrengt, dan ga je heel bijzondere problemen krijgen.

Voor Apache ziet een aanvraag die binnenkomt er namelijk uit alsof hij van HAProxy komt. Dit klopt in theorie ook, maar hiermee is het onbekend wie de daadwerkelijke bezoeker van je website is. Logfiles kloppen niet meer, PHP heeft geen kennis van het IP van de bezoeker, access control op basis van IP’s is stuk en ga zo maar door.

3.2.1 Proxy Protocol

Er zijn een aantal methodes mogelijk om deze problemen op te lossen. De meest moderne is het gebruik van het Proxy Procotol. Simpel gezegd, komt het erop neer dat HAProxy een stukje Proxy Protocol-informatie voor de payload (de volledige HTTP request) zet, voordat de aanvraag naar de backend (Apache) gestuurd wordt. Aan deze informatie kan Apache herkennen wat bijvoorbeeld de echte bezoeker van de website is.

HAProxy praat het Proxy Protocol, Apache doet dat echter standaard niet. Deze functionaliteit komt pas beschikbaar in mod_remoteip vanaf versie 2.4.26. We hebben specifiek deze functionaliteit uit een toekomstige release moeten pakken en Apache hiermee moeten rebuilden.

Dit was echter niet voldoende om alles werkend te krijgen. Binnenin Apache zijn er namelijk een aantal environment-variabelen waaraan Apache en, misschien nog wel belangrijker, PHP kan herkennen of een verbinding over SSL of onbeveiligd binnen is gekomen.

3.2.2 Aanpassingen in mod_remoteip

Stel je voor, je neemt in je .htaccess op dat alle gewone HTTP-verbindingen een redirect moeten krijgen naar HTTPS. Je browser ontvangt deze redirect en gaat vervolgens naar de locatie met HTTPS.

Vervolgens herkent Apache (of PHP) niet dat deze verbinding via SSL is binnengekomen en verstuurt weer een redirect response naar de browser. Je komt hiermee in een oneindige loop terecht, totdat de server of browser ermee kapt.

Voor dit probleem zijn geen kant en klare oplossingen, mod_remoteip doet namelijk niet aan eventuele SSL-flags die gezet worden binnen het Proxy Protocol. We hebben hiervoor zelf een aantal aanpassingen in de mod_remoteip-module van Apache moeten maken.

Ter kennisneming
Overigens gaat het Apache webserver project deze aanpassingen waarschijnlijk meenemen in een toekomstige versie. Alle SSL-gerelateerde variabelen kloppen binnen Apache dus bij ons. Dit zorgt voor een vlekkeloze werking van je website. Jij als eigenaar hoeft dus geen speciale aanpassingen te maken, omdat wij ons platform transparant hebben aangepast.

3.3 Aanpassingen in DirectAdmin

We hebben nu in hoofdlijnen duidelijk dat we een SSL-terminator voor Apache hebben gezet om de SSL-afhandeling te verzorgen. Maar hoe werkt dit, wanneer je een eigen certificaat hebt? Deze worden namelijk in DirectAdmin gezet, die op zijn beurt ze weer in de configuratie van Apache opneemt. Je kunt je voorstellen dat dit twee methodes zijn, die elkaar nogal in de weg staan. Het is het één of het ander, niet beide.

We hebben dit opgelost door het onderdeel dat verantwoordelijk is voor het schrijven van Apache-configuraties te vervangen door een eigen configwriter. Wordt er een wijziging gemaakt aan de Apache configuratie binnen DirectAdmin, dan wordt er een hook aangeroepen die onze configwriter triggert.

Onze configwriter kijkt naar de configuratie van de website, zoals die binnen DirectAdmin gedefinieerd is, en genereert een alternatieve, losstaande configuratie. Deze laden we in Apache en de door DirectAdmin-gegenereerde configuratie gaat naar /dev/null. Op deze manier kunnen we de SSL-logica uit Apache halen en tegelijk in HAProxy transparant implementeren.

3.3.1 Voordelen

Dit brengt een aantal belangrijke voordelen met zich mee. Je kunt als eindgebruiker altijd een Let’s Encrypt-certificaat overschrijven. Bestel ‘m via ons of regel ‘m zelf en zet hem in DirectAdmin. Dat is alles.

Mocht je een ongeldig certificaat hebben of je certificaat (per ongeluk) hebben laten verlopen, dan halen wij deze voor je uit de configuratie en wordt er automatisch teruggevallen op Let’s Encrypt. Je hebt op deze manier dus nooit een verlopen certificaat, en dus ook geen grote rode waarschuwing in je browser.

En stel, je hebt Uitgebreide SSL (Extra Validated) voor je domeinnaam. Daarnaast heb je ook een aantal aliassen of pointers als alternatieve domeinnamen aan je hoofddomeinnaam hangen. Voor deze pointers en aliassen werkt SSL niet met je EV-certificaat, omdat de domeinnaam niet overeenkomt. Je gebruikers krijgen een grote rode waarschuwing. Dankzij onze implementatie niet meer.

Ter kennisneming
Met de implementatie die wij gemaakt hebben, gebruiken je aliassen en pointers het Let’s Encrypt-certificaat en je hoofddomein het certificaat met de grote groene balk. Het beste van twee werelden. Iets dat onmogelijk is bij standaardoplossingen.

3.4 De certificaatmanager

Naast de aanpassingen aan bestaande software hebben we zelf het centrale orgaan voor het valideren, aanvragen en onderhouden van Let’s Encrypt-certificaten geschreven. Beter bekend als de certificaatmanager.

De certificaatmanager verzorgt voor alle domeinnamen, subdomeinen, pointers en aliassen het Let’s Encrypt-certificaat. Het controleert door middel van een pre-flight check of de content van de website (zowel voor IPv4 als IPv6) daadwerkelijk bij ons staat, zodat we zeker weten dat een aanvraag bij Let’s Encrypt door de validatie komt.

Vervolgens vraagt het een certificaat aan wanneer je een nieuw (sub)domein, pointer of alias toevoegt. 28 dagen voor het verlopen van je het certificaat start het de verlengprocedure. Dit geeft ons genoeg ruimte om potentieel onvoorziene problemen ver van te voren te signaleren. Ver voordat het certificaat verloopt en de bezoekers van je website een grote rode waarschuwing voorgeschoteld krijgen. Extra veiligheid dus.

Voor alle domeinen hebben we een certificaat voor je paraat staan. Ook wanneer je een eigen certificaat gebruikt. Ze zijn zelfs al ingeladen in HAProxy, alleen worden ze met een lagere prioriteit behandeld dan certificaten van onze klanten zelf.

3.5 Alles bij elkaar

Alles bij elkaar ziet het er schematisch gezien als onderstaand uit.

De implementatie van Basis SSL bij Antagonist

4. De uitrol

Nu duidelijk is hoe onze implementatie in elkaar zit, duiken we in de uitrol ervan. We hebben dit in verschillende fases uitgevoerd. Bewust in fases, zodat we op de achtergrond alle nodige aanpassingen aan ons platform konden maken, zonder dat dit impact had op onze dienstverlening.

Ik zal jullie stap voor stap meenemen in hoe we dit, in hoofdlijnen, aangepakt hebben. We beginnen met de situatie van voor de uitrol: hoe zag het er schematisch gezien uit voordat we aan dit project begonnen? Dat zie je terug in de onderstaande afbeelding.

De implementatie van Basis SSL bij Antagonist: de startsituatie

4.1 Ontwikkeling certificaatmanager

Eén van de eerste onderdelen waar we aan zijn gaan werken, is de certificaatmanager. We zijn hier zo vroeg mogelijk aan begonnen, omdat dit een losstaand onderdeel van de huidige productie-webstack is. We konden, zonder dat we veel integratiewerk moesten verrichten, hier direct mee aan de slag. Een nog belangrijker argument was dat we het aanvragen van certificaten zo gespreid mogelijk wilden doen, voornamelijk vanwege het volgende:

  • je komt zo de laatste bugs stuk voor stuk tegen, waardoor je ze ook stuk voor stuk kunt oplossen;
  • Let’s Encrypt hanteert een rate limit. Per IP, website of /48 IPv6-blok kun je een gelimiteerde hoeveelheid aanvragen per tijdsinterval doen;
  • minimalisatie van de impact. Door de aanvragen te spreiden, zorg je ervoor dat ook je verlengingen worden gespreid;
  • gaat er dus onverhoopt iets mis met verlengen, dan heeft dat maar impact op een klein gedeelte in plaats van op het grote totaal.

We houden ervan om veel kleine in plaats van grote ingrijpende wijzigingen te maken. Op deze manier houden we volledige controle over het proces. Mochten er toch onverwachte problemen opspelen, dan weten we waardoor het komt. We lossen het vervolgens op en gaan weer verder.

De implementatie van Basis SSL bij Antagonist: de certificaatmanager

4.2 Apache configuratieschrijver

De volgende stap was om onze eigengemaakte Apache configuratieschrijver te implementeren. We gebruiken configuratiebestanden voor Apache die door onszelf zijn gegenereerd. Naast de configuratieschrijver hebben we geen wijzigingen gedaan. De configuratie is dus hetzelfde, zoals DirectAdmin het zou bouwen. Dit hebben we bewust als tussenstap genomen, zodat we volledig zeker waren dat onze configwriter dezelfde bestanden genereert als DirectAdmin.

De implementatie van Basis SSL bij Antagonist: de configwriter

4.3 Samenknopen en activeren

Op dit punt hadden we alles klaarstaan om alle nodige wijzigingen aan elkaar te knopen. De eerste stap die we maakten, was om HAProxy de SSL-termination te laten verzorgen. Voorlopig nog op een alternatieve poort (444) en alleen met de huidige SSL-certificaten, dus nog geen Let’s Encrypt. Apache bleef daardoor nog netjes zijn SSL-certificaten serveren op poort 443. Geen wijzigingen voor onze gebruikers dus. Wel konden we zo zelf alles testen via poort 444, voordat we HAProxy in productie namen.

De implementatie van Basis SSL bij Antagonist: poort 444 bij HAProxy

Nadat er gedurende langere periode op de alternatieve poort 444 geen problemen naar voren waren gekomen, was het tijd om HAProxy de SSL-termination in productie te laten verzorgen. Het ging in deze stap dus volledig het SSL-verkeer van Apache overnemen. Daarna was de allerlaatste stap om HTTP/2 en alle Let’s Encrypt-certificaten, waarvan we het aanvraagproces een aantal weken geleden gestart hadden, te activeren.

De implementatie van Basis SSL bij Antagonist: poort 443 bij HAProxy

5. Tot slot

We zijn bij het einde van dit artikel aangekomen. Hopelijk heb ik je een diepgaande kijk in onze SSL-keuken kunnen geven en heb ik duidelijkheid kunnen verschaffen waarom we niet voor de gemakkelijke, maar de juiste weg gekozen hebben.

Werken bij Antagonist?
Vind je dit artikel enorm interessant en zou je ook zelf maar al te graag met dit soort uitdagingen aan de slag gaan? Check zeker onze vacatures, we zijn altijd op op zoek naar technisch talent!

Voordat we afsluiten, wil ik je graag nog een aantal punten meegeven:

  • what’s the catch? Die is er niet. Gratis SSL voor iedereen;
  • het ‘enable-antagonist-letsencrypt’-bestand is niet meer nodig;
  • verlopen certificaten vervangen wij automatisch voor je;
  • lees hier hoe je als Reseller van Antagonist je klanten gratis SSL geeft;
  • je site klaarmaken voor SSL, los mixed content op en forceer HTTPS;
  • meer weten over HTTP/2? Check dit artikel van Tiemo;
  • meer weten over OCSP stapling? Check dit artikel van Sander.

Wil je ook een website bij een hostingprovider die alle zorgen voor jou uit handen neemt en waarbij dingen ‘gewoon werken’? Neem dan gerust een kijkje in onze winkel.

Bestel je webhostingpakket →

Heb je vragen of opmerkingen? Wil je ons een taart of iets anders lekkers sturen? Neem gerust via support@antagonist.nl contact met ons op!

P.S. Wil je op de hoogte blijven van alle artikelen, updates, tips en trucs die verschijnen op ons blog? Dat kan! Rechts bovenin via RSS, e-mail, het liken op Facebook, het +1’en op Google+ of het volgen op Twitter.