Let's Encrypt is gestopt met aanbieden van OCSP in certificaten

Let's Encrypt heeft de ondersteuning van het Online Certificate Status Protocol in certificaten stopgezet. De certificaatautoriteit was eerder al gestopt met het meegeven van OCSP-URL's aan nieuwe certificaten. Alle nog lopende certificaten met OCSP-URL's zijn nu verlopen.

Let's Encrypt zegt dat zijn eigen OCSP-dienst de end-of-lifestatus heeft bereikt. Let's Encrypt kondigde eind vorig jaar al aan dat het daarmee zou stoppen en gaf al geen OCSP-URL's meer mee aan certificaten, maar het bedrijf zegt dat dat meer dan negentig dagen geleden was. Aangezien Let's Encrypt-certificaten een levensduur van maximaal negentig dagen hebben, zijn inmiddels alle certificaten waarin nog een OCSP-URL zat verlopen.

Volgens de certificaatautoriteit is OCSP een 'aanzienlijk risico voor privacy op internet'. Het Online Certificate Status Protocol is een standaard die het mogelijk maakt om te controleren of een certificaat ingetrokken is. Als dat gebeurt, krijgt een certificaatuitgever het IP-adres te zien van de bezoeker. OCSP was lange tijd verplicht, maar het CA/Browser Forum maakte in 2023 het protocol optioneel voor aangesloten CA's.

Let's Encrypt zegt dat het enkel nog certificate revocation lists of crl's zal gebruiken als alternatief voor OCSP. Die ondersteunt het bedrijf sinds 2022. Crl's zijn een privacyvriendelijkere manier om ingetrokken certificaten te controleren. Hierbij vernieuwt de certificaatautoriteit periodiek een lijst met zulke certificaten die lokaal kan worden gecontroleerd. Er wordt dus niet elke keer een verbinding met een CA gelegd, inclusief alle data zoals IP-adressen die daarbij wordt meegestuurd, zoals bij OCSP.

Reacties (35)

[Astronaut]

Ten aanzien van de privacy: het probleem is niet zozeer dat de certificaatuitgever het IP-adres krijgt te zien van de websitebezoeker, maar de uitgever krijgt óók te zien voor welk certificaat (c.q. de website) de bezoeker wil weten wat de status is. Om via OCSP de status van een certificaat op te vragen, moet je expliciet opgeven voor welk certificaat je dat wil weten.

Bij OCSP heeft de certificaatuitgever dus toegang tot de combinatie IP-adres en website die bezocht wordt. En dat is privacygevoelige informatie die niet bij een publieke Certificate Authority thuishoort.

Bij CRL ziet de uitgever enkel het Ip-adres van de bezoeker en weet alleen dat de bezoeker voor tenminste één van z’n uitgegeven certificaat de status wil weten, maar weet niet welke (de client zoekt dat lokaal uit).

In het nieuwsbericht staat dit wat cryptischer vermeldt.

[Reactie gewijzigd door Astronaut op 8 augustus 2025 10:51]

[JustVodka]

Naast privacy is er ook een delay/latency nadeel, omdat tijdens de tls/ssl hand shake een OCSP request gemaakt wordt door de browser voordat de content zelf geladen wordt.

Een manier om deze beide issues op te lossen is "OCSP stapling" Waarbij de server zelf al de OCSP status mee stuurt tijdens de hand shake. (deze zijn cryptografisch gesigneerd door de CA, dus geen security "wij van WC Eend" issue).
Bij OCSP Stapling neemt de webserver regelmatig contact op met de OCSP server van de CA om de status van de certificaten binnen te halen.
Maar hiermee verplaats je het probleem naar de server kant, wat over het algemeen iets minder gevoelig ligt.

Op zich een nette oplossing omdat er geen extra request van de client kant nodig is, dus ook geen CRL.

