Toch zou ik het fijn vinden als we dit even goed met DANE kunnen doen.

Het stomme is, er is niet echt een serieus probleem wat hiermee opgelost wordt, maar het kost wèl veel tijd en energie.

Globale CAs zijn nu nog maar 200 dagen geldig, in 2027 100 dagen en in 2028 47 dagen, niet 45.

Wat een blunder voor een securitysite (en niet de eerste keer).

TLS-certificaten hebben al heel lang (sinds clients en servers gebruikmaken van forward secrecy) niets meer te maken met het versleutelen van het netwerkverkeer.

Het enige doel van een DV (Domain Validated) TLS-certificaat (zoals Let's Encrypt) is, i.c.m. een geheime private key op de server, aantonen dat de domeinnaam van de website (of mailserver etc.) verwijst naar het IP-adres van de server met die private key.

Het gaat dus uituitend om het hebben van zekerheid (meer of minder) dat de client met de juiste server verbinding maakt.

Los daarvan is het verkorten van de levensduur van certificaten absurd. Het leidt tot grote energieverspilling, een toename van het risico op onbereikbaarheid door onbedoeld verlopen certificaten, en het biedt verwaarloosbaar meer veiligheid (authenticiteit). Na onterechte uitgifte van valse certificaten slaan aanvallers immers meteen toe; dat zulke certificaten 90, 60, of slechts 6 dagen geldig zijn, maakt geen klap uit.

Zie bijvoorbeeld https://arstechnica.com/security/2026/10/hackers-obtain-counterfeit-tls-certificates-for-google-and-other-large-services/ van deze week: criminelen kregen toegang tot de DNS-records van de Top Level land-Domeinen .gh, .sl en .as waarna zij de DNS-records van alle gewenste subdomeinen daarvan naar hun servers konden laten wijzen - waaronder websites van Google. Daar konden zij vervolgens probleemloos DV-certificaten voor verkrijgen (want DV-certificaten verkrijgen is een 1FA-proces via DNS - waarbij DNS ook nog eens een notoir onbetrouwbaar protocol is).

Zélfs als die criminelen zo stom zouden zijn om 6 dagen geldige certificaten aan te vragen, is dat lang zat. Hun hack wordt nagenoeg altijd sneller ontdekt; 6 dagen volstaat om veel slachtoffers te maken.

Als je kritiek wilt uiten op redactionele keuzes, zou ik eerst wat beter onderscheid maken tussen feiten, aannames en conclusies. Je verspeelt bij mij in ieder geval het voordeel van de twijfel al met je tweede zin ("TLS-certificaten hebben […] niets meer te maken met het versleutelen van het netwerkverkeer"), want dat is een misleidende voorstelling van hoe TLS werkt. Ben je eigenlijk wel kritisch op je eigen aannames?

Het is de "elke zoveel dagen password wijzigen" versie voor TLS .
En met dezelfde reden - zorgen dat een (mogelijkerwijs onmerkbaar) gelekt certificaat maar een beperkte tijd bruikbaar is, plus uitfaseren van OCSP .
https://blog.ascertia.com/ocsp-and-the-web-pki-whats-changing

(voor degenen die het niet wisten : een browser deed voor elk webbezoek naar "ergens" ook even een lookup bij de Certificate authority van die site om te kijken of het certificaat nog geldig was. Lekker private browsen ...
Het is erg veel later wat gemitigeerd )

Het intrekken van een certificaat is een slecht schaalbaar model - (inclusief privacy probleem dat een browser telkens roept naar een CA waar hij wilde gaan kijken ) - en intrekken wordt alleen gedaan wanneer mensen _weten_ dat een certificaat compromised is.

Cronjob verkorten. Hoeveel tijd en energie kost dit?

Had liever dat ze opschoten met het inbouwen van DNS-PERSIST-01. Dat zou al begin dit jaar klaar zijn.

Goed verdienmodel voor de grote jongens die kortere certificaten. Niet dat het ook maar iets van veiligheid brengt, maar laten we dat voor het gemak maar vergeten.

Nee dat is het niet.

Sowieso zijn server-certificaten optioneel in TLS, ook bij versleutelde TLS-verbindingen (zie Figuur 1 in https://www.rfc-editor.org/info/rfc9846/#tls-full).

Zonder alternatieve vorm van server-authenticatie kan zo'n verbinding welliswaar versleuteld zijn, maar als client heb je dan geen idee of je met de bedoelde server of met een AitM (Attacker in the Middle) communiceert. Daarom wordt in de praktijk bijna altijd een servercertificaat gebruikt dat door een vertrouwde Certificate Authority is afgegeven.

Sinds TLS v1.3 komen de client en de server een (symmetrische) encryptiesleutel overeen, en versleutelen daarmee de verbinding, vóórdat (optioneel dus) de server het servercertificaat naar de client stuurt (het certificaat gaat dus versleuteld over de lijn). Daarmee is uitgesloten dat de client het servercertificaat zou kunnen gebruiken voor het vaststellen van de sessiesleutel.

Ter illustratie: al heel lang geleden merkten gebruikers van Wireshark op dat zij geen servercertificaat meer "voorbij" zagen komen bij TLS v1.3 verbindingen (zie https://ask.wireshark.org/question/14909/tls-13-certificate/).

Het servercertificaat wordt dus al jaren uitsluitend voor authenticatie van de server gebruikt, en niet meer voor het versleuteld (asymmetrische encryptie zoals RSA) naar de server sturen van een door de client verzonnen sleutel.

Server-authenticatie werkt als volgt: de server gebruikt de private key (gekoppeld aan de public key in het certificaat) om de van de client ontvangen en op de server gegenereerde random parameters digitaal te ondertekenen. De client gebruikt de public key in het certificaat om die digitale handtekening te checken. Als die handtekening klopt is een AitM tussen client en server zo goed als uitgesloten - tenzij bijv. de private key van de server gelekt is of van de public key afgeleid kan worden (en dan nog moet de aanvaller zich wel tussen client en server kunnen "wurmen").

Dit levert werkelijk waar niks op behalve dat ze weer kunnen doen alsof ze ook maar iets doen aan extra veiligheid.
Niemand in de sector, branche neemt dit serieus als een oplossing.

Leg eens uit hoe en welke "grote jongens" "goed gaan verdienen" aan kortere certificaten ?

De grootste push ervoor komt van GRATIS provider Let'sEncrypt .

Geen idee in welk holletje van "de sector" jij zit , maar "de sector" in het CA/Browser forum waar ongeveer de hele industrie in zit stemt over dit soort keuzes en was dus voor.
samenvatting van wat tijdslijnen https://www.swisssign.com/en/blog/tls-validity-47-days.html

geen idee welke stroman je bedoelt met "oplossing" - maar het is een verbetering voor een aantal aspecten. Zoals alles - geen "100% voor eeuwig oplossing voor alles".

Zo heerlijk naïef. Zoek eens uit wie er achter Let’s Encrypt zitten allemaal. De grote jongens zoals Sectigo zijn er erg blij mee, certificaten gaan in een abonnement en voor ACME mag je bij betalen. Anders wordt het handmatig werk. En nee, lang niet elke site zal kiezen voor een gratis optie zoals Let’s Encrypt.

Ik vind de sprongen in je redenatie nogal groot en daardoor de plank echt misslaan.

Wie er allemaal achter LE zitten (gewoon even lui wikipedia gebruikt):
Founders:
- Electronic Frontier Foundation
- Mozilla Foundation
- University of Michigan
- Akamai Technologies
- Cisco Systems

Sponsors:
Electronic Frontier Foundation (EFF), the Mozilla Foundation, OVHcloud, Cisco Systems, Facebook, Google Chrome, the Internet Society, AWS, nginx, and the Gates Foundation. Other partners include the certificate authority IdenTrust, the University of Michigan, and the Linux Foundation.

Ik zie geen link met een leverancier die DV levert die hier ook maar iets aan zal hebben. Mocht je een mooie link hebben naar de grote cert jongens zou ik het graag zien.

Dat dit de grote jongens als Sectigo meer ruimte zal geven voor te hoge prijzen zou kunnen, maar de kosten voor een EV zijn al zo ongelofelijk buitenproportioneel hoog. Die hebben echt geen LetsEncrypt nodig om de prijzen veel te hoog te houden. Een gratis/goedkoper alternatief kan dit proberen wat te dempen. Het zal mensen kritischer laten kjken naar de meerwaarde van EV. En die is er vast voor partijen. Of dat ze de club LetsEncrypt niet vertrouwen, ook goed. Maar dat een versnelling van cyclen van certificaten (korter trust model) goed uit komt voor de "concurrenten" van LE snap ik niet.

Operation manager van een Zakelijk Provider en betrokken bij IETF in meerdere werkgroepen.
Ofwel een eindverantwoordelijke om dit goed te laten regelen voor bedrijven.

Je hebt niet eens flauw idee daf je letterlijk de Certificaat cartel zit te promoten.
Hier wat leden of zullen we het beestje gewoon bij zijn naam noemen lobby?

DigiCert, Sectigo, Let's Encrypt, GoDaddy, Amazon, AC Camerfirma, D-TRUST, TurkTrust, Visa Apple, Google, Microsoft, Mozilla, Brave, Cisco, Opera, ACAB Council, CertiPath, CPA Canada/WebTrust, ETSI, Keyfactor, tScheme, US Federal PK

Begint je al wat op te vallen?
Denk je nu werkelijk dat een provider zoals ons of een yourhosting, antagonist etc blij wordt van aanpassingen in enige certificaat duur? Enig idee hoeveel level 1 support sht er is van zogenaamde ITers die issues hebben met cert vernieuwingen?
Ooit een verstoring van een CA meegemaakt? ik wel was met SECTIGO/Comodo 3 dagen lang geen verniewing kunnen doen we had hadden een paar honderd dnszones gevuld met allemaal garbage CNAME records erdoor omdat het systeem op herhaling probeerde certificaten op te halen omdat ze besloten een lager ophaal limiet te hanteren maar dat niet eerst melden.

En met oplossing bedoel ik de laksheid van CA's met uitgaves.
Want hun zijn het probleem dat ze zelf proberen op te lossen.

Wie geven constant certificaten uit naar frauderende en criminele providers?
Exact CA's. En dit geintje speelt al decinia. In de tijd van de EV's moesten we volgens protocol met een leverancier bewijs van eigendom overhandigen een KVK uittreksel en een kopie ID of paspoort. Gevolgd door een belletje van de leverancier naar ons en client. Weet je hoe vaak dat werkelijk nodig was? nog geen 10%. Want de CA's hadden helemaal geen zin hierin dus wat gebeurde je deed een aanvraag voor je ook maar de KVK info had geupload maakte ze een belafspraak en dan was het klaar.

Sterker nog het ging zelfs zo ver dat fouten in KVK gedoogd werden. Dan kwam telefoon nummer niet overeen met wat client had ingevuld in formulier en officieel moest de kvk dan aangevpast eerst worden wat zo een week kon duren. Of de man of vrouw van een client stond als eigenaar ipv contactpersoon aan de lijn. Wat gebeurde er CA die letterlijk instructie gaf het zelf te corrigeren en ze accepteerden zonder enige vorm van verificatie een ander telefonisch contact persoon
.
Let me remind you het ging om honderden euros per aanvraag toen met idiote marges voor ons als voor de CA's maar nog moesten ze daar net dat beetje extra pakken en f veiligheid ervoor. En nee dat was geen uitzondering met een enkele CA maar waar ik boven over heb was Symantec en als je uit mijn branch kwam which you dont kan je de ellende nog wel herrineren van 2017 en 2018 daarmee. En dat was niet eerste incident waar we mee zaten..

Ik adviseer je eerst kennis in de praktijk op te doen voor je andere denkt enige les te kunnen leren over hun sector, branch.
Ik zou zeggen kruip lekker terug in je holletje van jouw eigen sector tot je respectvol kan argumenteren.

Je had gewoon heel beleefd kunnen argumenteren het niet eens zijn met me of uitleg vragen om mijn antwoord maar je wou belerend overkomen wel fine by me je zet jezelf enkel voor schut en dat is niet mijn zorg.