Let's Encrypt heeft problemen met uitgifte en vernieuwen certificaten

Let's Encrypt heeft vrijdag last van storing. De dienst heeft de problemen herleid tot responders voor het Online Certificate Status Protocol. Let's Encrypt kan vanwege de problemen geen certificaten vernieuwen of nieuwe certificaten uitgeven.

Gebruikers klagen vrijdag op de community-pagina van de dienst over het niet kunnen vernieuwen van certificaten. De beheerders van de certificaatautoriteit geven op de statuspagina aan op de hoogte te zijn van de problemen en te werken aan een oplossing.

Het probleem zou te maken hebben met ocsp-responders, wat tot diverse problemen met certificaatuitgifte leidt. Let's Encrypt verstrekt gratis X.509-certificaten voor tls-encryptie van verbindingen. In de afgelopen week liet de dienst weten 40 miljoen certificaten voor sites uitgegeven te hebben. In maart 2016, drie maanden na de start, waren dat er een miljoen.

Reacties (70)

[Ventieldopje]

Niet alleen bij de uitgifte/vernieuwing van certificaten maar omdat de OCSP servers er uit liggen/lagen betekende dit ook veel problemen met het bezoeken van websites waar OCSP stapling geconfigureerd is.

Ik kreeg vanochtend ineens melding dat er problemen waren met HTTPS en zag de OCSP stapling errors in de logboeken. Wetende dat een aanzienlijk deel Let's Encrypt certificaten gebruikte maar eens gaan kijken op hun status pagina maar daar stond alleen de acme server als down. Later hebben ze dit aangepast omdat ook de OCSP servers down bleken, beetje slordig dat dit pas veel later ontdekt werd.

Lijkt mij dat dit een enorm zwak punt is en best wat problemen kan opleveren als die servers een DDoS over zich heen krijgen.

[djwice]

Treedt het probleem dat je aangeeft alleen op als je OCSP Must Staple gebruikt of ook bij OCSP Stapling?

Hoe zou je dit issue automatisch kunnen ondervangen? (er even van uit gaande dat je gedurende de storing de performance hit voor de client accepteert).

[Reactie gewijzigd door djwice op 25 juli 2024 17:23]

[Ventieldopje]

Ook bij gewoon OCSP stapling want zo ver ik weet en lees is de must staple optie nog niet erg stabiel. Je zou OCSP stapling uit kunnen zetten, dan is het aan de browser om de OCSP request te doen (wat zal falen), wat denk ik net zo'n delay zal geven maar wellicht wel voorkomt dat de website onbereikbaar is, afhankelijk van wat je browser besluit.

Heb dit ook nog nooit eerder meegemaakt en had verwacht dat de OCSP cache dit wel zou ondervangen maar in mijn geval helaas niet dus. Hoe dan ook blijft het lastig en horen dit soort diensten stabiel te werken. Ik had veel liever gezien dat er een soort distributed systeem voor was, wat veel lastiger is plat te leggen.

[djwice]

Hmmmm... goed idee.
Hoe zouden we de keys veilig kunnen distribueren tussen de nodes?

[Verwijderd]

Dit geeft extra problemen omdat de certificaten maar kort geldig zijn. Misschien kunnen ze als het opgelost is certificaten voor een langere tijd ondertekenen.

[g1n0]

Ze hebben bewust voor 90 dagen gekozen. Lees hier hun blogpost hierover: https://letsencrypt.org/2015/11/09/why-90-days.html

[boyd91]

Ik verwacht niet dat de downtime zo lang zou duren. Ik draai de certbot iedere nacht, en 30 dagen voor het verlopen van een certificaat wordt hij vernieuwd. Dat geeft me dus 30 dagen speling.

[Brummetje]

Dan zou de storing iets van 2 maanden moet duren, dat lijkt me een beetje overdreven.

[azerty]

Vervelend natuurlijk, maar zolang ze het binnen een maand ofzo opgelost hebben is het voor de meeste die de aanbeveling volgen (elke maand hernieuwen) geen enkel probleem als het 1x misloopt