Nadeel, er is een potentieel issue met een downgrade attack wanneer certificate geen "must-staple" flag heeft waarbij de aanvaller een ouder gecompromiteerde certificaat gebruikt (juist het gene wat je met OCSP en CRL wilt voorkomen) Maar met de "must-staple" flag ligt de website feitelijk plat wanneer de webserver om een of andere reden niet (tijdig, voor de vorige OCSP status verloopt) bij de OCSP server kan om OCSP data binnen te halen. Want de webbrowser hoort certificaten met een must-staple flag te blokkeren wanneer die geen OCSP data mee stuurt.

[Reactie gewijzigd door JustVodka op 8 augustus 2025 14:53]

[TechSupreme]

Dit is dus ook de reden waarom Chrome het in 2017 al uit had gezet. Dus een overgroot deel van de browser installs gebruikte het niet, puur om deze reden. Een CA of CDN kon exact zien wie welke sites bezoekt.

Buiten dat alles om, om op bandbreedte en processing te besparen werden OCSP antwoorden vooraf gegenereerd en via CDN's gedistribueerd. Dus de CDN's konden exact zien wie, wat en waar.

Nou zijn CA's over het algemeen wel partijen die dingen als privacy en security hoog in het vaandel hebben, maar datzelfde kan je niet zeggen van een CDN. Een CDN wil zoveel mogelijk centen verdienen met hun bandbreedte, dat is hun taak. CDN's doen ook niet aan dezelfde security audits als CA's. De vraag is dan of je een CDN wel wil vertrouwen met die informatie.

[Reactie gewijzigd door TechSupreme op 8 augustus 2025 11:37]

[CAPSLOCK2000]

Het intrekken van certificaten is een groot zwak punt in de infrastructuur. Zowel OCSP als CRL zijn in praktijk bijna onwerkbaar. Er zijn maar weinig systemen die deze standaarden echt implementeren en er naar handelen. Systemen die het wel doen zijn al snel fragiel en storingsgevoelig.

Een groot pijnpunt is het actueel houden van de informatie. Daarvoor zal je regelmatig met internet moeten verbinden. Als jouw infrastructuur wordt aangevallen of die van de CA's dat alle systemen die daar van afhangen meegaan. Als je je securityinformatie niet kan updaten/controleren is de enige rationele beslissing dat je de communicatie met de buitenwereld verbreekt. Veel minder dan dat heeft geen zin, dan kun je het hele systeem wel achterwege laten.
CRL is daar wat bestendiger tegen omdat je die lijsten lokaal kan cachen, maar ook maar voor bepaalde tijd. Hoe langer je op de cache vertrouwt hoe groter de kans dat er in de tussentijd een certificaat is ingetrokken.

[kodak]

Als je je securityinformatie niet kan updaten/controleren is de enige rationele beslissing dat je de communicatie met de buitenwereld verbreekt.

Het toepassen van certificaten is nooit bedoeld om er volledig op te vertrouwen. En dus niet bedoeld is om alleen daarop te vertrouwen, of zelfs specifiek op een OCSP of CRL. Het is geen volledige vervanging en dus ook niet als er wel of geen problemen lijken te zijn.

Persoonlijk mis ik bij dit stoppen met een functionaliteit tot controle een behoorlijke onderbouwing waarom het verstandig zou zijn dat de overgebleven functionaliteit genoeg is. Natuurlijk wil dat niet zeggen dat er geen onderbouwing voor valt te geven of te accepteren. Maar het lijkt me niet uit te leggen dat als het CRL niet bijgewerkt kan zijn, niet op tijd bijgewerkt kan zijn of zelfs net als de 'geldige' certificaten onder controle van criminelen kan staan je daar geen 'second' opinion voor hebt. En ja dat komt ook op vertrouwen aan, maar ook vooral op de (on)wil om het uitgeven van certificaten veel makkelijker te maken dan eisen te stellen en daarop te controleren dat certificaten tijdig in te trekken en er dus behoorlijk mee om te kunnen gaan. De huidige CAs willen vooral makkelijk klanten die weinig kennis hebben maar wel veel certificaten, kaar nemen daar nauwelijks verantwoordelijkheid in of ze in kunnen staan voor de CRL. Ik durf te stellen dat 95% van wie certificaten heeft geen benul heeft hoe op tijd te beseffen wanneer deze niet meer betrouwbaar zijn en daar ook niets behoorlijks aam controles voor geregeld heeft. Fijn dat die nu geholpen zijn om geen benul meer te hoeven hebben van OCSP, maar dat maakt het behoorlijk gebruik van CRL niet spontaan beter.

