certificaat vernieuwen lukt niet

[reindu]

Ik heb een aantal websites op de NAS draaien, allemaal https. Ik kreeg een melding van de Let's Encrypt Expiry Bot dat een aantal verlopen.
Via configuratiescherm/beveiliging/certificaat/certificaat vernieuwen is dat in het verleden gelukt, maar nu krijg ik een melding:'De bewerking is mislukt. Meld u opnieuw aan bij DSM en probeer het opnieuw.'Poorten 80 en 443 staan open.
Op internet vond ik een ssh script om alle certificaten tegelijk te vernieuwen: /usr/syno/sbin/syno-letsencrypt renew-all -vv maar dat werkt ook niet.
Moet ik maar wachten tot ze verlopen zijn en een nieuw aanvragen?

[_-_Robin_-_]

Goedendag,

Hier het zelfde probleem gehad, als u naar de www.mijnnas.nl:80 gaat waar komt u dan op uit?

Het zou goed kunnen zijn dat die als eerste keus op staat en de NAS geen vrije toegang krijgt.
Bij mij was dit de app web station deze gewist en hij werkte weer.

Robin

[reindu]

Ik ben niet zo ingevoerd in het netwerk gebeuren. Wat bedoel je met www.mijnnas.nl:80 ? Mijn Nas bereik ik via het ipadres:5001 of xxx.synology.me:5001. Web Station zorgt juist voor de virtuele host van al mijn websites, dus wissen lijkt me geen optie.
Mijn websites zijn nu gewoon te bereiken met //https:www.mijnwebsite.nl

[Babylonia]

Gebruik zelf geen Let's Encrypt certificaten,
maar mogelijk is het een en ander "tijdelijk" niet werkend, omdat achterliggend bij Synology de server m.b.t. je Synology account "down is".
Nu is "Let's Encrypt" wel een andere externe connectie, maar het is onlosmakelijk toch verbonden met de Synology producten die je afneemt,
en daarmee wellicht ook een connectie met het account bij Synology.

Al pakweg 2 misschien 3 dagen is er geen connectie mogelijk, met een "500" als foutmelding in de webpagina getoond.
Heb n.a.v dit voorval daar vanuit mijn interne connecties met Synology in Taiwan inmiddels een e-mail over gestuurd.
Omdat de problemen ermee, naar mijn gevoel net te lang aanhouden.  Nog geen reactie terug.

(Opgemerkt omdat ik een ticket wilde insturen n.a.v. VPN connectie problemen beschreven < HIER > ).

[Briolet]

Mijn Nas bereik ik via het ipadres:5001 of xxx.synology.me:5001. …
Mijn websites zijn nu gewoon te bereiken met //https:www.mijnwebsite.nl

Je gebruikt dus 3 namen . Een IP adres kan niet op een Let's encrypt certificaat staan en geeft een certificaatfout

Gebruik je 2 verschillende certificaten voor de twee hostnamen, of staan beide op 1 certificaat?  Het verifiëren van een een synology naam gebeurt 'poortloos', die van je website gaat via poort 80.  De eerste is gevoelig voor storingen op de synology server, de tweede gaat buiten synology om.

[reindu]

Ik heb  vif websites draaien met https, met eigen certificaten. Ik reageerde op de post van Robin, want ik wist niet of de benadering van mijn NAS belangrijk was. Het invoeren van de certificaten is dus lang geleden goed gelukt, de websites draaien al jaren en het verlengen van de certificaten was al eerder gelukt. Maar nu loop ik tegen dit probleem aan.,

[Babylonia]

Al pakweg 2 misschien 3 dagen is er geen connectie mogelijk, met een "500" als foutmelding in de webpagina getoond.

Vergeet die eerdere reactie over dit onderdeel.   Mogelijk te maken met discrepanties in de webbrowser op mijn desktop PC.
Op een laptob en via bijv. Android smartphone geen problemen ermee.

[Briolet]

Op internet vond ik een ssh script om alle certificaten tegelijk te vernieuwen: /usr/syno/sbin/syno-letsencrypt renew-all -vv maar dat werkt ook niet.

Dat is hetzelfde script dat de nes 1x per week runt. (maar dan zonder de '-vv') Het loopt alle certificaten na en start een vernieuwing voor certificaten die binnen 1 maand aflopen. Maar als de button binnen het certificaten-menu niet werkt, zal dit script ook niet werken.

Verder heb ik geen idee. Als poort 80 open staat en er staat alleen 1 domein op, zou ik niet weten wat er nog meer te doen is. Zeker als het altijd gewerkt heeft.