[CH4OS]

Je certificaat zou maar verlopen. Geen heel grote ramp natuurlijk, maar wel vervelend voor hen die nu dus niet kunnen vernieuwen, maar wel moeten vernieuwen, omdat ze bijvoorbeeld wel eens in de drie maanden vernieuwen.

[FvdM]

Je certificaat zou maar verlopen. Geen heel grote ramp natuurlijk,

Ehm..
- Veiligheids waarschuwingen in de browser.
- Broken trust chain, dus mailserver kan geen TLS mails meer ontvangen.
- Andere toepassingen die TLS verificatie toepassen (API clients) werken niet meer.

Daarom dus ruim van te voren renewen. Het beste is om hiervoor in een cronjob certbot renew te draaien dan kan je het ook niet vergeten. Lukt het niet door de storing dan pakt ie het wel in een volgende run.

[Reactie gewijzigd door FvdM op 25 juli 2024 17:23]

[CH4OS]

Tja, het kan inderdaad voorkomen worden, maar dat het nu even niet kan, is toch niet zo'n groot probleem? Dat is mijn punt meer. Het is niet dat de wereld vergaat, nu Let's Encrypt tijdelijk even geen certificaten kan uitdelen.

De mail kan altijd nog opnieuw geprobeerd worden (volgens mij doen de meeste servers dat ook), de veiligheidsmeldingen in de browser zijn te negeren, plus boeien niet zo _heel_ erg en het certificaat is in een mum van tijd vervangen, wanneer Let's Encrypt weer werkt...

API's hebben veelal selfsigned certificaten (die ik ken althans), dus daar staat vaak al de verify peer op uit.

[Reactie gewijzigd door CH4OS op 25 juli 2024 17:23]

[Eagle Creek]

Leg jij de klanten van je webwinkel maar eens uit dat dat ze de melding gewoon even moeten negeren en wel hun creditcardgegevens moeten ik vullen. En leg jij de rechter maar even uit dat je er "alles" aan hebt gedaan om je klantdata te beschermen met een verlopen certificaat. En leg jij je medewerkers maar eens uit dat ze geen salaris krijgen deze maand omdat de aan te leveren bestanden in de back-end niet verwerkt kunnen worden. Of dat je de updates op je serverpark niet geïnstalleerd konden worden omdat je niet remote kon inloggen..

Nee, voor één gemiddelde eindgebruiker is het niet erg. Voor een bedrijf dat certificaten gebruikt om hun infrastructuur te beschermen kan dit enorme hoeveelheden geld kosten. Moet je voorstellen dat Bol.com een certificaat warning geeft of ING.nl. Absoluut ondenkbaar.

Dus.. Zorg je ervoor dat je tijdig vernieuwt en/of een back-up certificaat klaar hebt liggen om direct in te zetten. Of in het uiterste geval je diensten zelfs geheel tijdelijk zonder certificaatbescherming levert..(In de gevallen waar beschikbaarheid boven vrrtrouwelijkheid/integriteit staat).

Overigens is dat een generiek risico, niet specifiek van Let's enCrypt. Het feit dat dit toevallig een gratis dienst is betekent niet automatisch dat het minder betrouwbaar is.

[Reactie gewijzigd door Eagle Creek op 25 juli 2024 17:23]

[CH4OS]

Sorry, maar als je een webshop draait met een Let's Encrypt certificaat ben je ook niet goed bezig, dat zijn immers 'slechts' domain validated certificaten. Maar ja, alles om de ranking in Google op te krikken zonder verder te kijken.

Zeker voor zaken als salaris betalingen e.d, kun je geloof ik geeneens domain validated certificaten gebruiken. Dan wil je ook de eigenaar van het certificaat valideren.

[Reactie gewijzigd door CH4OS op 25 juli 2024 17:23]

[FvdM]

Sorry, maar als je een webshop draait met een Let's Encrypt certificaat ben je ook niet goed bezig, dat zijn immers 'slechts' domain validated certificaten. Maar ja, alles om de ranking in Google op te krikken zonder verder te kijken.

