Let's Encrypt trekt onlangs uitgegeven ALPN-certificaten in

Let's Encrypt trekt vanaf vrijdag ssl- en tls-certificaten in die onlangs zijn uitgegeven. Dat doet de certificaatautoriteit nadat er zwakke punten werden ontdekt in de verificatiemethode voor webdomeinen. Dat is aangepast, maar recente certificaten moeten opnieuw worden uitgegeven.

Let's Encrypt schrijft dat het vanaf 28 januari 15.00 begint met het intrekken van bepaalde certificaten. Dat gebeurt over een periode van vijf dagen. Het gaat om alle certificaten die vóór 25 januari om 23.48 zijn aangemaakt met behulp van de TLS-ALPN-01-methode. Let's Encrypt zegt niet om hoeveel certificaten het gaat, maar schat in dat het om 'minder dan een procent' gaat van alle actieve certificaten die de instantie heeft uitgegeven. Beheerders krijgen een melding als hun e-mailadres bekend is bij Let's Encrypt, maar veel websitebeheerders zijn voor hun certificaten afhankelijk van hun hostingprovider.

Volgens Let's Encrypt zit er 'een onregelmatigheid' in validatiemethode 'TLS Using ALPN' die Let's Encrypt gebruikt om domeinen te verifiëren. Daarin zaten twee fouten, waar Let's Encrypt niet veel over uitweidt, maar waarvan het schrijft dat het die aangepast heeft. TLS-ALPN-01 is een validatiemethode die niet standaard wordt gebruikt in CertBot. Beheerders kunnen de methode gebruiken om ALPN-certificaten te valideren. De functie was tijdelijk uitgeschakeld, maar werkt inmiddels wel weer, zegt Let's Encrypt.

Reacties (49)

[.oisyn]

Voor de mensen die ook niet wisten wat TLS-ALPN-01 validatie inhield, het is een challenge-response validatiemethode waarbij de response komt in de vorm van een speciaal voor dit doel gemaakt self-signed certificaat dat wordt geserveerd op de webserver*. De ACME server downloadt je certificaat en controleert zo of jij controle hebt over het domein waarvoor een certificaat wordt aangevraagd.

Dit is dus een alternatief voor HTTP-01 en DNS-01, waarbij respectivelijk een specifieke file wordt geserveerd op de webserver op dat domein met de challenge response, en waarbij een specifiek DNS record wordt gezet. Alleen die laatste is bruikbaar voor wildcard certs.

* Webserver is een groot woord, hij hoeft alleen de TLS afhandeling te kunnen doen. Dank @Sebazzz voor de toevoeging.

[Reactie gewijzigd door .oisyn op 24 juli 2024 14:29]

[Sebazzz]

Het mooie van TLS-ALPN-01 is dat je geen webserver nodig hebt, je hebt alleen een host nodig die naar poort 443 luistert.

[The Zep Man]

je hebt alleen een host nodig die naar poort 443 luistert.

Wat net zo goed een webserver kan zijn die op poort 80 luistert en die enkel online is tijdens validatie (die ook in certbot is ingebouwd).

Er zullen wel use cases zijn voor ALPN, maar het opzetten van een (tijdelijke) webserver op poort 80 lijkt mij simpeler in de meeste gevallen. Het is al helemaal geen punt als je een reguliere site draait, want dan heb je vaak toch al een HTTP listeren op poort 80 draaien om verkeer door te sturen naar poort 443.

[Reactie gewijzigd door The Zep Man op 24 juli 2024 14:29]

[Bor]

Het is al helemaal geen punt als je een reguliere site draait, want dan heb je vaak toch al een HTTP listeren op poort 80 draaien om verkeer door te sturen naar poort 443.

Dat hoeft al lang niet meer en is geen best practice vanuit beveiligingsoogpunt.

[Martin.Air]

...is geen best practice vanuit beveiligingsoogpunt.

Dat is nogal een statement, zou je die toe kunnen lichten?[quote]

[Reactie gewijzigd door Martin.Air op 24 juli 2024 14:29]

[Verwijderd]

