Synology-Forum.nl
Firmware => Synology DSM algemeen => Topic gestart door: dvandonkelaar op 04 juli 2018, 06:57:54
-
Tegenwoordig is het mogelijk om bij Let's encrypt een certificaat met wildcard aan te vragen. Binnen Synology is dit nog niet ondersteund, maar het is wel mogelijk om deze toe te voegen.
Voor het krijgen van dit certificaat moeten onderstaande handelingen uitgevoerd worden. Dit certificaat is voor de NAS en is op basis van dit topic op het Engelse forum (https://forum.synology.com/enu/viewtopic.php?t=141181). Dit topic is voor het VPNPlus package op de Router en wijkt dus af van onderstaande handelingen.
Automatische werkwijze:
Eenmalige acties (script instellen en certificaat aanvragen):
1. Verbind met de NAS door middel van PuTTy (bij voorkeur, voor de volgende stappen is dit nodig) of SMB/AFP, ga naar de map waarin het script bewaard mag worden en clone de SynologyLetsEncrypt-repository
git clone https://github.com/dvandonkelaar/SynologyLetsEncrypt.gitDe git clone zal er voor zorgen dat de map SynologyLetsEncrypt aangemaakt wordt. Ga dus naar de map waarin deze submap aangemaakt moet worden (bijv. /volume1/Temp)
Zie de git clone documentation (https://git-scm.com/docs/git-clone) voor alternatieven van dit command.
Standaard is git niet geïnstalleerd binnen DSM. Via de Synocommunity (https://synocommunity.com/package/git) is deze beschikbaar. Waarschijnlijk is git na installatie niet in de $PATH meegenomen en zal deze moeten worden toegevoegd, of worden aangeroepen via /volume1/@appstore/git/bin/git (/volume1 is de locatie waar de packages standaard worden geïnstalleerd. Als dit een ander volume is, zal /volume1 gewijzigd moeten worden).
2a. Wanneer geen verbinding gemaakt is met PuTTy, dan moet deze verbinding gemaakt worden en kan naar de map uit stap 1 genavigeerd worden.
2b. Maak een config.ini aan waarin het domein staat.
echo Domain=mijndomein.nl>>config.iniVervang hier mijndomein.nl door get gewenste domein.
3. Voer het script uit door middel van:
sudo ./SynologyLetsEncrypt.sh
Dit zorgt voor een output waarin onderstaande staat vermeld:
Add the following TXT record:
Domain: '_acme-challenge.mydomain.tld'
TXT value: 'LongTextValueWhichNeedsToBeAddedToTheDomain'
Please be aware that you prepend _acme-challenge. before your domain
so the resulting subdomain will be: _acme-challenge.domein.nl
Add the following TXT record:
Domain: '_acme-challenge.mydomain.tld'
TXT value: 'LongTextValueWhichNeedsToBeAddedToTheDomain'
Please be aware that you prepend _acme-challenge. before your domain
so the resulting subdomain will be: _acme-challenge.domein.nl
4. Maak bij de hostingprovider beide DNS TXT records aan met de waarde _acme-challenge en bovenstaande TXT values.
Wacht eventueel even totdat dit volledig is doorgevoerd bij de hostingprovider. Als dit niet is doorgevoerd zal de vervolgstap niet slagen.
Vervolg acties (het renew-proces):
1. Voer het script uit door middel van:
sudo /volume1/Temp/SynologyLetsEncrypt/SynologyLetsEncrypt.shHierbij is het pad afhankelijk van de installatie-map (zie stap 1 van de eenmalige automatische werkwijze)
Het script geeft redelijk wat output, waarbij alleen informatie wordt gegeven over het proces en geen fouten worden weergegeven.
Tijdens dit proces wordt het certificaat aangevraagd en worden de verkregen certificaten gekopieerd naar een submap (de naam hiervan is de datum van uitvoering) van de certificates-map certificates in de map SynologyLetsEncrypt.
De verkregen certificaten worden gekopieerd naar het standaard certificaat van DSM en naar de verschillende packages, behalve het Acitve Directory package (deze heeft een eigen certificaat).
Als laatste wordt nginx en de packages herstart om de wijzigingen door te voeren.
2. Als dit proces goed gaat kan dit aan de taakplanner van DSM worden toegevoegd.
De taakdetails zijn dan als volgt:
geplande taak > door gebruiker gedefinieerd script.
Tabblad algemeen: gebruiker is root
Planning: Uitvoeren op de volgende datum: Elke 3 maanden herhalen
Taakinstelling: Opdracht uitvoeren > "/volume1/Temp/SynologyLetsEncrypt/SynologyLetsEncrypt.sh"
Quotes in de taakinstelling zijn niet nodig als het pad geen spaties bevat. Verder is het pad naar de map afhankelijk van de installatie-map (zie stap 1 van de eenmalige automatische werkwijze)
De uitvoerdetails kunnen nog toegestuurd worden om te controleren of het proces goed is verlopen.
Handmatige werkwijze:
1. Verbind met de NAS door middel van PuTTy en log in als root.
2. Download het acme.sh script (https://github.com/Neilpang/acme.sh), welke nodig is om een certificaat te krijgen.
wget https://raw.githubusercontent.com/Neilpang/acme.sh/master/acme.sh
chmod a+x acme.sh
3. Vraag het certificaat op het domein aan, hier moet natuurlijk mijndomein.nl vervangen worden door het gewenste domein.
./acme.sh --issue -d mijndomein.nl -d *.mijndomein.nl --dns --yes-I-know-dns-manual-mode-enough-go-ahead-please
Dit zorgt voor een output die lijkt op aan onderstaande.
Creating domain key
The domain key is here: /root/.acme.sh/mijndomein.nl/mijndomein.nl.key
Multi domain='DNS:mijndomein.nl,DNS:*.mijndomein.nl'
Getting domain auth token for each domain
Getting webroot for domain='.mijndomein.nl'
Getting webroot for domain='*.mijndomein.nl'
You need to add the txt record manually.
Add the following TXT record:
Domain: '_acme-challenge.mijndomein.nl'
TXT value: 'LangeTekstValueWelkeInHetDomeinMoetWordenIngevuld'
Please be aware that you prepend _acme-challenge. before your domain
so the resulting subdomain will be: _acme-challenge.mijndomein.nl
Please add the TXT records to the domains, and re-run with --renew.
Please add '--debug' or '--log' to check more details.
See: https://github.com/Neilpang/acme.sh/wiki/How-to-debug-acme.sh
4. Maak bij de hostingprovider een DNS TXT record aan met de waarde _acme-challenge en vul het bovenstaande TXT value in.
Wacht eventueel even totdat dit volledig is doorgevoerd bij de hostingprovider. Als dit niet is doorgevoerd zal de vervolgstap niet slagen.
5. Hierna moet het script opnieuw gedraaid worden met het --renew commando
./acme.sh --renew -d mijndomein.nl -d *.mijndomein.nl --dns --yes-I-know-dns-manual-mode-enough-go-ahead-please
Dit zorgt voor een output die lijkt op onderstaande.
....
-----END CERTIFICATE-----
Your cert is in /root/.acme.sh/mijndomein.nl/mijndomein.nl.cer
Your cert key is in /root/.acme.sh/mijndomein.nl/mijndomein.nl.key
The intermediate CA cert is in /root/.acme.sh/mijndomein.nl/ca.cer
And the full chain certs is there: /root/.acme.sh/mijndomein.nl/fullchain.cer
6. Kopieer de benodigde certificaten naar een gedeelde map om deze toe te kunnen voegen aan DSM.
Hieronder is /volume1/Temp aangehouden als gedeelde map.
cp "/root/.acme.sh/mijndomein.nl/mijndomein.nl.cer" "/volume1/Temp/mijndomein.nl.cer"
cp "/root/.acme.sh/mijndomein.nl/mijndomein.nl.key" "/volume1/Temp/mijndomein.nl.key"
cp "/root/.acme.sh/mijndomein.nl/ca.cer" "/volume1/Temp/ca.cer"
7. De certificaten kunnen worden toegevoegd aan DSM zoals in onderstaande screenshots beschreven.
[attach=1]
[attach=2]
[attach=3]
8. Configureer DSM zodat het certificaat bij de benodigde toepassingen gebruikt kan worden.
Update 07-12-2019:
Het automatisch uitvoeren van het proces (aanvragen en updaten) heb ik werkend gekregen. Het script is te vinden op GitHub (https://github.com/dvandonkelaar/SynologyLetsEncrypt).
Deze kan automatisch of handmatig uitgevoerd worden en vervangt het huidige certificaat. Dit elimineert onderstaand opgesomde nadelen.
Update 18-12-2019:
Tijdens het updateproces werden de certificaten niet naar de packages gekopieerd door een typfout in een variabele, waardoor de certificaten voor deze packages niet geüpdatet werden.
Het acme.sh-script zet .conf-bestanden in de map /root/.acme.sh. Als deze hier staan wordt de renew-procedure gebruikt en wordt het certificaat op basis van de (in het issue-proces) gespecificeerde DNS-records vernieuwd.
Verder is het oude pad voor de Synology active directory server certificaten toegevoegd aan de uitgesloten paden voor het updaten van de certificaten.
In bovenstaande how-to heb ik de nieuwe werkwijze (d.m.v. het SynologyLetsEncrypt-script) omschreven en de oude (handmatige) en nieuwe werkwijze gesplitst.
Nadelen:
1. Het certificaat is ca. 2 maanden geldig en moet daarna dus opnieuw worden toegevoegd. Gezien met deze methode het certificaat handmatig moet worden toegevoegd zal dit voorlopig ook nog niet automatisch gebeuren.
2. Het via de commandline toevoegen (of vervangen) van een certificaat heb ik nog niet werkend kunnen krijgen, het werkend krijgen van het wildcard certificaat had de eerste prioriteit. Dit proces automatisch laten verlopen totdat Synology dit geïmplementeerd heeft (of totdat mijn setup wijzigt) moet ik nog goed onderzoeken.
3. Het updaten van een certificaat kan volgens mij door een bestaand certificaat te importeren in plaats van een nieuw certificaat toe te voegen (zie 1e screenshot), maar hier heb ik verder geen informatie over kunnen vinden elders op het internet.
-
Top beschrijving.
Ga het binnenkort ook proberen.
-
Een voordeel van dit nieuwe systeem is ook geen poort 80 naar de nas hoeft te wijzen. Authenticatie gebeurd via je DNS record.
Dat betekent wel dat je nu ook toegang tot de DNS moet hebben en je met deze methode geen certificaat kunt aanvragen voor je Synology ddns naam.
-
Mooie tut :thumbup: deze Sticky gemaakt.
-
Beste D van Donkelaar,
Ik heb mijn NAS synology geupdate van 4.3 naar 6.2 om gebruik te kunnen maken van let's encrypt om een certificaat te verkrijgen om beveiligd op mijn NAS te kunnen komen en om mijn mail fatsoenlijk te kunnen ontvangen en verzenden. Maar helaas is dat nog steeds niet gelukt, totdat ik op het forum dit hele verhaal tegenkwam. Ik begrijp niet alles, maar ik heb putty geinstalleerd en verder kwam ik niet.
Misschien een mogelijkheid voor hulp !!
Frans
-
Wat snap je niet van stap 2 dan ?
-
Als dit te hoog gegrepen is, zou ik helemaal van die wildcards afblijven. Synology ondersteunt het niet, dus je moet steeds handmatig updaten. En het hele DNS gebeuren is veel complexer.
Als het alleen voor een paar (sub)domeinen is, kun je veel beter bij de standaard setup blijven. Dat werkt bijna vanzelf.
-
Ik heb op de link geklikt en daarna op clone/download zipbestand vervolgens uitgepakt en de map acme.sh-master op mijn desktop gezet. en nu weet ik niet hoe ik verder moet.
-
Zoals Briolet al aan geeft is het voor jou denk ik beter om gewoon de Let's encrypt zonder wildcard in te stellen.
Als je de acme.sh-master op je desktop hebt staan dan heb je stap 1 al overgeslagen.
Mocht je toch echt met het wildcard certificaat willen werken, begin dan bij stap 1 van deze tutorial.
-
Volgens mij heb ik stap 1 gedaan.
Putty geinstalleerd, private key en public key gemaakt en Putty actief gemaakt door in te loggen
-
Dat is goed, maar als je dan stap 2 volgt (onderstaande code) komt de acme.sh-master niet op je bureaublad terecht volgens mij.
wget https://raw.githubusercontent.com/Neilpang/acme.sh/master/acme.sh
chmod a+x acme.sh
-
Daarom vroeg ik ook:
Wat snap je niet van stap 2 dan ?
Maar geen antwoord opgekregen.
-
@Melody Volg anders deze handleiding (https://www.synology.com/nl-nl/knowledgebase/DSM/help/DSM/AdminCenter/connection_certificate) van Synology zelf.
Werkt net zo goed voor de standaard gebruikers en is wellicht beter in jouw situatie.
-
Dank je wel voor alle hulp en info, maar krijg ik hiermee mijn mail weer op orde? En ik zou ook graag als ik inlog op mijn NAS dat het beveiligd is met een groen slotje, want dat is het nu niet. Klik ik op onbeveiligd dan staat daar dat er een ongeldig certificaat is, vandaar dat ik deze wildcard van let's encrypt wilde installeren.
Zal de raad opvolgen.
-
Wildcard is niet per se nodig, als je maar een geldig certificaat hebt.
Als je met je NAS verbind vanuit je interne netwerk maakt het m.i. niet zoveel uit of je een groen slotje hebt of niet, je weet immers waarmee je verbind dus weet je ook of het veilig is.
-
Bovendien is "groen slotje" een vaag begrip omdat dit per browser verschilt. b.v. bij Safari krijg je alleen bij een EV certificaat een groen slotje. Let's Encrypt geeft geen EV certificaat. Bij safari geeft dat 'slechts' een grijs slotje.
-
Nadelen:
2. Het via de commandline toevoegen (of vervangen) van een certificaat heb ik nog niet werkend kunnen krijgen, het werkend krijgen van het wildcard certificaat had de eerste prioriteit. Dit proces automatisch laten verlopen totdat Synology dit geïmplementeerd heeft (of totdat mijn setup wijzigt) moet ik nog goed onderzoeken.
Was hier inmiddels al een oplossing voor. Ik ben nu bezig met het gebruiken van de reverse proxy en wil dit eigenlijk met een WildCard certificaat van LE gaan afvangen... alleen ik heb geen zin om iedere 2,5 maanden dit handmatig te gaan doen...
Alvast bedankt voor het antwoord.
MAdD
-
Hier heb ik verder nog niet naar gekeken. Heb het de afgelopen paar keer wel met de hand gedaan, is ook niet zo heel veel werk. Ik zal de volgende keer eens kijken of dit ergens te automatiseren is.
-
Het is inmiddels bijna 3 maanden geleden dat ik het certificaat heb geïmporteerd dus moet hem weer vernieuwen.
Moet ik daar voor op nieuw alle stappen doorlopen of kan ik bij stap 3 beginnen?
-
Volgens mij ben ik de laatste keer bij stap 5 begonnen, maar weet niet 100% zeker of dat werkte. Het is voor mij ook alweer 2 maanden geleden. Anders zou ik inderdaad bij stap 3 beginnen.
-
Bedakt. Ik ga het proberen.
-
Hier heb ik verder nog niet naar gekeken. Heb het de afgelopen paar keer wel met de hand gedaan, is ook niet zo heel veel werk. Ik zal de volgende keer eens kijken of dit ergens te automatiseren is.
Heb je inmiddels al een oplossing hiervoor gevonden? Of doe je het nog steeds handmatig?
-
Wegens tijdgebrek doe ik dit nog steeds handmatig. Want dat kost op zichzelf helemaal niet zo veel tijd en tot nu toe ben ik er pas achter gekomen toen de certificaten verlopen waren.
Eind september zal het weer moeten (uit mijn hoofd), ik zal dan eens kijken of het mogelijk is.
-
Lost een wildcard het probleem op dat bezoekers een beveiligingswaarschuwing krijgen wanneer niet slechts https://www.mijn domein.com maar bijvoorbeeld de aanvulling met slashen zoals https://www.mijn domein.com/photo/ gebruiken?
-
Ne, een wildcard lost alleen het probleem op van steeds weer een nieuw (of langer) certificaat aanmaken als je een nieuw subdomein in gebruik neemt.
En alles na de slash valt buiten de controle van een certificaat.
-
Hallo Briolet, maar hoe moet dat dan wanneer je andere applicaties (die met een aanvullende slash) wilt gebruiken?
Moeten die dan per applicatie voorkomen op het certificaat of zijn die überhaupt niet te certificeren?
-
Ik kan alleen herhalen:
En alles na de slash valt buiten de controle van een certificaat.
Is ook logisch, want anders zou je voor elke webpagina een eigen certificaat moeten maken.
-
Oké duidelijk.
Kan ik overigens ook mijn externe IPadres als alternatieve naam op het certificaat kwijt?
-
Wegens tijdgebrek doe ik dit nog steeds handmatig. Want dat kost op zichzelf helemaal niet zo veel tijd en tot nu toe ben ik er pas achter gekomen toen de certificaten verlopen waren.
Eind september zal het weer moeten (uit mijn hoofd), ik zal dan eens kijken of het mogelijk is.
Bijna einde van het jaar... en ik heb het werkend gekregen via een Docker Container.
Hieronder mijn releas hoe ik het gedaan heb:
To create wildcard certificates for your Synology system for provider TRANS-IP, you can use the following code
SSH into Synology
create a folder called /var/docker-data/Certificatescreate a file in /etc/letsencrypt/ called domains.confper line fill in an owned domain like
Example.com *.example.com for 1 certificate
example.com *.example.com
smtp.example.com
imap.example.com pop.example.com for 3 certificate
create a file in /etc/letsencrypt/ called api.keycreate an API in your TRANS-IP controle panel
save this API key and now we need to modify it to an RSA key
download openssl
execute openssl rsa -in transip_original.key -out api.key (and save to /etc/letsencrypt/)
install docker on your Synology
Install docker packages adferrand/letsencrypt-dns
to create your own settings using the above docker image you can start the docker in SSH with the following line:
docker run \
--name YOUR OWN NAME \
--volume /etc/letsencrypt/domains.conf:/etc/letsencrypt/domains.conf \
--volume /etc/letsencrypt/api.key:/etc/letsencrypt/api.key \
--volume /var/docker-data/Certificates:/etc/letsencrypt \
--env 'LETSENCRYPT_USER_MAIL=YOUR@Email.address' \
--env 'LEXICON_PROVIDER=transip' \
--env 'LEXICON_TRANSIP_USERNAME=YOUR_TRANSIP_USERNAME' \
--env 'LEXICON_TRANSIP_AUTH_API_KEY=/etc/letsencrypt/api.key' \
--env 'LEXICON_TRANSIP_TTL=1' \
--env 'LEXICON_SLEEP_TIME=3720' \
--env 'LETSENCRYPT_STAGING=false' \
adferrand/letsencrypt-dns
When the certificates are created you can manually install them into the Synology interface (first time).
If you let the docker run, it will 30 days before the certificate will expire create new certificates.
With the following code you can copy these to the correct location
#!/bin/bash
echo "Starting script at : $(date)"
echo "Checking if certificates needs to be changed"
file1="/var/docker-data/Certificates/live/YOURDOMAIN/cert.pem"
file2="/usr/syno/etc/certificate/ReverseProxy/LOCATION_OF_YOUR_CERTIFICATE/cert.pem"
dirdate=$(date +"%Y-%m-%d")
if diff "$file1" "$file2" >/dev/null ; then
echo "Nothing has changed!!..."
else
cp /var/docker-data/Certificates/live/YOURDOMAIN/* /usr/syno/etc/certificate/ReverseProxy/LOCATION_OF_YOUR_CERTIFICATE/
cp /var/docker-data/Certificates/live/YOURDOMAIN/* /usr/syno/etc/certificate/_archive/LOCATION_OF_YOUR_CERTIFICATE/
/usr/syno/sbin/synoservicectl --restart nginx
echo "Certificates has been copied and activated!"
echo "Now make backup to /volume1/YOUR_LOCATION/History/$dirdate"
mkdir /volume1/YOUR_LOCATION/History/$dirdate
cp -R /var/docker-data/Certificates/* /volume1/YOUR_LOCATION/History/$dirdate
echo "Done on the certificate part...."
fi
echo "Stopping script at : $(date)"
echo "Now returning to normal operations!!!!"
to figure out /usr/syno/etc/certificate/_archive/LOCATION_OF_YOUR_CERTIFICATE/ check /usr/syno/etc/certificate/_archive/INFO
-
for provider TRANS-IP
Deze container werkt alleen voor TRANS-IP?
Ondertussen heb ik het zelf werken gekregen door middel van een bash script. Zie mijn update in de TS (https://www.synology-forum.nl/firmware-algemeen/let's-encrypt-met-wildcard-instellen/msg252389/#msg252389).
Via mijn GitHub (https://github.com/dvandonkelaar/SynologyLetsEncrypt) is deze te downloaden.
-
nee deze container werkt voor alle providers die Lexicon gebruiken (waaronder TRANS-IP).
zie voor meer info hier (https://github.com/AnalogJ/lexicon)
-
Begrijp met niet verkeerd, ik vraag me alleen af wat het voordeel van deze container is.
Wat deze container doet is het aanmaken van DNS-records (alleen bij providers die Lexicon gebruiken) en een let's encrpyt certificaat aanvragen.
Ten opzichte van het handmatig uitvoeren van het acme.sh-script wordt alleen het aanmaken van de DNS-records niet uitgevoerd.
Maar goed. Als het goed werkt, dan is er geen reden om dit anders te doen.
De repo van AnalogJ/lexicon (https://github.com/AnalogJ/lexicon) is daarbij veel interessanter. Deze kun je gebruiken om DNS-records aan te passen, mits je procider Lexicon gebruikt natuurlijk.
-
Met deze container maak ik een wildcard certiifcaat.
Aangezien je een wildcard certificaat alleen kan aanmaken, als er een bepaalde DNS entry in je domain staat, gebruik ik deze container om alles geautomatiseerd te doen.
Oftewel ik geen aan welke domainen ik in het certificaat wil, en dan zal de docker dit gaan uitvoeren (DNS record aanmaken, ACME controleert daarna of de key overeenkomt, aanmaken van cert en opruimen van de DNS record).
Ik heb hier geen omkijken meer naar......
-
Ondertussen heb ik het zelf werken gekregen door middel van een bash script. Zie mijn update in de TS (https://www.synology-forum.nl/firmware-algemeen/let's-encrypt-met-wildcard-instellen/msg252389/#msg252389).
Via mijn GitHub (https://github.com/dvandonkelaar/SynologyLetsEncrypt) is deze te downloaden.
Hoe doe je dit i.c.m. je DNS provider? Zet je elke keer handmatig de record goed of vernieuw je hem elke keer op tijd zodat je challenge in de cache blijftI?
-
Nee, niets handmatig:
Ik heb hier geen omkijken meer naar......
De DNS provider moet het wel ondersteunen (Lexicon), vandaar de restrictie in het script voor specifieke providers
-
Heb heel even mn reactie aangepast en er een quote bijgezet.
In het script van dvandonkelaar, wordt er gebruik gemaakt van het argument --yes-I-know-dns-manual-mode-enough-go-ahead-please
Daarmee neem ik dus aan dat hij deze modus gebruikt en dus niet automatisch vernieuwt. https://github.com/Neilpang/acme.sh/wiki/dns-manual-mode
Ik ben voornamelijk benieuwd wat hij dan wel doet.
-
Volgens mij worden de bestaande waardes in de sms behouden. Ik heb hier een poosje verschillende situaties mee zitten testen waardoor ik niet meer exact weet hoe dit nu zat.
Een deze dagen zal ik het nog wel eens proberen. Ik zag vandaag dat niet alleenalle virtual host certificates geüpdatet waren, dus dat wil ik ook nog even uitzoeken.
Zodra ik hier meer over weet zal ik het hier vermelden.
EDIT: typfout aangepast
-
Hoe doe je dit i.c.m. je DNS provider? Zet je elke keer handmatig de record goed of vernieuw je hem elke keer op tijd zodat je challenge in de cache blijftI?
Het acme.sh-script doet met een eerste renew in principe hetzelfde als met elke renew daarna. Dit gaat op basis van de gegevens die 'verwacht' worden.
Dit heb ik vanmorgen even getest en mijn certificaat van 08-12 is netjes geüpdatet, met de oude DNS-instellingen.
De Topic Start heb ik bijgewerkt met de laatste informatie.
-
In feite doet het standaard script hetzelfde bij een certificaat voor een Synology ddns naam. Dit gaat ook via de dns instellingen, waardoor er geen poort hoeft open te staan. Maar dat is dus alleen voor de eigen dns server van synology.
-
Sinds DSM Version: 6.2.3: Added support for Let's Encrypt wildcard certificates.
-
Heb net even getest met mij V-DSM test machine.
Het lijkt erop dat wilcard certificaten alleen werken met "synology" domein namen.
Als ik het voor mijn eigen domein probeer krijg ik de melding dat ik een "geldige domein naam" moet gebruiken.
-
Ik had al zo'n idee dat er een addertje onder het gras zat. Ik heb 6.2.2 op mijn testnas gezet en wilde het ook eens testen.
Poort 80 gaat niet naar mijn testnas, maar deze wildcard methode gebruikt een protocol dat poort 80 niet nodig heeft. Dat protocol gebruikt Synology al voor certificaat op zijn eigen domeinnamen.
Met een eigen domeinnaam moet je echter van alles in je dns systeem aanpassen voor deze nieuwe methode. Of de nas doet dat voor je, maar dan heeft hij inlog gegevens nodig voor je dns instellingen.
Tot mijn verbazing was er geen enkel menu om dit alles in te kunnen stellen. Ik zeg zelfs geen aanpassingen aan de certificaat menu's. Ook in de help wordt er niets geschreven over deze wildcards.
Bij de dns van synology ligt dat echter iets simpeler. Daar is de inlog voor het dns systeem gelijk aan de inlog van de ddns dienst. Dus daar kan Synology het realiseren zonder dat de gebruiker extra instellingen moet doen.
Dus eigenlijk een wassen neus dat wildcards mogelijk zijn.
-
Nou, bij mij ging het e.e.a. niet goed op m'n Test DS maar, dat komt waarschijnlijk omdat ik te veel geklooid heb met Synology DDNS en meerdere Certificaten, te veel om uit te leggen.
Ik ga terug naar fabrieksinstellingen en weer testen, morgen.
-
Ik heb poort 80 even naar mijn testnas gezet.
Een certificaat voor *.xxx.synology.me werkt niet. Een certificaat voor dsm.xxx.synology.me werkt wel. Het is wel nieuw dat je een asterix mag gebruiken in een domeinnaam. In de vorige dsm versies kon je geen asterix gebruiken.
Dit was wel met een nas die niet voor de ddns zorgt. Dus waarschijnlijk gebruikt hij het standaard protocol dat ook voor eigen domeinen gebruikt wordt.
Een test op mijn hoofdnas kan ik nog niet doen omdat ik daar zeker nog wacht met een update. Dat zal ik pas na 21 april doen als synology de 6.2.3-1 patch gaat releasen. OpenSSL heeft voor die dag nml een kritische bugfix aangekondigd (https://mta.openssl.org/pipermail/openssl-announce/2020-April/000170.html). En dan kun je een update niet meer uitstellen.
-
Getest op m'n Test-DS die ik volledig opnieuw heb geïnstalleerd.
Als test, eerst in Toepassingsportaal > File Station "Aangepast domein" ingeschakeld, domein: fs.xxx.synology.me en poort 7001 forwarded.
Na het verwijderen van de oude DDNS in m'n account, een nieuwe gemaakt, xxx.synology.me en heb het Let's Encrypt automatisch laten maken.
Echter, ik had nu eigenlijk wel verwacht dat ik een keuze zou krijgen of ik ook de Wildcard wilde instellen.
Niet dus, kreeg dus een standaard Certificaat voor xxx.synology.me.
Heb een tweede Certificaat gemaakt met Wildcard voor xxx.synology.me.
Het eerste Certificaat werd hierdoor aangepast.
[attachimg=1]
In Chrome: https://fs.xxx.synology.me:7001 krijg ik "Je verbinding is niet privé"
Ik klik op geavanceerd, krijg ik te zien:
"De server kan niet bewijzen dat dit fs.xxx.synology.me is. Het beveiligingscertificaat van de server is afkomstig van xxx.synology.me."
Ga ik toch door, dan kom ik onveilig in het inlogscherm voor File Station.
[attachimg=3]
[attachimg=2]
Het werkt dus idd niet of, ik snap het idee niet.
-
Overigens, op het Officiële Forum (https://community.synology.com/enu/) heb ik nog geen test gezien.
-
Voor een wildcard moet je bij de gewone naam je synology domein invullen en bij alternatieve naam hetzelfde met *. ervoor. Zo worden wildcard certificaten normaal uitgegeven.
-
Dat heb ik toch gedaan, gezien de certificaten?
Of, ik snap het niet.
-
Dat kon ik niet goed zien. Er was zoveel weggepoetst in je screeshots :P
Ik kijk liever rechtstreeks naar het certificaat dat de browser gebruikt. In Chrome is dat:
Weergave --> Ontwikkelaar --> Ontwikkelartools --> Security --> View Certificate
In elke normale browser: Gewoon het slotje klikken. (Chrome wil niet dat de gebruiker certificaten controleert en verstopt die optie)
-
Certificaat is verleend aan: xxx.synology.me
Met Wildcard zou ik met fs. ervoor, een geldig cert verwachten, toch?
-
In het SAN lijstje van Chrome moet naast de naam xxx.synology.me ook de naam *.xxx.synology.me voorkomen. Alleen dan weet je zeker dat Chrome ook het certificaat gebruikt wat je verwacht. Want eigenlijk zou ik verwachten dat het moet werken als je dat certficaat kunt maken en gebruikt.
NB: SAN staat voor Subject Alternative Name
-
Is je wildcard certificaat ook je default certificaat?
Of heb je de "fs" service toegekend aan het wildcard certificaat.
-
SAN staat voor Subject Alternative Name
Ik kan alleen "xxx.synology.me" vinden in de Certificaat details:
Onderwerp en Alternatieve naam voor onderwerp
Is dat wat je bedoelt ?
@zandhaas In Reactie #44 kan je zien hoe het ontstaan is en hoe het eruit ziet.
Certificaat 2 kan ik niet default maken, staat ook niet meer in het menu (rechts klik op cert).
Maar, als je naar het plaatje kijkt in reactie #44, dan is fs. toegevoegd aan Certificaat 1, die wel default is.
-
Ik kan alleen "xxx.synology.me" vinden in de Certificaat details:
Als ik naar het wildcard certificaat van Google zelf kijk, ziet dat er als volgt uit in Chrome:
[attachimg=1]
Als jij die wildcard naam niet ziet, staat het niet in het certificaat.
-
Tja, dat zie ik dus niet bij mijn Certificaat in Chrome maar wel op de NAS:
Certificaat 2: *.xxx.synology.me en xxx.synology.me
Certificaat 1: alleen xxx.synology.me
Dus, dat gaat niet werken dan en dat komt, denk ik, omdat het 1e Certificaat standaard door de DDNS instelling is gemaakt en daarna zelf een 2e heb moeten maken.
Ik zal weer eens terug gaan naar fabrieks instellingen, dan DDNS instellen zonder auto Certificaat.
Want ik kan die n.l. niet verwijderen in de huidige opzet. ::)
Wel vreemd allemaal, de gebruiker moet zelf kunnen bepalen of je een Certificaat mag verwijderen, het zou zelfs zo moeten zijn, dat je helemaal geen Certificaten hebt.
-
Eerst het 2e certificaat verwijderd, dan terug naar fabrieksinstellingen:
Heb dus nu 1 standaard certificaat van Synology.
1 - DDNS weer opgezet zonder auto certificaat.
2 - Wildcard Certificaat gemaakt voor xxx.synology.me en SAN *.xxx.synology.me
[attachimg=2]
3 - Nu kon ik wel het Certificaat default maken.
4 - In Toepassingstoegang voor File Station "Aangepast Domein" ingeschakeld: fs.xxx.synology.me
En nu gaat het goed:
[attachimg=1]
Kijkende in het het Certificaat (Chrome)
"Alternatieve naamvoor onderwerp":
DNS-naam=*.xxx.synology.me
DNS-naam=xxx.synology.me
Dus, het is een uitdaging om een bestaand certificaat op naam van ....synology.me even te wijzigen, zeker als deze automatisch is gemaakt door de DDNS instelling en niet is te verwijderen.
Ik zie geen opties om dat dan aan te passen en even terug naar fabrieksinstelling, is geen optie voor niet-test-nassen.
Misschien dat er wel onderwater wat te regelen valt, dat weet ik niet......heeeel mischien wil ik daar ook naar kijken maar, dat wordt geen optie voor de meeste gebruikers. ;)
-
Het is even 'een gedoe' met meerdere certificaten. Per functie moet je een certificaat aanwijzen. Uit je eerdere screenshot maak ik op dat File Station via poort 7000 nog steeds met het default certificaat ingesteld was.
Jij had dit bij instellingen moeten aanpassen. Zelf gebruik ik een stuk of 5 zodat ik er inmiddels een beetje vertrouwd mee ben. Hoewel ik een ander probleem heb bij het instellen. Als ik bij het toewijzen, niet eerst buiten het invulveld klik, voordat ik ok klik, wordt de instelling niet overgenomen. Als je daar niet attent op bent, kun je ook ten onrechte denken dat je het aangepast hebt.
Maar goed. Het werkt dus bij een certificaat op een Synology ddns naam. Die gebruikers zullen het minste belang bij een wildcard hebben.
Het was mooier geweest als dat ook bij eigen domeinnamen kon. De gebruiker moet dan een bepaalde public key aanmaken en die in zijn ddns record publiceren. Dan pas het certificaat aanmaken. Hierna mag je de public key weer verwijderen. Als de domeinnaam hoster een api heeft on de dns records te veranderen, kan dit geautomatiseerd worden.
-
File Station via poort 7000 nog steeds met het default certificaat ingesteld was.
Jij had dit bij instellingen moeten aanpassen.
Dat was poort 7001, maar goed, zoals eerder vermeld, ik kon de default niet instellen.
Mijn conclusie is, dat dit kwam door het DDNS automatisch gemaakte certificaat en het 2e certificaat die ik had gemaakt met Wildcard, lees maar eens terug.
-
Je schreef idd dat je de default niet kon aanpassen. Maar ik bedoelde dat je het ook via configuratie kunt instellen. Als een een eigen poort toewijst aan filestation (of elke andere app), dan kun je daar ook een eigen certificaat aan koppelen die alleen voor die inlogpagina gebruikt wordt.
Zelf heb ik een stuk of 8 certificaten. (De helft is voor testen in gebruik). Via configuratie wijs je dan een certificaat aan een bepaalde app, reverse proxy of poort toe.
[attachimg=1]
Ik noem dit hier toch even omdat je hier steeds heel goed naar moet kijken als je meer dan 1 certificaat in gebruik hebt.
-
Komen wildcards ook voor de RT2600acm of zijn die daar al beschikbaar via de GUI?
-
Dat kan je toch zelf zien? ;)
-
LUI! 8) :P ;)
-
:twisted:
-
In de RT is die optie nog niet aanwezig via de wizard....
-
Dat wist ik al blind ;), het kon ook niet, omdat SRM al lang geen update meer heeft gehad.
Maar, ik verwacht dat die optie nog komt.
-
In de RT is die optie nog niet aanwezig via de wizard....
En ook niet in DSM. Althans niet als zichtbare instelling en ook niet genoemd in de help. De enige clou is dat je een wildcard kunt intikken in de invulvelden. (en natuurlijk de releasenotes)
-
En ook niet als DDNS vraagt om een Certificaat voor je maken in DSM, dan gaat het volledig automatisch.
-
Okay, maar stel dat je dan een wildcard wilt aanvragen, kunnen jullie dan een voorbeeldje posten? :thumbup:
Iets met een * in de domeinnaam?
-
Dat is toch gewoon een * invullen i.p.v. een expliciet subdomein. Waar is dan een voorbeeld voor nodig?
-
Voorbeeld? Zie mijn Reactie 55. ::)
-
Wat ik al zei: LUI :lol:
-
Dat wist ik al blind ;), het kon ook niet, omdat SRM al lang geen update meer heeft gehad.
Maar, ik verwacht dat die optie nog komt.
IK zat er helemaal naast dus, excuses van mijn kant. :oops:
In SRM (voor alle Routers) wordt Wildcard al support sinds Version: 1.2.3-8017 (2019-07-24):
Added support for the Let's Encrypt wildcard certificates for the Synology DDNS domains.
Mijn RT2600ac:
[attachimg=1]
In de RT is die optie nog niet aanwezig via de wizard....
Die optie is dus WEL aanwezig @aliazzz ;D
Eigenlijk was ik dus ook te lui om te fact-checken, had dit n.l. helemaal niet verwacht, omdat Let's Encrypt op zich pas later in SRM was toegevoegd.
Dus, Wildcard in SRM was er eerder dan in DSM.
-
Wel een vreemd voorbeeld. Als dat echt klopt, zou je een wildcard certificaat kunnen krijgen voor alle synology ddns gebruikers.
Bij DSM staar er op dat punt geen voorbeeld over wildcards. SRM is wat dat betreft duidelijker en geeft ook goed de beperkingen aan.
-
*update* => die wildcard ( *. ervoor) helpt mooi wel!
Kijk, ik ben niet bekend met dit soort materie, daarom vraag ik ernaar...
Weet ik veel dat het derde veld ervoor dient? Hoe moet ik zoiets nou weten?
Goed, iedereen kan en mag fouten maken, dus geen probleem hoor! Eigenlijk wel grappig dat we er allemaal naast zaten. ;)
-
@dvandonkelaar , Ik heb vandaag voor het eerst eens goed naar je automatische update procedure gekeken. Mooi script, mijn complimenten voor het werk.
Nog een paar tips voor op je ToDo list.
1)
Je geeft aan om het script elke 3 maand te herhalen. Als dat een keer mis gaat, zit je met een verlopen certificaat. De nas zelf roept het vernieuwing script elke week op en kijkt dan naar de datum van elk certificaat om te kijken of het binnen een maand verloopt. Zo ja, dan start hij al met de vernieuwing. Dat is 4 week te vroeg, maar dan mag het nog 3x mis gaan. :P
Misschien een idee om zelf het script ook wekelijks te laten uitvoeren en dan naar de datum van het certificaat te kijken. (of zelf een tellertje met datum op te slaan met de laatste succesvolle vervanging)
2)
De verkregen certificaten worden gekopieerd naar het standaard certificaat van DSM en naar de verschillende packages, behalve het Acitve Directory package (deze heeft een eigen certificaat).
Dit zou ik aanpassen. Waarom maak je alleen een uitzondering voor "Acitve Directory". Er zijn veel meer certificaten waar je af moet blijven. Voor OpenVPN wil je b.v. geen Let's Encrypt gebruiken omdat je dan elke 3 maand je configuratie moet exporteren. Ook bij webserver gebruikt niet elke virtuele host hetzelfde certificaat.
Misschien moet je het script aanpassen door eerst te onderzoeken welk pakket het default certificaat gebruikt en dan alleen die certificaten vervangen.
De pakketten die het default certificaat gebruiken vind je in "/usr/syno/etc/certificate/_archive/INFO". Zoek het record met het default certificaat en kijk bij de entries
"service" : "xxx",
"subscriber" : "yyy"
Subscriber is de naam van het pakket en subscriber de foldernaam waar de certificaten staan. Dus:
/usr/local/etc/certificate/subscriber/service
Dan heb je precies de goede certificaten en zijn er geen uitzonderingen nodig in het script, zoals voor "Acitve Directory".
(Veel extra werk, dat begrijp ik)
-
Bedankt @Briolet. Volgens mij lukte het automatisch vernieuwen ook nog niet helemaal.
Dit heb ik wel eens getest en dat ging goed, later zat ik het nogmaals te proberen en dat ging niet helemaal lekker.
Eerdaags zal ik hier dus weer naar moeten kijken en dan zal ik eens kijken of (en in hoeverre) ik bovenstaande punten mee kan nemen.
In ieder geval dank voor de waardevolle aanvulling.
-
Volgens de stappen een wildcard certificaat aangemaakt voor www.domein.nl.
Problemen die ik hebt.
1. Mijn default Synology.com certificaat is verdwenen en vervangen door het aangemaakt certificaat voor www.domein.nl.
2. Tijdens het uitvoeren van de stappen was mijn default certificaat mijnddns.dscloud.mobi.
Voor Notestation in Application Portal de domeinnaam ingevuld: dsnote.domein.nl
Bij Certificaten --> Configure heb ik Notestation gekoppeld aan het certificaat van domein.nl
Poort 80 & 443 zijn doorgestuurd naar mijn NAS.
In config.ini ingevuld: domein.nl
Het certificaat in DSM laat zien *.domein.nl, domein.nl
Als ik nu in de browser ga naar https://dsnote.domein.nl dan kom ik waar ik wezen moeten. Maar krijg dus een waarschuwing en het certificaat wordt dus niet gebruikt.
Controleer ik nu via https://www.digicert.com/help/ of welke andere SSL checker site de link dsnote.domein.nl dan krijg ik de melding:
Certificate does not match name dsnote.domein.nl
Daaronder staat dan Subject mijnddns.dscloud.mobi
Daar gaat het volgens mij fout. Die url klopt niet.
Maar hoe kun je dit dan zo uitvoeren dat de url wel overeenkomt.
Ik krijg het dus niet voor elkaar om het aangemaakt certificaat ook te laten gebruiken.
-
Heb je je nieuwe certificaat wel ingesteld als toegepast certificaat voor die applicaties?
-
Neem aan dat je bedoelt bij Certificaten --> Configure
Daar inderdaad het juiste certificaat ingesteld.