Een certificaat biedt technisch alleen de encryptie, daarin zijn betaald, gratis, DV en EV gelijk aan elkaar. Maar met crypto is nog altijd beter dan informatie in plain text over het internet te sturen. En het maakt HTTP/2 mogelijk wat een performance winst kan opleveren.

Het zakelijke verschil zit in de verzekeringswaarde. Bij Let's Encrypt krijg je geen financiële compensatie als het geleverde certificaat verkeerd wordt uitgegeven. Dat wil zeggen, er is een cert in jouw naam uitgegeven aan heel iemand anders. Voor bijvoorbeeld Comodo PositiveSSL ben je verzekerd tot $10.000 schade. Dat is echter een wassenneus. Als de certificaten onbetrouwbaar blijken te zijn dan stort heel de uitgever de afgrond in, kijk maar naar DigiNotar en StartCom/WoSign.

Is het bedoeld voor verificatie doeleinden dan volstaat natuurlijk alleen Extended Validation (EV), maar ook dat geeft geen 100% zekerheid. De CA kan immers rogue gaan, zoals al eerder is gebeurd. Dan kom je uit op technische implementatie: HPKP met TLSA en DNSSEC. Alleen als de client die dingen strict controleert heeft een EV pas echt waarde. Anders is het gewoon een willekeurige naam is de adresbalk met dezelfde waarde als het slotje dat alleen maar werkende HTTPS aangeeft.

[tormentor1985]

Het gaat er uiteindelijk enkel om dat de verbinding tls encrypted is. Een self signed certificaat wat jij besluit te vertrouwen is net zo veilig als een certificaat wat door een ca is uitgegeven die onze browser als veilig beschouwd.

[djwice]

API's die ik ken hebben toch echt publieke certificaten. Waarom ook niet? Je zou toch niet willen dat een man-in-the-middle gewoon offload en self signed doorzet en jij de transactie dan accepteerd.

Denk aan API voor data van slimme meters. Denk aan API voor login met OpenID. Denk aan API voor het transactie overzicht van je bankrekening. Etc.

[BlaTieBla]

Selfsigned kan heel goed gebruikt worden tussen services/api's, zolang je aan beide kanten maar iets in de vorm van certificate pinning doet op die systemen.
Het enige wat je nml wilt bewerkstelligen in zo'n situatie is dat de data versleuteld is en dat je zeker weet met wie je communiceert.
In een one-to-one of one-to-few situatie kan dat een hele goede oplossing zijn, omdat dan wijzigingen in de keten eenvoudig te communiceren zijn. En bij wijzigingen met publieke certificaten zal je dat ook door moeten geven aan je communicatiepartner.

[tormentor1985]

Sterker nog, bij op java gebasseerde api's is voor het accepteren van bijv een pki overheidscertificaat exact dezelfde handeling nodig dan het accepteren van een self signed certificaat. Een java applicatie vertrouwd standaard namelijk geen enkel tls endpoint tenzij het certificaat in de truststore staat. Dat is heel anders dan wat onze browsers doen want daar bepalen microsoft, google en mozilla wat wel en niet te vertrouwen is.

[CH4OS]

En dergelijke API's zou jij vertrouwen als zij een Let's Encrypt SSL certificaat (die alleen domain validated zijn) hebben? Voor zulke data, zou ik zelfs een Let's Encrypt certificaat niet willen en verwacht ik toch echt een organization validated certificaat, zodat ik ook zeker weet dat ik met de instantie praat waarvan er gezegd wordt dat ik ermee praat.

Dat maakt een man in the middle nog lastiger.

[Reactie gewijzigd door CH4OS op 25 juli 2024 17:23]

[BlaTieBla]