[Reactie gewijzigd door kodak op 8 augustus 2025 12:16]

[CAPSLOCK2000]

Het toepassen van certificaten is nooit bedoeld om er volledig op te vertrouwen. En dus niet bedoeld is om alleen daarop te vertrouwen, of zelfs specifiek op een OCSP of CRL. Het is geen volledige vervanging en dus ook niet als er wel of geen problemen lijken te zijn.

Dat is waar, maar het is vaak toch wel een grote component.

Persoonlijk mis ik bij dit stoppen met een functionaliteit tot controle een behoorlijke onderbouwing waarom het verstandig zou zijn dat de overgebleven functionaliteit genoeg is.

Volgens mij, en ik ben niet zeker, is het meer uit pragmatisme. Het systeem werkt niet goed en wordt nauwelijks gebruikt maar levert wel een hoop gedoe op. Het lijkt de moeite niet waard.

Maar het lijkt me niet uit te leggen dat als het CRL niet bijgewerkt kan zijn, niet op tijd bijgewerkt kan zijn of zelfs net als de 'geldige' certificaten onder controle van criminelen kan staan je daar geen 'second' opinion voor hebt.

De CRL bijwerken aan de CA kant is maar een deel van het probleem. De software van de gebruikers moet er ook iets mee doen en dat deel is in praktijk maar heel matig, de meeste software doet het gewoon niet.

En ja dat komt ook op vertrouwen aan, maar ook vooral op de (on)wil om het uitgeven van certificaten veel makkelijker te maken dan eisen te stellen en daarop te controleren dat certificaten tijdig in te trekken en er dus behoorlijk mee om te kunnen gaan.

De huidige insteek is om certificaten maar kort geldig te laten zijn. Een verlopen certificaat hoef je niet in te trekken en dan heb je geen OCSP/CRL/... nodig. Vroeger was SSL-certificaten vervangen lastig (en duur) en kozen mensen dus het liefst voor certificaten die jaren lang geldig bleven. Als zo'n certificaat gestolen werd kon je dat jaren lang achtervolgen.

Tegenwoordig gaat het verversen van certificaten meestal automatisch gaat maakt het ook niet zo veel meer uit hoe lang een certificaat precies geldig is. Dankzij (met name) Let's Encrypt en het ACME-protocol is het proces eenvoudig te automatiseren. De computer vindt het niet erg om iedere maand, week, dag of uur een nieuw certificaat te installeren en steeds meer software gaat daar goed mee om.
Ik verwacht dat trend om certificaten steeds korter geldig te maken nog wel even door gaat.

Op lange termijn verwacht ik dat we naar een ander systeem toegaan (bv DANE/TLSA) waarin CA's niet meer nodig zijn voor "gewone" certificaten. Hun traditionele taak, het controleren van de identiteit van de eigenaren, is eigenlijk irrelevant voor de meeste certificaten. Als het verificatieproces in praktijk toch niet meer is dan een DNS- en/of HTTP-query dan heb je geen CA nodig, dat doet je PC toch al.

Ik durf te stellen dat 95% van wie certificaten heeft geen benul heeft hoe op tijd te beseffen wanneer deze niet meer betrouwbaar zijn en daar ook niets behoorlijks aam controles voor geregeld heeft.

