De volgende stap is om certificaten via DANE te accepteren, dan kan het hele WebPKI stelsel afgeschaft worden.

Mooi, dan kunnen de usual suspects alhier stoppen met hun voorspelbare copy/pasting van hun ellenlange templates van replies over hoe schadelijk Let's Encrypt voor veilheid op het internet is
(eventueel gelardeerd met speculatieve en implicerende defaming van wijlen Peter Eckersley).
...want ja, SSL is net als PassKeys niet de oplossing van alle wereldproblematiek, maar ondertussen kun je ook naar 10 mooie mijlpalen kijken - of naar hoeveel slechter het had kunnen zijn.

Wat mij een mooie invalshoek lijkt, is pki.goo die aanvankelijk ook gratis certifcaten ging uitdelen, eveneens middels certbot. Dat project is verkocht naar een commerciele partij, die graag enige userbase wenste gok ik (want veel omzet haal je niet uit gratis dingen weggeven).
Hoe komt het dat Google daar geen brood in zag?
Of was het het internet die dat niet van Google wenstte?
Of was de onboarding gewoon te gecompliceerd?
Waarom is Let's Encrypt groot geworden, en Google op dit vlak totaal niet?

Aan het domein pki.goo is geen website gekoppeld. Aan pki.goog wel: Google Trust Services, met het logo van Google erboven en de about-link is naar "About Google". Ik vind het eruit zien alsof het nog steeds van Google is en alsof Google er wel brood in ziet.

Ik neem aan dat het ermee te maken heeft dat Google Trust Services pas sinds vorig jaar gratis certificaten biedt en Let's Encrypt dat al 8 jaar doet. Ik kan me ook voorstellen dat menigeen een non-profit met vele sponsors (waaronder trouwens Chrome, dus Google) als een neutralere partij opvat dan tech-reus Google.

Graag, eerder is beter. Maar ondanks dat de standaard al jaren oud is zie ik nog amper support. Of zie ik iets over het hoofd?

Het grootste verschil is dat ik Let's Encrypt vertrouw (misschien naïef, ik kan het nergens mee onderbouwen), en weet dat ik niets van Google kan vertrouwen (gezien hun datagraai-bedrijfscultuur).

Het zou zomaar kunnen dat Google op dit moment harder groeit dan LE.

