Fritz! Box + HTTPS

Nu mijn kinderen ook vriendjes met hun eigen laptops mee naar huis nemen voel ik ineens urgentie om mijn gehuurde Fritz! Box 5490 te voorzien van een TLS-certificaat voor gebruik op mijn LAN. Alleen blijkt dat lastiger dan ik dacht.

Ik gebruik Linux Mint met Firefox.

Mijn pogingen tot nu toe zijn mislukt:

  • het certificaat van Fritz! downloaden lukt, maar als ik hem importeer in Firefox zie ik het publieke IPv4-adres en het maakt niet uit of ik na herstarten van Firefox dat IPv4-adres gebruik of het lokale https://192.168.178.1 -adres. Firefox blijft aangeven dat de verbinding niet is beveiligd.
  • Zelf een CA-certificaat fritz-client-cert.pem maken met OpenSSL, en het client-certificaat uploaden naar Fritz! lukt ook niet. Fritz! geeft aan dat het certificaat niet geĂŻmporteerd kan worden omdat het wellicht ongeldig is.

Ik heb het volgende gedaan om de certificaten aan te maken:

# aanmaken CA-certificaat
openssl genpkey -genparam -algorithm ec -pkeyopt ec_paramgen_curve:secp521r1 -out ecparam.pem
openssl req -new -newkey ec:ecparam.pem -x509 -noenc -days 3650 -out fritz-ca-cert.pem -keyout fritz-ca-key.pem
# aanmaken client certificaat
openssl req -newkey ec:ecparam.pem -noenc -keyout fritz-client-key.pem -out fritz-client-req.pem
openssl x509 -req -days 3650 -set_serial 01 -in fritz-client-req.pem -out fritz-client-cert.pem -CA fritz-ca-cert.pem -CAkey fritz-ca-key.pem

Nu heb ik ergens gelezen dat Fritz! niet overweg kan met iets anders dan een RSA-certificaat. Of misschien kan Fritz! niet overweg met het PEM-formaat?

Misschien dat ik het niet begrijp, maar wat voegt dit certificaat toe? En horen de vriendjes niet gewoon op het gasten netwerk van de fritzbox?

Ik denk dat je iets wilt waarvoor certificaten niet zijn bedoeld.
Waartoe waarvoor je dat zou willen, laat ik verder maar in het midden.

Certificaten zijn bedoeld om de identiteit van externe partijen (op grond van hun IP/domein) vanuit een ondertekende (CA) autoriteit te (laten) valideren.

Jouw private LAN(adressen) vallen daarbuiten, de CA kan simpelweg niet controleren dat jouw private adres, de geverifieerde identiteit heeft die het zegt te bieden. In de wereld zijn vele miljoenen apparaten met adres 192.168.178.1.

Anders gezegd, certificaten voor private adressen zijn niet of onvoldoende legitiem.

Je kunt FF of je systeem (d8 ik) wel verbouwen, veel succes daarmee, dat die jouw als “autoriteit” mbt dat zelf uitgegeven certificaat (h)erkent.
Dat betekent echter dan ook dat jouw bezoekers) die speciaal verbouwde browser als autoriteit moeten gaan gebruiken. Een browser die jijzelf mogelijk wel zult vertrouwen maar anderen daar zo hun gedachten bij zullen hebben.

De fritzbox maakt iedere keer als hij opnieuw opstart een nieuw self signed certificaat aan.
Ik vertel de browser dat het een uitzondering is en het loopt.

Ik heb nooit geprobeerd een ander aan te maken.
In de help staat dat dit via https://letsencrypt.org/ kan.
Met de vermelding toegang van buitenaf.
Kan me indenken, dat die wat langer mee gaat.
Je zelf als CA uitroepen, is weer een stapje verder.

Ik vermoed dan je dan ook iets anders in moet loggen.
Bijvoorbeeld https://example.connected.by.freedominter.net/
Er zijn hier vast mensen die dat beter uit kunnen leggen.
Ik ga het niet doen, omdat het op het randje van mijn kennis is.

