Kortdurende Let's Encrypt-certificaten komen dit jaar, met IP-ondersteuning

Let's Encrypt wil zijn kortdurende certificaten vanaf eind dit jaar breed aanbieden aan alle gebruikers. De certificaten krijgen tegen die tijd ook ondersteuning voor IP-adressen, zegt het bedrijf. Let's Encrypt bevestigt dat certificaten van negentig dagen blijven bestaan.

Let's Encrypt geeft in een blogpost meer informatie over de kortdurende certificaten die het dit jaar wil introduceren. Het bedrijf zei vorige maand al aan zulke certificaten te werken, maar gaf daar nog geen details over en zei niet wanneer die uit moesten komen. Het gaat om TLS-certificaten met een levensduur van zes dagen, in plaats van de reguliere negentig dagen zoals nu het geval is. Volgens Let's Encrypt is dat veiliger omdat er dan een kortere periode is om misbruik te plegen. Voor sommige sitebeheerders die bijvoorbeeld geen automatiseringstools als certbot kunnen of willen gebruiken, betekenen zulke korte periodes echter ook veel onderhoud.

Om die reden blijven huidige certificaten, die negentig dagen geldig zijn, bestaan naast de kortdurende. Sterker nog, gebruikers moeten zich aanmelden voor kortdurende certificaten via de ACME-api.

Let's Encrypt is van plan de kortdurende certificaten in februari voor eigen systemen in gebruik te nemen als test. In april volgt een beperkte bètatest voor bestaande abonnees. Het bedrijf zegt te hopen de certificaten tegen het einde van 2025 definitief voor alle gebruikers aan te kunnen bieden.

De kortdurende certificaten krijgen volgens Let's Encrypt ook ondersteuning voor IP-adressen. Dat betekent dat gebruikers een certificaat kunnen hangen aan adressen die niet met een domeinnaam bereikbaar zijn. De validatie daarvan gebeurt volgens het bedrijf op dezelfde manier als bij reguliere domeinnamen, maar alleen via http-01 en tls-alpn-01 en niet via dns-01.

Reacties (69)

[84hannes]

De validatie daarvan gebeurt volgens het bedrijf op dezelfde manier als bij reguliere domeinnamen, maar alleen via http-01 en tls-alpn-01 en niet via dns-01.

Ik was nieuwsgierig, dus heb even op hun website gekeken.

• http-01: Your ACME client puts a file on your web server at http://<YOUR_DOMAIN>/.well-known/acme-challenge/<TOKEN>
• tls-alpn-01 is performed via TLS on port 443
• dns-01: Your client will create a TXT record (...) and put that record at _acme-challenge.<YOUR_DOMAIN>.

[Reactie gewijzigd door 84hannes op 17 januari 2025 09:10]

[The Zep Man]

DNS-01 is nodig om wildcard certificaten te verkrijgen. Die zijn voor sommige use cases handig, zoals het hebben van een Bluesky Personal Data Server op een apart domein waarvoor je niet voor elke gebruiker een LE-certificaat wilt aanvragen en configureren voor diens subdomein.

Het is wel afhankelijk van de API van je DNS-provider als je zelf geen DNS beheert, en een stukje middleware code om het te integreren in certbot.

[Reactie gewijzigd door The Zep Man op 17 januari 2025 14:56]

[Hatsjoe]

Die zijn voor sommige use cases handig, zoals het hebben van een Bluesky Personal Data Server op een apart domein waarvoor je niet voor elke gebruiker een LE-certificaat wilt aanvragen.

En ook heel erg handig om een wildcard te gebruiken om niet je domeinen aan de grote boom te hangen. Zo is er een openbare stream waarbij je ALLE uitgegeven certificaten en voor welk domein deze zijn kan inzien. Zo kunnen mensen dus achterhalen dat jij Home Assistant hebt draaien op homeassistant.zepman.nl. Als je een wildcard zou hebben, zien ze enkel "*.zepman.nl" in de stream voorbij komen.

Is uiteraard beetje security through obscurity, maar hoe meer laagjes security je aanbrengt, hoe moeilijker je het een aanvaller maakt. 99% van de aanvallen zijn toch gelegenheidsaanvallers, die gewoon URLs scrapen en geautomatiseerd opzoek gaan naar kwetsbaarheden. Als de hele URL al niet bekend is, vang je al heel veel risico af.

