Google publiceerde onlangs de resultaten van een studie over browserwaarschuwingen – je weet wel, van die schreeuwerige berichten die zeggen dat jouw verbinding 'niet privé' is. Je bent ze vast wel eens tegengekomen. 

Waarschuwing voor self-signed of niet-vertrouwde roots in Chrome (bron: BadSSL.com)

Deze waarschuwingen hebben een duidelijk doel, namelijk voorkomen dat gebruikers verbinding maken met onveilige websites. Er kunnen heel wat dingen aan de basis liggen van deze waarschuwingen en sommige oorzaken zijn ernstiger dan andere. Omdat de gemiddelde gebruiker niet gemakkelijk een onderscheid kan maken tussen de waarschuwingen, bestaat het risico dat ze ALLE waarschuwingen gewoon negeren. De doelstelling van Googles onderzoek was om onschuldige fouten te helpen oplossen zonder echte fouten uit het oog te verliezen.

Ik kan alleen maar aanraden om het volledige verslag te lezen - Where the Wild Warnings Are: Root Causes of Chrome HTTPS Certificate Errors. Hieronder kan je een samenvatting vinden van de belangrijkste bevindingen. Daarnaast geef ik wat praktisch advies over hoe je een aantal van de meest voorkomende problemen kan oplossen.

Wat zijn de belangrijkste oorzaken van browserwaarschuwingen?

Waar komen deze waarschuwingen nu vandaan? Uit een steekproef van meer dan 300 miljoen fouten, verzameld tijdens een periode van ongeveer een jaar (de methodologie kan je in het rapport raadplegen), kon Google gemakkelijk de oorzaken van twee derde van de fouten classificeren. Daarna werden de fouten in drie belangrijke types ingedeeld: server, client en netwerk.

Bron: Google

Serverfouten doen zich voor "wanneer een server een ongeldige of onvolledige certificaatketen presenteert". Voorbeelden zijn:

• Datumfouten (bv. een site gebruikt een verlopen certificaat)
• Fouten omdat de servernamen niet overeenkomen (bv. het certificaat bevat de hostnaam van de website niet)
• Fouten door ongeldige autoriteit (bv. het certificaat is niet aan een vertrouwde root gekoppeld)
• Fouten door ontbrekende intermediate certificaten (bv. de server stuurt alleen het eindcertificaat, niet de intermediate certificaten)
• SHA-1-fouten (d.w.z. het certificaat gebruikt het SHA-1-algoritme, dat verouderd is en niet langer vertrouwd wordt door Chrome)

Clientfouten doen zich voor "wanneer een client de keten van het certificaat van een correct geconfigureerde server niet kan valideren". Voorbeelden zijn:

• Onjuist ingestelde klok van client (bv. de klok van een client is op een tijdstip in de toekomst ingesteld, waardoor een certificaat ten onrechte als verlopen wordt beschouwd, terwijl dat niet het geval is)
• Antivirusfouten (bv. antivirussoftware die dienstdoet als proxy om HTTPS-verkeer te ontsleutelen, inspecteren en opnieuw te versleutelen, gebruikt een verlopen root voor de certificaten voor het opnieuw versleutelen)

Netwerkfouten doen zich voor "wanneer een netwerkapparaat een HTTPS-verbinding onderschept en de certificaatketen vervangt door een keten die de client niet kan valideren". Voorbeelden zijn:

• Fouten veroorzaakt door aanmeldingspagina (bv. een aanmeldingspagina zoals u ziet wanneer u het wifinetwerk van een hotel voor het eerst gebruikt en wordt gevraagd om eerst in te loggen. In dit geval gaan de namen niet overeenkomen omdat de browser een hostnaam vraagt, dat is dan de website die u wilt bezoeken, maar de loginpagina heeft met een certificaat met een andere hostnaam)
• Ontbrekende roots TLS-proxy (bv. een browser beschikt niet over het rootcertificaat van de TLS-proxy, dus telkens als de gebruiker een website probeert te bezoeken die werd onderschept en opnieuw versleuteld door de proxy, krijgt deze een foutmelding te zien dat de root niet vertrouwd wordt)

Servers zijn niet de enige boosdoener 

De gelijke verdeling tussen server- en niet-server-fouten (client en netwerk) was bijzonder interessant – het meeste materiaal over dit onderwerp richtte zich op serverconfiguratie en vond het de taak van server- en sitebeheerders om dit soort waarschuwingen te voorkomen. Uit deze resultaten blijkt dat er meer bij komt kijken dan dat.

Opmerking: Ze hebben ook een steekproef van de niet-geclassificeerde fouten onderzocht en vonden een zelfs groter aandeel netwerk-/clientfouten in vergelijking met serverfouten, wat de rol van client en netwerk nog verder benadrukt.

Meest voorkomende browserfouten oplossen en voorkomen

