OCSP stapling uitgelegd: hoe controleer je of een SSL-certificaat nog geldig is?

Alles wat een begin heeft, heeft ook een eind. Voor een SSL-certificaat is dat niets anders. Bij het aanmaken van zo’n certificaat staat de geldigheidsduur vast. Maar wat als voor het verstrijken van de einddatum er een probleem is met het certificaat? Hoe communiceer je dat naar webbrowsers? Met OCSP stapling!

Met behulp van OCSP stapling de geldigheid van een certificaat controleren

UPDATE
Sinds 11 april 2017 hebben alle domeinnamen, subdomeinen, aliassen en pointers bij Antagonist gratis SSL en HTTP/2 gekregen. Dit geldt voor iedere klant, ongeacht hun webhostingpakket, inclusief Resellers. Lees hier meer!

Allereerst kan de geldigheidsduur van een certificaat verschillen. Er zijn certificaten met een geldigheidsduur van bijvoorbeeld drie jaar, maar ook met een geldigheidsduur van drie maanden. Een voordeel van een lange geldigheidsduur is natuurlijk dat je er al die tijd niet meer naar om hoeft te kijken. Maar wat als je op een gegeven moment niet wilt dat het certificaat nog langer geldig is? Bijvoorbeeld, doordat iemand anders de private key in handen heeft gekregen of omdat het domein van eigenaar verandert? Je wilt dan een certificaat intrekken.

Hoe trek je een certificaat in?

Als je jouw certificaat van je domein verwijdert, dan is deze natuurlijk weg. Echter, in het geval dat iemand anders jouw certificaat heeft weten te bemachtigen, is dat natuurlijk geen optie. Je wilt dan dat het certificaat niet meer geldig is. Je moet dus op een of andere manier aan de wereld laten weten dat je certificaat niet meer te vertrouwen is. Gelukkig bestaan hiervoor verschillende opties, waaronder:

  • Certifcate Revocation List (CRL);
  • Online Certificate Status Protocol (OCSP).

Verder lezen

Hoe wij ons platform voor jou veilig houden!

“Waar gehakt wordt, vallen spaanders.” Ofwel, waar software geschreven wordt, ontstaan bugs. Sommige van deze bugs zorgen voor instabiliteit, andere voor verminderde veiligheid. Dit geldt voor alle software, van welke ontwikkelaar dan ook. Hoe kunnen wij er dan voor zorgen dat ons platform betrouwbaar en veilig is?

Hoe wij ons platform voor jou veilig houden!

Een betrouwbaar en veilig platform begint natuurlijk met goed besturingssysteem als solide basis. Deze basis is bij ons ‘CloudLinux’, die op zijn beurt ‘Red Hat Enterprise Linux’ (RHEL) als basis heeft. Waar RHEL zich voornamelijk op de enterprise richt, is CloudLinux opgericht om speciaal voor webhosting aanvullende features te bieden. Wat Red Hat samen met de aanvullende mogelijkheden van CloudLinux levert, blijkt in de praktijk ook een uitstekende keuze te zijn. Er is een goede balans tussen stabiliteit en nieuwe features.

Naast een besturingssysteem is ook een beheeromgeving essentieel, een zogeheten ‘control panel’. Om het beheer van onze webhostingpakketten voor onze klanten eenvoudig te maken, is er daarom DirectAdmin als control panel geïnstalleerd. Dit is de meest zichtbare kant van onze servers. Het is de omgeving waarop je inlogt om bijvoorbeeld e-mailaccounts aan te maken of een applicatie, zoals WordPress, te installeren.

Dat beetje extra

Een stabiel besturingssysteem, een beheerpaneel erbij en dan ben je klaar om je klanten te bedienen. Simpel, nietwaar? Hoewel we het op deze manier zouden kunnen doen, is dit voor ons niet goed genoeg. Wij stellen, net zoals onze klanten, hogere eisen en doen graag net dat beetje extra!

Verder lezen

File system caching bij Antagonist!

Caching is de laatste tijd een populaire term en wordt vaak in de algemene zin gebruikt. Deze techniek kan echter op verschillende niveau’s plaatsvinden, zoals op applicatie- of file system-niveau. Wanneer er gesproken wordt over caching voor een website, dan vindt dit plaats op applicatie-niveau. Daar gaan we het nu niet over hebben. Aan caching binnen applicaties kun je namelijk al een volledig artikel wijden, wie weet iets voor later 😉 We duiken daarom nu een stukje dieper in het file system-niveau, en dan specifiek file system caching!