[Vorkie]

Ik vraag via DNS challenge gewoon mijn home assistant aan.

Alleen home assistant is niet bereikbaar vanaf internet… alleen maar via VPN.

hass.int.domein.nl vraag ik aan, die is geeneens opvraagbaar voor mensen in de DNS, want die bestaat alleen maar intern…

Idem voor al mijn andere interne systemen.

[Hatsjoe]

Zeker, maar niet altijd alles draait via VPN. Zo heb ik "interne" tools en applicaties draaien, maar die wel extern te benaderen zijn. Denk dan bijvoorbeeld aan Plex dat ik met familie en vrienden deel en wat andere kleine applicaties. Zijn geen kritieke systemen, maar toch wil ik liever dat de domeinen die ik daarvoor gebruik niet publiekelijk bekend zijn. Op die manier limiteer je het risico mocht er ooit een 0 day exploit komen, en ik nog niet de kans heb gehad te updaten.

[Jerie]

Dan laat je hen ook toe via VPN toegang. Niet de hele wereld hoeft toegang te hebben tot jouw Plex server. Met Shodan (Censys) of Hunter wordt zoiets namelijk wel gescanned en krijg je bovendien hits.

[GrandDynamo]

Een VPN voor familieleden is niet zonder mogelijke problemen. Het voegt voor mensen weer een stukje complexiteit toe waar je hen dan bij moet helpen. Ik snap de afweging wel dat niet alles via een VPN handig is. Ik heb zelf ook applicaties draaien welke ik alleen via een VPN kan benaderen en welke ik extern ook zonder VPN kan benaderen.

[vrow]

Daarom verander ik ook altijd de standaardpoorten, dat is ook om net wat minder snel bij een scan naar voren te komen.

[GeroldM]

Authentik of Authalia (en NginX als reverse proxy) zou je hierbij behoorlijk goed van dienst kunnen zijn.

Whatever extern toegangelijk is moet nu dus door Authentik/Authalia heen om na inlog en goedkeuring (via meerdere 2FA methodes als je dat wil) daarna naar de reverse proxy te worden geleid, welke de gebruikers naar de juiste interne server loodst.

Dat maakt de zaak al stukken veiliger. Met Authentik is het ook mogelijk om SSO aan te bieden aan je gebruikers. 2FA is verre van ideaal als het puur beveiliging gaat. Maar het is wel degelijk een vrij vervelende horde voor iemand die via automatie van een zero-day gebruik wil maken in zo'n setup.

Voor mij is dat extra beetje veiligheid wel het opofferen van wat gebruikersgemak waard. Of dat voor jouw (of je gebruikers) ook zo is, dat kan en ga ik niet voor je bepalen.

Het opzetten van Authentik/Authalia is niet zo moeilijk. Het configureren ervan, dat vraagt wel wat inzicht.

[Metalfreak]

En juist het gebruik van een wildcard wordt in de security best practices afgeraden omdat als je toegang krijgt tot de private key van dit certificaat, je meteen toegang hebt tot alle subdomeinen met dit certificaat erop. Als slechts 1 certificaat gecompromitteerd is, hoef je er maar 1 te vervangen en is slechts 1 systeem kwetsbaar. Bij een wildcard is meteen alles kwetsbaar.

[Hatsjoe]

Maar in de realiteit met dit soort thuis setups staan alle certificaten van alle websites toch bij elkaar. Dus als ze 1 certificaat kunnen bemachtigen, kunnen ze meteen alles bemachtigen.

Dit advies gaat natuurlijk wel op bij professionele setups bij bedrijven. Daar is het de norm om 1 server per doel/applicatie te hebben. Thuis is het echter vaak 1 server waarop alles draait.

[The Zep Man]

En ook heel erg handig om een wildcard te gebruiken om niet je domeinen aan de grote boom te hangen. Zo is er een openbare stream waarbij je ALLE uitgegeven certificaten en voor welk domein deze zijn kan inzien. Zo kunnen mensen dus achterhalen dat jij Home Assistant hebt draaien op homeassistant.zepman.nl. Als je een wildcard zou hebben, zien ze enkel "*.zepman.nl" in de stream voorbij komen.