Minder poorten open = minder exposure vanuit het internet. Minder poorten open is altijd al een best practice geweest ongeacht wat er achter draait.

[Martin.Air]

Eens, maar in dit geval draait hoogstwaarschijnlijk dezelfde server op poort 80 als op poort 443. Dan zou het zwaktepunt in deze zelfde applicatie zitten. In theorie zou er natuurlijk een kwetsbaarheid kunnen zitten in de http module die verborgen wordt door de https module, maar persoonlijk acht ik dit verschil nihil.

[Verwijderd]

Dezelfde applicatie betekent helaas vaak niet dezelfde code (of libraries). Een stuk software kan best een exploit hebben op HTTP terwijl dat niet in HTTPS zit.

We praten hier ook over terwijl er enkel een probleem zit in TLS-ALPN-01 module van LetsEncrypt, dus ik hoef mijn punt verder niet te maken denk ik

Tevens draai ik zelf een fysiek andere server op poort 80 dan dat ik draai op poort 443, dus het is niet ongewoon. Ik kan bij ook voorstellen dat loadbalancers en caching software vrij standaard zijn binnen webserver clusters dus ik verwacht dit verschil zeker niet nihil.

[The Zep Man]

Dat hoeft al lang niet meer en is geen best practice vanuit beveiligingsoogpunt.

Met een site die niet op de preloaded HSTS lijst staat en een gebruiker die enkel het domeinnaam intikt in een browser zonder afwijkende instellingen, zal er eerst een onveilige verbinding gemaakt worden. Als dat niet werkt, dan faalt de verbinding.

Beschikbaarheid is een pilaar van informatiebeveiliging die vaak vergeten wordt. Een open poort 80 die enkel een 301 redirect naar een HSTS HTTPS site en ACME verificatie doet is niet onveilig.

[Reactie gewijzigd door The Zep Man op 24 juli 2024 14:29]

[Verwijderd]

Een open poort 80 die enkel een 301 redirect naar een HSTS HTTPS site en ACME verificatie doet is niet onveilig.
Ow, heb jij websoftware zonder bugs dan? Geef even aan welke je gebruikt...
Want als een of andere onderzoeker een exploit vindt in die redirect dan is dit niet onveilig? Of in de ACME verificatie op poort 80?

Minder open poorten is altijd beter, dat hoeven we in 2000, ik bedoel 2010, ik bedoel 2022 toch niet meer uit te leggen?

[The Zep Man]

Een open poort 80 die enkel een 301 redirect naar een HSTS HTTPS site en ACME verificatie doet is niet onveilig.
Ow, heb jij websoftware zonder bugs dan? Geef even aan welke je gebruikt...

Diezelfde bugs zou je ook hebben via poort 443, met enkel een TLS laagje eroverheen. Dat gaat je webserver niet beter beveiligen.

Want als een of andere onderzoeker een exploit vindt in die redirect dan is dit niet onveilig?

Als een standaard 301 permanent redirect exploiteerbaar is, dan hebben wij grotere problemen dan een webserver die enkel dat op poort 80 gebruikt.

Of in de ACME verificatie op poort 80?

Je kan het onderscheppen en daarmee de verificatie laten falen. Net als dat je dat met een verbinding over een veilig kanaal zou kunnen laten doen. Wat valt er te exploiteren?

Minder open poorten is altijd beter, dat hoeven we in 2000, ik bedoel 2010, ik bedoel 2022 toch niet meer uit te leggen?

Minder open poorten is goed, maar beschikbaarheid blijft belangrijker. Dit geldt zowel voor informatiebeveiliging als het functioneel doel van sites. Men gaat niet het risico nemen dat een bezoeker voor de eerste keer 'site.xyz' in diens browser intikt en dat de verbinding faalt, waarna de gebruiker mogelijk naar een concurrent gaat die wel zijn zaken op orde heeft.

Zolang browsers zonder voorkennis standaard via HTTP op poort 80 verbinden, zal dat gefaciliteerd moeten worden voor sites die meer zijn dan een hobbyproject.

[Reactie gewijzigd door The Zep Man op 24 juli 2024 14:29]