Het mooie van kort geldige certificaten is dat de gebruiker er geen benul van hoeft te hebben. Omgaan met verlopen certificaten is makkelijker dan OCSP/CRL en vrijwel alle software doet dat goed (en de software die het niet doet heeft waarschijnlijk grotere problemen) en relatief gebruikersvriendelijk, voor zover dat mogelijk is.

[kodak]

Als een systeem met toegang tot de prive gegevens van het certificaat gecomprimeerd is dan hoort een certificaat nmm meteen ongeldig te zijn. Een jaar of 6 dagen geldigheid is dan beiden niet acceptabel, tenzij we het prima vinden dat er in die periode slachtoffers gemaakt worden. En dat is juist niet de bedoeling. Het kort geldig zijn helpt dus vooral wie in die periode geen slachtoffer is. Niet bij wie in de minuten, uren dagen vals vertrouwen werd gewekt. Dan kunnen we in de toekomst wel wat anders verwachten, het punt is dat xe huidige verwachtingen met het verdwijnen van OCSP niet zomaar beter of wel behoorlijk voldoen. Ververs je certificaat iedere seconde of 6 dagen, of laat het de crimineel automatisch doen omdat je er toch niet naar om hoeft te kijken, is nmm geen oplossing.

[Bor]

Als er geen vertrouwde CA is werk je met self signed exemplaren die in feite iedereen kan aanmaken en waarvan je de validiteit eigenlijk niet kan controleren als buitenstaander.

[michaelkamen]

Ik ben totaal niet bekend met de materie. Hoe vaak komt het voor dat certificaten worden ingetrokken voordat ze verlopen zijn? Ik dacht juist dat het hele idee van het verkorten van de looptijd van certificaten juist was om dit te voorkomen?

[wildhagen]

Ik ben totaal niet bekend met de materie. Hoe vaak komt het voor dat certificaten worden ingetrokken voordat ze verlopen zijn?

Best wel vaak:

A 2015 study found an overall revocation rate of 8% for certificates used on the Web,[2] though this may have been elevated due to Heartbleed.

Zie Wikipedia: Certificate revocation

8 procent klinkt niet enorm, maar als je beseft hoeveel certificaten zijn uitgegeven is het toch een substantieel aantal.

Kan diverse redenen hebben. Zoals simpelweg een foutje in de aanvraag, of een certificaat voor een dienst/URL die niet meer in gebruik is etc etc.

[bigtree]

In 2015 was HTTPS nog lang niet zo gewoon als nu. Let's Encrypt begon pas in 2016. Ik kan me niet voorstellen dat het percentage revocations nu nog steeds op 8% zit. Ik zou 1% al veel vinden.

Binnenkort gaat Let's Encrypt met short-lived certificaten beginnen. Die hebben een levensduur van 6 dagen. De noodzaak voor revocation lijkt me dan nihil.

[Bor]

Een certificaat hoort direct ingetrokken te worden wanneer er een vermoeden van compromise is. Wanneer je meer certificaten uitgeeft (want veel kortere geldigheid) zou het percentage zelfs op kunnen lopen.

[Vogel666]

Ik zie de reden voor revocations ook niet echt.

Foutje in de aanvraag? Vernietig de key en de noodzaak voor revocation is verdwenen.

Revocation is alleen noodzakelijk als de key gecompromitteerd is.


Vergelijk het met een paspoortcontrole aan de grens: als een persoon dood is of een paspoort verlopen is ga je als staat geen bericht sturen aan de autoriteiten van alle andere landen. Dat doe je alleen als je wet dat iemand met een vals paspoort reist.

[Guru Evi]

Als je een certificaat met de verkeerde naam aanmaakt, of een naam moet toevoegen of verwijderen, in een dagje kan ik soms wel 2 of 3 maal een certificaat intrekken (als de klant niet goed weet welke domeinen verbonden zijn). Daarnaast zou je in principe met elke security breach, elke keer dat je een sysadmin weggaat, net zoals een paswoord, al je private keys en certificaten moeten intrekken en hermaken. Met certbot is dit allemaal wel geautomatiseerd, dus het lijstje gaat wel vlotjes.