Is uiteraard beetje security through obscurity,

Precies. Een alternatief is alles achter een enkel domein met een reverse proxy gooien en gebruik maken van URL-paden. Dus iets van: example.com/app/...

Helaas zijn er veel brak ontworpen webapplicaties (waaronder Home Assistant) die daar geen ondersteuning voor bieden. Met hacky workarounds kan het vaak wel (server-side URL rewriting in headers en content), maar ideaal is anders. Uiteraard heb je dan wel dat webapplicaties een gedeelde security context hebben, waar je ook rekening mee moet houden vanuit een beveiligingsoogpunt.

Maar laten we eerlijk zijn: als je al zo ver nadenkt over beveiliging, dan heb je het zodanig geconfigureerd dat die systemen enkel benaderbaar zijn door een VPN heen. Het maakt dan niet echt uit wat publiekelijk bekend is. Je kan prima TLS-certificaten aanvragen voor systemen die geen TLS ontsluiten richting het internet, al wil of kan je geen HTTP zonder TLS door een VPN gebruiken.

[Reactie gewijzigd door The Zep Man op 17 januari 2025 14:56]

[vrilly]

Met hacky workarounds kan het vaak wel (server-side URL rewriting in headers en content), maar ideaal is anders

Één regel aan config in dezelfde nginx config waar je de reverse proxy opzet, zo hacky is het toch niet? Ik doe het voor een tiental interne applicaties hier.

[The Zep Man]

Totdat de applicaties links in hun webcontent hebben die refereren naar de root van de site, terwijl daar niet de resources voor die specifieke applicatie staan.

De inhoud van /app/index.html refereert naar een img op locatie /img/banner.jpg, niet naar /app/img/banner.jpg.

Hoe ga je dat met één regel in nginx afvangen?

[zenlord]

Correct, en wat mij betreft ook de eenvoudigste manier om (LE/ZeroSSL) certificaten te bekomen in alle mogelijke scenario's: cloudservers, on premise servers, on premise K8S clusters, etc. Het is mij wel duidelijk dat ik mij in een klein clubje bevind als beheerder van mijn eigen DNS servers: plugins voor Cloudflare DNS en andere grote aanbieders zijn beter getest dan de generieke RFC2136 plugin .

[Llopigat]

Ja en DNS-01 is ook heel handig als je geen inkomend verkeer van het publieke internet accepteert op je servers.

Ik gebruik het bijvoorbeeld voor certificaten op mijn interne netwerk. Je kan ook een eigen PKI opzetten maar dan moet je die overal toevoegen als vertrouwde root CA en dat wordt steeds moeilijker gemaakt, met name op mobiele OS'en.

Het is inderdaad erg lastig omdat elke DNS provider een eigen API heeft. Er zijn programma's om het makkelijker te maken hebben vaak extra plugins nodig.

[Reactie gewijzigd door Llopigat op 17 januari 2025 12:14]

[dev-random]

Ik zie meerdere certificaat boeren deze richting op bewegen. In enkele gevallen lijkt er een relatie te zijn met de ontwikkelingen in de hoek van quantum computing.
Als dat één van de achterliggende redenen is kunnen kort(er) levende certificaten mogelijk enkele risico's mitigeren tot de nieuwe hybride, quantum-proof, standaarden volledig uitgewerkt zijn en bruikbaar binnen het huidige ecosysteem.

/Edit
Korter levende certificaten mitigeren niet zozeer het risico van brute force maar pushen de gebruikers (sneller) naar nieuwe standaarden en geautomatiseerde processen.

Zie ook: root ca policy van chromium

[Reactie gewijzigd door dev-random op 17 januari 2025 09:28]

[evers97]

Lijkt mij zeer sterk, je hebt niets aan een kortere levensduur als de encryptiestandaard hetzelfde blijft. Bij voldoende qubits zou je in nanoseconde een certficaat kunnen kraken.

[overhyped]