Afhankelijk van de scope van het 'project'. Als de ene partij in Australie zit en de andere hier in NL dan is LE een uitdaging om de geldigheid goed vast te kunnen stellen, dan zou je publieke organisatie verified certificaten willen gebruiken. Maar als je project binnen het zelfde bedrijf is en misschien zelfs nog wel binnen 1 afdeling waarbij je invloed heb hebt op client en server... waarom dat een duur Verisign certificaat van 1500 per jaar kopen als een LE ook perfect werkt.

[djwice]

Ok een AWS signed dan

[CH4OS]

Tja, wíe het certificaat getekend heeft maakt natuurlijk niet uit, zolang het certificaat maar een organization validated certificaat is.

[djwice]

Hmm... die je vertouwd iedereen die zegt dat hij gevalideerd heeft dat het de organisatie zelf is.


Let's Automate: vraag bij kvk de domein op, komt die overeen, dan is het domein van die kvk. Stuur e-mail naar adres dat bij kvk hoort, klikken ze de link en vullen kvk weer in, validatie compleet. Namen domein, aanvraag en kvk gelijk. -> bonus punten.

Goed genoeg?

Dan kunnen we dit voor meerdere landen implementeren. Wellicht code voorstellen aan Let's Encrypt.

[Reactie gewijzigd door djwice op 25 juli 2024 17:23]

[BlaTieBla]

Hoe gratis denk je dan dat LE blijft? Die afhankelijkheden/koppelingen met externe partijen (in NL KvK en SIDN) moeten veilig zijn en onderhouden worden. Een KvK doet dat niet gratis kan ik je zeggen. Plus dat ieder land een eigen KvK heeft met andere wensen en eisen.
Gedoemd te mislukken (als je LE gratis wilt houden iig).

Daarnaast kunnen systemen geen goed onderscheid maken tussen Bijvoorbeeld 'Bedrijfsnaam B.V. in 's Gravenhage' en 'Bedrijfsnaam BV in Den Haag'.
Zaken die door mensen als goed of fout geïnterpreteerd kunnen worden, of nagevraagd kunnen worden. Een Whois en KVK administratie zijn nml vaak genoeg out-of-sync en vereisen met grote regelmaat handmatige acties aan de kant van de klant om zaken te corrigeren (in de CSR, of de Whois database).

[djwice]

KVK geeft die info nu wel gratis hoor via API. En anders via BAG register.

Maar van mij mag die extra validatie ook geld kosten hoor. De automatisering met mooie API vindt ik cool.

[FvdM]

Hangt van je toepassing af. Voor een hobby projectje, sure geen probleem, maar voor een (realtime) API endpoint kan dat processen lam leggen die daar gebruik van maken.

Maar dat het zou geen probleem hoeven te zijn als je geautomatiseerd de renewals pusht, ruim voor de vervaldatum. Heb je een nieuw certificaat nodig en wel nu direct, dan moet diegene maar even een betaalde cert nemen. Dat hoeft ook niet duur te zijn, maar is even iets minder gemakkelijk dan Let's Encrypt.

[CH4OS]

Mag hopen dat de (realtime) API endpoint dan een betaald certificaat heeft en hier dus geen last van heeft, omdat een certificaat dan een veel langere geldigheidsduur heeft dan de certificaten van Let's Encrypt.

[BlaTieBla]