[Verwijderd]

Diezelfde bugs zou je ook hebben via poort 443, met enkel een TLS laagje eroverheen. Dat gaat je webserver niet beter beveiligen.
Dat is een foute aanname. Draai ik namelijk dezelfde code voor HTTP als dat ik dat doe voor HTTPS? Nee. Draai ik überhaupt dezelfde systemen op poort 80 dan als ik op poort 443 draai? Dat weet jij niet (bijvoorbeeld in mijn geval niet, poort 80 gaat naar een fysiek andere server dan poort 443).
TLS is trouwens ook meer dan een 'laagje' maar dat weet je best.

Als een standaard 301 permanent redirect exploiteerbaar is, dan hebben wij grotere problemen dan een webserver die enkel dat op poort 80 gebruikt.
De software die de redirect uitgevoerd kan exploiteerbaar zijn. Dat heeft niets direct met de redirect te maken. Dit kan caching software zijn of zelfs een Log4j (ik log bijvoorbeeld op poort 80 en niet op 443). Dat is slechts een voorbeeld scenario. Je kunt er zelf ook wel een paar verzinnen.

Je kan het onderscheppen en daarmee de verificatie laten falen. Net als dat je dat met een verbinding over een veilig kanaal zou kunnen laten doen. Wat valt er te exploiteren?
Ik praat niet over het verificatie process, ik heb het over de software die het verificatie process uitvoeren. Een simpele input validation fout kan al problemen veroorzaken. Dat heeft Log4J toch hopelijk wel bewezen.

Minder open poorten is goed, maar beschikbaarheid blijft belangrijker. Dit geldt zowel voor informatiebeveiliging als het functioneel doel van sites. Zolang browsers zonder voorkennis standaard via HTTP op poort 80 verbinden, zal dat gefaciliteerd moeten worden voor sites die meer zijn dan een hobbyproject.

Dat is dus een problematische instelling die je niet moet hebben.
Iedere website is al over naar HTTPS (op een paar hobby projecten na). De groten zoals Microsoft, facebook en Google al zeker een decennia (vanaf 2010). Geen enkele grote organisatie ondersteund zelfs HTTP nog. Je wordt geforceerd naar HTTPS. Iedere website ontwikkelaar configureerd HTTPS want anders kom je helemaal onderaan in in Google. Dat is ook al zo sinds jaren (kan niet vinden hoe lang al). Maar SEO vereist het al zeker jaren. Alle zoekresultaten die je terugkrijgt in Google of whatever zijn HTTPS sites, geen HTTP sites. Als je zelfs een HTTP site bezoekt krijg je groot in beeld dat het onveilig is.

Chromium is eind 2020 al overgestapt op HTTPS-first:
https://nakedsecurity.sop...olution-https-by-default/

Minder open poorten is goed, maar beschikbaarheid blijft belangrijker. Dit geldt zowel voor informatiebeveiliging als het functioneel doel van sites.
Je adviseert hier onveiligheid en geen enkele browser of hoster zal het met je eens zijn. Geef even een bronvermelding van je argument.

[The Zep Man]

Je adviseert hier onveiligheid en geen enkele browser of hoster zal het met je eens zijn. Geef even een bronvermelding van je argument.

Information security's primary focus is the balanced protection of the confidentiality, integrity, and availability of data (also known as the CIA triad) while maintaining a focus on efficient policy implementation, all without hampering organization productivity.

Bron

Wat je schrijft is leuk in theorie, maar de praktijk laat anders zien. Niet alles is gebaseerd op een recente versie van Chromium. Zolang er nog een significant deel van de gebruikte browsers verzoeken zonder expliciet het protocol te benoemen als http:// afhandelt, zal dat deel gefaciliteerd worden.

[Reactie gewijzigd door The Zep Man op 24 juli 2024 14:29]

[Verwijderd]

Haha, ik vraag om een bronvermelding welke hoster of browser maker aanraad om je website nog aan te bieden op HTTP (poort 80). Dan moet je natuurlijk niet beantwoorden met een bron dat beveiliging productiviteit of beschikbaar niet moet beperken. Natuurlijk moet dit niet en er is ook helemaal geen browser die geen HTTPS meer ondersteund. Maar dat begrijp je denk ik ook wel.