Filesystem caching bij Antagonist: hoe werkt het exact?

File system caching wordt gebruikt om het opvragen en wegschrijven van bestanden te versnellen door veel opgevraagde bestanden of ‘blocks’ (tijdelijk) op een ander, veel sneller medium te plaatsen. Bij Antagonist maken we gebruik van een cachingmechanisme dat anders is dan traditionele systemen. Het is niet alleen anders, want anders is per definitie niet beter. De caching die wij gebruiken, is vele malen sneller. Sneller is wel beter!

Een woord vooraf
Dit artikel is behoorlijke ‘technische hardcore’. Om ervoor te zorgen dat het zo goed mogelijk is te volgen, heb ik het zo gestructureerd mogelijk opgezet. Handig om te weten, is dat er een aantal termen zijn die ik willekeurig door elkaar gebruik, maar waarmee ik hetzelfde bedoel:

  • blocks, files en bestanden;
  • lezen, leestransacties en reads;
  • schrijven, schrijftransacties en writes;
  • disk, harddisk, schijf en harde schijf;
  • werkgeheugen en RAM.

Read en write caching

Het cachen van bestanden (file system caching) kan worden onderverdeeld in twee categorieën, namelijk: lezen (read caching) en schrijven (write caching).

Verder lezen

Netneutraliteit: hoe zit het precies?

Nederland was één van de eerste landen met een netneutraliteitswet. Dit moment is men in de Europese Unie bezig een EU-brede wet te ontwerpen die de neutraliteit van het internet afdwingt. Hier zitten nogal wat haken en ogen aan. In dit blog leg ik daarom graag uit wat netneutraliteit is, wat de voor- en nadelen zijn en wat de nieuwe EU-brede wet inhoudt.

Netneutraliteit uitgelegd: hoe zit het precies?

Netneutraliteit is het principe dat internetproviders al het verkeer op hun netwerk gelijk behandelen zonder het te blokkeren, vertragen of anderzijds te verstoren. Op papier klinkt het als een goed idee, maar de werkelijkheid is complex. Er zijn namelijk goede redenen voor providers om verkeer dat aan bepaalde eisen voldoet, anders te behandelen dan de rest. Dit maakt het lastig om een goede neutraliteitswet te maken. Laten we beginnen met wat achtergrondinformatie.

Bandbreedte en latency

De snelheid waarmee data over het internet wordt verstuurd, kan worden opgedeeld in twee aspecten: de ‘bandbreedte’ en de ‘latency’. Met bandbreedte wordt de hoeveelheid data die per seconde via een internetverbinding verstuurd wordt, bedoeld. Veelal wordt dit in megabits per seconden of Mb/s gemeten. Met latency wordt de tijd bedoeld die tussen het moment zit, waarop de zendende partij begint met zenden en de ontvangende partij de eerste data ontvangt.

Dit is te vergelijken met een tuinslang. Stel, je hebt een tuinslang waar twee liter water per seconde uitstroomt. Het maakt niet uit of die slang 10 of 100 meter lang is, zodra het water gaat stromen komt er twee liter per seconde uit. Dit is de bandbreedte van de tuinslang. We kunnen die snelheid verhogen door een dikkere slang te gebruiken (mits de kraan het water kan leveren). Echter, ongeacht de dikte (bandbreedte) van de slang, duurt het even voordat er water uitstroomt zodra je de kraan aanzet. Dit is de latency.

Netneutraliteit uitgelegd: bandbreedte en latency

Op het internet geldt ongeveer hetzelfde. De afstand tussen zender en ontvanger is grotendeels bepalend voor de latency. Andere factoren die een rol spelen zijn: het aantal routers tussen zender en ontvanger en het medium dat wordt gebruikt (bijvoorbeeld een satellietverbinding die een hoge latency heeft).

Verder lezen

Een pikdonker en doodstil datacenter…

Afgelopen dinsdag, 23 juni 2015, gebeurde rond 8:30 uur het ergste wat een hostingprovider kan overkomen: er was een volledige black-out in één van de datacenters, waarin wij het merendeel van onze servers hebben geplaatst. Het gevolg: alle apparatuur down en tienduizenden klanten onbereikbaar. Een fantastisch begin van de dag. Het kan nóg erger: totale verwoesting van het datacenter in kwestie, maar dat was gelukkig niet aan de orde. Wat dan wel? Nou, een stroomstoring…