Gebruik je dsm5?  En er is recentelijk een root certificaat van Let's Encrypt verlopen. Oudere versies van Drive konden daar ook niet mee omgaan. Misschien dat er nog meer oude onderdelen zijn die hier fout mee omgaan.

[reindu]

Ik heb DSM geupdate naar DSM 6.2.4 Update 2. Dat maakte wel verschil. Oorspronkelijk meldde DSM heel snel na 'certificaat bijwerken' dat het niet kon, nu deed hij er zeker 5 minuten over met dezelfde mededeling. Toen heb ik het script geprobeerd en JA, een aantal websites hebben nu 24-1-2022! Bij de overgeblevene nog eens het knopje bijwerken geprobeerd, maar weer niks. Nog een keer het script en ja hoor, alles is weer bij.
Het script werkt dus beter dan de DSM routines.
Toch is dit onbevredigend, het heeft een hoog 'Hans Klok' gehalte, een magisch script en hij doet het, maar waarom nu wel?

[Briolet]

Let's Encrypt heeft 'onder water' meerdere procedures om het certificaat te vernieuwen. Een deel is inmiddels verouderd. Ik houd het niet zo bij omdat het een gecompileerd script is en je de regels dus niet even kunt nalopen.

Het synoscript is vrijwel een script van Let's Encrypt zelf met een paar aangepaste regels. Miischien dat er met de DSM update ook een nieuwer script geïnstalleerd is.

Het script is echt hetzelfde dat de nas standaard elke week rund. Je ziet het in de cron-log file waar het aanroepen van dat script expliciet met pad gelogd wordt.

[Briolet]

Ik heb voor de aardigheid eens via ssh gekeken. Dan vind ik:

Code: [Selecteer]

root@GedeeldeData:/usr/syno/etc/letsencrypt# ls account
6NjoC1  BKSQ6y  HpAL56  jaaBL5  qbVuZb  Ti4y8D

root@GedeeldeData:/usr/syno/etc/letsencrypt# ls account/6NjoC1
info.json  private_key.json

root@GedeeldeData:/usr/syno/etc/letsencrypt# cat account/6NjoC1/info.json
{
   "account_url" : "https://acme-v02.api.letsencrypt.org/acme/acct/64579283",
   "contact" : "administrator@gebruederhummelxxxxx.nl",
   "directory" : "https://acme-v02.api.letsencrypt.org/directory",
   "version" : 2
}
root@GedeeldeData:/usr/syno/etc/letsencrypt# cat account/BKSQ6y/info.json
{
   "contact" : "info@yyyyyy.nl",
   "directory" : "https://acme-v01.api.letsencrypt.org/directory",
   "version" : 1
}

Het lijkt er op dat hij voor elk certificaat de settings opslaat in een folder. Als ik in de folders "6NjoC1" en "BKSQ6y" kijk, zie ik verschillende e-mail adressen van mij staan. Dat zal het e-mail adres zijn dat ik bij het aanmaken opgegeven heb. Wat ik echter ook zie is dat bij de een "versie 1" staat en bij de andere "versie 2".  Bijden wijzen ook naar een andere api voor het updaten van het certificaat.

Zonder het zeker te weten, krijg ik het vermoeden dat de eerder aangemaakte certificaten nog steeds het oude serveradres gebruiken. Tenzij er in het script zelf nog iets staat dat de oude adressen overruled.

[JdM]

Ik heb hier ook altijd ellende mee en heb geen handige oplossing, maar voor mij wel een die werkt:
Wanneer ik in de virtuele host instellingen een fictieve poort (bijvoorbeeld 1) aan http en https koppel ipv 80/443 en dan de certificaten vernieuw werkt het wel.
Je website is dan even down ten tijde van het tijdelijk koppelen aan de genoemde poort, maar zodra je poort 80/443 weer aanvinkt is alles weer oké.
Ik heb zelf meerdere websites op mijn synology draaien en moet dit steeds voor iedere virtuele host doen, dus dat kost me meer tijd dan gewenst, maar het werkt uiteindelijk dus wel.

[reindu]

JdM,
Lollige oplossing, zeker om te onthouden, maar hoe kom je daarop? Per ongeluk, of wanhopig alle mogelijkheden proberen?

[JdM]

Haha, ja wanhoop is wel een passende benaming 
Ben er ook met het Synology servicecentre niet uit gekomen, dus ik moest iets.
Ik kwam er min of meer achter dat het zo werkte, omdat een site die offline was omdat deze naar een verkeerde documenthoofdmap verwees wél wilde vernieuwen. Je kunt dus ook een verkeerde documenthoofdmapverwijzing maken, maar die verkeerde poort instellen gaat gevoelsmatig iets sneller