Dit ooit regelmatig gedaan voor interne services die zich naar buiten moeten presenteren, desnoods als Fritz zelf of een daarachterliggend apparaat te voorzien van/met een geldig certificaat.

Het zelf signed certificaat van de FB kan voor anderen weer onvoldoende betrouwbaar zijn en je dan als gebruiker (handmatig) de challenge als uitzondering moet controleren/accepteren of jouw FB is wie die zegt dat die is. (zie [Internet] → [Permit Access] → [FRITZ!Box Services] → { Status Certificate }

  • Voorbeeld: The FRITZ!Box uses the user’s own certificate.
    SHA-1 Fingerprint of the certificate: A4:B5:25:55:6C:36:FC:36:1A:36:BA:CA:27:A4:48:F2:4E:F9:E5:F3
    dat dan eventueel als uitzondering moet worden geaccepteerd.

LetsEncrypt kan op het eigen domein/IP adres een certificaat maken dat je daar op de FB dan importeert. Het te valideren IP/domein moet voor LE (alszijnde CA-autoriteit) ten tijde van (certificaat) aanmaak/vernieuwing, bereikbaar zijn.

Voor een (FB poort forwarded) achterliggend apparaat moet voor het LE validatie proces, tijdelijk via FB poort 80/443 worden doorgesluisd, het betrokken domein in DNS moet (extern) verwijzen naar het betrokken IP adres; zodat LE in dat externe adrespad de aanvraag qua bereikbaarheid kan toetsen*.
*De achterliggende LE controlegedachte is: wie zowel de DNS en het geadresseerde apparaat qua IP-adres controleert, zich daarmee authenticeert als rechthebbende. Dat zelf zegt verder niets over een legitimiteit of bedoelingen. Aanwezigheid van een ‘certificaat’ zegt zelf helemaal niets.

Vriendjes willen soms ook via LAN gamen met mijn kinderen, daarom nemen ze hun eigen spullen mee. En ik ben voor mijn werk afhankelijk van mijn thuisnetwerk. Vanuit security gedacht is het niet beveiligen van je LAN ‘omdat die achter een firewall zit’ geen goed uitgangspunt, eigenlijk moeten de services over je LAN net zo goed beveiligd zijn buitenshuis als binnenshuis. WiFi staat ook aan, en je stelt daarmee toch je netwerk bloot aan ‘buitenshuis’, iedereen kan vanaf de straat proberen te hacken.

Wat het certificaat toevoegt is dat je een versleutelde verbinding met je modem hebt, voordat je het hoofdwachtwoord ingeeft om in te loggen. Als een kwaadwillende daar tussen zit kan die je hele LAN te configureren (ontregelen/af te luisteren) is. En ik heb geen idee wat die vriendjes op hun laptop aan malware of virussen hebben staan.

Je kunt prima eigen TLS-certificaten voor een privaat LAN-netwerk gebruiken, zo lang de CA vertrouwd wordt kan je het client certificaat daarmee laten valideren als geldig.
Bijvoorbeeld:

openssl verify -CAfile fritz-ca-cert.pem fritz-ca-cert.pem fritz-client-cert.pem

geeft:

fritz-ca-cert.pem: OK
fritz-client-cert.pem: OK

Met deze constructie heb ik vaker versleutelde verbindingen op een LAN ingeregeld. Alleen heb ik dat nog niet eerder gedaan tussen een browser en de Fritz! Box.

Let’s Encrypt is geen optie, dan moet ik elke maand (een LE-certificaat wordt 45 dagen over een paar jaar) opnieuw een certificaat inregelen.
Helaas haalt een zelfondertekend certificaat vertrouwen in de browser het risico van een MITM-aanval niet weg.

Ik ga eens verder kijken hoe ik dit kan inregelen.

Ik heb al wel gevonden dat je in Firefox prima je eigen CA kan importern bij about:preferences#privacy onder Beveiliging → Certificaten beheren → Organisaties → Importeren

Mij valt op dat bij de IP-adressen de vaste publieke IP-adressen van mijn verbinding met Freedom staan. Ik weet niet of dat erg is, het zijn adressen voor de CA en ik kan me voorstellen dat die niet nodig zijn een client certificaat te valideren.

Waarom het eigen TLS-certificaat niet werkt met de Fritz! Box is me al iets duidelijker. Het is weer ochtend, ik heb een paar koppen koffie op en bekijk eens rustig de foutmelding van Firefox:

Foutcode: MOZILLA_PKIX_ERROR_CA_CERT_USED_AS_END_ENTITY

Dus het oploaden van het client certifcaat wil nog steeds niet, vanwege de Fritz! error dat het niet geĂŻmporteerd kan worden, dat het mogelijk niet geldig is, terwijl OpenSSL zegt van wel.
En het in Firefoz importeren van een door Fritz! aangemaakte certificaat (boxcert.cer) maakt https://fritz.box nog niet veilig.

Ik heb ergens gelezen dat Fritz! geen EC-certificaten aan zou kunnen, alleen RSA. Ik ga het eens opnieuw proberen met RSA. Ook al moet RSA worden uitgefaseerd volgens het NCSC.

Als je je hier zorgen over maakt, dan zou ik per direct de Fritzbox het raam uitkieperen en een fatsoenlijke oplossing aanschaffen, want je hebt (terechte) zorgen, maar geen adequate mogelijkheden tot je beschikking om de risicos af te dekken.

Het lijkt me duidelijk dat je een VLAN wil wat voor je interne spul is, met aparte wifi-netwerken (als die al nodig zijn). Daarnaast heb je een “publiek” VLAN, dat gebruikt alles en iedereen, inclusief eigen telefoons e.d. Toegang tot admin interfaces van bijvoorbeeld je modem gaat via een ander apart VLAN, etc. etc. Meerdere laagjes dus, en de specifieke vraag wie moet nu eigenlijk bij wat kunnen, en heb je daar misschien een VPN techniek voor nodig om in zo’n VLAN te kunnen komen.

Dat certificaat van je lost helemaal niks op. Het moet uberhaupt al onmogelijk zijn om via http een verbinding te maken met het Fritzbox, en een self-signed certificaat is zo veilig als een eigen certificaat op het moment dat je je zorgen maakt om afluisterpraktijken, maar geen externe CA kunt gebruiken om de Fritzbox te identificeren. Waarom kunnen mensen eigenlijk al bij je Fritzbox komen, moet je je eerder afvragen, en waarom is dat dan nodig. Nogmaals, laagjes.

Zoiets heb ik ooit opgelost met een 2e fritzbox aan de gasten LAN van de eerste.

Dat gevoel krijg ik ook, er zijn anderen die klagen over dat ze alleen RSA kunnen gebruiken..

De vraag die bij mij opkomt is, wat voldoet dan wel?

  • Vriendjes en gaming PC’s op het gastennetwerk?
  • Een betere modem? (Welke?)
  • Een decente firewall met VLAN ondersteuning, zoals OPNSense?

Ik blijf het vreemd vinden dat je denkt dat het certificaat zelfondertekend is? De CA is zelfgegenereerd ja, maar het client certificaat is dat niet.
Betekent dat dan ook dat de versleutelde verbinding die ik op deze manier gebruik tussen een database server en een applicatieserver niet veilig genoeg is?

Het lijkt me wel dat dit gewoon mogelijk moet zijn, bijvoorbeeld deze SO thread geeft ook aan dat het moet kunnen. Of lees ik iets verkeerd?

Ik zou zeker alle apparaten die niets te zoeken hebben bij werk computers, eigen computers, nas, routers, tvs, zonnepanelen, autoladers, weet ik veel, apart willen zetten. Mijn telefoon bijvoorbeeld hoeft nergens bij, maar mijn werkstation weer wel. Mijn wasmachine die zo nodig het internet nodig heeft, heeft ook niks te zoeken bij mijn telefoon of mijn werkstation. Dat is typisch VLAN + firewall werk. Er zijn hier mensen met ervaring met opnsense, ik zelf doe veel met OpenWRT. Ik denk dat deze system dit allebei kunnen. Het belangrijkste hier is wat je zelf denkt dat afgeschermd moet zijn, waarbij je ook moet bedenken dat in termen van “zones”, je zones kan creeren (bv via VLANS) en via de firewall kan aangeven hoe verkeer tussen die zones mag lopen. Bijvoorbeeld, je werkstations mogen bij de TVs, het internet en je zonnepanelen/laders, maar omgekeerd mogen je TVs alleen bij het internet, en je zonnepanelen helemaal nergens bij (bijvoorbeeld omdat je ze lokaal uitleest, en dat helemaal niet via de cloud van een leverancier wenst te doen).

Voor apparatuur, als je bijvoorbeeld kijkt naar een filogic apparaat, dan heb je met een ASUS RT-AX52 (Pro of niet) al een heel aardig ding in huis dat de kracht heeft om een fiberverbinding goed af te handelen en daar nog een heleboel bovenop te doen, maar je moet OpenWRT er wel zelf op zien te krijgen. Voor de fractie van het bedrag van de link hierboven, denk ik dat dat het risico waard is. (Ik heb dit ding zelf op m’n TODO-lijst staan, maar hem nog niet aangeschaft om te zien of de installatie via de UI te doen is.)

Ik heb je waarschijnlijk niet goed begrepen. Als je je eigen CA hebt, dan kun je inderdaad zelf-uitgegeven certificaten vertrouwen, en zien dat er geen man-in-the-middle is. Dat is fijn, (ik doe dat zelf ook, natuurlijk, OpenWRT maakt dat erg makkelijk) maar neemt geen toegang tot je fritzbox weg. Het afluistergevaar, is verdwenen, maar praktisch zou je nooit http moeten doen. Je hebt het nooit gehad over het risico dat je je username/password zou invoeren op een fritzbox die eigenlijk niet jouw fritzbox is, vandaar dat ik er altijd ben uitgegaan dat een self-signed certificaat door de fritzbox zelf net zoveel als je eigen certificaat doet.

Ik denk dat “we” een andere gedachte hebben over certificaten en hun toepassing.
Het gaat niet of je dingen kunt fröebelen door zelf je eigen spullen daarop aan te kunt passen en die met (commando)tools kan controleren etc.etc.

Jij kunt in jouw netwerk voor jouw software/tools, prima de CA zijn wat niet wil zeggen dat een ander daar aangesloten (met hun eigen apparatuur of haar FireFox op zijn laptop) jouw certificaten ondertekend door jouw CA gaat vertrouwen.
Jouw CA maakt simpelweg geen onderdeel uit van FF en een geldige ondertekening qua key, zegt hoegenaamd niets of jouw certificaat te vertrouwen is.
Dat je daarmee, ondanks & who cares, wel kunt versleutelen; is een ander verhaal. Jij in jouw netwerk kan sws het daarmee ondertekende verkeer, afluisteren. Ik als gebruiker moet dus voor jou(w certificaat/ondertekening) een uitzondering maken dat het voor mij/jou, daarmee niet perse veiliger maakt.

Dit zelfde geldt ook voor jouw FritxBox die - terecht - simpelweg jou als CA niet zal vertrouwen en zegt dat jouw Certificaat niet geĂŻmporteerd kan worden. Dat je zou willen dat de FB jouw CA wel accepteert, is dan een kwestie van OpenSource en je dus jouw CA wilt kunnen toevoegen op de FB. Dat gedaan hebbend, maakt jouw netwerk, voor anderen en daarmee jouzelf, niet veiliger.

Enne als hierboven leders gezegd, indien je gebruikers jouw netwerkdiensten onvoldoende vertrouwd, stop ze op hun eigen (gescheiden V)LAN of met Fritz, in het gastennetwerk.
Dan ben je ook af van whateverelse als risico voor jouw thuisnetwerk(zaamheden).

Netwerksegmentatie moet nog even wachten, ik weet bijvoorbeeld nog niet eens of afzonderlijke apparaten op het gastennetwerk elkaar kunnen zien, hoe dat precies werkt. Ik kom er ook niet snel achter als ik ff zoek op internet. Voor LAN games is dat wel nodig. (Antwoord: ja, ik keek net bij de static routing in de Fritzbox).

Maar ook wel fijn dat het met een eigen CA wel moet kunnen werken.
Zo heb ik ook een Synology doos die zelf een CSR kan maken die je met je eigen CA kan tekenen, waarna je de CA kunt importeren op je systeem of in de browser. Dan zou het moeten werken volgens deze link.
Dat lijkt helemaal goed te gaat tot het punt dat ik Firefox herstart en https gebruik,
dan blijft de melding SSL_ERROR_BAD_CERT_DOMAIN, alsof ik nog een DNS moet inrichten. Ik had gehoopt dat het opgeven van een hostname genoeg zou zijn.
Zowel geprobeerd met https://nas als https://nas.local maar nee.

Ook even snel de cert9.db verwijderd uit het Firefox profiel, om te kijken of die tip werkte, ook niet.

En als ik verder kijk naar wat de Fritzbox kan.. je kunt daar geen domeinnamen linken aan lokale IP-adressen, je kunt alleen IP-nummers opgeven van een externe DNS server.

Afgezien van het gastennetwerk aanzetten lijk ik niet veel mogelijkheden te hebben.

Ok dit wordt een groot project denk ik

Domeinen: .local = mdns (geen normale DNS, mdns is afhankelijk van Broadcast in een segmentm en praat niet standaard met andere VLANs). Andere domeinen zijn per definitie port 53 UDP, unicast.
(en hebben een DNS server/forwarder nodig).

Ter inspiratie, ik heb een

  • IoT netwerk: HomeAssistant, WiFi devices, Zigbee router, Geen connectie met internet,
  • CoreLAN: services pi-hole, database, nextcloud, 
, Wired.
  • GastenLAN: WiFi, Wired, QR code hangt in de hal, Koppeling met Internet direct DNS
  • PriveLAN: WiFi voor werk zaken en algemeen intern gebruik, Wired poort op switch in kamer en kantoor beschikbaar, DNS via strikte pi-hole, filter op firewall naar enkele reclamebureaus.

Voor de interne services gebruik ik een homebrew CA (in XCA) deze certificaten zijn trusted op alle eigen apparatuur. Voor services die aan het internet hangen (via HAproxy server), is een Letsencrypt certificaat beschikbaar.

Voor het runnen van services ben ik van een grote server die “alles” deed over gestapt naar een paar NUC type systemen die als een proxmox cluster draaien met een functie per server, met de opslag van schijven op een NAS. (NFS shares).

Aanvulling: voor bediening/gebruik van buitenshuis kan m’n telefoon via een wireguard tunnel bij HomeAssistant en mailserver etc.

Ik vermoed dat je je beeld aangaande gebruik, doel en toepassing van certificaten nog wat moet assimileren.

In FF maak je dan een uitzondering.

Certificaten - zijn niets magisch - worden vaak pas door een legitieme uitgever afgegeven na controle van bijvoorbeeld en/of op grond van een bepaalde DNS aanwezigheid.
Het certificaat van een bank zal daarin vaak andere afgifte checks & balances volgen zoals het (mede) hebben van bv een serie in een kluis opgeborgen hardware (2FA) key(s) en andere voorwaarden e.d.

In het gebruik heeft het domein of een naam daarin, zelf geen enkele relatie anders dan wij als mens daarin menen te lezen.
Dat ik Larry heet, wil niet zeggen dat ik Larry ben.
NB: certificaten kunnen ook verlopen, worden ingetrokken of “locatie” afhankelijk gemaakt zijn waarbij bv systeemdatum/tijd in het controlerend key-proces worden betrokken.

Om jouw aangemaakte certificaat te gebruiken, moet die in FF worden ingeladen en die zal dat imo standaard alleen doen met/voor de reeks van gekende instanties (cert roots).
Jouw zelf gefabriekte certificaat moet in jouw FF dan als uitzondering [via/pad Edit → Preferences → Privacy Security → Certificates ] worden toegevoegd. Hetzij als uitzondering qua apparaat of als zijnde door jou als echt zijnde ondertekend.
Dit laatste gebeurd in FF alleen wanneer jij als “uitgever” in de betreffende server (in houw geval de FritzBox) in het bezit bent van de daarbij horende private-key die dan qua hash moet overeenkomen met het publieke uitgegeven deel.

FWIW. Jouw certiticaat (naast andere zaken) bestaat o.a. uit publiek -en privatekey deel dat ergens haar plaatsing moet krijgen, dus minimaal twee uitdagingen:

  1. Jouw (private) certifcaat in de FB zien te krijgen en
  2. Jouw (publiek) certificaat in de betreffende FF te frommelen.
    Dit laatste doet FF - middels onderhandeling - alleen voor legitiem uitgegeven instanties.

In beide gevallen zal je met een eigen certificaat, voor de FB of voor die FF worden gezien als “valsspeler”.

Vervolgens op één of beiden, zal je ergens een uitzondering moeten maken. Ik vermoed dat de FB geen zelf gefabriekt ondertekende certificaten zal willen inslikken.
Bij OpenWrt (en FireFox) zal dat wel mogelijk zijn omdat je daar het immers lijstje van toegestane autoriteiten kan aanpassen.

Deze/mijn aandacht op jouw interessante topic omdat het voor mijzelf goed is om dingen weer even een revue te kunnen laten passeren.

Om enige verwarring weg te nemen, het certificaat is alleen voor gebruik op eigen LAN (niet op internet) en het is juist mijn bedoeling om het eigen CA-certificaat in de browsers op te nemen die ik gebruik.

Waar het mij om gaat is dat wanneer ik de FritzBox benader via de webintercface op https://192.168.178.1, geen irritante melding krijg en zeker weet dat aansloten vriendjes van mijn kinderen op het LAN mijn wachtwoord niet kunnen onderscheppen met hun eigen devices waar ze vanalles op kunnen hebben gedownload.

Op andere apparaten zoals de Synology NAS hoort het ook gewoon te kunnen, het is verder geen rocket science, het blijft waarschijnlijk op iets simpels steken dat je even moet weten. Ik kan natuurlijk een DNS service starten op de NAS en de FritzBox er naar laten verwijzen, maar daar wordt het ook niet echt eenvoudiger van om het DNS-verkeer ook weer te versleutelen.

Duidelijk is dat ik het onderwerp nog verder moet uitdiepen voordat ik HTTPS kan gebruiken.

Dan heb je met een FB een verkeerde implementatie voor ogen, naast dat de software daarvan; het door jou ondertekende certificaat simpelweg niet zal zien als legitiem uitgegeven.
Hou hierbij in gedachten dat de FB het certificaat gebruikt voor/met haar extern verkeer dat niet jouw LAN is.

Jou insteek lijkt MITM te willen voorkomen waar het selfsigned van de FB imo al prima in voorziet. Het feit dat mensen “verkeer” kunnen waarnemen, wil niet zeggen dat zij daarmee dan ook “inzage” hebben.
Die “irritante melding” - die je kunt onderdrukken - is juist om jou en je gebruikers daarvan in kennis te stellen.

Indien je geen vertrouwen schept in wat de FB (je) uit doos biedt, kan je kiezen om een gekend certificaat van erkende andere te laden.

Tot mijn grote vreugde kan ik meedelen dat het is gelukt op mijn Synology NAS te beveiligen via HTTPS met een eigen CA in Firefox!
(Met dank aan dit artikel)

Ik heb de lange touristische route genomen en heb er het e.e.a. van opgestoken, de foutmelding SSL_ERROR_BAD_CERT_DOMAIN is verholpen door de hostname niet het FQDN in te vullen in de CLI, maar met het veld subjectAltName in een apart configuratiebestand dat wordt meegegeven bij het tekenen van de CSR.
(Een eigen CSR op basis van de private key van de NAS.)

De inhoud van het config.txt-bestand:

authorityKeyIdentifier=keyid,issuer
basicConstraints=CA:FALSE
keyUsage = digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment
subjectAltName = @alt_names

[alt_names]
DNS.1 = nas
DNS.2 = nas.fritz.box
IP.0 = 192.168.178.2

Vervolgens is de CA getekend met de optie -extfile:

openssl x509 -req -in server.csr -CA ca.pem -CAkey ca-key.pem -CAcreateserial \
  -out signed.pem -days 3650 -sha256 -extfile config.txt

Dit is voor mij een PoC dat, nu Firefox zonder klagen meteen een vinkje zet bij het adres https://nas, ik veilig kan inloggen zonder bang te hoeven zijn dat de credentials lekken.

Volgende stap: de Fritz! Box zo ver krijgen om hetzelfde te doen.

Fritz!Box + HTTPS = gelukt!

TL;DR

Met OpenSSL:

  1. Maak een CA (“Certificate Authority”) key en certificaat aan
  2. importeer het certificaat in de browser
  3. Maak een key en CSR of (“Certificate Singing Request”) aan
  4. Teken de CSR met de CA
  5. upload de certificaten naar de Fritz!Box

Stap 1

CA key aanmaken (met wachtwoord):

openssl genrsa -aes256 -passout -out ca-key.pem 4096

Controleer of het wachtwoord klopt:

openssl rsa -in ca-key.pem -check -noout

CA certificaat aanmaken:

openssl req -new -x509 -sha256 -days 3650 -key ca-key.pem -out ca.pem

Stap 2
Certificaat importeren in Firefox:
Bij about:preferences#privacy → Beveiliging → Certificaten beheren → Organisaties → Importeren
 het bestand ca.pem uploaden → Deze CA vertrouwen voor het identificeren van websites aanvinken → OK → OK → Firefox herstarten (voor de zekerheid)

Stap 3
Client key aanmaken voor de Fritz!Box (met wachtwoord):

openssl genrsa -aes256 -out fritz.key 4096

CSR aanmaken met de client key:

openssl req -new -key fritz.key -out fritz.csr

Stap 4

Maak het bestand config.txt met de volgende inhoud:

authorityKeyIdentifier=keyid,issuer
basicConstraints=CA:FALSE
keyUsage = digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment
subjectAltName = @alt_names

[alt_names]
DNS.1 = fritz.box
IP.0 = 192.168.178.1

Teken de CSR vanuit de CA en gebruik daarvoor het CA wachtwoord. Maak geen nieuw wachtwoord aan als daarom wordt gevraagd:

openssl x509 -req -in fritz.csr -CA ca.pem -CAkey ca-key.pem -CAcreateserial \
  -out fritz-signed.pem -days 3650 -sha256 -extfile config.txt

Controleer dat het client certificaat geldig is:

openssl verify -CAfile ca.pem fritz-signed.pem
fritz-signed.pem: OK

Stap 5

Voeg de client key en het client certificaat samen in 1 bestand:

cat fritz.key fritz-signed.pem > fritz-chain.pem

Log in op de Fritz!Box en ga naar Internet → Permit Access → Fritz!Box Services # User’s Own Certificate

Upload daar het bestand fritz-chain.pem en geef het wachtwoord in van de client key van stap 3.

De Fritz!Box geeft dan de melding Import of the ssl certificate was succesful.

Nu kan je veilig op je modem inloggen via https://fritz.box .

Details

Er is maar 1 invoerveld in de Fritz!Box om zowel de client key als het client certificaat te uploaden. Beide moeten tegelijk worden geupload. Dit kan door de bestanden achter elkaar te zetten. (vandaar het cat commando)

De bestanden moeten in PEM formaat zijn, en de Fritz!Box kan alleen met RSA-certificaten overweg, zie de handleiding.

RSA is niet heel veilig meer, gebruik een RSA modulus van 3072 of liever 4096.

:+1: Cool dat je de FB zo met je eigen certifcaat hebt weten te laden. Het proces verder overeenkomt met bv een LetsEncrypt aangemaake versie. Ook goed om opnieuw te vernemen dat de FB alleen met RSA overweg kan.


//--// Let wel dat een zelf aangemaakt certificaat strikt genomen voor een ander (dan reeds jou/w aangepaste software/apparaten), onbetrouwbaar kan ogen omdat het certificaat geen deel uitmaakt van de TrustList waar anderen zoals LetsEncrypt of GoDaddy, wel lid van zijn. Dit laatste kan dan weer voor jou een "feature" zijn.