Handleiding

Certificaten

Wat de tool aan certificaten maakt, waarom je browser blijft klagen, en wanneer dat terecht is.

Een certificaat doet twee dingen tegelijk, en dat is de reden dat dit onderwerp verwarrend is. Het versleutelt de verbinding, en het bewijst met wie je praat. Een zelfondertekend certificaat doet het eerste net zo goed als een duur exemplaar. Het tweede doet het niet.

Wat de tool aanmaakt

Op drie plekken maakt de configurator certificaten, en alle drie doen ze het op de router zelf. Er gaat niets naar een server, ook niet van ons: de tool draait in je browser.

WebFig over HTTPS

Zet je in Beheertoegang de dienst HTTPS aan, dan staat HTTPS: zelfondertekend certificaat aanmaken standaard aan. Het script maakt dan een CA met de naam local-ca en een servercertificaat webfig, ondertekent dat met de CA, en koppelt het aan www-ssl. Staat API-SSL ook aan, dan krijgt die hetzelfde certificaat. Beide krijgen tien jaar geldigheid, want een beheerinterface die na een jaar stilletjes stopt is erger dan een lange looptijd.

De common name is de naam die je bij Systeem als identity hebt ingevuld. Dat is geen hostnaam die je browser kent, dus je krijgt een waarschuwing. Daarover verderop meer.

IKEv2

In VPN kun je IKEv2 op certificaten zetten. Het script maakt dan vpn-ca, een servercertificaat vpn-server met de FQDN die je invult als common name én als subject alternative name, en per client een certificaat vpn-<naam>. Die clientcertificaten worden meteen geëxporteerd als .p12-bestand met het wachtwoord dat je erbij zet. De CA zit in dat bestand, dus de client heeft verder niets nodig.

Na het plakken staan die bestanden op de router. Je haalt ze op met WinBox onder Files, of je kijkt eerst met:

/file print

Die .p12-bestanden bevatten de private sleutel van de client. Haal ze van de router af zodra je ze hebt, in plaats van ze daar te laten staan.

De FQDN is hier niet cosmetisch. iOS en Windows controleren de servernaam in het certificaat tegen de naam waarmee je verbindt. Klopt dat niet, dan weigert de client, en de foutmelding zegt zelden wat er mis is.

SSTP en OpenVPN

Kies je SSTP of OpenVPN, dan maakt het script ppp-ca en ppp-server. De common name wordt het publieke adres of de hostnaam die je bij VPN hebt ingevuld; is dat een hostnaam, dan komt die er ook als subject alternative name bij. Vul je daar niets in, dan staat er router en zal elke client klagen over de naam.

Let's Encrypt

In Diensten en tools is er één veld: Let's Encrypt certificaat voor deze hostnaam. Vul je daar een naam in, dan doet het script dit:

  1. een tijdelijke firewallregel die TCP 80 vanaf WAN toelaat, bovenaan de input-chain, met de opmerking acme-http01;
  2. /certificate enable-ssl-certificate dns-name=…, de RouterOS-opdracht die het certificaat aanvraagt;
  3. die firewallregel weer weghalen;
  4. www-ssl aanzetten.

Twee voorwaarden, en de tool zegt ze er ook bij. De naam moet naar het WAN-adres van deze router wijzen, en poort 80 moet tijdens de aanvraag echt vanaf internet bereikbaar zijn. Zit je achter CGNAT of achter een modem dat niet in bridge staat, dan komt de challenge niet aan en mislukt de aanvraag. Zie Een veranderend adres bereiken.

Wat er daarna gebeurt is RouterOS-werk: hij koppelt het certificaat zelf aan www-ssl en vernieuwt het zelf. Je hoeft er verder niets voor in te richten. Controleer na een paar maanden een keer of dat ook echt gebeurt:

/certificate print detail

Let op: het veld vraagt om een naam die vanaf internet bereikbaar is. Voor een router die alleen binnen je netwerk staat is Let's Encrypt niet de oplossing; daar blijft het zelfondertekende certificaat over, of een eigen CA die je op je apparaten installeert.

Wat de browserwaarschuwing betekent

Ga je met HTTPS naar een router met een zelfondertekend certificaat, dan zegt je browser iets als "de verbinding is niet privé". Dat is waar en tegelijk misleidend.

Wat er wél aan de hand is: je browser kent de CA niet die dit certificaat heeft ondertekend, dus hij kan niet controleren of dit echt jouw router is. Zou iemand tussen jou en de router zitten, dan zou je dat hieraan niet kunnen zien.

Wat er níét aan de hand is: de verbinding is niet onversleuteld. Het verkeer is precies zo versleuteld als bij een certificaat van een bekende CA. Een meelezer op het netwerk ziet geen wachtwoord.

In de praktijk betekent dat: op een netwerk dat je beheert en waar je via een vast adres naar een apparaat gaat, is de waarschuwing acceptabel. Klik je hem weg terwijl je op een netwerk zit dat je niet vertrouwt, dan gooi je wel iets weg. En als je hem eenmaal gewend bent weg te klikken, klik je hem ook weg op de dag dat er iets aan de hand is.

Wil je er vanaf, dan zijn er twee wegen. Let's Encrypt voor een router met een publieke naam, of je eigen CA op je beheerlaptops installeren. Dat tweede kent de tool niet: er is geen veld om een bestaand certificaat of een eigen CA te importeren, en er wordt geen CRL bijgehouden. Wil je dat, dan doe je het met de hand op de router met /certificate import.

Controleren en opruimen

/certificate print

Je ziet per certificaat de vlaggen: K betekent dat de private sleutel erbij zit, T dat het vertrouwd is, A dat het door een CA is ondertekend. Een servercertificaat zonder K kan niets. Met print detail zie je de geldigheidsdatums.

De looptijden die de tool gebruikt: tien jaar voor de CA's en voor het WebFig-certificaat, drie jaar voor de VPN-server- en clientcertificaten. Loopt er een af, dan maak je een nieuw certificaat en onderteken je het met dezelfde CA; de clients hoeven dan niets opnieuw te installeren, want de CA die ze vertrouwen is niet veranderd. Verloopt de CA zelf, dan begint het rijtje opnieuw.

Verder lezen: Beheertoegang voor de HTTPS-schakelaar, VPN voor onderweg voor IKEv2 en de clientbestanden, en Een veranderend adres bereiken voor de naam die je nodig hebt.

Meteen proberen? Open de configurator