Hoewel deze fouten en de oorzaken ervan heel duidelijk worden uitgelegd in het rapport, wordt er weinig aandacht besteed aan hoe deze fouten kunnen worden opgelost of voorkomen. Dat is begrijpelijk, want deze vallen buiten de focus van het rapport. In een aantal gevallen wordt er wel verwezen naar oplossingen of zijn deze duidelijk gebaseerd op de fout, maar meer details en instructies zouden wel handig zijn.

Ik zal me vooral concentreren op de serverfouten omdat ik daar zelf het best in thuis ben en dat deze kunnen worden opgelost door sitebeheerders. Je kan uiteraard niet controleren of de systeemklok van de bezoekers juist is ingesteld en of hun bedrijf een SSL-inspectieservice gebruikt. Bovendien is serverconfiguratie iets dat enorm belangrijk is – een certificaat kopen is slechts één stap van het implementeren van HTTPS; je moet ook de server correct configureren!   

Server date errors

Uit het rapport blijkt, niet onverwacht, dat vrijwel alle server date errors of datumfouten werden veroorzaakt door verlopen certificaten. Daar is een heel voor de hand liggende oplossing voor: laat jouw certificaten niet verlopen!

Je maakt nog steeds een overzicht van alle certificaten bij in een Excel-spreadsheet en je hebt er enkele over het hoofd gezien?

Komaan. Maak gebruik van een beheerplatform om een beter overzicht te krijgen. Je hebt waarschijnlijk certificaten van meerdere CA's en hebt problemen om alles op te volgen? Gebruik een inventaristool om alle certificaten en hun oorsprong op te sporen. Wil je alles automatiseren zodat je je zich geen zorgen meer hoeft te maken? Je kan al veel doen met API's en het ACME-protocol (dat is niet alleen voor DV). Er is geen excuus meer voor verlopen certificaten!

Name mismatch errors

Google heeft het specifiek over fouten met subdomeinen www/niet-www en 'buiten bereik van de wildcard', maar dezelfde logica geldt voor alle hostnamen en domeinen. De hostnaam moet in het certificaat worden vermeld, tenzij specifiek binnen het bereik van een wildcard.

De www-fouten worden mogelijk veroorzaakt door een onjuiste veronderstelling dat een certificaat geldt voor zowel de www- als de niet-www-versies van een domein. Dat is niet het geval! Beiden moeten vermeldt worden in het certificaat (of de juiste wildcard gebruiken). In de certificaten van GlobalSign worden beide gratis opgenomen (d.w.z. dat we niets extra aanrekenen voor www en niet-www in hetzelfde certificaat).

De wildcardfouten kunnen een gewone onoplettendheid zijn of kunnen te maken hebben met problemen met meerdere domeinniveaus (bv. een certificaat voor *.voorbeeld.com geldt niet voor test.demo.voorbeeld.com of voor voorbeeld.com). De moraal van het verhaal is dat je eigenlijk altijd moet controleren of de hostnaam deel uitmaakt van het certificaat of van het bereik van de wildcard.

Invalid Server authority errors

Omdat het certificaat van jouw website vertrouwd wordt, moet het aan een root (of "autoriteit") worden gekoppeld die is opgenomen in het vertrouwensarchief van de browser. Google ontdekte dat de meerderheid van deze fouten, waarbij certificaten gekoppeld aan een root die niet in het browserarchief zat, veroorzaakt werd door selfsigned certificaten of roots beheerd door de overheid.

Eenvoudig gezegd: gebruik geen selfsigned certificaten op openbare websites. Nooit. Je vraagt zich misschien af hoe dat zit met interne sites of intranetten. Wel, dat is ook risicovol omdat werknemers ze bezoeken via een browser en daarom browserwaarschuwingen zullen zien. Zo ga je hun eigenlijk leren om deze waarschuwingen te negeren voor interne sites, kan ertoe leiden dat ze andere waarschuwingen ook negeren, waardoor jouw bedrijf kwetsbaar kan zijn voor malware en andere gevaarlijke dingen.

Opmerking: Als je selfsigned certificaten gebruikt in interne netwerken omdat je configuraties nodig hebt die niet zijn toegestaan door de Baseline Requirements van het CA/Browser Forum (zoals interne servernamen, lokale hostnamen, lange geldigheidsperiodes), bieden sommige CA's (zoals GlobalSign) nu certificaten aan die werden uitgegeven via niet-openbare roots die specifiek werden ontwikkeld voor deze toepassingen.

Roots beheerd door de overheid kunnen fouten veroorzaken omdat ze vaak niet zijn opgenomen in standaard vertrouwensarchieven en burgers ze apart op hun computers en apparaten moeten installeren. In het rapport vermeldt Google een mogelijke toekomstige oplossing hiervoor. Ze stellen eigenlijk voor dat wanneer een gebruiker dit type fout te zien krijgt, hij een specifiek bericht zou ontvangen met instructies over hoe hij de juiste root van de overheid kan installeren. Ze vermelden de bijbehorende uitdagingen, maar het is interessant om te horen wat hun plannen zijn.