Niet alles is gebaseerd op een recente versie van Chromium.
Ik mag hopen dat een browser dat juist wel doet. Anders zou het onverantwoord onveilig zijn en niemand zou een verouderde browser aanraden. Je browser moet altijd up2date zijn anders moet je die niet gebruiken. Eens, toch?

Tevens is het overgrote deel wel gebaseerd op chromium. Meer dan 80% zelfs:
https://kinsta.com/browser-market-share/

Zolang er nog een significant deel van de gebruikte browsers verzoeken zonder expliciet het protocol te benoemen als http:// afhandelt,
Chromium heeft een voorkeur voor HTTPS, zie vorig benoemde bronnen. Mozilla doet dat: https://support.mozilla.org/en-US/questions/959914
En Safari ook:
Apple Safari: see the section 'Defending Your Privacy & Security' about mid-page...
https://www.apple.com/safari/

Firefox will attempt to connect via HTTPS as will other modern browsers, and will show when
you click on the icons in browser URL window, the status of the icons & their meaning.
https://discussions.apple.com/thread/7640612

Ik denk dat je aanneemt dat browsers nog, bij voorkeur, verbinden met HTTP maar dit is al heel erg lang (meer dan 5 jaar) niet het geval. Browsers vallen terug op HTTP wanneer geen HTTPS beschikbaar is. Je moet tegenwoordig expliciet opgeven dat je een HTTP site wilt bezoeken. Daarbij geven ze uitgebreid aan dat je dit niet moet doen. Iets anders aanraden zou wederom onverantwoord zijn.

zal dat deel gefaciliteerd worden.
Zo werkt dit natuurlijk niet. Beveiliging is bedoelt om dingen veilig te maken en dit te garanderen. Niet om onveilige dingen te faciliteren. Stel je voor, een browser die aangeeft dat alles veilig is terwijl dat technisch niet het geval is. Als we jouw argument zouden volgen dan zouden we tevens nooit vooruitgang boeken.

We zijn gelukkig ook al veel verder dan dit, HSTS maakt het mogelijk om het volledig onmogelijk te maken om een site ooit te mogen benaderen via HTTP. Dat doet je bank bijvoorbeeld om SSL-strippende proxies te voorkomen: https://www.chromium.org/hsts/

Wist je dat HSTS (en uiteraard HTTPS) verplicht is voor overheden en instellingen uit de (semi-) publieke sector? Die kun je dus letterlijk niet eens bezoeken via HTTP:
https://www.forumstandaar...standaarden/https-en-hsts

De GDPR maakt het tevens vrijwel onmogelijk dat je een website zonder HTTPS aan mag bieden. Een simpel contactformulier maakt het al dat HTTPS vereist is.

Wat je schrijft is leuk in theorie, maar de praktijk laat anders zien
Ik geef toch echt duidelijk aan, met bronnen van vrijwel 100% van de browser markt, dat de praktijk zeker laat zien dat HTTP verleden tijd is. Ik heb trouwens ook geen idee waar je nog HTTP sites tegen komt. Ik kan je enkel aanraden om dit te melden bij een interne security officer (CISO) of een melding maakt bij de AVG. ik kan zelf geen site bedenken.

Mocht je bij willen lezen, zie het volgende artikel van al weer 5 jaar geleden:
reviews: Tweakers stapt over op https
En probeer tweakers even te bezoeken via HTTP en meld je resultaten terug. Ik ben benieuwd of je om de HSTS beveiliging heen komt

[Verwijderd]

Dat is zeker niet altijd het geval. In moderne systemen (hopelijk alle) wordt poort 80 enkel en alleen gebruikt om een redirect uit te voeren naar poort 443 (dus van onveilig naar veilig).