Stroomuitval in het dataceter: pikdonker en doodstil

Ik hoor het je denken: “Hè, wat?! Dat kan toch niet? Alles in zo’n datacenter is beveiligd, dubbel uitgevoerd, heeft noodaggregaten en zo?” Inderdaad, dat is er allemaal en in veel gevallen zelfs vierdubbel uitgevoerd. In theorie kan stroomuitval dus niet voorkomen. Echter, door de meest ongelukkige samenloop van omstandigheden gebeurde het toch. Een goed voorbeeld van hoe theorie en praktijk soms ver uit elkaar liggen.

Naast dat het voor iedereen zeer vervelend is, was het voor ons ook een ultieme proef of we spoedig konden herstellen van zo’n grote storing. Daarnaast was het de vuurdoop voor ons nieuwe platform, waarin duidelijk werd of het in de praktijk deed wat het moest doen. Omdat jij ook recht hebt op deze informatie, hebben we hieronder een gedetailleerd verslag geschreven.

Inhoudsopgave

  1. Antagonist zegt sorry!
  2. Klein team, veel klanten
  3. Prioriteit tijdens calamiteit
  4. Hoe kan dat dan, geen stroom?
  5. De gevolgen voor Antagonist
  6. Opstarten na stroomuitval
  7. Nazorg, totdat alles weer in orde is
  8. Wat is de schade?
  9. Communicatie
  10. Hoe gaan we dit voorkomen?
  11. One more thing…

Antagonist zegt sorry!

Maar eerst zeggen we: “Sorry!” Een storing is altijd hinderlijk. Helemaal als klanten er de dupe van worden. Door de stroomstoring in het datacenter heeft ons gehele platform er even uit gelegen. Al onze klanten hebben daardoor downtime ondervonden. Daarnaast hebben enkele klanten langer last gehad vanwege herstelwerkzaamheden.

Het ‘uitvallen’ van de stroom heeft dus een behoorlijke impact. Dat vinden we erg vervelend en daarom bieden we onze excuses aan. Dat is tevens één van de redenen voor dit blog. Daarnaast willen we je een eerlijk en helder inzicht geven in wat er precies is gebeurd.

Tijdens de storing hebben we regelmatig updates geplaatst. Het waren vooral beknopte berichten over de voortgang van de situatie en het herstel. Daarnaast hebben we twee ‘post incident’-berichten geschreven. Deze gaven inzicht in de toedracht. De werkelijke gevolgen zijn voor een buitenstaander wellicht lastig voor te stellen. Vandaar dat we je graag een kijkje in de keuken geven, hoe het er dinsdag aan toe ging.

Klein team, veel klanten

Antagonist heeft tienduizenden klanten en 12 medewerkers. Zodoende moet je tijdens een grote storing, als een geoliede machine te werk gaan. Alles moet vanzelfsprekend zijn, want tijd is er niet. Met een klein en hecht team moet je handelen vanuit instincten. Juist daarom vinden we het zo belangrijk dat een medewerker goed moet passen binnen ons team. Naast de juiste kennis en vaardigheden zoeken we dus naar de perfecte match.

Als het misgaat, dan is het heel simpel. Er zijn drie dingen die er toe doen. Eén: onze klanten moeten zo snel mogelijk weer online. Twee: voorkom zoveel mogelijk schade en dataverlies. Drie: zorg voor een vlotte en oprechte communicatie, waarin vragen van klanten zorgvuldig worden beantwoord.

Qua prioriteit ligt het ietsje ingewikkelder. De hoogste prioriteit is bij Antagonist altijd data-integriteit. Dat betekent dat we het voorkomen van dataverlies belangrijker vinden dan beschikbaarheid. Je hebt immers niets aan een website zonder data. Gelukkig hoeven we ons daar weinig zorgen over te maken. Gegevens worden veilig opgeslagen. De kans op dataverlies is daardoor zeer gering. Zodoende storten we ons, tijdens een storing, vrijwel direct op de beschikbaarheid.

Prioriteit tijdens calamiteit

Goed, het is dinsdagochtend en we zien dat er heel veel loos gaat. De oorzaak weten we niet. Er was weliswaar een sterk vermoeden dat het om een (deels) falende stroomtoevoer gaat, maar dat kunnen we niet bevestigen. Dat is erg naar. Want hoe kun je iets oplossen, als je het probleem niet kent?

Verder lezen