Het gaat niet zo zeer om de kraakbaarheid, maar om vertrouwen. Als er morgen een vulnerability komt die het certificaat met de gebruikte methoden onveilig maakt, duurt het met een kort certificaat max 6 dagen voordat er een ander certificaat staat, met hopelijk een nieuw algoritme als basis. Bij 90 dagen duurt dat max 90 dagen.

Het limiteert de exposure van clients die ten onrechte denken dat een bron is die die pretendeert te zijn.

[The Zep Man]

Het gaat niet zo zeer om de kraakbaarheid, maar om vertrouwen. Als er morgen een vulnerability komt die het certificaat met de gebruikte methoden onveilig maakt, duurt het met een kort certificaat max 6 dagen voordat er een ander certificaat staat, met hopelijk een nieuw algoritme als basis.

Dat ligt aan het verzoek. De aanvrager kan ook certificaten aanvragen gebaseerd op een specifiek algoritme en bestaand asymmetrisch sleutelmateriaal. Dat laatste heeft als voordeel dat TLSA records die refereren naar de eigen publieke sleutel in DNS niet gewijzigd hoeven te worden bij het vernieuwen van een certificaat.

[Reactie gewijzigd door The Zep Man op 17 januari 2025 10:45]

[NuclearBanana]

Ik denk dat je dommer moet kijken. Ik denk dat menig site nog een handmatig proces heeft voor de certificaten met de private key opgeslagen op een domme plek (denk mapje genaamd 'private keys' op het bureaublad). Het introduceren van kortdurende certificaten maakt het op twee vlakken veiliger. 1. Het forceert de admin om geautomatiseerd proces in te stellen wat dit domme gedrag voorkomt. En 2. Stel dat mapje wordt gejat, dan heeft de hacker maar max 6 dagen om gebruik te maken van deze private key ipv max 90 dagen.

[bwerg]

Lichtelijk overdreven, want het duurt al ~10ns om een CPU iets uit het RAM te laten vissen.

Maar verder staat je punt natuurlijk wel. Al zou het kraken een minuut duren, dan is de geldigheidsduur van je certificaten nou nog steeds niet echt de doorslaggevende factor voor de kraakbaarheid.

[Vaevictis_]

Daar is toch PFS voor uitgevonden? https://nl.wikipedia.org/wiki/Perfect_forward_secrecy

[The Zep Man]

Uit het Engelse artikel:

However, forward secrecy cannot defend against a successful cryptanalysis of the underlying ciphers being used, since a cryptanalysis consists of finding a way to decrypt an encrypted message without the key, and forward secrecy only protects keys, not the ciphers themselves.[8] A patient attacker can capture a conversation whose confidentiality is protected through the use of public-key cryptography and wait until the underlying cipher is broken (e.g. large quantum computers could be created which allow the discrete logarithm problem to be computed quickly). This would allow the recovery of old plaintexts even in a system employing forward secrecy.

Dus nee.

[D11]

Als dit gaat om de kraakbaarheid van de certificaten (eventueel met quantum computing). Dan heb ik nog wel wat vragen:
1. Worden de root-ca en sub-ca's dan ook sneller vervangen?
2. Hoe komt deze nieuw root-ca en/of sub-ca public keys dan bij de web-browsers, OS-en, firewalls, etc?

[Neurosis]

RSA en EC zijn op papier al jaren gekraakt, maar is de duur om deze te kraken met conventionele computers veel langer dan de CA certificaten geldig zijn. Met quantum is de enige beperkende factor nog de hoeveelheid qbits, maar dat zal net als met schijfruimte of werkgeheugen ook sterk kunnen toenemen.

Die systemen hebben vaak een eigen reeks aan vertrouwde CA certificaten die door de fabrikanten worden geupdate, maar een gevorderde gebruiker of beheerder kan deze ook gewoon zelf importeren.

Bepaalde roots zijn soms nog wel 10 jaar geldig. Met de aankomende ondersteuning voor quantum resistant algoritmes, heeft het (denk ik) geen zin meer om die roots te verlengen met RSA/ECDSA.

[dev-random]

Correct, maar voor backwards compatibility denk ik dat we RSA e.d. nog enige tijd zullen blijven zien. De hybride standaarden maken dit ook gelijktijdig mogelijk i.c.m. post-quantum ciphers.