Er zijn veel situaties waar poort 80 geblokkeerd kan zijn, alleen al om veiligheidsredenen.
Ik gebruik zelf voor privé projecten een reverse proxy (Traefik) die alles afhandelt (certificaten, hostname redirect, flow control zoals ratelimiting en SSO). Allemaal enkel en alleen met 1 poort open aan de buitenkant (443). Certificaat aanvraag loopt dus via TLS-ALPN-01 en is wat mij betreft echt de toekomst voor webservers. Je wilt namelijk helemaal niemand toegang gegeven tot je DNS provider of een extra poort (80) open zetten. En dat hoeft dus ook niet.

[juke1349]

Ja, ALPN is super handig!

Ik gebruik op werk UACME UALPN.
Dat is een transparante proxy. Luistert op poort 443, en geeft alles, behalve TLS-ALPN-01, door aan een interne poort naar keuze.
De Alpn-challenges worden netjes afgehandeld, de rest gaat door naar de "gewone" Webserver, die er niets van merkt.

Supermakkelijke manier om Lets-Encrypt toe te voegen aan kleine servertjes!

[lembregtse]

De uitweiding staat, of zal binnenkort staan in het Bugzilla ticket bij Mozilla: https://bugzilla.mozilla.org/show_bug.cgi?id=1751984

De twee bugfixes worden in de comments ook vermeld.

[NBK]

En hoe weet ik of mijn 3rd-party software de TLS-ALPN-01-methode heeft gebruikt?
Is dat te zien in de certificaten?

Blijft fijn dat ze dit gratis aanbieden maar van mij hadden ze dit ook wel gewoon 90 dagen stil mogen houden Ik twijfel sterk of er echt misbruik van is gemaakt en de versleuteling is verder gewoon in orde voor zover ik begrijp. Maar je weet nu eigenlijk pas zeker dat het na 28 januari blijft werken als je de boel massaal gaat verversen. Wat over 90 dagen weer leidt tot een massale verversingsgolf..

[Reactie gewijzigd door NBK op 24 juli 2024 14:29]

[Cilph]

Je krijgt een mail als je affected bent.

[NBK]

Mits je mail bekent is bij let's encrypt...

[Sebazzz]

Als het goed is wel; die heb je bij het aanmaken van het certificaat opgegeven en je bent ook akkoord gegaan met Let's Encrypt voorwaarden.

[FlyingDutchMen]

Behalve zoals ook aangegeven in het artikel, als je niet zelf het certificaat hebt geregeld. Na genoeg alle hosting partijen bieden een website + domein + gratis SSL certificaat. Er zijn er best wel wat welke dan let's encrypt certificaten 'serveren'.

Waar verder niks mis mee is, maar inderdaad dan krijg je geen melding.

[Robbaman]

Maar je hostingpartij dan toch wel? En ik neem aan dat deze (als professionele hostingpartij) dan op basis van deze mail weten wat ze moeten doen.

[FlyingDutchMen]

Daar mag je zeker vanuit gaan. Nou heb ik geen idee hoe en wat want ik regel dit al tijden zelf. Maar ik kan wel wat hosting partijen bedenken welke hierbij vast achter de feiten aan zullen lopen. To be fair, ik vermoed niet dat er veel hosting partijen zijn die gebruik maken van deze verificatie methode.

[devices]

Je email ingeven in optioneel, maar akkoord gaan met de voorwaarden is verplicht.

[Sando]

Hoe weet je welk domein bij het id in de email hoort?

[kodak]

Dat is geen juiste aanname en ook niet een situatie die zomaar helpt bij het probleem dat @NBK lijkt te stellen.

Let's Encrypt geeft zelf aan dat ze alleen contact konden opnemen met bekende e-mail adressen. Maar als je een product van iemand koopt of een dienst afneemt krijg je dus niet zomaar een mail en is het zelfs niet duidelijk of Let's Encrypt contact heeft kunnen opnemen met die 3rd-party.

Aangezien @NBK waarschijnlijk wil weten waar die aan toe is kan je dus maar beter concluderen dat er zonder extra informatie kans is dat je er te laat achter komt dat je er last van hebt. Wat daar nog aan valt te doen? Zoek bijvoorbeeld uit of je 3rd-party of verkoper duidelijk is of ze de methode gebruiken of vraag anders zo snel mogelijk bij je 3rd-party of verkoper na of dit gevolgen voor wat je hebt gekocht heeft en waarom je dat zo snel mogelijk wil weten. En waarschijnlijk had je dit al willen weten, aangezien het intrekken hoe dan ook sneller kan gebeuren dan je antwoord hebt.

