Maak je eigen SSL certificaat

[Martijn85]

Wat is een SSL certificaat

Ik ga er vanuit dat je optware al geïnstalleerd hebt zodat je IPKG commando`s kan uitvoeren.
Heb je optware nog niet geïnstalleerd, bekijk dan deze pagina.

Login op je DiskStation via SSH of Telnet met de gebruiker: root

We moeten eerst openssl geïnstalleerd hebben om een certificaat aan te kunnen maken. Om openssl te installeren voeren we het volgende commando uit:

Code: [Selecteer]

ipkg install openssl
Nu kunnen we een certificaat aanmaken.

We gaan het certificaat opslaan naar een map waar we gemakkelijk bij kunnen komen, hiervoor gaan we de map public, type hiervoor het volgende commando:

Code: [Selecteer]

cd /volume1/public
Nu gaan we het certificaat aanmaken, type hiervoor het volgende commando:

Code: [Selecteer]

openssl req -nodes -newkey rsa:2048 -keyout server.key -x509 -days 365 -out server.crt
Volg nu de instructies, je kunt hier de gegevens naar eigen wens invullen. Als je certificaat is aangemaakt kun je deze terug vinden in je public map.

Je kunt het certificaat gebruiken voor bijvoorbeeld je web server die op de DiskStation staat.

[9-10-2014, Toevoeging door Briolet: Op DSM 5.0 staat OpenSSL al geïnstalleerd, alleen de config file die voor de certificaat aanmaak nodig is, ontbreekt op de standaard lokatie. Je kunt echter een eigen config file gebruiken door achter het commando '-config openssl.cnf' te plakken. Je moet dan alleen nog ergens een config file opduikelen]

[Briolet]

NB OpenSSL maakt standaard een certificaat met een SHA1 algoritme. Dat is nog steeds sterk genoeg, maar door de toegenomen rekenkracht wordt verwacht dat dit binnen afzienbare tijd kraakbaar wordt.

Daarom hebben Firefox en Chrome al aangekondigd in de toekomst te stoppen om deze certificaten als veilig te bestempelen. Beter is het om een SHA2 codering te gebruiken. Een onderdeel daarvan is SHA 256. Door toevoeging van "-sha256" aan bovenstaande code maak je een certificaat met deze sterkere hash.

Code: [Selecteer]

openssl req -nodes -sha256 -newkey rsa:2048 -keyout server.key -x509 -days 365 -out server.crt
Overigens is het op de iMac voldoende om alleen bovenstaande regel in te vullen in de terminal van de mac zelf omdat daar OpenSSL al aanwezig is. Je hebt wel minimaal OpenSSL version 0.9.8o nodig voor de SHA256 codering maar dat is onder Mavericks in elk geval aanwezig. (Net getest)

[TopGear_1542]

Misschien een hele domme vraag, maar wat is het verschil tussen een zelfondertekend certificaat via de UI en de manier waarop jullie het beschrijven?

[TonVH]

Ik heb me nooit verdiept in die certificaten maar is het niet zo dat ze alleen zin hebben als ze ook bij een neutrale instantie gedeponeerd zijn zodat elke browser en meer ze kan controleren. En die instantie zal dat vast niet gratis doen. Dus met maken ben je er nog niet.

[TopGear_1542]

Bedankt voor je reactie om te beginnen.

Het voordeel van een certificaat aanschaffen bij een erkende instantie is dat certificaten door de browser geaccepteerd zullen worden en dat je geen melding krijgt dat het certificaat ongeldig is. Een zelf gemaakt certificaat kan je ook importeren in je browser of besturingssysteem. Daarmee omzeil je de melding van het ongeldige certificaat. Als er ook andere (externe) mensen gebruik maken van je NAS, zullen zij nog steeds deze melding krijgen. Het gaat mij om het verschil tussen het aanmaken van het certificaat zoals hierboven beschreven of via de UI van DSM.

[Jozef]

Je moet toch elk certificaat installeren in je besturingssysteem, ongeacht of deze via de GUI van DSM gemaakt is of dmv een andere organisatie, of ben ik nu abuis?

Voor bv Explorer is dat dan genoeg maar voor Google moet je hem nog importerern in de browser.

[Babylonia]

Zelf kon ik met benadering via verschillende PC's altijd met enkel een opkomende waarschuwing van "onveilige website" en dan toch vertrouwen ermee wegkomen. In Firefox een paar schermpjes doorlopen om het ergens op te slaan / vast te leggen, van hetgeen kennelijk automatisch reeds via de internetverbinding meekomt?
Dat hele extra gedoe wat in het begin van de draad wordt aangegeven, me daar nooit mee bezig gehouden.
Dus ik snap eigenlijk niet al dat extra werk wat mensen doen?

[Briolet]

van hetgeen kennelijk automatisch reeds via de internetverbinding meekomt?

Ja, met een verbinding wordt het certificaat (Public key) meegestuurd zodat het systeem hem met zijn eigen kopie kan vergelijken. Via een browser kun je hem simpel via het slotje bekijken. Een certificaat van een mailprogramma is lastiger, maar kun je toch nog via b.v. Wireschark bekijken als je het verkeer aftapt.
Op de Mac is het heel simpel om een self-signed certificaat aan je systeem toe te voegen tijdens de eerste inlog of verbinding met een mailprogramma. Firefox bied ook een relatief simpele optie om vanuit de verbinding dat certificaat op te slaan. Chrome is een ellende en kan dat niet. Met IE heb ik geen ervaring.

Het 'gedoe' uit de eerste post stamt uit 2012, toen Synology nog niet zelf de optie bood om een certificaat te maken. Dat is nu niet meer strikt nodig. Maar bij mijn weten maakt Synology een certificaat met een SHA-1 ondertekening en in elk geval twee browser fabrikanten hebben afgelopen maand aangegeven onderscheid te gaan maken tussen SHA-1 ondertekening en sterkere ondertekeningen. Dit om de certificaatverstrekkers alvast te pushen om dit bij een volgende uitgave aan te passen. Zie ook Einde+SHA-1+probleem+voor+Windows+XP+SP2+en+Android+2_2

Dus bovenstaande methode kan nog steeds handig zijn voor mensen die meer controle over het eigen certificaat willen hebben.

Dit topic gaat over self-signed certificaten. Certificaten die door een bekende root autoriteit ondertekend zijn is een heel ander verhaal en hoort niet in dit topic thuis.

[Babylonia]

Maar ik mag toch wel aannemen indien meerdere browsers met SHA2 coderingen gaan werken dat Synology niet stil blijft zitten en waarschijnlijk ook wel met een update van hun certificatenproblematiek zal komen?

[Jozef]

Ook bij chrome is het eenvoudig hoor om een certificaat te installeren, gewoon in de advanced settings bij SSL,duurt 10 seconden

[Briolet]

Je hebt waarschijnlijk gelijk voor Windows, maar op de mac laat chrome de certificaatbeheer volledig over aan het OS. Als je daar de advanced settings opent, wordt je direct doorgestuurd naar het sleutelhanger programma op de mac.
Als de inlog URL overeen komt met de naam in het certificaat, dan is er niets aan de hand bij Chrome. Wijkt het af, b.v. omdat je met je interne IP inlogt, dan is het onmogelijk dit te valideren zoals bij Safari wel kan.

En dan vraag ik me nu af of je met een helemaal zelf gegenereerd certificaat niet meerdere geldige URL's kunt toevoegen… Dit is tenslotte een tweaks draadje.

[Jozef]

Hoi Briolet, weet niet zeker of ik helemaal begrijp wat je bedoeld maar intern beveiligt inloggen lijkt me niet zinvol toch?

En waarom wil je meerdere externe URL's hebben in je certificaat? Kun je aangeven wat daar het voordeel van is? Ik kan het dan wel proberen door ze in te geven met een scheidingsteken.

[Briolet]

Intern beveiligd inloggen is inderdaad weinig zinvol. Maar als je de nas ingesteld hebt om een http automatisch in een https om te zetten, ontkom je er intern ook niet aan. En als je router geen nat-loopback kent, kun je intern je url niet gebruiken.

Meerdere url's kan voorkomen als je "mijndomein.nl" gebruikt, maar ook "www.mijndomein.nl", "mail.mijndomein.nl", etc wilt gebruiken. Ik heb nu b.v. een "imap.mijndomein.nl" aangemaakt, maar op mijn tablet moet in nu instellen om certificaat controle over te slaan omdat hij het anders niet pikt. Op mijn mac-mail programma was het genoeg om éénmalig aan te geven dat ik "imap.mijndomein.nl" vertrouw voor een "mijndomein.nl" certificaat. Dat is al beter dan de android 2.2 optie waar ik direct de gehele controle moet overslaan.

[Briolet]

Multiple domain names zijn toch mogelijk in een certificaat: Wildcard_certificate.

Ik zal daar dus eens mee gaan experimenteren.

[Martijn85]

Maak ik ook gebruik van. Werkt prima voor alle subdomeinen.