[dev-random]

Voor zover ik in kan schatten gaat het bij de kortere levensduur niet primair om de kraakbaarheid.
Dat gezegd hebbende, ook root en sub CA's krijgen een kortere levensduur.

[thePiett]

Wat is een certificaat boer? Iemand die certificaten op zijn land verbouwd en oogst?

[grimlock]

Zeker een leuke ontwikkeling, het zou helemaal mooi zijn als je met je Synology dit proces automatisch kan laten verlopen. Om de drie maanden dit handmatig doen is niet echt comfortabel.

T.a.v. onderstaand reacties: klopt inderdaad, ik heb poort 80 dicht staan en moet hem handmatig steeds openzetten om alleen de check te laten doen. Vind ik persoonlijk net iets teveel van het goede. My bad!

[Reactie gewijzigd door grimlock op 17 januari 2025 09:19]

[Pikkemans]

Synology DSM ondersteund het aanmaken van Let's Encrypt certificaten met automatisch verlengen.

[adebruin]

@StackMySwitchUp Synology DSM ondersteunt alleen http-01 voor het verlengen van het Let's Encrypt certificaat. Deze optie vereist een open 80, 443 poort tijdens het verlengen. Veel gebruiken zetten deze poort standaard dicht vanwege veiligheidsredenen. Het alternatief is handmatig verlengen en tijdelijk de poorten 80 en 443 te openen. Helaas kan het tijdelijk aanpassen van de firewall niet automatisch.

Het alternatief kan zijn om de ACME DNS-01 optie te gebruiken. Dit is niet een standaard optie bij Synology, maar het schijnt prima te werken.

[Reactie gewijzigd door adebruin op 17 januari 2025 09:59]

[RefriedNoodle]

Het is alweer een tijd geleden dat ik het zelf geconfigureerd heb, maar ik weet vrij zeker dat mijn Synology nu ook automatisch LetsEncrypt-certificaten ververst? Of hebben we het over iets anders?

[adebruin]

@grimlock Dit is inderdaad niet een Synology out-of-the-box optie. Je zou de ACME protocol DNS-01 optie kunnen gebruiken om het probleem met http-01 (EIS: port 80, 443 moeten op het moment van vernieuwen bereikbaar zijn naar het internet) te omzeilen. Meer hierover hieronder:

1 - https://www.christosgeo.c...y-using-acme-sh/#comments
2 - https://dr-b.io/post/Syno...Encrypt-and-DNS-Challenge

[Reactie gewijzigd door adebruin op 17 januari 2025 09:49]

[grimlock]

Dat is inderdaad interessant en een veel betere optie! Dank je!

[StackMySwitchUp]

Dat kan volgens support van synology
https://kb.synology.com/n...uest_on_your_Synology_NAS

[The Zep Man]

Lijkt mij ook prima voor testomgevingen. Vaak is een langdurig certificaat echt niet nodig. Korter is natuurlijk veiliger, en je kan sneller een nieuwe aanvragen als je met de vele verschillende TLS-opties aan het experimenteren bent en tegen rate limits aanloopt. Natuurlijk is gebruik van de stagingomgeving beter.

Sneller een langdurig certificaat aanvragen om rate limits te ontwijken kon natuurlijk al met een workaround, omdat voor LE de set (sub)domeinnamen in een certificaat bepalen of deze (opnieuw) aangevraagd mag worden. Vraag een certificaat aan voor de domeinnamen example.com en test1.example.com. Vraag daarna een certificaat aan voor example.com en test2.example.com. Test enkel met example.com. Hoewel dit kan, is het natuurlijk niet echt netjes omdat je zo veel certificaten hebt die langdurig geldig zijn en die je mogelijk niet gebruikt.

Voor sommige sitebeheerders die bijvoorbeeld geen automatiseringstools als certbot kunnen of willen gebruiken, betekenen zulke korte periodes echter ook veel onderhoud.

Als je anno 2025 nog niet je certificaatbeheer hebt geautomatiseerd, dan respecteer je niet (de waarde van) je tijd. Er zijn zoveel andere zaken waar je beter je tijd aan kan besteden dan aan het handmatig wisselen van certificaten. Investeer eenmaal in die tijd en het verdient zich snel genoeg terug.