[Yzord]

90 dagen stilhouden is 90 dagen zweten om te hopen dat je goede naam niet besmeurd wordt. Ik vind het een goede actie van ze.

[CyBeR]

3rd, en die kans is heel klein. TLS-ALPN-01 heeft specifieke configuratie nodig die meestal niet gebruikt wordt. De meest gebruikte verificatiemethode is HTTP-01 waarbij een file op een specifiek pad opgevraagd wordt, gevolgd door DNS-01 waarbij een specifieke waarde in DNS gezet wordt als CNAME.

Als je een wildcardcertificaat aan het aanvragen was gebruikte je DNS-01 (verplicht), als je een webserver had dan waarschijnlijk HTTP-01.

[Christoxz]

3th-party software

Door contact op te nemen met de 3rd party.

Ik twijfel sterk of er echt misbruik van is gemaakt en de versleuteling is verder gewoon in orde voor zover ik begrijp

Denk het niet, aangezien het is gerapporteerd (zegt natuurlijk niks), maar het betekent niet dat als iets werkt je het maar gewoon kan laten. Blijkbaar werkte het niet zoals gewenst.

The client used to perform the “acme-tls/1” handshake and protocol negotiation did not enforce that the minimum negotiated TLS version was 1.2 or higher, and the validation code accepted either the id-pe-acmeIdentifier OID or a different OID which was used in earlier drafts of RFC 8737.

[Reactie gewijzigd door Christoxz op 24 juli 2024 14:29]

[TweakMDS]

Ik heb zelf een mailtje gehad van LetsEncrypt. Ik gebruik een behoorlijk aantal certificaten die met TLS-ALPN-01 werken (via Traefik op Kubernetes). Dan vond ik zelf fijner werken dan ook HTTP open zetten voor de http challenge, of door een integratie met namesilo te maken, vooral omdat daar altijd 15 min tussen zit.
Het aanmaken, aanvragen en vernieuwen van de certificaten gaat nu volledig automatisch, dus ik vraag me af of ik iets moet doen, of dat het vanzelf weer goed gaat.

Update:
@zenlord - Traefik gebruikt geen certbot, maar op basis van even snel zoeken heb ik gevonden dat je de acme.json in traefik leeg kan gooien, en dan de pod moet herstarten. Inmiddels zijn alle certificaten alweer renewed.

[Reactie gewijzigd door TweakMDS op 24 juli 2024 14:29]

[zenlord]

Gewoon zelf even vlug een "certbot renew -f" uitvoeren. Dat ben je absoluut zeker dat er geen enkele onderbreking zal zijn in de diensten die die machines aanbieden.

/EDIT: '-f' moet '--force-renewal' zijn

[Reactie gewijzigd door zenlord op 24 juli 2024 14:29]

[Tozz]

Ik denk dat je voor alle certificaten een reissue of renewal moet aanvragen.

[e.dewaal]

Inderdaad, ik had die oplossing op de github van Traefik gevonden.

Het was voor mij even zoeken voordat ik wist om welke certificaten het ging. Die ACME registration (account) ID is dan ineens erg weinig informatie.
Deze bleek uiteindelijk in hetzelfde acme.json bestand te staan van traefik.

[CH4OS]

Dat is aangepast, maar recente certificaten moeten opnieuw worden uitgegeven.

Is er duidelijk wat bedoeld wordt met 'recente'? De certificaten zijn weliswaar maximaal 90 dagen geldig, maar als dit geldt voor certificaten die tussen nu en 30 dagen geleden gemaakt zijn, scheelt dat nogal aan nieuwe certification requests. En ik moet dan even checken of de TLS-ALPN-01 gebruikt is ja of nee.

[Reactie gewijzigd door CH4OS op 24 juli 2024 14:29]

[etiennebruines]