[Blokker_1999]

Je zou zelfs kunnen zeggen dat het intrekken van certificaten veel te weinig gebeurt. Vele organisaties laten na om tijdig een certificaat in te trekken, enkel als men denkt dat er echt al een lek van het certificaat is, dat er al misbruik is gaat men pas over tot intrekking.

En dat is dan ook 1 van de redenen waarom we de volgende jaar dus de geldigheid van certificaten gaan zien verkleind worden.

[Guru Evi]

Voor mij mag het hele systeem wel op de brandstapel gaan, er zijn encryptiesystemen waar je per sessie een certificaat uitwisselt, dan weet zowel de client als de server dat beide kanten hetzelfde 'systeem' zijn en moet je geen derde partij inschakelen, behalve dan misschien voor de eerste verbinding, identiteitsverificatie, indien nodig, voor 1 van de kanten, maar dat kan door de client gedaan worden naar een 3de partij van keuze, of je kunt zelfs vb. voor banksystemen, aan beide kanten identiteitsverificatie doen.

Geen gezeur met certificaten, want elke sessie krijgt een nieuwe die minuten of een paar uur geldig is, afhankelijk van wat de client wilt.

Het probleem met sleutels intrekken is een nog groter probleem voor 'root' certificaten. Stel dat er een gestolen wordt, wie en hoe snel ga je die intrekken. Zoals we gezien hebben met bedrijven die vroeger verwijderd zijn, ten eerste waren ze traag omdat ze anders klanten gingen verliezen, dan nog duurde het maanden, soms zelfs jaren alvorens ze verwijderd zijn uit alle systemen.

[Bor]

Het nadeel aan een CRL (certificate revocation list) controle is dat een CRL veelal met een lage freqentie wordt aangeboden / gedownload en je dus een situatie kan hebben waarmee een certificaat wel al is ingetrokken maar deze nog niet op de CRL vermeld staat waar je mee werkt. Een CRL kent een geldigheidsduur, veelal 24 uur of korter. Firefox doet dit bv elke 6 tot 12 uur.

[TechSupreme]

Het hele probleem is dat OCSP optioneel is en meeste (denk zelfs alle, hierover straks meer) browsers een verbinding toe lieten als de OCSP check niet slaagde. De browser gaat er dus vanuit dat het certificaat nog goed is als er geen OCSP check plaats heeft gevonden.

Nou kan je (zoals jij dat doet) beargumenteren dat een CRL outdated kan zijn, dat klopt maar bij een OCSP server die offline of onder een aanval is kan je alle certificaten niet valideren en krijg je een soft-fail situatie waardoor je browser er maar vanuit gaat dat alle certificaten goed zijn.

Bij een CRL gaat het alleen om de certificaten sinds de laatste update.

https://community.letsenc...n-safari-and-chrome/42677
https://www.feistyduck.co...21_the_slow_death_of_ocsp

Buiten dat alles om, is gebleken dat Safari en Chrome OCSP checks standaard uit hebben gezet.

Browsers are either not checking it or are implementing it in a way that provides no security benefits. As a result, OCSP is just costing Let’s Encrypt good money in personnel and infrastructure costs.

Dus we hebben een situatie waarin een overgroot deel van de browser installs het niet gebruikt en de deel die het wel gebruikt, gebruikt het op zo'n manier dat het helemaal niks toevoegt aan de veiligheid.

Let’s Encrypt moet dus investeren in manuren en infra terwijl het helemaal geen nut heeft. Dan kan je er toch beter mee stoppen tot de industrie besluit wat het er wel mee wil doen en het op zo'n manier implementeert dat het wel iets toevoegt.

[Reactie gewijzigd door TechSupreme op 8 augustus 2025 11:02]

[Bor]

Bij een CRL gaat het alleen om de certificaten sinds de laatste update.

Dat hoeft niet. Een delta CRL (waar je het hier over hebt) is optioneel en een mogelijke implementatie methode.

