Synology-Forum.nl
Firmware => Synology DSM algemeen => Topic gestart door: Leonard1052 op 15 augustus 2021, 15:33:41
-
Om een certificaat van een externe partij te verlengen dien ik een .txt file in een bepaalde directory in de root te zetten volgens deze instructie />Kan iemand my helpen hoe ik dit moet doen want met een normaal ftp programma zie ik geen root directory.
BVD
-
Geen idee waarom je root toegang nodig hebt. Normaal maak je een CSR aan (Certificate Signing Request). Dat bestand stuur je op en je krijgt gevalideerde certificaten terug. NB: De nas exporteert twee bestanden. In de zip zit ook de private key. Die mag je natuurlijk onder geen beding opsturen. Alleen de CSR file)
Ik heb de video niet bekeken, maar weet je zeker dat dit voor de Synology nas is.
-
Er komt geen NAS in voor, maar ik denk dat TS wel een Cert heeft van SSLs.......
-
Dat hij al een heeft, schrijft hij ook. Want om te verlengen, moet hij al eerder een geïnstalleerd hebben.
-
Geen idee waarom je root toegang nodig hebt.
Dit is zoals het in de instructie staat. De text file hebben ze opgestuurd, ik hoef het "alleen maar"in de root te zetten en twee mappen aan te maken:root/.well-known/pki
Als het bestand juist is geüpload dan kunnen ze die van buiten af bekijken en het certificaat toe sturen. Maar je breng op een idee om CSR op te sturen, kijken of ze daar iets mee kunnen.
Aanwijzing om de textfile en de mappen aan te maken in de root blijven welkom.
BVD
-
Dat is een certificaat voor een synology.me adres. Is het dan niet veel eenvoudiger dit via Let's Encrypt aan te maken?
In elk geval is dat hele root-gedoe niet nodig omdat synology een hele mooie GUI heeft voor certificaatbeheer.
-
Goed idee, maar hoe krijg ik dit verlopen certificaat verwijderd. Kan in menu niet aanvinken.
Zolang dit verlopen certificaat er staat is mijn domein niet benaderbaar.
-
Je kunt nooit het laatste certificaat verwijderen. Dit omdat de afwezigheid van een certificaat nog erger is dan een verlopen certificaat. Dus eerste een nieuwe installeren en dan pas onnodige certificaten wissen.
In elk geval eisen browsers tegenwoordig dat je minimaal elke 13 maand een nieuw certificaat installeert. Via een externe partij moet je dan elk jaar weer aan de slag. Let's Encrypt vernieuwt elke 2 maand automatisch.
-
Ok, als ik bij Let's encrypt een nieuw Certificaat aanvraag, komt die oude dan automatisch te vervallen cq kan ik die dan gewoon deleten?
Toch is de oplossing met die derde partij dicht bij, ik moet alleen weten hoe ik die mappen moet aanmaken in de root directory van mijn server en daarin een txt file kopiëren. Wie zou mij dat kunnen vertellen?
-
Als jij met de certificaten op root niveau aan de gang gaat, is de kans groot dat de boel alleen maar in de soep draait. Zeker als die handleiding niet voor de Synology nas bedoeld is en Synology dingen niet op de standaard manier doet.
Als je via de GUI kiest om het certificaat te vernieuwen, maakt hij standaard een CSR aan. Een een uitgeven van certificaten heeft alleen wat aan een CSR file.
-
Ik heb even naar de video gekeken. Daar gaat het helemaal niet om de root van de nas. Alleen over de root van je website. Dus het zelfde level als waar je de .htacess file zet. (De web share of een folder voor een virtual host) En die folder is gewoon via ftp te benaderen.
-
@Briolet geeft hiervoor al een indicatie waar het betrekking op heeft.
Toch is de oplossing met die derde partij dicht bij, ik moet alleen weten hoe ik die mappen moet aanmaken in de root directory van mijn server en daarin een txt file kopiëren. Wie zou mij dat kunnen vertellen?
Ik kan me wel voorstellen dat het verwarrend is. Zal proberen wat aanwijzingen te geven.
Zelf maak ik ook gebruik van een gewoon "commercieel" domein (met NL extensie) voor mijn WAN IP-adres, met SSL certificaat.
Bij vernieuwing van het certificaat heb je uiteindelijk 3 "tekst" bestanden en een DNS-record "string".
Die bestanden bestaan feitelijk uit een "private-key" - certificaat en een "bundel" van een paar certificaten.
Grofweg zo'n heel stuk tekst met cijfers/letters, omgeven met een begin "tag" en eind "tag" codering.
Private-key:
-----BEGIN PRIVATE KEY-----
xxxxxxxxxxx
-----END PRIVATE KEY-----
Certificaat:
-----BEGIN CERTIFICATE-----
xxxxxxxxxxx
-----END CERTIFICATE-----
Bundel (2 of 3 certificaten):
-----BEGIN CERTIFICATE-----
xxxxxxxxxxx
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
xxxxxxxxxxx
-----END CERTIFICATE-----
Die stukjes tekst zet je gewoon in een tekstbestandje. De extensie "txt" van die bestandjes hernoem je echter!
Om het makkelijk te onthouden en de volgorde van importeren in de NAS, heb ik de namen tevens hernoemd naar:
1 private.key
2 certificaat.crt
3 Sectigo 2x-bundel.crt
Dat importeer je dan vervolgens in de NAS: Configuratiescherm ----> Beveiliging ----> Certificaat
[attach=1] [attach=2] [attach=3]
Het stukje regel met een DNS-record "string" plaats je in het account bij de service provider,
waar je het domein hebt geregistreerd. (Met nog een aantal A-records met verwijzingen naar je WAN IP-adres).
M.b.t. die A-records e.d. zie onderwerpen eerder < HIER > (https://www.synology-forum.nl/firmware-algemeen/https-access-op-domein-nl-en-www-domein-nl/msg202237/#msg202237) en < HIER > (https://www.synology-forum.nl/ddns-extern-benaderen/kan-domeinnaam-niet-met-m'n-synology-ds213-verbinden/msg243179/#msg243179) + vervolgreacties.
-
Als ik de video bekijk, gaat het hier om een heel andersoortig tekstbestand.
Deze uitgever van certificaten wil, nadat hij de CSR ontvangen heeft, controleren dat jij ook de eigenaar bent van dat domein. Hij doet dat door een tekstfile te geven die je zelf in je website(s) moet plaatsen. Vervolgens test deze uitgever of hun bestand op de website gevonden wordt. Zo ja, dan maken ze het certificaat aan.
Als je geen webserver hebt draaien, dan zul je dat pakket eerst moeten installeren en een mini-website inrichten.
Wat ik alleen niet snap is dat het hier om een verlenging gaat. Dan is dit toch ook al in het verleden gedaan? Waarom zou een uitgever het domein de eerste keer niet controleren en bij verlenging een heel nieuwe procedure toevoegen?
-
Dank voor de uitleg.
Het verlengen van het certificaat was me inmiddels gelukt.
Het lag meer aan het proces bij de uitgevende instantie.
Allereerst moet je weten dat je via een tussen bedrijf het abonnement koopt, in mijn geval is dat vijf jaar. Sinds kort is het verplicht bij meeste websites om het certificaat jaarlijks te vernieuwen. Bij zo'n tussenbedrijf kan je dan kiezen voor CSR of Web issue. In het laatste geval krijg je van hen een private key die in DSM moet matchen met het certificaat. Zaak dus om je private key niet weg te gooien zoals ik had gedaan en het aanvraagproces weer op nieuw moest doen.
Het nut van die bundle (nr 3 in jouw voorbeeld) is mij nog niet duidelijk, mede omdat het invullen daarvan optioneel is.
-
Dank, en klopt helemaal wat je schrijft alleen heb ik geen CSR gestuurd maar via hun website aangegeven dat ik een private.key wil ontvangen. Deze had ik dus weggegooid dus toen ik het certificaat kreeg en dus was er geen match waardoor ik het proces opnieuw moest doen. Enfin, uiteindelijk allemaal gelukt.
Waarom ik dit proces moest volgen om het verlengd te krijgen is mij ook niet duidelijk. Wellicht heb ik te laat gereageerd voor de verlenging en was de geldigheid al verlopen toen ik een verlenging aanvroeg. Wel weet ik inmiddels dat je nu ieder jaar dit proces moet doorlopen , meeste websites hebben dit als extra veiligheid ingebouwd.
-
Het nut van die bundle (nr 3 in jouw voorbeeld) is mij nog niet duidelijk, mede omdat het invullen daarvan optioneel is.
In het verleden heb ik het ook op moeten zoeken. Heeft mogelijk te maken met bepaalde services die je op je NAS hebt draaien.
(e-mail server ??). De uitleg ervan is al wat langer geleden, dus weet het zo ook niet meer uit mijn hoofd.
Ik zet het er gewoon standaard bij. Merk geen problemen.
(Misschien met de extra certificaten ook in een OpenVPN configuratiebestand, heb je nog een extra controle match erbij??)
-
heb ik geen CSR gestuurd maar via hun website aangegeven dat ik een private.key wil ontvangen
Dat is vreemd. Een serieuze uitgever van certificaten zal nooit een private key versturen. Dat houdt nml in dat jij nooit zeker weet of zij geen kopie van de private key achter houden en dus altijd in jouw ssl verkeer kunnen kijken.
De goede methode is om zelf een private key te maken en dan een CSR file te maken op basis van die private key. Dat gebeurt beide als je binnen DSM een CSR aanmaakt. De CSR stuur je op en de private key houdt je achter. Die CSR ondertekent de ssl uitgever met hun root certificaat en voegt er de gewenste domeinnamen aan toe. Vervolgens stuurt hij dit als public key (Het certificaat) naar jou terug.
Vervolgens installeer je de eerder aangemaakte private key, samen met het ontvangen certificaat op de nas.
De hele omweg via een CSR file is er juist voor ontwikkeld om te zorgen dat de private key zelf nooit door anderen gezien kan worden. Dus ook niet door de uitgever van het certificaat.
-
Dat is vreemd. Een serieuze uitgever van certificaten zal nooit een private key versturen.
Ja en toch is het me via deze weg gelukt. Toen ik erachter kwam dat ik die private key (uit onwetendheid weggegooid) niet meer had gaven ze wel aan dat het proces van voren af aan moest omdat zij die key ook niet meer hadden. Of dat ook daadwerkelijk zo is weet ik natuurlijk niet.
Volgend jaar, wanneer ik het certificaat weer moet verlengen zal ik voor de optie van CSR kiezen, lijkt me idd veiliger.
-
Dat is vreemd. Een serieuze uitgever van certificaten zal nooit een private key versturen.
Bij mijn serviceprovider -als tussenpartij- (die het vervolgens ook bij een uitgever aanvraagt),
wordt ook een private key toegestuurd (en is terug te vinden in mijn account).
-
Dan is dat een foute uitgever. Punt
Soms sturen gebruikers wel eens een private key mee op bij de aanvraag. Een goede uitgever, vraagt dan om de CSR opnieuw te doen met een nieuwe private key. (Dergelijke goede praktijken zijn op dit forum ook wel gemeld)
En het klopt i.d.d dat er uitgevers zijn die zelf een private key aanmaken voor het gemak van de klant. Maar als gebruiker weet je dan nooit of ze dit niet delen met statelijke veiligheidsdiensten (al dan niet gedwongen) zodat deze diensten al je ssl verkeer kunnen ontsleutelen. Dit soort uitgevers kun je qua veiligheidsniveau niet serieus nemen.
Edit: Het zelf aanmmaken van een private key is geen rocket science. Op de nas (en elke pc) staat gewoon het commando "openssl" (of een equivalent), dat dit voor je doet:
openssl genrsa -out private.key 2048
DSM doet dat ongemerkt voor je als je nieuwe certificaten maakt.
-
Dan is dat een foute uitgever. Punt
Het zal best. Ik ga er toch niet achteraan om dat te veranderen of aan te passen.
Zou ik een volledige weektaak kunnen vullen om bij allerlei organisaties wat niet klopt aan te sturen op aanpassingen.
Overigens zit die private key bijv. NIET in mijn OpenVPN configuratiebestand.
Dat is een afwijkende sleutel. Gerelateerd aan een 2048 bit autorisatiesleutel.
(Naast nog eens in mijn geval een tweetal certificaten).
<tls-auth>
#
# 2048 bit OpenVPN static key
#
-----BEGIN OpenVPN Static key V1-----
xxxxxxxxxxx
-----END OpenVPN Static key V1-----
</tls-auth>
-
…Zou ik een volledige weektaak kunnen vullen om bij allerlei organisaties wat niet klopt aan te sturen op aanpassingen.
Dat klopt, maar bij een bedrijf waarbij de core-bussines het uitgeven van certificaten is, zou ik wat meer zorgvuldigheid verwachten. Ik snap wel dat ze zo veel minder probleem-vragen van klanten krijgen, waarbij het aanmaken van een private key en een CSR maken niet direct vlot. (Niet overal loopt dit zo simpel via een GUI als bij DSM).
Dan moeten ze de klanten maar iets vaker helpen en dus iets meer berekenen voor hun certificaten, want het hele ssl gebeuren berust er juist op dat de private key geheim blijft voor de buitenwereld.