Onvoldoende intermediate certificaten

Intermediate certificaten verbinden eindcertificaten (de certificaten uitgegeven voor domeinen/websites) met het trusted root-certificaat (de serverautoriteit vermeldt hierboven) dat is opgeslagen in het vertrouwensarchief van de browser en zorgt zo voor een keten van vertrouwen. Dat betekent dat naast het eindcertificaat een server doorgaans ook de tussenliggende certificaten moet voorzien.

De oplossing om dit type fout te voorkomen, moet je er dus voor zorgen dat de juiste intermediate certificaten geïnstalleerd zijn op de server. De CA waar je het certificaat koopt, heeft telkens zijn eigen set intermediate certificaten, afhankelijk van het type certificaat dat je hebt. Bij GlobalSign voorzien we de juiste intermediate certificaten wanneer we het certificaat uitgeven. Instructies voor het installeren van certificaten en tussenliggende certificaten per servertype kan je hier vinden.

SHA-1 errors

Ik denk dat we intussen al alles hebben verteld over SHA-1. Het advies is heel simpel: gebruik het niet meer!

Bonus – Client clock errors

Deze fout is niet servergerelateerd, maar er is iets dat beheerders van servers en sites kunnen doen om dit type fout te helpen voorkomen (waarbij de systeemklok onjuist is ingesteld en de browser denkt dat de huidige tijd en geldigheidsperiode van het certificaat niet overlappen, waardoor het certificaat niet vertrouwd mag worden). Als je een beetje tijd laat tussen het tijdstip dat je het certificaat ontvangt en wanneer je het daadwerkelijk begint te gebruiken, kan je dit voor een stuk voorkomen. Als je het certificaat bijvoorbeeld vandaag ontvangt en installeert, en een clientklok op een tijdstip in het verleden is ingesteld, zelfs al is het maar een dag eerder, dan veroorzaakt dit een fout. Google beschouwt dit scenario als een reden voor een piek in clientfouten in Windows-computers in september 2016.

Bonus – TLS-proxy errors

Deze fout is opnieuw niet servergerelateerd, maar ligt wel binnen de controle van het bedrijf en is daarom het vermelden waard. Veel organisaties hebben systemen voor SSL-inspectie geïmplementeerd die HTTPS-verkeer onderscheppen en ontsleutelen, op zoek naar schadelijke inhoud. De systemen vereisen dat hun eigen niet-openbare CA's nieuwe SSL-sessies aanmaken bij de eindclients nadat de inspectie voltooid is. Omdat deze CA's niet openbaar vertrouwd kunnen worden, worden hun roots niet automatisch opgenomen in de vertrouwensarchieven van browsers. Je hebt waarschijnlijk door waar dit naartoe gaat – als de browser van de eindgebruiker de root niet in zijn vertrouwensarchief heeft, ziet deze een certificaatfout voor elke website die hij bezoekt.

De oplossing hiervoor is dat je de root van het systeem verzendt naar alle computers en apparaten van de eindgebruiker. Dit is gemakkelijker gezegd dan gedaan, vooral als je werkt met gemengde eindpuntomgevingen met niet-Windows-clients of mobiele toestellen en meerdere roots moet beheren. In die situatie kunt u overwegen om een specifieke privéroot van een externe CA te gebruiken. Zo moet je slechts één root te verzenden met meerdere CA's die je kunt gebruiken voor verschillende toepassingen (bv. SSL-inspectie, certificaten voor gebruikersauthenticatie enz.). We bespreken dit onderwerp in detail in een recent artikel. Het komt er eigenlijk op neer dat je de problemen bij het beheer en de implementatie van de root kunt voorkomen en het beheer van CA en cryptografie kunt overlaten aan een vertrouwde derde partij.

Samenvattend – De serverconfiguratie is belangrijk!

Hoewel we de rol van de client- en netwerkconfiguratie bij browserwaarschuwingen niet uit het oog mogen verliezen, en het fijn is te lezen hoe Google deze hoopt op te lossen met behulp van meer aangepaste, uitvoerbare foutmeldingen, benadrukken de resultaten van de studie het belang van een juiste serverconfiguratie.

We benadrukken dit al een hele tijd... Heb ik onze serverconfiguratietest al vermeld? Hoewel het bovenstaande advies een aantal van de meest voorkomende fouten kan voorkomen, raad ik jullie aan om met deze tool ook andere configuratiecomponenten te zoeken (bv. welke SSL/TLS-protocollen en coderingssuites u gebruikt vs. wat wordt aanbevolen, of kwetsbaar bent voor algemene SSL-kwetsbaarheden). Vergeet niet: er is meer nodig dan een certificaat om HTTPS te implementeren!

Nog vragen over SSL of serverconfiguratie? Laat het ons weten. Wij helpen jullie graag verder.