[edit]
Reactie wat aangepast m.b.t. de opmerking van @jurroen.

[Reactie gewijzigd door The Zep Man op 17 januari 2025 09:22]

[jurroen]

en je kan sneller een nieuwe aanvragen als je met de vele verschillende TLS-opties aan het experimenteren bent.

De duur van het certificaat staat daar helemaal los van. Je kunt er, als je zou willen, nu ook al verschillende achter elkaar 'issuen'.

Hou er wel rekening mee dat je de vorige(n) dan dient te revoken. Anders blijven die geldig, iets wat je vanuit veiligheidsoogpunt niet wilt.

Het enige wat een belemmering kan zijn in de uitgifte, zijn de rate limits.

Toevoeging:

Sneller een langdurig certificaat aanvragen om rate limits te ontwijken kon natuurlijk al met een workaround, omdat voor LE de set (sub)domeinnamen in een certificaat bepalen of deze (opnieuw) aangevraagd mag worden. Vraag een certificaat aan voor de domeinnamen example.com en test1.example.com. Vraag daarna een certificaat aan voor example.com en test2.example.com. Test enkel met example.com. Hoewel dit kan, is het natuurlijk niet echt netjes omdat je zo veel certificaten hebt die langdurig geldig zijn en die je mogelijk niet gebruikt.

Wat je hier zegt klopt evenmin. Je kunt ook kort na elkaar twee (of meer) certificaten uitgeven voor alleen example.com. Wellicht is het een artificiële beperking in de ACME app (Certbot?) die jij gebruikt - maar Lets Encrypt ondersteund het gewoon @The Zep Man.

[Reactie gewijzigd door jurroen op 17 januari 2025 09:54]

[The Zep Man]

Wat je hier zegt klopt evenmin. Je kunt ook kort na elkaar twee (of meer) certificaten uitgeven voor alleen example.com. Wellicht is het een artificiële beperking in de ACME app (Certbot?) die jij gebruikt - maar Lets Encrypt ondersteund het gewoon @The Zep Man.

Je kan nog steeds rate limits daarmee ontwijken. Voor een testomgeving is dat handig als je vaak faalt (=aanslag op rate limits).

[jurroen]

Okee, met die gedachte is het wel logisch.

Vraag mij uit interesse wel af hoe het komt dat men die failure rate limit raakt. Dat een wat meer beginnend persoon het een of twee keer opnieuw moet doen omdat ze vergeten zijn een poortje open te zetten, allez. Maar veel vaker?

En de merendeel van de vele opties en configuraties die TLS kent zitten niet in het certificaat. Dat is hoofdzakelijk de keuze uit RSA of ECC (en evenrueel de hoeveelheid bits) en als je wat dieper gaat misschien iets als must-staple.

Maar zaken als de TLS versies, cipher suites, etc, staan daar vrijwel los van.

[lenwar]

Ik zat zelf gelijk te denken aan containers? Van die containers die maar een paar dagen bestaan, maar dan wel allemaal een eigen certificaat (moeten/kunnen) krijgen? Als die certificaten maar 6 dagen geldig zijn, hoef je ook geen moeite te nemen om ze ongeldig te maken.

[MeetTommy]

Hoe werkt dat met een IP-adres? Betekent dit dat iedereen met een dynamisch adres dan een certificaat kan aanvragen? In tegenstelling tot een domeinnaam ben je meestal geen eigenaar van je IP-adres.

Ook al is het een kortdurend certificaat en zal het niet vaak voorkomen dat je zelf een IP-adres kan kiezen… Lijkt mij toch een behoorlijk gat in de veiligheid. Zie ik hier nog iets over het hoofd?

[DDX]

IP Address Support For Securing Additional Use Cases
We will support including IP addresses as Subject Alternative Names in our six-day certificates. This will enable secure TLS connections, with publicly trusted certificates, to services made available via IP address, without the need for a domain name.

