Synology-Forum.nl
Tweaks / Addons A.K.A. The Underground => Algemeen => Topic gestart door: Briolet op 11 oktober 2014, 09:42:56
-
(Edit: zie voor DSM 6.x ook verderop in dit draadje vanaf hier (https://www.synology-forum.nl/algemeen/maak-je-eigen-multie-domein-ssl-certificaat/msg188244/#msg188244))
Sinds DSM 5.0 kun je in DSM je eigen self-signed certificaten maken zodat de meeste mensen niet met code in de weer hoeven voor de aanmaak. Wil je wat meer dan de standaardinstellingen, dan moet je toch zelf aan de slag. Hieronder volgt een handleiding hoe je zelf een self-signed certificaat maakt die meerdere domeinen gelijktijdig signeert. Dan kun je b.v. naast je 'domeinnaam.nl' ook subdomeinen in je certificaat opnemen, zoals www.domeinnaam.nl, *.domeinnaam.nl (wildcard voor alle subdomeinen), een compleet andere domeinnaam of het interne IP adres van je nas.
Configureer ssl verzoeken met 'SubjectAltName' via openssl
Met meervoudige domein certificaten kun je een groter aantal domeinen via één enkel certificaat beveiligen. SubjectAltName's zijn een X509 versie 3 (RFC 2459 (https://www.ietf.org/rfc/rfc2459) punt 4.2.1.7) uitbreiding die het toestaat om in één ssl certificaat meerdere namen op te nemen die moeten matchen. SubjectAltName kan e-mail adressen, IP adressen, DNS hostnamen, nasnamen etc bevatten. SubjectAltName zal hier verder tot SAN afgekort worden.
Voorbereiding op de NAS
De nas wil het certificaat uiteindelijk van de PC importeren dus laten we het certificaat in de homefolder aanmaken. In deze home folder creëren we een map met de naam OpenSSL en plaatsen hierin de openssl.cnf file die in het attachment van deze message staat.
Nu loggen we in op de nas via de termimal/putty en zetten de current directory op de OpenSSL folder die net in de homefolder geplaatst is.
cd /volume1/homes/<account>/OpenSSL<account> is de naam van het account waarmee je in de homefolder inlogt.
Voorbereiding op de iMac
Als je een mac hebt, hoef je het certificaat niet op de nas aan te maken, maar kunt dat ook op je mac doen. Creëer dan de OpenSSL folder in je User folder en plaats de openssl.cnf file in deze folder. Je opent vervolgens het Terminal programma en typt in : 'cd OpenSSL' Hierna gaat alles weer gelijk aan de beschrijving voor de nas.
Genereren van de 'Certificaat Request' file
Voor een algemene SSL Certificaat Request (CSR), hoef je niet moeilijk te doen met openssl. Omdat we een paar SAN's aan ons CSR toe willen voegen moeten we een paar toevoegingen plegen aan de openssl conf file. En dan met name de x509 V3 extensie met de SAN's. Deze toevoeging is in bijgevoegde conf file al gebeurd, alleen moeten de domeinnamen etc. nog naar eigen behoefte aangepast worden.
Aanpassen van de openssl.cnf file
In de config file staan twee secties die naar behoefte aangepast moeten worden. (# Dat aanpassen doe je met een code-editor, zie opmerking op het einde) De eerste is de [req_distinguished_name] sectie:
[ req_distinguished_name ]
countryName = Country Name (2 letter code)
countryName_default = NL
countryName_min = 2
countryName_max = 2
stateOrProvinceName = State or Province Name (full name)
stateOrProvinceName_default = Mijn Provincie
localityName = Locality Name (eg, city)
localityName_default = Mijn Plaats
0.organizationName = Organization Name (eg, company)
0.organizationName_default = Mijn Firma b.v.
# we can do this but it is not needed normally :-)
#1.organizationName = Second Organization Name (eg, company)
#1.organizationName_default = Mijn andere Firma b.v.
organizationalUnitName = Organizational Unit Name (eg, section)
#organizationalUnitName_default = Mijn afdeling
commonName = Common Name (e.g. server FQDN or YOUR name)
commonName_default = mijndomein.nl
commonName_max = 64
emailAddress = Email Address
emailAddress_default = info@mijndomein.nl
emailAddress_max = 64
Dit stuk hoef je niet perse aan te passen. Dit zijn de vragen die je gedurende de aanmaak krijgt en de default antwoorden. Als je echter de default antwoorden alvast naar eigen wens aanpast, hoef je later alleen maar een aantal keer <return> te geven op de vraag. Als je wilt dat er twee firmanamen in het certificaat staan, omdat je de nas voor meerdere firma's gebruikt, dan kun je het '#' teken wissen waarna je de optie van een tweede firmanaam krijgt. Je kunt zo ook een derde of vierde toevoegen door het tellertje op te hogen. Wil je ook nog een afdeling op het certificaat, dan moet je ook daar de '#' weghalen.
Het tweede deel dat je moet aanpassen is de [alt_name] sectie:
[ alt_name ]
DNS.1 = mijndomein.nl
DNS.2 = *.mijndomein.nl
DNS.3 = mijntweededomein.nl
DNS.4 = mijnderdedomein.nl
IP.1 = 10.0.1.10
IP.2 = 10.0.1.23
email.1 = pietje@mijndomein.nl
email.2 = pietje@mijntweededomein.nl
URI.1 = https://mijndomein.nl
Je kunt hier DSN, IP, email en URI namen toevoegen. Je kunt elke hoeveelheid toevoegen als het tellertje maar steeds correct opgehoogd wordt.
Merk op dat de domeinnaam die in de req_distinguished_name sectie staat, niet meer gebruikt wordt als je de alt_name gebruikt, dus je domeinnaam moet ook daar nog eens herhaald worden.
Met *.mijndomein.nl creëer je een wildcard die elke toevoeging voor je domein accepteert. Het 'kale' domein valt niet onder de wildcard en moet je dus ook nog vermelden.
Aanmaak van de privé sleutel
De privé sleutel maak je nu aan met:
openssl genrsa -out private.key 2048Hier is 2048 de sleutellengte. Je kunt ook 1024 of 4096 kiezen. Des te langer de sleutel, des te trager gaat het ver- en ontsleutelen, maar des te veiliger wordt hij. 2048 geldt echter als een veilige waarde terwijl de 1024 bit nu nog veilig is maar men verwacht dat dit in de nabije toekomst kraakbaar wordt. Veel software zal in de toekomst geen 1024 bit sleutels meer accepteren.
Aanmaak van de CRT file
De CRT file maak je met:
openssl req -new -out public.crt -key private.key -config openssl.cnfJe krijgt nu een aantal vragen die je in kunt vullen. Als je alleen een return geeft, wordt de default waarde uit de config file gebruikt. Alleen bij de vraag over een 'challenge password' vul je niets in, want dat wil je niet.
Zo, nu hebben we een mooi certificaat (CRT), maar het is nog niet getekend. Dit laten we echter niet door een CA doen, maar doen het zelf.
Zelf ondertekenen van het certificaat
Het ondertekenen doen we met:
openssl x509 -req -sha256 -days 3650 -in public.crt -signkey private.key -out public.crt -extensions v3_req -extfile openssl.cnf'-sha256' is het gebruikte handtekenings algoritme. Je kunt hier ook het minder veilige '-sha1' gebruiken voor compatibiliteit met oude software.
'-days 3650' is de geldigheids duur in dagen. Nu is het 10 jaar.
Installeren op de nas
Copieer de 'public.crt' en 'private.key' file die net in de OpenSSL folder gecreëerd zijn, naar je PC. Vervolgens log je in op DSM, ga naar de Certificaat tab onder beveiliging en kies "Certificaat importeren'. Nu vul de eerste twee velden voor 'persoonlijke sleutel (=private.key) en Certificaat (=public.crt) in. Een intermediate certificaat gebruiken we niet. Als je nu OK kiest zal DSM het certificaat installeren.
# Als je code met een tekstverwerker aanpast komen er onzichtbare tekens in die de boel doen vastlopen. Je moet dus een echte code editor gebruiken. Voor Windows is dat b.v. 'Notepad++' Dus geen Notepad, want die verminkt de boel indien verkeerd ingesteld. Voor de Mac is dat TekstEdit (in de mode 'platte tekst') of TextWrangler.
Als je op de mac trema's gebruikt in de tekst van de config file, kan het gebeuren dat ze verminkt in het certificaat komen. Mocht je hier tegen aan lopen, save de file dan expliciet in het utf-8 formaat met Textwrangler.
-
Top! Thx m8 :-)
-
Ik hoop dat het zo opgeschreven is dat ales duidelijk is. Het blijft een technisch verhaal en staat daarom toch in 'tweaks' en niet in 'algemeen'. Laat weten of er iets fout in staat, dan zal ik dit in het originele bericht verduidelijken.
De default configuratie file van openssl staat in: /etc/ssl/openssl.cnf. Maar toch gebruikt OpenSSL deze niet. Volgens de website van openssl.com is dat een vaker voorkomend probleem en zij noemen het een bug als het zo 'gebroken' geïnstalleerd is. Maar dat geeft hier niet omdat we toch een eigen openssl.cnf file gebruiken.
-
Ik had de SubjectAltName alleen met Safari, chrome en Apple Mail getest. (Alles de Mac versie) Die ondersteunden het allen perfect, na één keer importeren en toestaan werkt het direct voor alle andere hosts. Sterker, omdat hij in de sleutelhanger komt en Safari, Chrome en mail die sleutelhanger ondersteunen, hoef je maar eenmalig het ceriticaat te accepteren en hij is dan ook direct geldig in de andere programma's.
Firefox blijkt deze SubjectAltName niet te ondersteunen. Voor elk domein krijg ik de certificaatvraag opnieuw en moet het certificaat expliciet toestaan. Ze worden dan bij de certificaten onder het kopje 'servers' opgeslagen. Hij staat er onder het hoofd domein met de urls die je zelf als geldig hebt gespecificeerd. Eigenlijk zoals vroeger met één dus hij kijkt niet naar het SubjectAltName veld. Valt me tegen van deze browser.
Dan vraag ik me nu af hoe dat met de Windows versie van Chrome is en met IE en Outlook
Mij viel wel op de het Synology.me certificaat bij Firefox ook onder het kopje 'Servers' staat, maar dat mijn vorige certificaat onder het kopje 'Authorities' vermeld was.
-
Ik ben vanochtend nog even met Firefox in de weer geweest. Het is (gelukkig) niet mijn standaard browser. Het certificaat beheer is toch een beetje ellende. Als ik de site via een andere poort benader, moet ik weer een exceptie toevoegen. Op de certificaat pagina zie je onder je certificaat alle excepties staan met de gebruikte url en poort.
Ik dacht slim te zijn en het certificaat te importeren via de 'import' button. Nu staat dit geïmporteerde certificaat ook onder de exceptions met een *. Echter, nu werkt niets meer. De reeds bestaande excepties werken nog, maar nieuwe kun je niet meer toevoegen.
Ik heb een keer alles gewist, cache geleegd en afgesloten. Nieuw opstarten en certificaat importeren. Als ik nu naar de site ga krijg ik toch een certificaatfout, maar ik mag geen exception toevoegen. Wis ik de exception met een *, dan werkt alles weer.
Ik heb hetzelfde gedaan met de website van een kennis die een synology.me certificaat gebruikt. Ik heb daar ooit een exception voor gemaakt in firefox. Voor de aardigheid heb ik zijn certificaat eens via de 'import' button toegevoegd. Hij komt nu ook met een * onder exceptions te staan, maar ik kan zijn site nu niet meer benaderen. Ik blijf hangen in de certificaatfout zonder mogelijkheid een verdere exception toe te voegen. Delete ik de exception met een * weer, dan werkt alles als vanouds.
Mijn conclusie: het certificaatdeel van Firefox is bagger. Als je een certificaat importeert werkt het niet. Beter niet importeren en elke keer een exception toevoegen. :!:
------
Ik heb voor de compleetheid ook nog eens de Opera browser geprobeerd. Dat werkte in één keer voor alle domeinnamen, zonder iets te hoeven configureren. Maar Opera gebruikt op de mac ook de systeem-sleutelhanger om wachtwoorden en certificaten te valideren. (Net als Safari en Chrome).
-
Ik heb het stappenplan helemaal doorlopen. Alles gelukt, zonder problemen. Bij het openen van de firmware middels interne IP adres in Chrome (versie 38.0.2125) en in IE krijg ik toch een foutmelding. Terwijl het IP adres toch echt in het multi domain certificaat is opgenomen. Heeft iemand al ervaring met een Windows computer? Kan ik iets vergeten zijn?
-
Ik denk niet dat je iets vergeten hebt. Maar misschien moet er nog een veld in de config file aangepast worden om een browser te dwingen dat SAN veld te gebruiken. Of een heleboel browsers ondersteunen deze feature niet. Het document waarin deze versie 3 uitbreiding met de SAN besproken wordt (Link in mijn oorspronkelijke bericht) stamt uit 1999. Dat is 15 jaar geleden, dus gaat het hier niet om een heel nieuw iets wat browsers nog niet kennen.
Naar aanleiding van je melding heb ik nog een oude versie van de Opera browser geprobeerd die zelf nog de certificaten beheert. Ook die kon niets met die multi domeinen. Bij mij zijn het wel 3 browsers die het wel doen, maar strikt beschouwd gebruiken ze alleen een systeem routine voor verificatie, dus is het bij mij steeds het mac systeem dat de uitbreiding wel ondersteunt.
Er op lettende viel mij deze week op dat security.nl ook het SAN veld gebruikt. Alleen staat daar maar 1 domein vermeld die gelijk is aan het hoofd domein dus dan maakt het niet uit welk veld de browser gebruikt.
Ook google.com gebruikt meerdere SAN's. Ik zie er nu maar twee maar las dat ze wel eens over de 40 in dat veld hadden staan. Een ander werkend voorbeeld is https://www.digicert.com/. Dus als die wel met de browser werken, moet er toch nog iets missen in mijn beschrijving.
Maar ik zal nog eens flink zoeken of er iets aan te passen is zodat bij mij ook Firefox gaat werken.
Volgens deze pagina: subject-alternative-name-compatibility (https://www.digicert.com/subject-alternative-name-compatibility.htm), zouden de meeste browsers het sinds 2003 al moeten ondersteunen.
Edit: in dit bericht (http://www.michaelm.info/blog/?p=1281) uit 2013 lees ik dat Chrome en IE het IP veld niet inlezen. (Bug in die browsers)
-
Bedankt voor je reactie en al het uitzoek werk!
Ik heb nog een keer de hele routine doorlopen en valt me op dat er bij het genereren van de private.key staat:
WARNING: can't open config file: /usr/syno/ssl/openssl.cnf
Allereerst kijkt hij dus niet naar de directory waar ik op dat moment in sta. En als ik vervolgens navigeer naar de directory die wordt aangegeven kom ik niet verder dan /usr/syno/. Ik kan de map ook niet aanmaken in deze map, omdat ik daarvoor onvoldoende rechten heb (uiteraard ben ik aangelogd als admin). Nu blijkt bij het creëren van de private.key en het certificaat dat hij waarschijnlijk helemaal niet gekeken heeft naar het config bestand.
@Briolet: Ben jij dat ook tegengekomen? Of heb je een idee wat ik hier verder mee kan?
-
Ik krijg dezelfde waarschuwing, maar het gegenereerde certificaat is identiek aan die op de mac gegenereerd wordt. En daar krijg ik de waarschuwing niet, dus neem ik aan dat die eerste instructie die config file niet echt nodig heeft. En de '-config' parameter voor het selecteren van de eigen config file werkt niet bij de private key generatie. (Net geprobeerd)
Dat die config file niet vanzelf gevonden wordt is een bug in dsm. De file staat op
/etc/ssl/openssl.cnf
maar OpenSSL staar ingesteld op
/usr/syno/ssl/openssl.cnf
Één oplossing is de file te copieren naar waar hij hem wil hebben:
GedeeldeData> mkdir /usr/syno/ssl
GedeeldeData> cp /etc/ssl/openssl.cnf /usr/syno/ssl/openssl.cnf
Dus een 'ssl' directory aanmaken en dan de interne config file er naar toe kopiëren.
Dat is vast ook aan te passen door de link naar de config file te veranderen.
-
…kom ik niet verder dan /usr/syno/. Ik kan de map ook niet aanmaken in deze map, omdat ik daarvoor onvoldoende rechten heb (uiteraard ben ik aangelogd als admin).
Ik ben ervan uit gegaan dat je als 'root' ingelogd bent. Ik lees nu het woord 'admin'. Als je dat gebruikt, klopt het dat je geen map in het systeemdeel kunt aanmaken. Je moet inloggen als gebruiker "root' met het admin wachtwoord.
(Of het sudo commando gebruiken, maar dat is omslagtig)
-
Geen idee wat ik fout doe maar ik krijg:
openssl req -new -out public.crt -key private.key -config openssl.cnf
Error Loading request extension section v3_req
4147517064:error:220A4076:lib(34):func(164):reason(118):NA:0:value=192.268.0.201
4147517064:error:22098080:lib(34):func(152):reason(128):NA:0:name=subjectAltName, value=@alt_name
DiskStation>
Sorry heb het al gevonden had typfout gemaakt
-
Je kunt dit ook gewoon doen via het configuratiescherm van DSM. Kun je ook geen type fouten maken.
Beveiliging > Certificaat > certificaat maken
-
Ik wil even een aanvulling geven op de certificaat.
Ik zie allemaal zoveel verhalen terwijl het voor € 12,00 p/jr ontzettend makkelijk te doen is.
Mijn stappen zijn als volgt.
SSL aangevraagt bij Xolphin en dan SSL via RapidSSl doen. Die is het snelst en de perfecte ondersteuning.
Dat alles is in 10 minuten gebeurt. (Mits er een domein voor handen is.)
Dan kan je is je DSM 5.0 alles invoeren, en ff wat makkelijker is om een sub-domein aan je domein te hangen.
Dus al die mappen maken en al die tekens in voeren zoals Briolet doet, is niet meer nodig.
-
Update: Via Synology maak je sinds DSM 6.0 ook multidomein certificaten aan.
In DSM 6.0 zit de optie om Multi-domein certificaten te maken via Let's Encrypt. Deze zijn gesigneerd door Let's Encrypt dus geven geen browser waarschuwingen.
Als je om wat voor reden dan ook geen certificaat van Let's Encrypt wilt maken, kun je een self-signed certificaat via Synology maken. Er worden dan twee certificaten gemaakt. Het root certificaat en het gebruikers certificaat. Het root certificaat moet je vervolgens in je systeem of browser opslaan om geen foutmeldingen te krijgen.
Persoonlijk vind ik de paginas van Synology een beetje verwarrend, daarom geef ik ze hier nog eens weer. Het zijn twee paginas die bijna gelijk zijn. De eerste pagina is voor de root certificaat (De Certificaat Authority), de tweede voor het gebruikers certificaat. De twee velden met de rode pijl moeten verschillend zijn. Bij de eerste laat je de naam op 'CA' eindigen voor herkenbaarheid.
De certificaten hebben beiden een geldigheid van 10 jaar met een SHA256 handtekeningalgoritme. (kun je niet zelf instellen in de GUI)
(Edit 13-2-2021: Tegenwoordig is de geldigheid van beide certificaten slechts 12 maand)
[attachimg=1]
[attachimg=2]
Dit certificaat heeft nu alle kenmerken uit mijn eerste post. Dus vervalt eigenlijk de noodzaak om hier zelf mee aan de slag te gaan.
Bij de certificaten wordt die domeinnaam automatisch aan de ingevulde alternatieve namen toegevoegd bij het creëren van het certificaat. Je hoeft hem dus niet 2x op te geven zoals bij de introductie van deze optie nodig was.
Tegenwoordig laat Synology toe om een '*' teken in de naam te gebruiken. Deze wildcards zijn echter beperkt mogelijk bij Let's Encrypt certificaten. Vanwege de speciale test die Let's Encrypt doet, werkt dat alleen bij de Synology domeinnamen.
-
Ik wil even een aanvulling geven op de certificaat.
Ik zie allemaal zoveel verhalen terwijl het voor € 12,00 p/jr ontzettend makkelijk te doen is.
Mijn stappen zijn als volgt.
SSL aangevraagt bij Xolphin en dan SSL via RapidSSl doen. Die is het snelst en de perfecte ondersteuning.
Dat alles is in 10 minuten gebeurt. (Mits er een domein voor handen is.)
Dan kan je is je DSM 5.0 alles invoeren, en ff wat makkelijker is om een sub-domein aan je domein te hangen.
Dus al die mappen maken en al die tekens in voeren zoals Briolet doet, is niet meer nodig.
Maar dat is niet onbeperkt toch?
En het is sowieso geen wildcard.
-
Volgens synology support moet je poort 80 open laten staan voor de auto renew van het certificaat. Ik heb mijn firewall van de NAS zei ingesteld dat enkel BE & US zijn toegelaten op poort 80... Ik ben benieuwd of de renew zal lukken binnen een paar weken.
Bedankt voor je uitgebreide info trouwens Briolet.
-
Veel websites draaien onder een www subdomein. Als je dan alleen een certificaat voor die www.mijndomein.nl koopt, zal iemand die met https://mijndomein.nl probeert in te loggen alsnog een certificaat fout krijgen.
En dat is niet theoretisch, want ik ben dat in de praktijk vaker tegengekomen. Een firma geeft alleen een url door zonder www in zijn publicaties. Hij verwacht dan dat mensen dat intikken en dan ge-redirect worden naar het www subdomein met certificaat. Als je dan uit veiligheidsredenen direct https intikt met de opgegeven url, loop je tegen die certificaat error aan.
Een wildcard subdomein toevoegen aan je certificaat lost dit op. Of alle subdomeinen specificeren.
NB ik liep nog tegen een bugje aan in het Synology certificaat maken. Dat heb ik als edit aan mijn vorige bericht toegevoegd, om alle relevante info op 1 pagina te hebben.
-
Update: Via Synology maak je sinds DSM 6.0 ook multidomein certificaten aan.
In DSM 6.0 zit de optie om Multi-domein certificaten te maken via Let's Encrypt. Deze zijn gesigneerd door Let's Encrypt dus geven geen browser waarschuwingen.
Als je om wat voor reden dan ook geen certificaat van Let's Encrypt wilt maken, kun je een self-signed certificaat via Synology maken. Er worden dan twee certificaten gemaakt. Het root certificaat en het gebruikers certificaat. Het root certificaat moet je vervolgens in je systeem of browser opslaan om geen foutmeldingen te krijgen.
Persoonlijk vind ik de paginas van Synology een beetje verwarrend, daarom geef ik ze hier nog eens weer. Het zijn twee paginas die bijna gelijk zijn. De eerste pagina is voor de root certificaat (De Certificaat Authority), de tweede voor het gebruikers certificaat. De twee velden met de rode pijl moeten verschillend zijn. Bij de eerste laat je de naam op 'CA' eindigen voor herkenbaarheid.
De certificaten hebben beiden een geldigheid van 10 jaar met een SHA256 handtekeningalgoritme. (kun je niet zelf instellen in de GUI)
(Link naar bijlage)
(Link naar bijlage)
Dit certificaat heeft nu alle kenmerken uit mijn eerste post. Dus vervalt eigenlijk de noodzaak om hier zelf mee aan de slag te gaan.
Edit: ik zie dat er een bug in het certificaat zit. Als je nml alternatieve namen bevat, wordt het eerdere veld met je domeinnaam niet meer gebruikt. Bij de Let's Encrypt certificaten wordt die domeinnaam automatisch aan de ingevulde alternatieve namen toegevoegd. Bij het Synology certificaat gebeurt dit niet. Dus daar moet je de domeinnaam ook nog eens toevoegen bij de alternatieve namen.
Jammer genoeg laat Synology niet toe om een '*' teken in de naam te gebruiken. Dus een wildcard subdomein aanmaken kan niet via deze methode.
Briolet, ik zou graag willen vernemen wat de vervolgstappen zijn nadat het gebruikscertificaat is aangemaakt en de knop 'toepassen' is geklikt. Zou je dit met een step by step uitleg kunnen toelichten svp?
-
Wat een top post. Dank Briolet en de andere bijdragers!
-
Ik kwam er vandaag achter dat je nu ook een eigen IP adres in het certificaat kunt krijgen via de GUI van Synology voor een self-signed certificaat. Dus ook daarvoor hoef niet niet meer met OpenSSL unixcode uit dit topic aan de gang.
Ik heb net een self-signed certificaat gemaakt en mijn synology ddns naam en het IP van mijn nas bij alternatieve naam ingetikt. Dit wordt nu netjes in het certificaat verwerkt.
[attachimg=1]
Ik heb geen idee hoe lang dit al mogelijk is, maar de vorige keer dat ik dit probeerde kreeg ik een foutmelding.
-
Even een update omdat Synology de geldigheid van de aangemaakte certificaten verlaagd heeft naar 1 jaar, wat een slechte zaak is.
Browsers accepteren sinds eind vorig jaar geen gebruikerscertificaten meer die langer dan 13 maand geleden uitgegeven zijn. Ook al is de ingestelde geldigheid langer. Die 13 maand is gekozen zodat je de certificaten elk jaar kunt updaten en dan nog een speelruimte van 1 maand hebt. Synology is hier roomser dan de paus en maakt er direct 12 maand van. Dat betekent dat je ze elk jaar een paar dagen eerder moet vernieuwen.
Ik merk nog een probleem omdat ze ook de rootcertificaten een geldigheid geven van 12 maand. (Was 10 jaar) Dat betekent dat je ook de root elk jaar moet vervangen, wat onhandig is.
Zelf heb ik de rootcertificaten op elke PC geïnstalleerd. Als ik dan via een CSR een nieuw certificaat aanmaak en met mijn root onderteken, is dat certificaat direct op elke PC geldig. Dat werkt zelfs als ik IP adressen in het certificaat zet. Maar nu de root ook slechts 1 jaar geldig is, moet je die ook elk jaar op alle PC's installeren.
Ik denk dat je nu toch weer terug moet naar de start van dit draadje en je handmatig een root certificaat moet maken via OpenSSL. Geef het een geldigheid van 10 jaar, importeer het in de nas en gebruik deze dan voor het ondertekenen.