Goed dat zij de trend zien van crimminele pop-up shops, zo hoeven zij in hun database nog maar kort die gegevens hebben

Dit lijkt mij onverstandig.
Deze beslissing maakt het hele internet gevoeliger voor storingen bij Lets Encrypt.
Als zij offline gaan voor wat voor reden dan ook, dan heb je gemiddeld minder dan drie dagen speling!
Daarna beginnen dan een hele hoop websites uit te vallen wegens zo'n verlopen midweek certificaat.

Trouwens, als een key gecompromitteerd is, dan is de server dat waarschijnlijk ook.
Bij ontdekking behoor je die keys eigenlijk in te trekken in plaats van te laten verlopen!

In het ergste geval is het domein verkocht terwijl er nog een geldig certificaat is.
Dan zou de registrar eigenlijk alle certificaten moeten laten verlopen op moment van transfer.
(Of zouden CA's oude certificaten moeten intrekken bij het aanvragen van een nieuwe.)

Als je elke HTTPS sessie een nieuw Let's Encrypt certificaat aanvraagt, is dat nog veiliger. Het is ondertekend door het root certificaat van Let's Encrypt dus altijd te vertrouwen. Als je twee keer hetzelfde certificaat tegenkomt dan weet je dat de site gehackt is. Het root certificaat van Let's Encrypt neemt dan eigenlijk de functie van het domein certificaat van de website over.

Tja, 6 dagen.. nou snap ik wel waarom je OCSP / CRL servers wil uitzetten met deze onzin.
Minimaliseren van tijd is ook alleen nodig OMDAT je de OCSP servers uit zet... zo veroorzaak je een probleem en heb je de oplossing klaar? beetje teveel van munchhausen/proxy of hero-syndrome geslikt daar bij LE?

Nog steeds absurd dat waar de bek vol van hebben over beveiliging, lekgevoeligheid enz, ze wel EISEN dat je een http interface op poort 80 open hebt staan om het cert te updaten. Voor een HTTPS cert op 443 of andere poorten...

https://letsencrypt.org/docs/challenge-types/#tls-alpn-01
Gaat wél via 443... er staat dat apache dit niet support, maar dat klopt niet. Met mod_md kun je namelijk zowel via 80, 443 als DNS een challenge uitvoeren.

Leuk tot er eens een grote storing komt omdat de certificaat dienst overbelast is en honderduizenden certificaten erdoor verlopen. Of zijn we de verstoringen bij COMODO, Sectigo etc uit het verleden vergeten waar het dagen duurde om soms auto requests er door te krijgen omdat ze een queue limit hadden per provider.

Dit dient geen enkel ander onderdeel dan dat Let's encrypt zich meer in de picture wil drukken en gelobby van Google wegens hun 90 dagen TLS plan.

Wat je nu gaat krijgen is dat bedrijven moeten gaan vertrouwen op een volledig geautomatiseerde uitgave en niet eens meer de moeite gaan nemen om te controleren want als je paar honderd certificaten hebt allemaal met andere uitgifte tijd dan ga je dat echt niet meer in je planning krijgen. Gevolg teams gaan vertrouwen op dat alerts van verlopen certificaten en uitol goed gaat en we gaan potentieel veel meer ellende krijgen. Autorotate werkt zolang het werkt en daarna is het je worst nightmare.

Ik ga gesprekken voorbereiden met leveranciers om garanties te krijgen dat er langdurige certificaten blijven qua inkoop want ik ga dit gezeik niet toestaan in onze infra dan desnoods duurdere inkoop zodat we alles kunnen inplannen en auditten wanneer de middelen er voor zijn en niet wanneer het een leverancier uitkomt.

Zo te zien is het dus een keuze tussen 90 en 6 dagen. Hoe te kiezen zie ik in het artikel https://letsencrypt.org/2024/12/11/eoy-letter-2024/ ook niet.

Vertel dat tegen bijvoorbeeld SonicWalls, Fortigates en Sophos appliances.. Die ACME draait alleen op tcp80.

U laat u foppen

OCSP uitzetten betekent nog niet dat er geen adres voor CRL en/of OCSP in de certificaten zit.
Indien wel, dan zal steeds een validatieping naar Lets-Encrypt gaan. Die vraagt minimaal
- ik vraag aan Lets-Encrypt of dat certificaat van die website geldig is.
- ik (mijn IP adres) is nodig omdat Lets-Encrypt anders geen antwoord kan geven.
- die website is nodig omdat alleen die website dat certificaat heeft.
- dan weet Lets-Encrypt precies welke websites ik bezoek
- en kan daarmee mij profileren voor allerhande toepassingen.
Omdat Lets-Encrypt (door gratis certificaten - hoera) zo groot is (dominant),
daarom is Lets-Encrypt een goudmijn voor toepassingen als targeted reclameboodschappen

En je weet het
- als iets gratis, dan ben jij het product.
- in dit geval niet de website eigenaar (die de certificaten gratis heet gekregen)
- maar de website bezoeker (die niets te zeggen heeft over welke certificaten op de website staan)
En je kan dit niet uitzetten (zoals bij tracking cookies wel het geval is)

Wat Lets-Encrypt helemaal niet doet
- identiteit van de website eigenaar vaststellen
- en dus kunnen ook bewust bekwame slechteriken rogue websites maken en daarop de o-zo-vertrouwde lets-encrypt certificaten plaatsen
- waardoor de bewust bekwame slechteriken niet opspoorbaar zijn als er frauduleus wordt gehandeld
- en daarmee enabled Lets-Encrypt de frauduleuze websites

Lets-Encrypt (en bigtech) vertellen dit ook
onder het motto dat certificaten alleen maar zijn bedoeld voor transportveiligheid.
En negeren daarmee de belangrijkste aanvalsvector (impersonisatie)
In technisch opzicht is dat ook niet het geval, maar in functioneel opzicht wel.

Overweeg eens een Qualified Website Authentication Certificate (QWAC).
De erkenning ervan (dus ook door BigTech) is bij wet (de eIDAS verordening) verplicht gesteld.
Zoek een QTSP (QWAC uitgever) die langere geldigheidsduur hebben.
Dat kan best
- er is nooit een RSA sleutelpaar gekraakt
- de gedocumenteerde 1024 bits sleutel kraak is alleen mogelijk als men de hardware in handen heeft waar die sleutel op staat.
- dus vanuit de publieke sleutel alleen is zelfs ook nooit een 1024 bits RSA sleutel gekraakt.


Vraag aan CoPilot:
Hoe lang is de geldigheid van een QWAC?

Antwoord van CoPilot
De geldigheid van een Qualified Website Authentication Certificate (QWAC) varieert, maar meestal is deze geldig voor een periode van één tot drie jaar. Dit hangt af van de certificeringsautoriteit (CA) die het certificaat uitgeeft en de specifieke vereisten van de organisatie die het certificaat aanvraagt.

Is het open moeten staan van poort 80 dan een EIS van LE, of van SonicWall, Fortigate of Sophos?

Ik wist van EV certificaten af, maar niet van QWACs.
Hoe is een QWAC anders dan een EV cert?

En waarom bemoeid big brother er ineens mee?
Als je het verhaal daar achter weet, hoor ik het graag.

Als je ontdekt dat een key gecompromitteerd is laat je die intrekken ja. Dat kan bij LE ook gewoon.

Het voordeel van de OPTIE om je cert een geldigheid van 6 dagen te geven, is dat als je key zonder dat je het ontdekt gecompromiteerd raakt, deze alsnog maar max. 6 dagen gebruikt kan worden door kwade doeleinden.

Verder is het dus een optie. Dat geeft de mogelijkheid een risicoafweging te maken. Welk risico vindt men aanvaardbaarder? Het risico dat een gecompromiteerde key tot 30 dagen gebruikt kan worden, of het risico dat een storing bij Let's Encrypt downtime oplevert? Dit kan per toepassing verschillen. En het is een belangrijk aspect van security. In kaart brengen en prioritiseren van risico's.

Het probleem van opties is dat het vaak geen opties zijn maar tijdelijk wen er vast maar aan mededelingen. Die 90 dagen certs waren eerst ook een optie en niemand die er echt voordeel in zag ten op zichte van de jaarlijkse. Nu krijgen we exact zelfde gezeik weer en met half jaar schat ik dat die 90 dagen optie ook weg is. Dit is gedram van de sponsors intern bij Lets Encrypt partijen als Google en zeker geen beslissing omdat de community dit wil.

Ik hoor nooit maar dan ook nooit collegas in enterprise zeggen goh ik wou dat we kortere TLS rolatie hadden dat maakt mijn netwerk en gebruikers zoveel veiliger. Wat ik wel hoor is dat iedereen de overdreven focus op houdbaarheid zat is terwijl de controle op uitgifte nul comma nul is.

Phising en andere ellende ga je hier niet mee stoppen die sites zijn in seconden opgezet met een ander domein en een legaal uitgegeven certificaat dankzij Lets encrypt. Wat wel zou helpen is als alle certificaat informatie niet steeds verder verborgen wordt en een in browser meldt functie komt voor melden van een certificaat gebruikt op een phising of comprimenteerd domein. Zodoende die bij controle een verbod krijgt voor een maand gevolgd door een jaar bij tweede overtreding op nieuwe uitgaves van alle CA's.

Gaat de nieuwe phising sites niet voorkomen maar het zal wel behoorlijk schoon schip maken als het om incompetente beheerders gaat die niet omkijken naar hun site veiligheid. Leg als zo beheerder maar uit aan je directie dat hun site gevaarlijk wordt bestempeld en dit minimaal 1 maand duurt om er van af te komen. Verzeker je die ligt de laan uit. Of de hobbyist die geen kaas heeft gegeten van IT maar wel denkt dat die het recht heeft een gevaar te vormen voor de rest van de wereld door een unmanaged provider te kiezen van paar euros per jaar en niks aan veiligheid te doen.

En een significante reductie van die twee groepen daar wordt het internet wel beter van.

Ik kan hier niet volledig zijn. Het tekst veld is te klein.
Als je specifieke zaken wilt weten, stel daar dan een vraag over.
Ik laat graag zien (aantoonbaarheid) aangevuld met mijn professionele mening (ik werk in de vakgebied, niet bij een commerciële partij die QWAC's levert)

Over Big Brother (als je BigTech bedoelt)
zie mijn eerdere reacties. En op vele andere nieuwsberichten die gaan over vertrouwensdiensten. (zoek maar eens)
BigTech is bezig het leven van Trust Service Providers moeilijk aan het maken onder het motto van veiligheid. Terwijl wat zij bereiken resulteert in (veel) minder veiligheid voor burgers. Namelijk uitbannen van identificeerbare gegevens in certificaten.
Dat neemt BigTech op de koop toe om de ultieme macht op certificatengebied te krijgen. Hun belang? Die vertellen ze niet. Mijn eerder bijdrage geeft een denkbare reden. Dan is de verminderde veiligheid voor gebruikers niet meer dan collateral damage.

Over QWAC's

QWAC is opgenomen in de eIDAS verordening. Vanuit artikel 45 lid 1bis van eIDAS2 zijn webbrowsers verplicht de QWAC te erkennen (inwerking) en gebruiksvriendelijk de attestatie (zichtbaarheid de gecontroleerde gegevens) weer te geven. Zie de wetstekst onder de stippelllijn. Lees artikel 1bis.

In mijn beleving is die verplichte erkenning ongeacht de levensduur van de QWAC. In mijn beleving kan die veel langer zijn dan wat Lets Encrypt biedt. Wellicht dat een uitvoeringshandeling anders bepaalt (lees art 45 lid 2)

In bredere context dan Artikel 45
Een belangrijker voordeel is de wettelijke inbedding van de QWAC.
- de erkenning is wettelijk geregeld. (dit is anders dan onder CABForum)
- de aansprakelijkheid ook. (dit is anders dan onder CABForum)
- het toezicht is transparant (in Nederland door de Rijksinspectie voor Digitale Infrastructuur). (dit is anders dan onder CABForum)
- De Trust Service Provider (de CA) gehouden aan formele vereisten (denk aan ETSI standaarden), is er auditplicht door wettelijk aangestelde (feitelijk hetzelfde als onder CABForum).
- De erkenning geldt voor elke QWAC door elke Qualified Trust Service Provider (dit is anders dan bij de browserpartijen onder CABForum die allemaal nog eens eigen eisen stellen die ook nog eens tegenstrijdigheden bevatten).
- is de identiteit van de website eigenaar bekend (dit is anders dan onder CABForum).
- bij onregelmatigheden zal de CA worden ingetrokken en is de TSP (de CA) schadeplichtig. (dit is anders dan onder CABForum)
- Voor besluit intrekken van een CA zal ook de nevenschade worden beschouwd. Dit betekent dat er geen professioneel narcisme zal worden gebruikt voor een besluit, maar juist weloverwogen met alle belangen in overweging nemende. Dit beschermt vooral de eigenaren en gebruikers van websites. Denk aan het verstandige besluit van de Nederlandse regering tijdens de DigiNotar crisis. Denk aan het onverstandige besluit van DigiCert om (ook voor grote organisaties een certificaatvervanging binnen 24 uur te eisen (waartegen een Amerikaanse medische firma met succes juridisch verweer heeft ingesteld).

Kortom
- erkenning is wettelijk geregeld
- betere cyberveiligheid voor websitebezoekers (immers eigenaar website bekend)
- betere bescherming eigenaren en gebruikers van websites (continuiteit)
- wettelijke aansprakelijkheid als er (grote) fouten worden gemaakt.

------------------
“Artikel 45. Eisen voor gekwalificeerde certificaten voor websiteauthenticatie
1. Gekwalificeerde certificaten voor websiteauthenticatie voldoen aan de eisen van bijlage IV. De evaluatie van de
overeenstemming met die eisen wordt uitgevoerd overeenkomstig de in lid 2 van dit artikel bedoelde normen,
specificaties en procedures.

1 bis. De overeenkomstig lid 1 van dit artikel afgegeven gekwalificeerde certificaten voor websiteauthenticatie
worden erkend door aanbieders van webbrowsers. Aanbieders van webbrowsers moeten ervoor zorgen dat de in het
certificaat geattesteerde identiteitsgegevens en aanvullende geattesteerde attributen op gebruiksvriendelijke wijze
worden weergegeven. Aanbieders van webbrowsers moeten zorgen voor ondersteuning van en interoperabiliteit met de
in lid 1 van dit artikel bedoelde gekwalificeerde certificaten voor websiteauthenticatie, met uitzondering van micro- of
kleine ondernemingen zoals gedefinieerd in artikel 2 van de bijlage bij Aanbeveling 2003/361/EG tijdens de eerste vijf
jaar waarin zij actief zijn als aanbieders van webbrowserdiensten.

1 ter. Voor gekwalificeerde certificaten voor websiteauthenticatie gelden geen andere dwingende eisen dan de in
lid 1 vastgelegde eisen.

2. Uiterlijk op 21 mei 2025 stelt de Commissie door middel van uitvoeringshandelingen een lijst met
referentienormen en, waar nodig, specificaties en procedures vast voor de in lid 1 van dit artikel bedoelde
gekwalificeerde certificaten voor websiteauthenticatie. De uitvoeringshandelingen worden volgens de in artikel 48,
lid 2, bedoelde onderzoeksprocedure vastgesteld.”
-----------------

Wat is nu de extra veiligheid? Grote kans dat indien het private key van het huidige certificate is gehacked, dat het nieuwe certificate 6 dagen later op dezelfde manier wordt gehacked.