Betaalde certificaten gaan net zo vaak fout hoor. Die dingen zijn tegenwoordig 2 of 3 jaar houdbaar en tegen die tijd is iedereen dat vergeten en/of werken de betrokkenen van destijds er niet meer en dan gaat het ook fout.
Een klein voordeel van LE is dat de renewal te automatiseren is en je de menselijke factor op dat vlak mist. Daarnaast is de doorlooptijd van een betaald certificaat vaak vele malen langer, dus is het ook sneller recht te trekken bij een LE versie (als de service niet in zijn geheel op z'n gat ligt).

[CH4OS]

Een beetje SSL certificaat leverancier houdt dat voor jou bij. Toen ik een (betaalde) SSL certificaat had bij Xolphin kreeg ik een maand voordat het certificaat verliep een bericht dat mijn certificaat dreigde te verlopen. Heb je dus een betaalde certificaat en krijg je een dergelijke reminder niet, zou ik zeker overwegen om over te stappen naar een andere leverancier.

[BlaTieBla]

De aanvrager krijgt de email, maar die kan na 2.5 jaar een andere baan/functie/mail adres hebben waardoor de mail in de bitterbak valt.
Ik heb jaren aan verisign certificaten resellen gedaan en je wil niet weten hoe vaak ik hoorde dat de email ergens in /dev/null verdwenen was en dat men dus eigenlijk best wel met spoed een nieuwe wilde omdat de webwinkel (or whatever) plat lag.

[CH4OS]

Zo kun je alles wel blijven afschuiven. Als je als bedrijf de contact gegevens niet bijhoudt, dan laat je zelf ook echt wel een steekje vallen als bedrijf natuurlijk.

[BlaTieBla]

Klopt, maar bij hoeveel doorsnee ict afdelingen weet men exact wat certificaten inhouden en wat daarbij komt kijken qua beheer? Dat is verbazingwekkend laag kan ik je zeggen. En dan heb ik het niet alleen over de slager op de hoek met z'n webwinkeltje, maar ook zelfs de multinationals.
Certificaten/PKI is een vak apart wat heel vaak onderschat wordt.

[Verwijderd]

Sowieso beetje raar om dat soort dingen op een persoonsadres binnen te laten komen en niet op een afdelingsalias zodat iedereen op die afdeling (bijv sysops) dit binnenkrijgt.

[Verwijderd]

Doorlooptijd valt prima mee. Uitzondering van de certificaten waarbij een check wordt gedaan op Kvk etc.

Zeker bellen is in dit geval ook vaak een stuk sneller.

[tormentor1985]

Een beetje sysdadmin maakt als hij een certificaatje inklopt meteen een entry in het monitoringsysteem die de een warning geeft als het certificaat bijna gaat verlopen.

[ASS-Ware]

Je certificaat zou maar verlopen. Geen heel grote ramp natuurlijk, maar wel vervelend voor hen die nu dus niet kunnen vernieuwen, maar wel moeten vernieuwen, omdat ze bijvoorbeeld wel eens in de drie maanden vernieuwen.

Ze zijn steeds 3 maanden geldig, maar na 2 maanden probeert de let's encrypt client al te vernieuwen.
Je hebt dus een maand de tijd om die vernieuwing opnieuw te proberen.

[Blokker_1999]

Dat klopt, maar vergeet niet dat LE op termijn die termijnen wil verkleinen. Dan spreken we niet meer over maanden, zelfs niet over weken maar slechts over dagen. En dan zijn dit soort storingen wel nefast.

[servicedb]

Een goede implementatie doet dit na 60 - 72 dagen al zodat er een ruime marge is :-). Stel dat Let's Encrypt om wat voor reden dan ook helemaal niet bruikbaar is, dan kan je altijd nog zelf een certificaat kopen in het ergste geval (kost voor een enkele website de kop niet, maar als je meerdere hebt dan kan het snel oplopen).

[CH4OS]

Bij meerdere (sub)websites kun je natuurlijk ook een Wildcard certificaat overwegen.

[BlaTieBla]

Een wildcard certificaat? Da's vloeken in de kerk hoor . Overigens zie ik steeds meer appliances die wildcard's niet accepteren. Om het veilig te houden wil je de private key in de software gegenereerd hebben (of appliance) waar de private key non-exportable is. Alleen dan ben je redelijk zeker dat die private niet gaat wandelen.
Bij wildcards zie je vaak genoeg dat een aantal mensen toegang tot dat p12/pfx bestand hebben en de veiligheid/betrouwbaarheid van dat wildcard certificaat per definitie al om zeep is.

[CAPSLOCK2000]

Vervelend natuurlijk, maar zolang ze het binnen een maand ofzo opgelost hebben is het voor de meeste die de aanbeveling volgen (elke maand hernieuwen) geen enkel probleem als het 1x misloopt

