Certificaatwaarschuwing op de router of de VPN

Je opent de webinterface van de router op HTTPS en de browser zet er een waarschuwing voor. Of je VPN-client verbindt niet en zegt iets over een certificaat dat niet vertrouwd wordt. Het is verleidelijk om door te klikken, maar het loont om eerst te lezen wat er staat, want de tekst noemt de oorzaak.

Wat het niet is: een certificaatwaarschuwing betekent niet dat het verkeer onversleuteld is. De versleuteling werkt; wat niet lukt, is bewijzen dat de andere kant is wie hij zegt te zijn. Op een router in je eigen meterkast is dat een ander risico dan op een bank. Het is ook geen firewallprobleem: je komt er duidelijk bij, anders had je geen waarschuwing.

Er zijn drie families waarschuwingen. Onbekende uitgever betekent dat je machine de ondertekenaar niet kent. Naam klopt niet betekent dat het adres dat je intypte niet in het certificaat staat. Verlopen betekent dat er ergens een klok fout staat.

De snelle controles, op volgorde

Wat zegt de waarschuwing letterlijk? Klik op de details. Goed antwoord: een code als ERR_CERT_AUTHORITY_INVALID, ERR_CERT_COMMON_NAME_INVALID of ERR_CERT_DATE_INVALID. Die drie wijzen naar drie verschillende hoofdstukken hieronder.
Welke certificaten staan er op de router? /certificate print detail. Goed antwoord: een CA en een servercertificaat, allebei met de vlag T (trusted) en K (private key aanwezig). Ontbreekt de K, dan kan de router er niet mee ondertekenen.
Waar staat de naam in? Kijk in diezelfde uitvoer naar common-name en subject-alt-name. Goed antwoord: de naam of het adres waarmee jij verbindt staat in subject-alt-name. Staat hij alleen in common-name, dan accepteren moderne browsers hem niet.
Hangt het certificaat aan de dienst? /ip service print detail. Goed antwoord: bij www-ssl staat certificate=webfig, en niet none.
Klopt de tijd? /system clock print en invalid-before uit stap 2. Goed antwoord: nu ligt tussen begin en eind. Zie De klok klopt niet.

De gewone oorzaken, meest voorkomend eerst

Het certificaat is zelfondertekend, en dat is normaal

Een router maakt zijn eigen CA en ondertekent daar zijn webcertificaat mee. Jouw laptop kent die CA niet, dus vertrouwt hij hem niet. Er is niets stuk. Je hebt twee wegen: importeer de CA van de router eenmalig in de certificaatopslag van je beheermachines, of gebruik een certificaat van een publieke uitgever. Wegklikken kan ook, maar dan controleer je nooit meer of je met de goede router praat.

De naam in het certificaat is niet de naam die je intypt

Je verbindt met https://192.168.88.1 en het certificaat is uitgegeven op de naam van de router, bijvoorbeeld kantoor-gw. Dat is nooit hetzelfde. Bovendien kijken browsers al jaren niet meer naar het veld common-name: ze willen de naam of het IP-adres in subject-alt-name zien staan, en anders weigeren ze onafhankelijk van vertrouwen. Dit is de waarschuwing die niet weggaat door de CA te importeren.

De klok stond fout toen het certificaat werd gemaakt

Een certificaat krijgt zijn begindatum bij het ondertekenen. Wordt het aangemaakt op een router die net is opgestart en nog niet met NTP heeft gepraat, dan staat er een begindatum in die nergens op slaat. Verwijderen en opnieuw aanmaken als de tijd klopt, is de enige nette oplossing.

De VPN-client kent de CA niet

Bij IKEv2 met certificaten, SSTP en OpenVPN maakt de router een eigen CA. De client moet die CA vertrouwen, anders weigert hij. Voor IKEv2 wordt per client een pkcs12-bestand geëxporteerd waar de keten in zit; dat bestand moet je van de router halen en op het apparaat installeren. Voor SSTP moet je het CA-certificaat apart op de Windows-machine in de opslag "Vertrouwde hoofdcertificeringsinstanties" zetten.

Wat de configurator hiervan doet

In Beheertoegang staat, zodra je HTTPS (www-ssl) aanzet, de schakelaar HTTPS: zelfondertekend certificaat aanmaken, standaard aan. Het script maakt dan local-ca met een geldigheid van 3650 dagen, ondertekent die, maakt webfig met de naam van de router als common-name, ondertekent die met de CA en koppelt hem aan www-ssl en aan api-ssl als die aanstaat.
Wees eerlijk over dat certificaat: er komt geen subject-alt-name in, en de common-name is de identity van de router, niet het adres waarop je verbindt. Een browser waarschuwt er dus hoe dan ook over, ook nadat je de CA hebt geïmporteerd. Het is er om het verkeer te versleutelen, niet om een groen slotje te krijgen. Wil je dat laatste, gebruik dan Let's Encrypt of zet met de hand een certificaat op de router waar wel een SAN in staat.
In Diensten & tools zit het veld Let's Encrypt certificaat voor deze hostnaam. Het script opent daarvoor tijdelijk poort 80 vanaf WAN, draait /certificate enable-ssl-certificate dns-name=..., sluit poort 80 weer en zet www-ssl aan. De tool waarschuwt erbij dat de naam naar dit WAN-adres moet wijzen en dat je minstens RouterOS 7.1 nodig hebt.
Let op de vernieuwing: die poort 80 gaat na de aanvraag weer dicht. RouterOS vernieuwt het certificaat later zelf, en heeft daar poort 80 opnieuw voor nodig. Zet er dus een blijvende regel voor terug als je de vernieuwing automatisch wilt laten verlopen, of houd in de gaten wanneer het verloopt.
In VPN maakt IKEv2 met certificaten een vpn-ca, een servercertificaat op de FQDN die je invult, en per client een certificaat dat als pkcs12 wordt geëxporteerd met de wachtwoordzin die je zelf invult. SSTP en OpenVPN krijgen een eigen ppp-ca en ppp-server, met een subject-alt-name als het publieke endpoint een hostnaam is.
Wat de tool niet doet: hij zet geen certificaten op jouw laptop of telefoon. Het vertrouwen aan de clientkant is handwerk, op elk apparaat apart.

Als het niet aan je router ligt

De klok van de client. Een telefoon of laptop met een verkeerde datum weigert een certificaat dat prima is.
HSTS in de browser. Heeft een domein ooit HSTS gestuurd, dan kun je de waarschuwing niet wegklikken. Gebruik een andere naam of het IP-adres.

Verder lezen: Certificaten, Beheertoegang en VPN voor onderweg.