[Reactie gewijzigd door Bor op 8 augustus 2025 11:03]

[TechSupreme]

Kijk daar gaat het niet om.

De CRL wordt gehost op een HTTPs server. Stel die server is offline of onder een aanval dan kan je de CRL niet updaten.

In dat geval heb je nog altijd de oude CRL in je cache waardoor de oudere certificaten nog invalid worden.

Bij OCSP heb je dat dus niet, als de OCSP server wegvalt dan zijn alle certificaten ineens valid.

Buiten dit alles om, om te besparen op processing en bandbreedte genereren alle CA's de OCSP lijst van tevoren. OCSP heeft een lifetime van 8 uur tot 10 dagen. Tijdens onderzoek van Let's Encrypt is gebleken dat meeste CA's lijsten hadden die tot 7 dagen oud waren. Dan gaat het hele caching argument van een CRL ook niet meer op.

Dan kan je met zekerheid zeggen dat het CRL-mechanisme veel robuuster is.

[Reactie gewijzigd door TechSupreme op 8 augustus 2025 11:31]

[SleutelMan]

Ik zou een CRL niet op een HTTPS server hosten, persoonlijk. Ofwel je creëert een leuke afhankelijkheid met een andere CA om de geldigheid te controleren van het certificaat dat wordt gebruikt om de HTTPS verbinding te beveiligen, ofwel je creëert een loop omdat de TLS verbinding is beveiligd met een certificaat uitgegeven door dezelfde CA die het oorspronkelijke certificaat uitgaf waarvan je de geldigheid wilde controleren.

Aangezien de CRL zelf ook al cryptografisch is getekend door de CA is de integriteit toch al geborgd (hetzelfde geldt overigens ook voor OCSP, dat zijn getekende responses via HTTP, niet HTTPS).

[Pinkys Brain]

Als de OCSP server wegvalt zijn alle certificaten die niet al eerder geinvalideert waren ineens valid. Niemand wil dat Apple geintje nadoen.

Apple gebruikt zonder goede reden OCSP voor app certificaten, server had time out en toen deed niets het meer ... dat is geen aanvaardbare failure mode.

CRL met delta kan bijna alles wat OCSP kan, beter. Voor bijna geen een toepassing zijn er genoeg certificaten om de grootte van de CRL een probleem te laten zijn.

[Reactie gewijzigd door Pinkys Brain op 8 augustus 2025 16:35]

[Bor]

Feitelijk is de verificatie inconclusive als de server weg valt. Het meest veilige is dan het certificaat niet vertrouwen maar dat is een keuze.

[Reactie gewijzigd door Bor op 8 augustus 2025 16:33]

[TechSupreme]

Als de OCSP server wegvalt zijn alle certificaten die niet al eerder geinvalideert waren ineens valid.

Sorry ik snap even niet hoe ik dit moet lezen? Volgens mij zeg jij exact hetzelfde als wat ik zei.

[DaRealRenzel]

CRL staat niet op een HTTPS server, want dan krijg je een kip en ei verhaal. Voordat je de CRL kan downloaden, moet je eerst een secure sessie met de CRL server opzetten. Daarvoor moet je de revocation van de server checken via... Juist.. de CRL....

[Llopigat]

Bovendien is een cachetijd van 7 dagen nutteloos.

Als je een gestolen certificaat gaat misbruiken dan duurt het enkele uren voor dat aan het licht komt. Tegen de tijd dat die 7 dagen voorbij zijn (of gemiddeld: 3,5 dag) dan is het probleem allang opgelost. Dus het beschermt tegen bijna niets.

En het is ook een heel slecht punt qua privacy. Beter is gewoon een zwarte lijst van certificaten doorsturen aan iedereen. Zoveel worden er niet geblockt. En laat dat nou net het principe van de CRL zijn, wat we allang hadden. OCSP providers kunnen anders een hele hoop telemetrie halen en ook bijv. Apple die het voor app ondertekening gebruikt.