Dat OCSP er uit ligt is een stuk vervelender. Systemen die daar gebruik van maken (en dat zouden ze eigenlijk allemaal moeten zijn) komen snel in de problemen.

[Mr. Boojengle]

Inderdaad, daarentegen was het niet kunnen vernieuwen (wat eigenlijk een non-issue zou moeten zijn) nog het minste probleem. Als het zaakje 1 dag in storing zou staan heb je voor de certificaten nog 1 maand de tijd om de vernieuwing te regelen ruim voldoende lijkt me.

OCSP was inderdaad een veel groter probleem, een hele boel sites gehad die sinds vanmorgen performance issue's hadden hierdoor en een hele stapling response errors.

[Reactie gewijzigd door Mr. Boojengle op 25 juli 2024 17:23]

[Henrikop]

Hernieuwen lijkt me vooralsnog geen probleem, maar als je kijkt naar de aantallen dan zijn er duizenden nieuwe domeinen die er bijkomen per dag en dan is het vervelend als dit ineens een dag of meer vertraging heeft.

Zeker als je het helemaal geautomatiseerd hebt en je platform even geen nieuwe portal kan opleveren (en tegenwoordig wil je niets meer op HTTP afleveren, ik niet althans).

Maar goed dienst doet het praktisch altijd.

[mscha]

Wel direct een probleem.
Browsers gaven (soms) ook foutmeldingen doordat ze niet konden checken of het certificaat ingetrokken was.

[whitey-d]

Live gaan met een andere URL vereist ook een certificaatupdate, zal daar helaas op moeten wachten.

[Loekie]

Gheh, zag in bugtracker al mensen 'mekkeren'

Zakelijk voor ons wel even minder, volgende week maar weer proberen.
(gaat om aanvraag nieuwe certificaten)

[Reactie gewijzigd door Loekie op 25 juli 2024 17:23]

[Yzord]

Ik heb hem om de drie maanden staan. Is dat terug gezet naar elke maand?

[joelharkes]

Ai dat zal hun imago wel een groote schade toebrengen. echt een mooie techniek&service let's encrypt. Het idee dat je kklant alleen nog maar een dns hoeft aan te vragen en juiste dns wijziging hoeft te doen en jouw applicatie automatisch een ssl certificaat kan regelen is echt geniaal. het scheelt zoveel beheer.

Maar nu zullen we bij ons wel twee keer nadenken als de let's encrypt voor productie doeleinden gaan gebruiken, omdat je namelijk best vaak je certificaten moet vernieuwen, moet die storen net in die period zitten. (je kunt natuurlijk altijd halverwege de verstreken periode al opnieuw certificaat proberen aan te vragen, dan dek je jezelf in)

[Kees]

Je vervangt je certificaten ook gewoon tijdig en niet vlak voordat ze verlopen. Zo renew ik de certificaten voor deze site elke maand gewoon. En als dat niet goed gaat heb ik nog 2 maand om het te fixen.

[Iva Wonderbush]

Renew je ook via Let's Encrypt? Want ik kijk elke 12 uur of ik al mijn domeinen kan hernieuwen maar pas voordat de certificaten aflopen kan ik pas een renewal uitvoeren die succesvol is, elk ander request wordt door Let's Encrypt geskipped.

[thomas1907]

/path/to/certbot/certbot-auto renew --force-renew

zou het renewen moeten forceren

en om te testen kun je dit doen:

/path/to/certbot/certbot-auto renew --dry-run --force-renew

[Reactie gewijzigd door thomas1907 op 25 juli 2024 17:23]

[Iva Wonderbush]

Ik gebruik:

letsencrypt renew --agree-tos

En krijg terug:

The following certs are not due for renewal yet:
/etc/letsencrypt/live/<domain>/fullchain.pem (skipped) (keer 6)
No renewals were attempted.

[Reactie gewijzigd door Iva Wonderbush op 25 juli 2024 17:23]

[thomas1907]

En als je daar achter --force-renew neerzet? Gok dat die het dan wel zou moeten doen