Alleen al achter één Cloudflare IP-adres (https://www.virustotal.com/gui/ip-address/104.18.73.116/relations) zijn er de afgelopen week zo'n 1500 domeinnamen van nepwebshops bijgekomen. Voor zover ik zie allemaal gebouwd met Shopify en voorzien van een GTS (Google Trust Services) certificaat (een deal tussen Shopify en Google zou mij niet verbazen, waarschijnlijk zitten de sites zelf op Google cloud servers). Big Tech wrijft weer in haar handen met Black Friday en de aankomende feestdagen.

Gezien jouw "usual suspects" en de gebruikelijke anonieme comments op deze site: voor serieus geïnteresseerder meer info in (technisch, Engels) https://infosec.exchange/@ErikvanStraten/113500408482385786 of (voor Sinterklaas, NL) https://infosec.exchange/@ErikvanStraten/113488427652048575.

vind het nog steeds absurd dat je voor een lets encrypt cert te kunnen auto-updaten je poort 80 http moet openzetten.
de meest gescande poort op misschien ssh tegenwoordig na, maar iig in de top 3 altijd-allertijden...
en die moet je open zetten om een veilige verbinding te kunnen maken...

is toch een beetje als in het donker door een hele wijk in de Bronx te lopen om naar je extra veilige S80 te lopen met gepantserde deuren.

Validatie kan ook middels DNS records, dan is poort 80 niet nodig.

Ik doe elke 3 maanden een DNS challenge voor mijn wildcard certificaat.
Geen open poort 80 nodig slechts een TXT record aanmaken met de challenge id erin en klaar.
Bij sommige DNS registrars kan je het ook automatiseren maar dat is me bij die van mij nog niet gelukt helaas.

Dat is niet noodzakelijk, er zijn meerdere challenges mogelijk zoals bijv. over DNS.
Je kunt ook een aparte server gebruiken voor het ophalen van je certs.

Hoe lost DANE het grootste probleem van PKI op, zodat een gebruiker weet dat bijvoorbeeld abn-amro.org een malafide website is en niet wordt gehost door ABN AMRO? De issues betreffende authenticatie, het doel van PKI, zijn hiermee niet opgelost. Het enige dat je weet is dat de eigenaar van de site de controle heeft over de DNS (net zoals bij het ACME protocol dat Let's Encrypt gebruikt). Het lost hiermee eigenlijk geen enkel echt probleem op (enkel zaken als SMTP downgrade attacks, maar die kun je ook voorkomen door geen STARTTLS te gebruiken).

Stagnatie komt door Google Domains.
Die als leverancier hebben was altijd een vereiste om "gratis" SSL certificaten te krijgen / ACME naar hen te kunnen gebruiken. Theoretisch dan, want in de praktijk werkte dat minder fantastisch dan de fantastische beloftes.
En die "hen" heeft ook een wisseling doorgemaakt; die divisie is opgekocht door Squarespace
https://support.google.com/domains/answer/13689670?hl=en
Squarespace had enkel oog voor omzet, en argusogen voor kosten. Efin...

Dus inderdaad, http://pki.goog bestaat uiteraard nog, is nog altijd Google, èn levert aan zichzelf en aan Google Cloud clientèle. Doch even gratis als Let's Encrypt is Google niet, en ook nooit geweest.

Niet heel moeilijk. Helemaal als je je eigen DNS draait.
De plek waar je certbot draait moet DDNS calls kunnen doen naar de DNS primary.
Zo heeft mijn certbot een aparte TSIG om (restricted) enige TXT records te mogen maken.
En met een global config van certbot doet die al het werk.
Ikzelf run het handmatig, vlak voor "day 90", maar kan ook vanuit een crontab.
Reden dat ik het handmatig doe is om dan direct expired danwel transfered domains periodiek op te ruimen.

Sinterklaas is niet NL maar ES. Lijkt mij logisch.
Was ooit DNSSEC enabled, en destijds compliant met internet.nl's validatie. Daarmee was sinterklaas.es beter op orde dan ABN-Amro en DHL die destijds SPF records al erg progressief en eng vonden - en DNSSEC helemaal.

Als je eenmaal WEET hoe je een trui moet breien dan is het niet heel moeilijk meer nee ;)

Ik draai lokaal wel een authoritive dns server (bind9).
Op Internet gebruik ik de DNS server(s) van de registrar.
Ik heb een API key van bij die registrar om o.a. records programmable aan te passen. Wat ik uit het verleden nog weet is dat ik daarvoor lexicon gebruikte. Maar het lukte steeds maar niet. Ik heb het uiteindelijk opgegeven en grotendeels vergeten dat wat ik toen al wel wist. Als ik die API handmatig dmv cli commando's gebruikte werkte het wel maar geautomatiseerd die LE dns challenges laten werken lukte steeds maar niet.
Uiteindelijk dat los gelaten want ik was en ben ook druk met andere dingen. Ik doe het nu dus ook handmatig. Ik herinner mezelf in mijn agenda eraan als ik in de laatste 30 dagen kom dan die ik e.e.a. handmatig op de dns server van mijn registrar en dat gaat al jaren eigenlijk prima.
Als ik ooit weer eens heul veel tijd over heb zal ik nog wel eens erin duiken misschien is e.e.a. ondertussen ook wat gemakkelijker geworden hoop ik dan.
bedankt voor je toelichting dat ga ik eens bestuderen.

Dat doet het ook niet.

Het is een project van/voor mensen met een hekel het stelsen van cert authorities (ik denk dat ze al op geel gingen bij het woord 'authorities' ) , en aimgh bedacht nog voor de gratis certs .

Het voornaamste wat 'opgelost' wordt is dat de trust verschuift van (tig) root cert authorities naar de DNSSEC domein hierarchie .
En dat de kosten voor de domain owner naar ongeveer nul gingen wat voor LetsEncrypt nog wat geld was.

Get real.
Je wilt blijkbaar een website publiek hosten , want je bent een certificaat aan het onderhouden.
Dan moet je van 'portscan' niet van de kook raken maar gewoon je server bestendig hebben. Dat moet je toch al op 443.
Nog meer zelfs omdat daar die enorme complexe ssl code draait in plaat van een simpele solide http parser.

Waarschijnlijk (ik heb geen zin het na te zoeken) kun je nog filteren op een reeks adressen waar de LE challenges vandaan komen.

Je snapt blijkbaar niet dat tls je server niet beveiligt, alleen het verkeer onderweg. Feitelijk wordt je server er wat meer kwetsbaar door - omdat je ook die berg TLS code draait.

Verder is je al verteld dat je ook andere challenges kunt gebruiken (DNS based)