Validation for IP addresses will work much the same as validation for domain names, though validation will be restricted to the http-01 and tls-alpn-01 challenge types. The dns-01 challenge type will not be available because the DNS is not involved in validating IP addresses. Additionally, there is no mechanism to check CAA records for IP addresses.

Zit dus wel een risco aan idd, al is de kans dat een ipadres binnen 6 dagen weer door iemand anders in gebruik genomen wordt volgens mij redelijk klein (maar nooit 0)

[Dykam]

Er is alleen een gat als vervolgens een ander binnen zes dagen een server aanbied die dmv. een certificaat TLS aanbied. Dan kan inderdaad de eerdere gebruiker een MITM pogen.

Of anders gezegd, de overlap tussen mensen die TLS dmv. certificaat gebruiken, en mensen die een dynamisch IP hebben, en mensen die een doelwit zijn zal praktisch nihil zijn. Sowieso is een server aanbieden door een dynamisch IP te adverteren al niet heel handig, het is in die zin een niet zo relevant scenario.

[Anoshky]

Dit is in lijn met wat de Chromium community / Google in de toekomst wenst te implementeren:
https://www.chromium.org/.../moving-forward-together/

[FaLLenOnes]

Zolang google het nog voor het zeggen heeft:
https://edition.cnn.com/2...ice-department/index.html

Korte levensduur van certificaten = hogere volumes, = meer kans dat er iets foutgaat in "the lifecycle" van het certificaat.(aanvraag, installatie, validatie, vernieuwen).

Revocation checks worden dan ook lastiger ivm volume, grotere CRL. ivm lets encrypt geen OCSP meer gaat doen vanaf halverwege het jaar 2025.

We gaan het meemaken

[coolkil]

Met kort durende certificaten lijkt revocatie me ook minder nodig..??

[FaLLenOnes]

Ligt aan wrmcert revoked is.

Revokatie na eindigen levensduur, nee dan niet.
maar mss revokatie ivm een certificaat gecompromitteerd is, private key bv by 3den terecht gekomen.

[Gwaihir]

Laat Let's encrypt eerst maar 'ns certificaten uitgeven die niet zelf-saboterend zijn. Als enige vinden ze dat ze moeten besluiten dat op clients met een ouder OS geen certificaat uitgereikt wordt.. Geeft maar onnodige extra koppijn.

[kwaakvaak_v2]

Dat moet dan wel een heel oud OS zijn of je moet bedoelen dat het oude OS het certificaat niet accepteert omdat de chain niet gevalideerd kan worden.

[Gwaihir]

Het zijn niet de nieuwste natuurlijk, maar Android 7 ging er bijvoorbeeld uit met nog een ruime gebruikers-base. Voor bijv. outlook op zo'n toestel, is er dan geen workaround meer als je de mailserver certificaten van let's encrypt hebt. Dus klagende mensen..

[En dat wordt bewust door Let's Encrypt zo veroorzaakt, op basis van hun mening die ze zo opdringen. Die Android toestellen halen nog gewoon nieuwe certificaten binnen.]

[Reactie gewijzigd door Gwaihir op 17 januari 2025 16:49]

[eborn]

Je kunt je afvragen of dat een probleem van Let's Encrypt is of van de partij die die Android toestellen niet meer onderhoud.

[stormbyte]

Vraag me hier nog wel af of we dan tegen api limiten gaan aanlopen.
Gezien ik deze bij de huidige api aan lopen bij het testen die om de 90 dagen ververst worden.
Als deze om de 6 dagen moeten worden ververst lijkt het me dat het verkeer nog hoger word aan de kant van let's encrypt, maar daar lees ik nog niks over.

[moonlander]

Als je certificaten gaat testen moet je de productie omgeving niet gebruiken, daar hebben ze staging of test voor. Die kunnen hogere limits aan. https://letsencrypt.org/docs/rate-limits/

[Pazo]

Voor mijn Nextcloud omgeving heb ik ze ook van Let's Encrypt van 90 dagen, en dat vind ik prima, hoeft van mij geen 6 te worden. Fijn dat de optie blijft.

[Kazu]

Oh, ik wist niet dat IP-adres ondersteuning inmiddels een mogelijkheid was bij TLS certificaten. Dat is op zich wel interessant. Moet ik een keertje in duiken!