Het zal wel gaan om *alle* certificaten voor 25 januari om 23:48 uur. De revocation is dan voor alle certificaten die jonger zijn dan die 90 dagen - oudere certificaten waren al niet meer geldig.

[Usul_Atreides]

Het gaat om alle certificaten die zijn aangemaakt en gevalideerd via de TLS-ALPN-01-methode.
En het artikel hier en bij LE geven aan dat dit minder dan 1% van alle actieve certificaten is.
Een heel groot algemeen probleem zal het niet zijn, maar wel vervelend als dit toch nou net jouw certificaat betreft.

[NBK]

Als LE 0,9% van alle certificaten in gaat trekken zijn dat er nog steeds miljoenen

[Usul_Atreides]

Het meest vervellende zal zijn voor gebruikers die geen idee hebben of de applicatie of device die het certificaat regelt deze methode gebruikt.

[NBK]

Precies, ik heb bijvoorbeeld nextcloud draaien en nog wat andere dingen die zelf aanbieden om LE te gebruiken. Geen idee of die de TLS-ALPN-01-methode gebruiken.. dat moet ik nu voor al die software en hardware gaan google'n en het is maar de vraag of het ergens vermeld word.

(Het is best vervelend dat je tegenwoordig in je browser eerst nog een waarschuwing open moet klikken en dan nog een keer op doorgaan moet klikken voor je op de pagina ben waar je wil zijn)

[Reactie gewijzigd door NBK op 24 juli 2024 14:29]

[Bor]

En het artikel hier en bij LE geven aan dat dit minder dan 1% van alle actieve certificaten is.
Een heel groot algemeen probleem zal het niet zijn, maar wel vervelend als dit toch nou net jouw certificaat betreft.

Om het geheel wat beter in proportie te plaatsen. Let's Encrypt levert naar eigen zeggen TLS certificaten naar plm 260 miljoen websites. 1% van dit aantal is zijn nog steeds erg veel certificaten!

[Reactie gewijzigd door Bor op 24 juli 2024 14:29]

[wvc_]

Het antwoord op je vraag staat duidelijk in het artikel

[CH4OS]

Dank! Moet even checken wanneer mijn certificaten voor het laatst zijn bijgewerkt, dan is dit wel handig om te weten.

[LEiPiE]

Heb inderdaad een mailtje gehad, maar alleen met een id en dus geen idee om welk certificaat of systeem het gaat
Ben niet zo gestructureerd dat ik een overzicht heb van ACME Registration IDs
Het is op mijn werkmail, anders zou ik een 'we zien wel wat er omvalt' doen, maar nu moet ik dus kijken waar we allemaal certificaten renewen.

maar als ik het goed begrijp is het dus juist niet certbot die deze methode gebruikt... is het dan Azure die dat gebruikt?
never mind azure gebruikt digicert, op alle andere plekken gebruiken we certbot die dus geen tls-alpn-01 doet, dus bleef er alleen een testmachine over met een image van bitnami die hun eigen certificaatscriptjes hebben en jawel: daar kon ik dat id terugvinden ( /opt/bitnami/letsencrypt/accounts/acme-v02.api.letsencrypt.org/ voor wie het toevallig ook heeft).

[Reactie gewijzigd door LEiPiE op 24 juli 2024 14:29]

[justinkb]

Acht het zeer onwaarschijnlijk dat dit misbruikt is in die periode, maar better safe than sorry

[3raser]

Een zoekopdracht met DirectAdmin en TLS-ALPN-01 levert bij mij redelijk wat hits op. Moet ik er vanuit gaan dat DirectAdmin deze methode standaard gebruikt? Dat zou kunnen betekenen dit er straks heel wat certificaten afgekeurd gaan worden op onze servers.

[Jimbolino]

Uit de commits lijkt het dat het mogelijk was om de TLS handshake te doen met oude TLS versies < 1.2
Aangezien TLS1.0 en 1.1 vulnerable zijn voor downgrade attacks, snap ik dat certificaten gemaakt in die periode ongeldig worden gemaakt.

[adoteq]

Worden de self signed certificaten met tls voor postfix hier ook mee bedoelt?