[Iva Wonderbush]

Ik zal vanavond kijken of dat lukt, dankjewel.

[CH4OS]

Volgens mij kun je eens per maand vernieuwen, zonder gelijk te moeten forceren.

[Kees]

Ik renew soort van via let's encrypt. Ik heb een eigen wrapper eromheen geschreven zodat ik bijvoorbeeld de certificaten mbv de api van de loadbalancers op de juiste plek kan zetten. We draaien niet een heel erg standaard setup waar letsencrypt out of the box werkt.

Ik doe dus gewoon elke maand een renew, met dezelfde csr zodat er niet al teveel veranderd. En dat gaat niet via letsencrypt renew maar 'certonly --standalone' etc waarbij ik mijn eigen keys en crt genereer (in het verleden kon je geen ECDH certificaten via de normale procedure krijgen).

[thomas1907]

Want als je 1 keer storing hebt, is het meteen een "grote schade voor hun imago"? Iedereen heeft wel is storing, toch?

Hoezo 2 keer nadenken over productie doeleinden gebruiken, verliezen jullie meteen al jullie vertrouwen in een product als dit 1 keer een storing heeft?

[Reactie gewijzigd door thomas1907 op 25 juli 2024 17:23]

[Oerdond3r]

Incidentje moet kunnen, als ze het ook snel weer weten op te lossen.

Gaat dit vaker gebeuren dan gaan ze wel imagoschade krijgen, denk ik zo.

Volgens mij hebben ze al een fix gedeployed: https://app.status.io/pages/55957a99e800baa4470002da

[Reactie gewijzigd door Oerdond3r op 25 juli 2024 17:23]

[Brummetje]

Je vernieuwd je certificaten ook niet op de laatste dag natuurlijk. Dit doe je ruim van te voren en dan maakt zo`n storing helemaal niks uit.

[- peter -]

Ik heb een cronjob waar elke week gewoon alles word gechecked en vernieuwd word wanneer dat kan.

[base_]

Standaard geautomatiseerde renewal door certbot is 30 dagen voordat certificaat verloopt, dus ze hebben nog even voordat paniek uitbreekt/in gebruik zijnde certificaten daadwerkelijk verlopen....

[Iva Wonderbush]

Ik had al zo'n vermoeden toen er 3 werden aangevraagd, "succesvol" waren maar toch niet. Heb alleen nog geen tijd gehad om te kijken, gelukkig heb ik Tweakers!

[boyd91]

Volgens de statuspage is alles weer up and running, maar ik krijg nog steeds de 504 gateway timeout bij de aanvraag van een nieuw certificaat.

Edit: Ik had niet goed gekeken, het gaat momenteel om de OSCP servers die weer operational zijn. De ACME server heeft vooralsnog problemen.

[Reactie gewijzigd door boyd91 op 25 juli 2024 17:23]

[AmazingDreams]

Volgens de statuspagina is het alweer opgelost. Zelf niet getest.

https://app.status.io/pag.../591ed0da457ea42d38001796

[Reactie gewijzigd door AmazingDreams op 25 juli 2024 17:23]

[Echron]

Net 2 certificaten kunnen vernieuwen.

acme-v01.api.letsencrypt.org zou weer operationeel zijn, de statuspagina geeft wel aan dat nog niet alles 100% is.
Hopelijk blijft het nu zo. Ik ben benieuwd naar de oorzaak.

[alienfruit]

Misschien komt het hierdoor dat iOS de SSL-certificaat van Let's Encrypt niet meer vertrouwd. Ik kan momenteel niet mijn mail checken. Erg vreemd, omdat het SSL certificaat nog niet is verlopen.

[mutley69]

Ik ben benieuwd naar wat de oorzaak op iOS zal zijn. Veel is er niet nodig om certificaten-verificatie te laten mislopen - het is in elk geval een interessante gebeurtenis. Jammer dat er weer zoveel slachtoffers door vallen. Nu ja - 't is gratis, dus moeten we dat er maar bij nemen zeker?