Willekeurig de melding "SLL certificaat is gewijzigd" vanuit Cloud Station Drive

[pcrrules]

Ik heb op het forum gezocht naar vergelijkbare cases, maar ik kan mijn antwoord of case (nog) niet vinden. Zodoende toch maar een post over een SSL certificaat.

DSM versie
DSM 6.1.3-15152 Update 4

Type SSL certificaat
Comodo domein validatie

Achtergrond:
Ik heb een simpel Comodo domein certificaat aangeschaft. Ik heb het certificaat ingeinstalleerd volgens de handleiding van de partij waar ik hem heb aangeschaft (https://www.sslcertificaten.nl/support/Synology/Synology_DSM6_-_Installeren_SSL_Certificaat).

Aanmaken CSR en installeren van het certificaat ging zonder uitdagingen, synology zorgt er wel voor dat je geen fout kan maken.

Gebruikers loggen niet alleen in op de webportal, maar maken ook gebruik van cloud station drive om een map op hun computer te synchroniseren. En daar gebeurd nu net iets vreemd met het SSL certificaat.

De case:
Verschillende gebruikers krijgen willekeurig een melding op hun cloud station drive dat het certificaat is gewijzigd. Hierdoor stopt uiteraard de synchronisatie, om dit te verhelpen moet de gebruiker opnieuw inloggen op cloud station drive. Ik heb dit zelf ook al een keer gehad zonder een wijziging te doen aan cloud station drive en zonder wijziging te doen in de Synology DSM zelf.

Aangezien het aantal gebruikers op ongeveer 80 man zit is het niet wenselijk dat deze oplossing een standaard actie wordt. Bijgevoegd heb ik 2 foto’s (ja, printscreen was makkelijker geweest) van 1 van de gebruikers die deze melding laatst weer kreeg.

Ik heb google en fora afgestruint om te begrijpen waarom dit gebeurd. Heeft iemand anders ook eenzelfde probleem gehad of is er iemand die een idee heeft wat ik hier aan zou kunnen doen?

[Birdy]

Op het Synology Forum zie ik iets dergelijks echter, daar gaat het over LetEncrypt Cert.

Tijdelijke oplossing:

control panel >> Security >> Certificate >> Configure and select the Synology cert for Cloud Station Server this doesn't happen. It is not a FIX, but it is a work around.

[pcrrules]

Die post heb ik nog niet eerder gezien. Ik heb het default Synology certificaat voor cloud station server geselecteerd en alle overige diensten op het aangeschafte certificaat.
Nu krijgt iedereen uiteraard weer de melding dat het certificaat is gewijzigd, maar dit keer klopt het. Hopelijk is dit de laatste keer geweest, ik laat over een paar weken wel weten of dit een workaround is gebleken.

[Birdy]

Mooi echter, als deze work around inderdaad blijft werken, dan is het werkelijke probleem dus niet opgelost, zou hiervoor wel een Ticket inleggen dan.

[Briolet]

daar gaat het over LetEncrypt Cert.

Bij let's Encrypt is het logisch dat het certificaat elke 3 maand veranderd. Onterecht dat op het engelse forum iemand klaagt dat hij deze melding elke paar maand krijgt.

Als je Cloud Station met dezelfde naam verbind als in het certificaat staat, behoor je nooit een melding te krijgen. Als je echter een andere naam gebruikt of je locale IP nummer, dan moet je na elke update bevestigen dat je het nieuwe certificaat vertrouwt. (Door de naam mismatch mag cloud station niet zo aannemen dat ook dit certificaat vertrouwd wordt).

Maar hier is het een fixed certificaat dat nooit veranderd, dus zou die SSL vraag nooit moeten komen.

[pcrrules]

Als je Cloud Station met dezelfde naam verbind als in het certificaat staat, behoor je nooit een melding te krijgen. Als je echter een andere naam gebruikt of je locale IP nummer, dan moet je na elke update bevestigen dat je het nieuwe certificaat vertrouwt. (Door de naam mismatch mag cloud station niet zo aannemen dat ook dit certificaat vertrouwd wordt).

Maar hier is het een fixed certificaat dat nooit veranderd, dus zou die SSL vraag nooit moeten komen.

Hi Briolet ik begrijp niet helemaal wat je probeert uit te leggen.
Ik snap dat mijn certificaat een fixed certificaat is, deze heb ik afgenomen voor 3 jaar. De Let’s Encypt gaat maar 3 maanden mee en dan moet je hem opnieuw vernieuwen en krijg je uiteraard de melding dat het certificaat gewijzigd is. Juist om die reden heb ik een certificaat aangeschaft met een langere THT. Tot hier toe duidelijk.

Wat bedoel je echter met de ‘naam’ uit de zin ‘met dezelfde naam verbind als in het certificaat'? En wat bedoel je met ‘update’ uit de zin ‘dan moet je na elke update bevestigen dat je het nieuwe certificaat vertrouwt’?

Het SSL certificaat is gekoppeld aan cloud.domein.nl. Ik heb dit subdomeinnaam via DNS record naar het ddns adres gekoppeld van de synology. Dit werkt voor de web interface prima. Voor de cloud station server moet een gebruiker het quickconnectID gebruiken bij het ‘server adres’. Wanneer in het ‘server adres’ van de cloud station drive softare cloud.domein.nl gebruikt wordt, dan wordt dit adres niet gevonden. Wellicht dat hier de crux zit van mijn probleem. Als dit het probleem is, wat zou ik dan moeten doen om het probleem te verhelpen?

Ik blijf het dan nog wel apart vinden dat de melding van het gewijzigde SSL certificaat willekeurig naar boven komt bij verschillende gebruikers op verschillende momenten. Er zijn ook gebruikers die er bijvoorbeeld nooit last van hebben gehad.

[Briolet]

Wat bedoel je echter met de ‘naam’ uit de zin ‘met dezelfde naam verbind als in het certificaat'?

De URL waarmee je verbind moet overeenkomen met de URL waar het certificaat op uitgegeven is. Maar dat is iets wat altijd zo is bij een certificaat. Als daar een mismatch is, wordt het certificaat niet automatisch vertrouwd en moet je dat handmatig doen.

Van Quick Connect heb ik geen verstand. (Heb ik nooit aangemaakt of gebruikt) Daarom kan ik ook niet snappen dat Quick Connect kan werken met een certificaat. Dat Quick Connect ID staat toch nooit in het certificaat vermeld?

Ik gok dat je bij QC ook handmatig moet aangeven dat het certificaat betrouwbaar is. Deze week las ik elders op dit forum dat je soms spontaan een ander CQ ID ziet. Dan moet je waarschijnlijk dat certificaat weer bevestigen. En als dat ID weer de oude naam krijgt, is dat weer een verandering.

Cloud Station gewoon gebruiken met het de URL wat ook in het certificaat staat en niet via QC. Dan zijn waarschijnlijk alle problemen weg. Ook bij Let's Encrypt heb je dan geen 3-maandelijkse problemen.

[pcrrules]

Duidelijk.

Dan snap ik waar de crux zit en ik snap ook jou vraagteken hoe het certificaat ooit had kunnen werken met een QuickConnect-ID. Het vervelende is nu alleen dat de verbinding alleen maar tot stand komt wanneer ik dat Quickconnect-ID gebruik. Wanneer ik dtat QuickCOnnect-ID uitschakel en cloud.domein.nl gebruik (wat via de browser prima werkt), krijg ik de melding dat er geen verbinding gemaakt kan worden en ik mijn netwerk instellingen moet controleren. Ik ga eens nadenken en googlen waarom dat is.
Dank tot zover.

[Briolet]

poorten geforward?

[Briolet]

Dat over een veranderende Quick Connect naam staat hier.

Daar gebeurt blijkbaar een soort re-direct waardoor er plots met een andere naam verbonden wordt. Ik had dit nog niet eerder gelezen. Misschien is de standaard server overbezet of gestoord waardoor je ergens anders heen gestuurd wordt.

Sinds de introductie lees ik alleen over problemen met QC. Dit is een gammel systeem wat je via een ingewikkelde manier laat verbinden en je afhankelijk maakt van het constant blijven werken van de synology servers. Terwijl er al decennia lang een goed en veel minder storingsgevoelig systeem bestaat om met een server te verbinden. : de domeinnaam

[pcrrules]

Dat is het. Ik moet poort 6690 forwarden.

Zal ik het weekend eens doen. Klinkt nu allemaal wel erg logisch en bedankt voor de link.

//Edit
Zojuist de poort 6690 geforward en nu kan ik inderdaad netjes connecten via cloud.domein.nl met de cloud station drive. Heb gelijk QuickCOnnect uitgezet en mijn eigen certificaat weer aangezet voor cloud station drive.

Nu afwachten of het probleem is verholpen. Ik ga er wel van uit aangezien het erg logisch klinkt allemaal.

Nogmaals dank.