[Reactie gewijzigd door Llopigat op 8 augustus 2025 19:45]

[Pinkys Brain]

Wel grappig dat Apple het in Safari uitzet voor de privacy tov derde partijen, maar dat ze nog steeds elke start van je apps willen bespioneren. Classy.

[Pinkys Brain]

Ik mag toch aannemen dat je gewoon een delta kan downloaden.

[Bor]

Zeker, in de meeste gevallen wel maar de standaard verplicht het aanbieden van delta crl's niet. Het is wel de meest voorkomende implementatie.

[dnnns]

OCSP werkte in veel browsers als een soft-fail systeem: als de statuscheck geen snel antwoord gaf, werd de verbinding toch toegestaan. Dat gaf een extra controlelaag, maar de feitelijke veiligheidswinst was in de praktijk beperkt. CRL’s bieden een stabieler alternatief, omdat de hele lijst lokaal beschikbaar is en niet afhankelijk van live verbindingen. Ze zijn wel alleen zo actueel als de laatste update, maar voor veel partijen weegt dat op tegen de privacyrisico’s en instabiliteit van OCSP.

[N8w8]

De webserver kan bij t certificaat, ook een gecachte OCSP status meesturen, dan hoeft de client er niet apart nog naar te zoeken.
Daarvoor moet de _webserver_ dan dus wel 1x/week ofzo (vergeten) de OCSP server kunnen bereiken om de cache te updaten, maar dat is al n stuk minder foutgevoelig dan dat elke client dat op eigen houtje moet doen.
Helemaal geen OCSP is natuurlijk in theorie nog stabieler maar dit scheelt wel n hoop.
Weet niet hoe populair dit is maar op mijn server werkte t prima, was alleen wat instelwerk.

[martdj]

Hier was ik al tegenaan gelopen. Als je in bijvoorbeeld nginx deze waardes op on hebt staan, word je begroet met een rits waarschuwingen bij een nginx -t. Zaak dus om die op off te zetten:

• ssl_stapling off;
• ssl_stapling_verify off;

[Recursio]

@TijsZonderH

"Alle nog lopende certificaten met OCSP-URL's zijn nu verlopen."
-->
"Alle uitgegeven certificaten met OCSP-URL's zijn nu verlopen."

[jb044]

Persoonlijk gebruik ik squid icm proton vpn voor mijn webverkeer. Squid doet standaard wel de nodige checks maar revoked certs dus niet. Wel is het mogelijk om via een api een extern programma aanvullende checks te laten doen. Vrij snel iets gevonden op de squid mailing lists dat ocsp revoked certs kan detecteren. Dit was wel behoorlijk oud en werkte net niet, dus de boel wat aangepast zodat het wel werkte.

En toen kwam ik dit tegen Dus de boel uitgebreid, al was het maar omdat letsencrypt tegenwoordig min of meer de default is: indien er geen ocsp info in het cert staat probeert mijn script nu om een crl te downloaden (gecached met een timer). Voor allebei geldt dat alles het voordeel van de twijfel krijgt dus als er iets misgaat is de conclusie neutraal. Wel vond ik dat iig 1 van beide stukjes info in een cert aanwezig hoort te zijn dus als dat niet zo is dan wordt de request wel gedenied.

Je blijft fröbelen maar certficaatlijsten van oa Google heb ik nog niet werkend, want kon daar wel een python script voor vinden die de hele standaard implementeert maar ook 10 jaar al geen updates meer had gekregen en dus alleen nog draait in een even zo oude Ubuntu container. Werd me ook niet duidelijk of het überhaupt wenselijk is het voorkomen op zijn lijst als een requirement te zien en of courante browsers daar op checken. Denk het niet eigenlijk en het is ook weer een vertraging in de hele keten. Net zoals ocsp/crl lijsten zoals door anderen al opgemerkt.

[DaRealRenzel]

Ook al eens van OCSP Stapling gehoord ?