Google en Mozilla gaan geldigheid tls-certificaten beperken tot 398 dagen

Vanaf 1 september accepteren Googles Chrome en Mozilla's Firefox tls-certificaten die langer dan 398 dagen geldig zijn niet meer. Ze volgen daarmee Apple, dat eerder dit jaar eenzelfde beslissing bekendmaakte. Verschillende certificaatautoriteiten zijn tegen.

Officieel lijken Mozilla en Google de stap om de maximale levensduur van ondersteunde tls-certificaten te beperken tot 398 dagen nog niet aangekondigd te hebben, maar de wijziging blijkt uit opmerkingen op de Github-site voor Mozilla's pki-beleid en het Chromium-project, waar Googles Chrome op gebaseerd is. Het lijkt waarschijnlijk dat Microsoft de wijziging ook meeneemt voor zijn Edge op Chromium-browser.

Apple maakte in maart al bekend dat het vanaf 1 september met zijn Safari-browser alleen nog tls-certificaten met een geldigheid van maximaal 398 dagen zou ondersteunen. De browsers blokkeren certificaten met langere geldigheidsduur vanaf die datum.

Google diende vorig jaar september tijdens het CA/Browser Forum het voorstel in om de ondersteuning voor tls-certificaten met een geldigheidsperiode langer dan 398 dagen te stoppen. Dat voorstel werd niet aangenomen, omdat negentien certificaatuitgevers tegenstemden en slechts elf voor, bij twee onthoudingen van stemmen. Van de 'certificaatconsumenten' stemden alle zeven partijen voor: Apple, Cisco, Google, Microsoft, Mozilla, Opera en 360. Na de eenzijdige stap van Apple, krijgen de browsermakers nu in de praktijk toch hun zin.

Volgens Google zijn de voordelen van een kortere levensduur van tls-certificaten dat problemen minder lang voortduren. Het beleid is dat certificaatautoriteiten deze intrekken bij misbruik, maar deze procedure duurt soms lang. Sommige certificaatuitgevers zien weinig voordelen van de maatregel en stellen hierdoor meer werk te krijgen.

Reacties (175)

[Saven]

Dus als je net een 2-jarig certificaat hebt gekocht mag je over een paar maanden weer de portemonnee trekken omdat een paar tech reuzen dat willen?

[Drardollan]

Nee, pas op 1 september 2020 gaat dit in. Dit betekent dat certificaten die zijn uitgegeven voor 1 september 2020 met een langere levensduur gewoon blijven werken. Certificaten die een begindatum hebben vanaf 1 september 2020 mogen nog maximaal 398 dagen geldig zijn.

Dus je hoeft helemaal niets te doen, het kost je geen eurocent meer.

[Bor]

Dat hangt er vanaf of je betaalt per certificaat of voor een vaste periode van bv 1 of 2 jaar.

[Saven]

Heb net een tweejarig certificaat gekocht bij Xolphin. Die is straks dus niet meer geldig en mag ik een nieuwe gaan aanvragen, toch?

Beter hadden ze dit dan gedaan voor certificaten die ná december ofzo worden uitgegeven. Want als iemand net een week voor Google's deadline zo'n langdurig certificaat loopt, ligt heel z'n website plat voor de meeste bezoekers.

[Reactie gewijzigd door Saven op 25 juli 2024 11:39]

[Mushroomician]

Ik zou toch eisen om compensatie.

Je hebt een certificaat gekocht wat 2 jaar vertrouwd hoort te zijn. Bij een lek of aanpassing aan hun kant moeten ze je gewoon een nieuwe geven gedurende deze periode.

Je betaald voor het vertrouwen. Niet voor het certificaat. Dat is slechts een middel.

1 september is nog 64 dagen vooruit. + 365 maakt dat de browsers 301 dagen voor het einde van jouw cert het blokkeren. Uitgaande vanuit aankoop gisteren 302, etc.

[Reactie gewijzigd door Mushroomician op 25 juli 2024 11:39]

[Drardollan]

Nergens voor nodig. Certificaten geleverd voor 1 september 2020 vallen buiten deze beperking.

[GekkePrutser]

Ik vind het maar schijnveiligheid. Als er echt misbruik van gemaakt wordt, is 1 dag al veel te lang. Dan is de schade al geschied. Het is veel belangrijker dat de revocation procedure goed en snel werkt.

Maargoed, kwaad kan het verder ook niet.

[Reactie gewijzigd door GekkePrutser op 25 juli 2024 11:39]

[GrooV]

Nee als jij 1x in de 4 jaar je certificaat moet vernieuwen is de kans groot dat je dit vergeet of niet meer weet hoe dit moet omdat een andere collega dit gedaan heeft.

Door een snellere roulatie van certificaten te hebben wordt het aangemoedigd om dit te automatiseren. Daarnaast zijn gestolen keys en/of slecht geconfigureerde certificaten minder lang exposed

https://letsencrypt.org/2015/11/09/why-90-days.html

[Bor]

Je vergelijkt nu de 90 dagen van Lets Encrypt met de (straks) 398 dagen die Google en Mozilla gaan hanteren waardoor deze argumenten niet of veel minder op gaan.

[Verwijderd]

Denk je dat dit de laatste verlaging is?
Vroeger hadden we certificaten die 5 jaar geldig waren....

Ik vind het een goede ontwikkeling en ben het helemaal met @Groov eens. Mensen vergeten heel vaak hoe ze precies de certificaat renewal moeten uitvoeren op hun Exchange server of Netscaler. Hiermee worden ook leveranciers gedwongen om een goede oplossing te maken voor certificaat lifecycle.
Iets dat al sinds dag 1 in hun product had moeten zitten, maar goed...

[bbob]

Wie weet moet een de niet gratis registrars dan ook een soort let's encrypt model invoeren. Je koopt voor 5 jaar een certificaat maar door automatisering wordt het iedere x dagen geupdate naar nieuwe verloopdatum.

[CAPSLOCK2000]

Wie weet moet een de niet gratis registrars dan ook een soort let's encrypt model invoeren. Je koopt voor 5 jaar een certificaat maar door automatisering wordt het iedere x dagen geupdate naar nieuwe verloopdatum.

Dat doen ze al, inclusief ACME interface. Zie bijvoorbeeld Digicert of Sectigo.

[bbob]

De bedrijven die dat doen zouden dus geen last hebben van deze maatregel.

[syl765]

Automatiseren gaat prima met normale certificaatjes. Heb je echter een overheids certificaat nodig waarbij je fysiek je paspoort moet tonen en een iris scan moet ondergaan dan word automatiseren erg lastig. Nog maar niet te spreken over de kosten.

[deadinspace]

Hoe belangrijker het vertrouwen in een certificaat is, hoe kwalijker een lange levensduur is.

Als zo'n certificaat zo nauw luistert, dan lijkt het me alleen maar goed dat daar 1x per jaar een nieuwe controle op plaatsvindt, in plaats van bijvoorbeeld elke 3 jaar.

[Verwijderd]

Ja maar ambtenaren zijn lui.....

Ik heb een keer een overheids project gedaan (erg lang geleden) waar het vast zat op wie het certificaat ging betalen (moest met creditcard). Na 5 vergaderingen bleek dat het gewoon onmogelijk te regelen was. Toen hebben wij als ‘externen’ de 80 euro ofzo bij elkaar gelegd om het project maar door te kunnen laten gaan...

[elmuerte]

Daarnaast zijn gestolen keys en/of slecht geconfigureerde certificaten minder lang exposed

Grote aanname dat men bij het aanvragen van een nieuwe certificaat een nieuwe key maakt. Dit is namelijk echt vaak niet het geval.

[Reactie gewijzigd door elmuerte op 25 juli 2024 11:39]

[GeroldM]

En dan gaan de hackers de systemen van LetsEncrypt aanvallen. Zitten ineens een heleboel sites/bedrijven met gehackte certificaten die ze automatisch door de strot krijgen geduwd. Mochten ze de LetsEncrypt servers niet breken, maar platleggen, dan zijn er nog altijd een boel sites/bedrijven welke hun certficaten niet tijdig kunnen up-daten en allerlei problemen intern/extern daardoor krijgen.

Staar jezelf niet te blind op de argumenten van LetsEncrypt. Deze zijn zeer zeker valide, maar niet zaligmakend. Geen enkel update schema is dat.

Een certificaat is veilig tot het moment dat dit niet meer het geval is. Hoe lang de periode tussen creatie en onveilig is, dat hangt nogal af waar het betreffende certificaat is toegepast.

Daarnaast las ik ook in comments hier dat mensen/personeel vergeten hoe je certificaten creert en/of implementeert. Dat is zeker het geval, maar als tegenargument: dan moet je toch echt eens achter de oren krabben over hoe slecht de benodigde documentatie-skills zijn.

Al dit soort handelingen leg ik vast (met plaatjes etc.) in een wiki. Echt niet zo moeilijk om bij te houden en makkelijk te doorzoeken.

[Tozz]

Kwaad kan het wel in de zin dat het geld kost. Wij beheren letterlijk duizenden certificaten en die verlengingen zijn best een gezeik. Op een normale server valt het nog mee, dat is wel te automatiseren. Maar bij veel appliances gaat dat niet. Of de validatie slaagt niet door een aangepaste .htaccess, etc, etc.

[Robbaman]

Op zich een valide punt, maar toch zul je zien dat dit soort acties ertoe zullen leiden dat deze processen opnieuw onder de loep genomen zullen worden en na een aanpassing werkt het dan ook in die andere situaties 'gewoon automatisch' en is de wereld er na een vervelende periode van aanpassing toch veiliger op geworden.

Wij deden vroeger ook alles gewoon 'met het handje' en dit ging op zich prima, maar leidde er wel toe dat we dus liever gingen voor TLS certificaten van 3 jaar of langer. De enige reden waarom we geen LetsEncrypt gebruikten is omdat we niet wisten hoe en niemand er zin in had om het uit te zoeken. In ons geval was de 'schop onder de kont' gewoon dat iemand zei dat we het gewoon moesten doen, maar nu we het hebben omgezet is het toch wel ideaal dat het gewoon automatisch werkt en klaar.

Bijkomend voordeel is dat we nu ook elke testomgeving, hoe pietluttig ook, een TLS certificaat geven (het is immers toch maar een 10s klusje)

[dakathefox]

Even uit interesse: Om wat voor appliances heb je het hier dan?

[Tozz]

Cisco ASAs, A10 loadbalancers, Juniper SRX.

Maar ook 'gewone' servers die bv. gefirewalled zijn of achter 2FA VPN systemen hangen.

En dan hebben we nog ouwe machines die om wat voor reden dan ook niet geupgrade mogen worden waarop tooling dan niet meer werkt.

[CAPSLOCK2000]

Ik vind het maar schijnveiligheid. Als er echt misbruik van gemaakt wordt, is 1 dag al veel te lang. Dan is de schade al geschied. Het is veel belangrijker dat de revocation procedure goed en snel werkt.

Maargoed, kwaad kan het verder ook niet.

Ik ben het met je eens dag 1 dag eigenlijk al te lang is, maar trek een andere conclusie. Ik geloof namelijk niet zo in revocation.

Niet in het minst omdat het in praktijk slecht werkt. De systemen die we hebben, hebben last van storingen en haperingen. Je browser (of andere applicatie) zou zo'n verbinding moeten weigeren, maar de meeste systemen zijn niet zo geconfigureerd omdat het te veel storingen zou opleveren die de gebruiker niet snapt. Het sneue is dat omdat er geen verplichting is er ook weinig drijfveer is om het probleem op te lossen, de meeste mensen hebben er geen last van. Dat is wel vaker het probleem bij beveiliging.

Dat is gelukkig oplosbaar als browsers afspreken dat revocation voortaan verplicht is en overal bij default aan staat, maar dat zou nog wel eens lang kunnen duren, zeker als je verder kijkt dan alleen webbrowsers.

Ieder centraal systeem is eenvoudig aan te vallen, als je 1 zo'n punt uitschakelt of blokkeert hebben heel erg veel mensen daar last van terwijl er niks mis is met hun eigen systeem. Daarom zal er een sterke drang blijven om het uit te schakelen. Ook daar zijn weer oplossingen voor, zoals OCSP-stapling maar dat is maar een lapmiddel dat vooral werkt tegen haperingen, niet tegen een centraal systeem dat langere tijd uitvalt.

Het fijne van een korte verloopdatum is dat het eigenlijk altijd werkt.

Ik ben wel fan van DANE. Dat is een systeem waarmee je informatie over je SSL-certificaten in DNS publiceert. Je kan het op verschillende manieren gebruiken, maar revocation is heel simpel: je haalt het record weg uit DNS (en wacht 1 TTL) en je bent klaar. Het is niet nodig om lijsten bij te houden van certificaten die zijn gerevoked.
DNS is super gedistribueerd en eenvoudig op te schalen waardoor het niet vatbaar is DDOS-aanvallen.
Nog een voordeel is dat iedereen de baas is over z'n eigen domein en dus ook z'n eigen beleid mag maken. Je hebt niks te maken met de revocation-regels van een of andere grote partij die de lijst beheerd.
Ook kun je het zo vaak en zo snel aanpassen als je wil. Iedere paar minuten een vers certificaat is dan realistisch.
Sterker nog, als je het proces automatiseert dan kun je in een oogwenk een nieuw certificaat aanmaken dat je 'on demand' genereert op het moment dat iemand je website bezoekt en direct daarna weer verdwijnt.

[the_stickie]

dns is dan wel zelf niet echt vatbaar voor ddos, 'tis een prima tool voor attack amplification en bijgevolg (d)dos. Grote records vergroten dat probleem.
DANE wordt (nog?) niet breed ondersteund. Vooral browsers ondersteunen het niet.

ik voorzie overigens nog altijd issues met revocation met DANE. ook hier moet de client nog steeds zelf checken of het certificaat nog geldig is en moet een admin de geldigheid ter dege beheren.. Daar komt nog bij dat dns ttl lang niet altijd gerespecteerd wordt.

[Scriptkid]

Dit zal meer te maken hebben met Time to remediate als er een exploit is.

Zoals laatst bij lets encrypt bijvoorbeeld. gelukkig hebben zijn een max van 3 maanden dus na 3 maanden was alles weer opgelost.

Als dit een cert entity was die 5 jaar signed duurt het ook 5 jaar eer alle certificaten zeker vervangen zijn. Ja revocation lijsten zijn mogelijk maar werken niet voor alles en het is nog steeds aan een client om te bepalen of hij dat honoreerd.

Voorbeeld een certificaat voor encryptie wordt vaak de revocation niet van gechecked.

[Argantonis]

Dat is ook precies wat hij zegt.

[--Andre--]

Niet helemaal, een ding is of de autoriteit het certificaat intrekt, ander ding is of de software überhaupt op intrekkingen controleert.

[Argantonis]

Niet helemaal, een ding is of de autoriteit het certificaat intrekt, ander ding is of de software überhaupt op intrekkingen controleert.

GekkePrutser zegt letterlijk "Het is veel belangrijker dat de revocation procedure goed en snel werkt.", dat valt daar gewoon onder vind ik, en de belangrijke partijen zullen dat ook goed doen, en al helemaal als er expliciet een lek is gemeld dan zal dat ruimschoots binnen zo'n termijn van 398 dagen zijn. Dat was het argument van GekkePrutser, dat die kortere termijn schijnveiligheid is omdat het nog steeds veel te lang is.

[Rolfie]

Afgezien je met interne devices it, waarbij je dit voornamelijk handmatig moet doen.

[SuperDre]

Nouja, kwaad kan het wel, namelijk onnodig mensen op kosten jagen.. Precies zoals je het al zegt, die revocatie procedure moet gewoon goed en snel werken.. Want het is precies wat je zegt, een schijnveiligheid, of een certificaat nu 3 maanden geldig is of 3 jaar, maakt in principe helemaal niets uit.

[iRobbery]

Komt letsencrypt (chrome LE sponsor/partner) vast weer ergens ten goede. Ik zou het toch ergens fijn vinden als er een LE alternatief kwam, gesteund door andere (grote) partijen.

[-=bas=-]

Een nieuw certificaat is een nieuwe rekening sturen naar de klant dus je zou verwachten dat certificaatuitgevers er blij mee zouden zijn.
Wat mis ik hier?

[o0Runaljod0o]

Ik koop normaal mijn certificaten voor minimaal 2 jaar, dan hoef ik er vervolgens na de regulieren checks en dergelijke niks meer mee te doen.

Als dit zodadelijk doorzet zal ik bijvoorbeeld eens per jaar onderhoud moeten doen en de certificaten vervangen. Ik denk dat de certificaatuitgevers het achter de schermen ook flink wat meer werk zal opleveren dan dat het ze nu kost.

[readefries]

Waarom zou je dat überhaupt nog handmatig willen doen als het automatisch kan met LetsEncrypt?

[o0Runaljod0o]

De certificaten die ik nodig heb moeten voorzien zijn van EV en dat biedt letsencrypt niet aan.

[RobbieB]

EV-certificaten zijn allang niet meer zo noodzakelijk als ze voor doen komen.

Troy Hunt heeft er een uitgebreid stuk over geschreven: https://www.troyhunt.com/...on-certificates-are-dead/

Het biedt een schijnveiligheid die in veel gevallen gewoon niet meer werkt als intended.

[Reactie gewijzigd door RobbieB op 25 juli 2024 11:39]

[curry684]

De kans dat @o0Runaljod0o zelf die policy heeft bedacht is niet zo groot he, dat zijn in de regel compliance documents van 5 jaar oud. Dan kunnen de IT jongens roepen wat ze wil over die Amerikaan met zijn mening maar in de praktijk is het dan gewoon voorlopig nog EV of niet verzekerd cq bij voorbaat aansprakelijk.

Daarnaast betalen veel bedrijven ook graag voor de verzekerde waarde van certificaten, die bij EV aanmerkelijk hoger is. Voor security is het een wassen neus, voor veel andere zaken niet.

[Reactie gewijzigd door curry684 op 25 juli 2024 11:39]

[Epidemias]

Verzekering/warranty op een certificaat is compleet waardeloos: https://scotthelme.co.uk/...s-rocks-keep-tigers-away/

[o0Runaljod0o]

En je hebt inderdaad volkomen gelijk, ik voer de policy uit in dit geval en maak een deel, maar verzekeringen en verzekeringswaarde daar blijf ik ver van uit de buurt .

[RobbieB]

Maar blind de policy uitvoeren als deze achterhaald is, is een ander probleem by itself en de reden waarom ik zelf uit de financiele wereld ben vertrokken... Vooral omdat er niet geluisterd werd als aangegeven werd dat hun policies achterhaald waren...

[Zebby]

Wij zijn gebonden aan Logius en zij vereisen PKI Overheid, dus helaas.
Standaard geval waar policies achter de feiten aanlopen, maar wel de realiteit.

[readefries]

Oh ja, dat is een ander verhaal. Maar ik begrijp niet dat dit niet te scripten is.

[klakkie.57th]

Een lijst van hoeveel devices wil je waarbij dit niet te scripten is .....

[Bor]

Afhankelijk van de vorm van controle die een issuer hanteert is automatisering zelfs onmogelijk doordat bv een fysieke controle van een identiteitsbewijs nodig is. Daarbij worden certificaten natuurlijk op veel meer devices gebruikt dan alleen webservers waarbij het draaien van een script lang niet altijd mogelijk is.

[Reactie gewijzigd door Bor op 25 juli 2024 11:39]

[xvilo]

Het kost wel moeite om dit geautomatiseerd op te zetten. Daarnaast zal je dan monitoring moeten instellen en dit kan allemaal vaker kapot gaan omdat de certificaten een minder lange levensduur hebben.

[Keypunchie]

Precies.

LE zorgt ervoor dat mensen het goed inrichten, in plaats dat Hans de Beheerder een reminder voor over 2 jaar in zijn agenda zet, in de tussentijd een nieuwe baan vind en het certificaat verloopt.

(En je moet *sowieso* monitoring op je certificaten inrichten, vind ik!)

[Reactie gewijzigd door Keypunchie op 25 juli 2024 11:39]

[Bor]

LE zorgt er vooral voor dat mensen een tool draaien die verlengen automatiseert en hier niet meer naar om kijken. Dat hoeft geen verbetering te zijn. Het is zaak de hele lifecycle van een certificaat / encryptiepaar goed te managen.

[xvilo]

Tuurlijk, maar het geeft wel meer momenten tot falen. Daar doelde ik meer op

[Sander]

Nee hoor er zijn/waren er genoeg die je voor 2 of 3 jaar kon aanvragen, goedkoper en iets minder werk (zeker bij EV certificaten)

[dakathefox]

Nee, dat valt wel mee. Ik werk momenteel aan de ontwikkeling van een SaaS applicatie waarmee je certificaten automatisch kunt issuen, inclusief de monitoring waar jij aan refereert.

[Verwijderd]

Lang leve ACME die het hele proces nagenoeg automatisch doet.

Geef eenmalig het commando --reloadcmd "service nginx restart && service httpd restart" mee, en de webservers worden na hernieuwen van het certificaat herstart. Meer services die herstart moeten worden maak gewoon een bash-script en brouw daar wat in zodat de services allemaal herstart worden.

Je kunt zelfs een check doen in dat bash-script of de nieuwe cert goed uitgerold is en indien dit niet zo is de oude (die je natuurlijk altijd wel backupped) kunt herstellen en automatisch een e-mail naar je stuurt zodat je het handmatig kunt checken.

Moeite kost het dus eigenlijk niet eens meer.

[kevin93w]

Omdat een standaard certificaat voor grote klanten vaak niet voldoende is. Zij willen bijvoorbeeld een gevalideerd certificaat (OV/EV) of een wildcard certificaat. Dit is beide nog niet mogelijk met Let's Encrypt. Daarnaast merk ik dat het gevoel nog wel leeft dat Let's Encrypt ook niet heel professioneel overkomt als je een grote organisatie bent, dat is natuurlijk jammerlijk want in feite zijn de certificaten net zo goed, maar merk desondanks wel dat het zo is.

Edit: Correctie, wildcard wordt wel gesupport.

[Reactie gewijzigd door kevin93w op 25 juli 2024 11:39]

[Keypunchie]

Het gaat hier om certificaten die in de browser gebruikt worden.

Die organisaties die denken dat het ‘niet professioneel’ overkomt, overschatten schier het aantal gebruikers dat de certificaten überhaupt ooit eens bekijkt.

Voor non-browser verkeer zet een beetje instantie een eigen CA op. Goedkoper, sneller en meer controle.

[Reactie gewijzigd door Keypunchie op 25 juli 2024 11:39]

[Cergorach]

Die organisaties die denken dat het ‘niet professioneel’ overkomt, overschatten schier het aantal gebruikers dat de certificaten überhaupt ooit eens bekijkt.

Ligt geheel aan je doelgroep. Als je pampers verkoopt, sure, niemand significant die er naar kijkt. Als je security diensten/consultancy verkoopt ligt dat waarschijnlijk weer heel anders, zeker als je doelgroep qua klanten ook nog eens in een branch zit waar dergelijke certificaten verplicht zijn...

[Keypunchie]

Nou, ik ben actief in een sector waar flink wat wettelijke regels en toezicht is op de informatiebeveiliging.

De managers/budgethouders zijn verstandig genoeg om zich niet met de inhoud te bemoeien.

De beheerders/ontwikkelaars zijn doorgaans allang blij dat iets werkend wordt gekregen, die moet je vaak echt met de haren naar ‘secure’ slepen (dus goed dat de regels/toezicht er is!)

En dan heb je twee soorten security officers/auditors:
- de lijstjesvinkers. Inhoudelijk niet sterk, maar zolang hun lijstje afgevinkt wordt vinden ze het ok. Let’s Encrypt is ‘vinken’ dus ok
- De inhoudelijken. Degenen die snappen waar ze het over hebben. Daar was een paar jaar terug misschien nog wat scepticisme over Lets Encrypt, want nieuw, maar dat is nu wel echt voorbij. Die zien het juist als goed teken, want LE is een teken dat je ook over automatisering van je (security)-processen hebt nagedacht.

Ok, dit is natuurlijk mijn ervaring. Maar eenieder die anno 2020 ‘Lets Encrypt’ niet professioneel vind, heeft wat mij betreft een streepje tegen. Er zijn genoeg argumenten waarom het niet bij jouw organisatie past, maar categorisch is het prima.

[Bor]

Die zien het juist als goed teken, want LE is een teken dat je ook over automatisering van je (security)-processen hebt nagedacht.

Op zich is het dat niet direct. Veel mensen installeren een standaard agent voor de verlenging en kijken hier niet meer naar om. Een goede auditor zal altijd doorvragen en controleren, juist om te zien of je niet te veel op dit soort scripts vertrouwt.

[djkooij]

Doorvragen is een belangrijk punt tijdens een audit. Maar een goede auditor zal dan vooral kijken naar de incidenten voortkomende uit het vertrouwen op je geautomatiseerde processen. Geen of weinig incidenten? Dan mag je prima vertrouwen op dat proces. Zolang alles maar netjes beschreven is met voldoende borgen en controle komt dat wel goed.
Zelf ruim ervaring mee als Security Officer van een Cloud platform (ISO27001/ISO27003/ISAE3402)

[markjanssen]

$klant levert diensten aan CISO's ... we gebruiken gewoon LE-wildcards. Geen enkele browser laat nog groene balkjes of gevalideerde bedrijfsnaam in de url-bar e.d. zien
Nutteloos om EV/OV te gebruiken. Echt niemand let er meer op / weet waar ze 't moeten vinden.

[PhoenixT]

In die sector zou ik het juist een slecht teken vinden als iemand een 2 jaar EV certificaat gebruikt ipv een geautomatiseerd Let’s Encrypt certificaat.

[Bor]

En waarom dan wel? Wat maakt een Let's Encrypt certificaat in jouw ogen veiliger?

[PhoenixT]

Het is vele malen minder lang geldig. Hoe minder lang geldig, hoe veiliger. Het is vrij simpel Als je wilt weten waarom kun je zoeken op waarom certificate revocation “stuk” is in de praktijk en de duur van een certificaat dus enorm belangrijk is.
Ook is EV validatie makkelijk te omzeilen en voegt het niets doe, dat is door onderzoekers al vaak genoeg bewezen (bekend voorbeeld is Stripe Inc in de VS)

[Zebby]

Logius (DigiD) vereist een PKI Overheids certificaat, dus daar gaat het al niet meer. Zo zullen er nog wel meer partijen zijn.

[Keypunchie]

PKI Overheid is wel even wat anders dan een 'publiek' certificaat. Dat is in principe het scenario 'eigen CA', maar dan op schaal.

[curry684]

Letsencrypt ondersteunt wildcards sinds begin 2018 al, is wel iets complexer via DNS om te automatiseren gezien je een wildcard niet via een HTTP postback kan valideren.

[VHware]

Wildcard en multi-domain certificaten zijn gewoon mogelijk bij letsencrypt. Wildcard vereist DNS-verificatie (Let’s Encrypt DNS challenge)

[deadinspace]

Omdat een standaard certificaat voor grote klanten vaak niet voldoende is. Zij willen bijvoorbeeld een gevalideerd certificaat (OV/EV)

Dat heeft voor de meeste situaties weinig zin meer, want geen enkele moderne browser toont nog dat het om een EV-certificaat gaat in de URL-balk. Daarmee is het nut van EV-certificaten voor websites verdwenen (voor zover het er al was).

De EV highlights zijn verdwenen in Chrome 77, Firefox 70, Safari 12, en Edge.

[Reactie gewijzigd door deadinspace op 25 juli 2024 11:39]

[Nss]

Wildcard certificaten zijn er al sinds begin 2018 via Let’s Encrypt.

[markjanssen]

Natuurlijk wel... ik vraag maandelijks vele wildcard-certs aan via Letsencrypt... Volledig automatisch... je moet de validatie echter wel doen via DNS, en je hebt dus een DNS(-dienst) nodig met een API of andere programmeerbare interface, zodat je de juiste records kan aanmaken en verwijderen.

Op mijn github heb ik wat modules staan voor openprovider en transip, de 2 DNS-diensten die ik gebruik, maar er zijn kant-en-klare oplossingen voor alle grote dns-diensten, en bij self-hosted oplossingen als powerdns kan je eventueel ook direct naar de postgres/mysql/sqlite database schrijven.

[Gtoniser]

Leuk dat het te automatiseren is voor jouw specifieke use-case maar de grote meerderheid van domein providers biedt deze mogelijkheid niet. Als ze al een API aanbieden is dit vaak met een enkele sleutel voor het hele account waar je dus alles mee kunt beheren en zijn de API keys niet te scopen naar een specifiek domein. Vanuit security is het nogal onwenselijk om op iedere web server een API key neer te gooien die al je domeinen kan beheren.

[DataGhost]

Is het dan niet eens tijd om over te stappen naar een aanbieder die dat wel doet, jouw huidige aanbieder te bewegen een moderne API te exposen, of zelf een server op te tuigen die requests voor specifieke domeinen afhandelt met de master-API-key zodat je die niet op elke server hoeft te hebben? In plaats daarvan lijk je te blijven hangen in het elke keer handmatig doen. Moet je zelf weten, maar enorm veel admins zijn daar al van teruggekomen met een reden.

[EraYaN]

Dan schop je dus of tegen je domeinprovider aan totdat ze het aanpassen of verhuis je... Die jongens moeten ook maar een moderniseren.

[dakathefox]

Een herkenbaar punt. Ik maak intussen gebruik van een zelf geschreven beta oplossing waarbij het wel mogelijk is om op domein-niveau een API-key te krijgen.

[Reactie gewijzigd door dakathefox op 25 juli 2024 11:39]

[Verwijderd]

Openprovider DNS? Jij durft... Mijn ervaringen met de DNS die ze aanbieden is buitengewoon slecht. De service mag dan wel niks kosten, maar de DNS is langzaam, onbetrouwbaar en zwaar instabiel. Ik vind het verbazingwekkend dat Openprovider daar nog mee weg kan komen, vooral ook omdat de support erop matig is.

Ik ben intussen gestopt met het afnemen van DNS bij ze. In de afgelopen jaren heb ik veel contact gehad met ze, suggesties gedaan zelfs, maar wat er volgde waren zoethoudertjes en loze beloftes. Daar zijn ze goed in trouwens. Er was 1 gast die het wel snapte en die zich ook hard heeft gemaakt voor een betere DNS, maar hij is begin dit jaar ook vertrokken. En daarmee verdween ook mijn hoop op een betere DNS bij Openprovider.

[blinchik]

Ten eerste zijn er toestellen die de automatische procedure van Lets Encrypt niet geimplementeerd hebben (bv. hardware enterprise firewalls, vele embedded devices zoals airco's, prikklokken, whatever).

Ten tweede is (of misschien eerder was) een EV certificaat toch wel wat veiliger dan Lets Encrypt. Je krijgt het certificaat niet zomaar, je krijgt het enkel bij een grondige doorlichting, men neemt echt contact met je op, dus je bent zeker dat je niet zomaar met een "leeg" bedrijf of scammer te maken hebt. Een DV certificaat (van Lets Encrypt) krijg je door gewoon je mail adres of een dns record te verifieren. Als je een CAA record aan je DNS toevoegt waarbij in staat dat je enkel de CA van het EV certificaat mag gebruiken, dan kan er daarbij ook nog eens gezorgd worden dat als er toch een server gehacked wordt en iemand zet een gratis lets encrypt certificaat op die gehackte server, dit certificaat toch niet als trusted wordt aanzien.

Begrijp me niet verkeerd, LE is een goede zaak om http encrypted te maken voor veel partijen. Maar het afschaffen van de groene balk, het verkorten van de certificaatsduur, heeft waarschijnlijk ook wel wat andere doelen dan echt als white-hat 100% voor security te gaan zoals men graag wil laten uitschijnen.

[lenwar]

Ten eerste zijn er toestellen die de automatische procedure van Lets Encrypt niet geimplementeerd hebben (bv. hardware enterprise firewalls, vele embedded devices zoals airco's, prikklokken, whatever).

Er zijn inderdaad legio apparaten die niet een standaard Letsencrypt-module hebben. Echter, zodra je op afstand een certificaat in het apparaat kan laden, is het te scripten. Niet optimaal, maar wel mogelijk. (REST APIs, ssh, enz. enz.)

Ten tweede is (of misschien eerder was) een EV certificaat toch wel wat veiliger dan Lets Encrypt.

Op papier klopt dit deels. Het is al meerdere keren aangetoond dat die EV-controles vaak een wassen neus of papieren tijger zijn. Die telefonische controles of jij jij bent zijn vaak kinderlijk simpel te neppen. Je moet alleen een beetje brutaal zijn. Een KvK-registratie overhandigen is natuurlijk leuk, maar dan moet dat (bijvoorbeeld) Canadese bedrijf wel kunnen achterhalen of dat mooie Nederlandse document echt is of niet. Ik kan zo snel geen voorbeelden vinden, maar er zijn over de jaren heen meerdere tests gedaan en het gebeurde toch vrij vaak dat men onterecht EV-certificaten heeft kunnen krijgen. (al was het maar voor een paar dagen).

Daarnaast voegt die EV alleen wat toe als er op gecontroleerd wordt. Computers zouden dit onderling natuurlijk met een 100% score kunnen doen. (dus interbancaire communicatie ofzo) Maar ik denk dat er niet veel mensen zijn die iedere keer als ze naar www.mijnbank.nl gaan, controleren of er een EV-certificaat achter hangt. Wel of niet https kan ik me nog voorstellen (als mensen dat al doen), maar verder dan dat zullen het er denk ik niet veel zijn.

[blinchik]

Scripten is uiteraard mogelijk, er bestaan zelfs scripts voor Fortigate e.d.

Ik wil echter geen 2FA afzetten om dan vanaf een aparte Linux machine om een certificaat te laten installeren - dat is gewoon te gek voor woorden.

De EV controles die ik bij GlobalSign heb ervaren, gingen erg ver. Het was echt niet zo makkelijk om dit te krijgen, ik werd er ook soms echt brutaal van, maar de controle ging door en men hield het been altijd stijf.

Ja, er zijn tests waar men aan een niet legitiem EV certificaat is geraakt. Je kan een houten deur installeren in een bank of een grote stalen deur. En uiteraard geraak je ook door de stalen deur, alleen is het toch wel een pak moeilijker en zal het heel heleboel criminelen tegenhouden. Maar het feit dat er toch enkele door de stalen deur geraken is geen reden om een houten deur te installeren.

[lenwar]

Ik wil echter geen 2FA afzetten om dan vanaf een aparte Linux machine om een certificaat te laten installeren - dat is gewoon te gek voor woorden.

Of dat nodig is zal per apparaat verschillen. Ik kan me zo voorstellen dat sommige apparaten een 'alles of niets' hebben met 2FA. Andere zullen wat flexibeler zijn om met APIs bepaalde dingen te kunnen doen en de rest wel met 2FA te dwingen.

Ja, er zijn tests waar men aan een niet legitiem EV certificaat is geraakt. Je kan een houten deur installeren in een bank of een grote stalen deur. En uiteraard geraak je ook door de stalen deur, alleen is het toch wel een pak moeilijker en zal het heel heleboel criminelen tegenhouden. Maar het feit dat er toch enkele door de stalen deur geraken is geen reden om een houten deur te installeren.

Mooie analogie Alleen is in het in de praktijk niet een houten en een stalen deur, maar een stalen deur met of zonder een bordje erop, dat zegt dat een CA zegt dat achter die deur echt die bank zit.

Zolang niemand naar het bordje kijkt voegt het niet zoveel toe En zolang eens in de zoveel tijd dat bordje ook onterecht afgegeven kan worden is de hele waarde ervan natuurlijk discutabel. (onder aan de streep blijft het een kwestie van vertrouwen. Volgens mij heeft GlobalSign wel een goede naam in z'n algemeen. Al zullen daar uiteraard ook dingen mis gaan, want mensenwerk )

[blinchik]

Zolang niemand naar het bordje kijkt voegt het niet zoveel toe

Sorry maar dat vind ik toch een compleet van de pot gerukte redenering hoor :-)

Rode lichten staan er ook om gevaar aan te duiden. Als een groot deel door het rood rijdt, dan is het tijd voor grotere rode lichten, niet om ze af te schaffen. Of met die redenering zou je ook de "deceptive site ahead" van Chrome of Firefox kunnen weghalen. Als iedereen toch op "doorgaan" klikt, waarom zou je dan die waarschuwing tonen?

Nee, het kon zeker geen kwaad en was voor de eindgebruiker een makkelijke manier om iets te controleren, en je kon het ook makkelijk aan de eindgebruiker uitleggen. Dat kan toch niet slecht zijn?

[lenwar]

(ik schreef niet dat ze afgeschaft moeten worden??)

Je maakt precies m'n punt. Als iedereen de verkeerslichten negeert kan je ze of weglaten (gelijkwaardige kruisingen maken) of iets beters verzinnen (grotere lichten/slagbomen/flitsers/watdanook), want anders zijn ze gedegradeerd tot mislukte straatversiering. Als iedereen klakkeloos doorklikt naar de 'deceptive site', dan heeft het blijkbaar onvoldoende nut en moet er wat anders/beters worden bedacht.

Hetzelfde voor de EV-certificaten. Als we er vanuit gaan dat ze foutloos worden uitgegeven dus dat de certificaten daadwerkelijk doen waarvoor ze bedoeld zijn. En dat de eindgebruiker kan controleren dat hij 'echt met bedrijf XYZ' aan het praten is, dan kan dat natuurlijk best handig zijn. (Dat je echt met bank praat enzo)

Echter: Als echt serieus niemand daar ook maar aandacht aan besteed heeft het 0.0 nut om daar moeite in te steken. Het is leuk voor het bedrijf, nog leuker voor de CA, maar zolang er niks mee gebeurd zegt het niks. Ik ben persoonlijk ook van mening dat de EV-certificaten veel meer zichtbaarder moeten worden in plaats van steeds onzichtbaarder wat internetverkenners nu doen.

Ik zie op dit moment niet het verschil tussen ing.nl/particulier/enz.html en img.nl/particulier/enz.html als ik vluchtig naar de adresbalk kijk, en de site er verder identiek uit ziet. Ik zie alleen een slotje. Eventueel 'https' erbij. Als ik gewend ben dat mijn browser 10x groen knippert met de naag ING Bank N.V. in het midden bij het EV-certificaat (even gechargeerd) dan is de kans groter dat het dan opvalt als ik naar m'n bank denkt te gaan, en hij knippert niet.
Ik zeg niet dat dit flauwe voorbeeld een goede oplossing is, maar nu is het volledig onzichtbaar en voegt het naar mijn mening niks toe zolang gebruikers het niet zelf controleren.

Edit: Aanvulling
In de breedste zin geldt volgens mij altijd: Als je iets doet met een bepaald doel, en je bereikt dat doel niet, moet je wat anders gaan doen om dat doel wel te bereiken (of eventueel je doel aanpassen)
Als het doel van EV certificaten moet zijn dat mensen gaan controleren dat ze met bedrijf ABC aan het praten zijn, dan werkt dat doel op dit moment niet. Als het doel alleen is, dat mensen kunnen controleren dat ze met bedrijf ABC praten, dan hebben ze hun doel bereikt, alleen voegt dat doel wat mij betreft niet zoveel toe als dat kunnen teveel moeite kost of mensen het niet snappen hoe ze het moeten doen.

[Reactie gewijzigd door lenwar op 25 juli 2024 11:39]

[GeroldM]

Als noot: Hier in Paraguay groeit een boomsoort (Curupay) welke harder is dan staal. Ongeveer 150 jaar nadat dit hout is gekapt is de densiteit hetzelfde als nieuw staal.

Onderschat hout dus niet

[PhoenixT]

Jammer dat je denkt dat mensen een andere agenda hebben dan veiligheid. EV is jarenlang echt een scam geweest om veel geld mee te verdienen, en mensen zijn die marketing nog gaan geloven ook. Als je je zo druk maakt om beveiliging dan zijn de gratis (!) 90 dagen LE certificaten veel veiliger.

Dit gaat trouwens over browser certificaten, niet alle encryptie certificaten.

Lees anders eens grondig:

https://www.troyhunt.com/...s-are-really-really-dead/

https://scotthelme.co.uk/...-paper-theyre-written-on/

[blinchik]

Ik ken het artikel van Troy Hunt, maar ben het er zeker niet mee eens.

Vroeger konden we tegen onze mensen zeggen, let altijd op de groene balk voor onze sites, en van de subbedrijven, en zelfs voor je bankzaken. Dat was voor domme eindgebruikers echt wel makkelijk, en daar hebben we ook in het verleden zelf enkele phishing sites mee tegengehouden (!). Een eindgebruiker die ons contacteerde en zei, het ziet er goed uit maar ik zie de groene balk niet. Dat heb ik met nog geen enkele andere oplossing meegemaakt, die ook nog eens zo eenvoudig voor de gebruiker was.

Het "makkelijk" bekomen van EV certificaten is ook anders in mijn beleving. We moesten echt wel moeite doen om een EV certificaat te bekomen. Het was zeker niet "simply buying an EV certificate" zoals Troy Hunt beweert. Men belde je tevens nog eens op op je bedrijfsnummer ook, er waren meerdere controles.

[Korben]

Het "makkelijk" bekomen van EV certificaten is ook anders in mijn beleving. We moesten echt wel moeite doen om een EV certificaat te bekomen.

Dat is inderdaad als je je netjes aan de regels houdt, maar er zijn voldoende voorbeelden waarbij het erg makkelijk is om een EV-certificaat te bemachtigen, en als het makkelijk is om een EV-certificaat te bemachtigen voor een vergelijkbare domeinnaam, dan maakt het niet uit hoe moeilijk het voor jou is.

Het artikel van Troy gaat er voornamelijk over dat omdat alle browsers de 'groene balk' niet meer tonen, de meerwaarde van EV-certificaten is ingestort. Browsersfabrikanten (die, met alle respect, echt wel iets meer data hebben over hoe gebruikers zich gedragen) zagen dat gebruikers niet voorzichtiger waren bij het ontbreken van de groene balk.

Om Scott Helme te quoten:

My problem with this whole aspect of EV certificates is that it places some pretty big requirements directly on the user. The user must first know the domain name of the company they want to visit, the user must then know the legally registered name of the company they want to visit and the user must finally validate that the name and domain are correctly shown by the browser. I'm not a fan of any security mechanism that places a burden on the user and I'm really not a fan of any security mechanisms that depends on the user behaving in the 'correct' way for it to work.

[Keypunchie]

De oplossing voor phishing bij bankzaken is alleen op een andere manier gevonden. In plaats van een gegeneraliseerde browser, een 'site-specifieke' browser. We noemen het 'app'.

Die kun je een eigen truststore meegeven, waardoor je helemaal geen EV nodig hebt, maar een volledig zelf beheerde trust-chain, met een certificaat specfiek voor de organisatie, dienst of zelfs gebruiker. Een- of tweezijdige authenticatie.

En je bent niet afhankelijk van een gebruiker die wel/niet een groene balk ziet: Het moet altijd een 100% match zijn, anders dan weigert de app en hangt de gebruiker al snel met de klantenservice aan de lijn (bij MitM-aanvallen, bvb).

(Er wordt intussen meer via 'apps' gebankierd dan via websites en als het aan de banken ligt, gaat het nog meer die kant op).

[Reactie gewijzigd door Keypunchie op 25 juli 2024 11:39]

[Bor]

Een scam zelfs? Dat een EV certificaat inmiddels minder nuttig is doordat policies niet goed nageleefd worden en browserfabrikanten hebben besloten zaken niet meer duidelijk zichtbaar te maken maakt iet nog geen scam. Of heb je daar hard bewijs van?

[Tozz]

Leg me even uit hoe ik een LetsEncrypt certificaat automatisch installeer op een Cisco ASA of een willekeurig ander professioneel netwerk apparaat? Dat gaat meestal niet. Tel daarbij op dat klanten ook nogal eens spelen met .htaccess achtige oplossingen waardoor /acme-challenge/ URLs worden afgevangen bijvoorbeeld.

Het is een gezeik.

[PhoenixT]

Termineren die apparaten de TLS verbinding en maken ze een nieuwe aan? Want dit gaat enkel over browser certificaten, niet alle certificaten. Hoe dan ook, alles kun je automatiseren, daarvoor ben je toch ook Cisco klant?

[lenwar]

Ik denk dat het op de meeste apparaten prima mogelijk is, alleen zal er iets voor gescript moeten worden. De meeste apparaten voor zakelijk gebruik zijn prima op afstand te beheren met REST APIs of ssh-achtige constructies.

Voor een Cisco ASA weet ik het niet, maar ik heb zelf (in de privésfeer) meerdere apparaten zelf gescript. Met behulp van de DNS Challenge kan je zo'n beetje ieder certificaat aanmaken en ophalen voor je domein (ook die je alleen in je eigen LAN gebruikt. Dus zonder publieke DNS-entries). (( effectief wordt er dan alleen gecontroleerd of jij het domein beheerd )). DNS Challenge heeft uiteraard wat eisen (effectief terplekke een DNS-entry aanmaken) , maar daar zouden denk ik de meeste DNS-providers wel iets op kunnen bedenken.
Effectief maak je dan je certificaten op het ene apparaat en kopieer/verplaats je ze naar het apparaat dat ze nodig heeft. (Privé heb ik o.a. m'n Unifi Manager, AdGuardHome (die op m'n unifi router draait), mailserver, Plex server, en allerlei andere kleine tools met een web interface op Letsencrypt certificaten draaien, waar dus geen formele plugins voor zijn (en dus ook niet hoef te prutten met reverse proxies e.d.))

Er was een module die de Cisco ASA ondersteunde net de REST API van het apparaat praatte, maar die werkt niet meer omdat die module gebruik maakte van TLS-SNI01 module van LetsEncrypt.
https://github.com/chrismarget/certbot-asa

Op de github van die module staat beschreven hoe die werkte (high-level). Ik kan me niet voorstellen dat iemand die handig is in scripten (in elk geval handiger dan ik ben) dit niet zou kunnen doen, al moet je in een zakelijke omgeving natuurlijk uitkijken voor 'inhuis-oplossingen'.

[Tozz]

Ik denk dat de praktijk inderdaad wat lastiger is. Al is het maar omdat je misschien niet wilt dat al je management interfaces vanaf 1 'TLS config doos' bereikbaar zijn. Of omdat er apparatuur op klant locaties hangt waar je alleen met 2-factor VPN verbindingen bij kunt.

Hoe het ook zij.. Ookal zijn er oplossingen voor.. 1 jarige certificaten kosten gewoon aanzienlijk meer tijd terwijl ik het voordeel vanuit security oogpunt niet zie.

[kamerplant]

Dat laatste kan worden opgelost door een reverse proxy te gebruiken met als doel het managen van HTTPS verkeer, inclusief automatische renewal.
Maar je hebt wel gelijk, het automatiseren is een hobbel. Maar sooner or later moet die wel worden genomen.

[DanielB]

Ligt aan het type certificaat, je betaalt voor een certificaat met extra checks alvorens uitgifte een stuk meer. Daar waar Let's Encrypt vrij basic is.

[Reactie gewijzigd door DanielB op 25 juli 2024 11:39]

[readefries]

Maar kan dat ook nog steeds niet geautomatiseerd? Ik zou verwachten dat die certificaatboeren ook niet stilzitten...

[Sander]

Ze moeten fysiek valideren dmv een belletje naar nummer in KVK en praten met persoon dat gemachtigd is. dat is harde eis voor het Certificaat en lastig te scripten

[PhoenixT]

In de regels voor certificaat autoriteiten staat dat deze checks niet hoeven worden uitgevoerd iedere keer dat het certificaat wordt vernieuwd, juist om dit te voorkomen. Maakt EV certificaten ook nog nuttelozer, maar dat terzijde.

[readefries]

Écht, dat voelt echt heel erg ouwbollig en niet meer van deze tijd.

[Sander]

Hoe wil je anders met redelijke zekerheid weten dat:
- bedrijf bestaat
- bedrijf zelf het certificaat heeft aangevraagd en door een bevoegd persoon

Email validatie etc gebeurd ook gewoon maar dit is waar de E(xtended) in EV voor staat.

Overigens automatiseert bij Xolphin (geen reclame ben daar toevallig klant), het proces van KVK valideren, mail validatie etc al volledig alleen het belletje is een persoon die dat doet. En dan moet je dus wel net op kantoor zijn 🙈

[Keypunchie]

Het is ook best een farce. Moest onlangs wat certificaten vervangen en alle informatie was out-of-date.

Dus dan bellen ze naar een bedrijf dat 15 minuten voor de vervanging alle bedrijfsgegevens heeft veranderd en krijgen iemand aan de lijn die niet op het KvK-formulier staat en dat is allemaal ok...

En dan was ik nu nog wel zo netjes om niet domweg te claimen aan de telefoon dat ik wel de persoon op het kvk-formulier was.

Het is beter dan niets, maar tegen een gerichte aanval gaat het je niet beschermen.

[Bor]

Waarom is dat ouwbollig en niet meer van deze tijd? Hoe meer en hoe betrouwbaarder de controles voor uitgifte zijn hoe beter te vertrouwen het certificaat en daarmee de waarde. Zo werkt het al sinds jaar en dag. Niet elke CA hanteert dezelfde regels.

[readefries]

Dat iets al jaren zo werkt is geen enkele reden om het te blijven doen.

Als ik het allemaal zo lees (en ook de post van Troy Hunt), voegt een EV certificaat niets toe aan de veiligheid en zorgt het er alleen maar voor dat managers een product kopen waar een verzekering bij inzit. Ik denk niet echt dat dit onderdeel zou moeten zijn van het certificaat, helemaal niet gezien alle nadelen (en daarbij komende risico’s) van een EV certificaat.

[Bor]

Dat iets al jaren zo werkt is geen enkele reden om het te blijven doen.

Wat is in jouw ogen een betere en vooral veiligere oplossing dan fysieke controle (mits juist uitgevoerd)
aangevuld met geautomatiseerde / digitale controles?

Lees ook eens: curry684 in 'nieuws: Google en Mozilla gaan geldigheid tls-certificaten beper...

[readefries]

Ik wil meer zeggen, dat ik me afvraag of de reden waarom de controles nodig zouden zijn wel nodig zijn. Wat voegt het nou echt toe.

[Bor]

Wat het toevoegt is meer zekerheid over eigenaarschap. Dat lijkt mij evident. Wat belet een hacker, eenmaal binnen, om een geautomatiseerd proces te doorlopen? Goede controles geven meer zekerheid, zo simpel is het.

[lenwar]

Even los van hoe betrouwbaar een belletje naar een brutaal persoon en een anderstalig KVK document zijn (is al meerdere keren aangetoond dat men onterecht EV certificaten heeft kunnen bemachtigen al was het maar tijdelijk. Kan zo snel geen voorbeelden vinden overigens, maar het gebeurde wel), zou dit eigenlijk juist iets moeten zijn dat te scripten moet worden.

De KvK/Digid-achtige organisaties zouden eigenlijk daar een opening voor moeten maken. Dus dat ik toestemming kan geven dat CA 123 een validatie mag doen voor bepaalde doeleinden. Dat is dan betrouwbaarder dan (al dan niet vervalste) fotokopietjes van mijn legitimatiebewijs en KVK registraties. Al is het maar omdat ze in Canada enzo niet echt handig in Nederlands zijn.

[blinchik]

Bij een echte controle is het juist de bedoeling dat men controleert of je bedrijf bestaat, of je wel een BTW nummer hebt, of je wel met de persoon te maken hebt die hij beweert te zijn. Je moet een copie van je paspoort en een document met een stempel van de organisatie opsturen, bijvoorbeeld.

Als je dat automatiseert zoals bv LE door middel van een email verificiatie, is de controle dus een pak minder (of eigenlijk bijna niet bestaande).

[dipje2]

We krijgen veel klanten die het zelf willen aanleveren, en voor overheid klanten moet het (bijna) altijd.

Ben ook voorstander van letsencrypt ne we gebruiken het per default, maar we hebben toch een 15-tal certificaten in de monitoring staan omdat het van de klant hun eigen certificaten moeten zijn. En wij zijn maar een klein bedrijfje.

[Rolfie]

Omdat sommige certificaten intern gebruikt worden?
Of handmatig op devices geïmporteerd worden?
Je geen poort 80 open wilt hebben staan? (volgens mij tegenwoordig niet 100% meer noodzakelijk)

[Reactie gewijzigd door Rolfie op 25 juli 2024 11:39]

[lenwar]

Ik heb hier zelf een aantal certificaten intern in gebruik van Letsencrypt. Geen van die apparaten zijn vanaf internet bereikbaar. Je kan met een DNS challenge, zo'n beetje ieder certificaat krijgen dat je wilt, en die alleen in je lokale netwerk beschikbaar maken. (effectief wordt er alleen gecontroleerd of jij het domein beheerd)

Als een apparaat niet gescript een nieuw certificaat kan krijgen houdt het inderdaad een beetje op. Echter kunnen volgens mij de meeste (in elk geval zakelijke) apparaten wel via een API of ssh-sessie één en ander regelen.

[GieltjE]

Lets Encrypt ondersteund ook geen revocation

[deadinspace]

Let's Encrypt ondersteunt zeker wel revocation.

Dat niet alleen, een LE certificaat waarvan de private key is gelekt intrekken is zelfs verplicht volgens de gebruikersovereenkomst:

... revoking certificates that correspond to compromised private keys is an important practice, and is required by Let’s Encrypt’s Subscriber Agreement.

[SleutelMan]

Niet alleen daar, dat geldt zo’n beetje voor alle CA’s. Komt voort uit industriebrede regels, zie https://cabforum.org/wp-c...rowser-Forum-BR-1.7.0.pdf en dan sectie 4.9.1

[mrcreatech]

Ik werk zelf in de tv wereld, waar LetsEncrypt in veel gevallen nog niet wordt ondersteunt (lees: devices uit het jaar kruik, die al jaren geen updates hebben gehad). Daar zit je vast aan de grotere uitgevers als DigiCert en GlobalSign.

[deadinspace]

Ik werk zelf in de tv wereld, waar LetsEncrypt in veel gevallen nog niet wordt ondersteunt

Weet je dat zeker?

Let's Encrypt certificaten zijn cross-signed door het root certificate van IdenTrust, een Certificate Authority opgericht door banken (geen grap). Dat certificate stamt uit 2000, en zit in veel trust stores.

Dit is precies hoe Let's Encrypt relatief snel van de grond kon komen, zonder te hoeven wachten tot hun eigen root certificate (dat overigens ook alweer uit 2015 stamt) overal vertrouwd is.

Is dus misschien wel de moeite om eens te controleren of LE certificaten echt niet ondersteund worden...

[mrcreatech]

In het geval van sommige televisies zitten er nog weer wat haken en ogen aan hoe de Chain of Trust wordt ondersteund. Op de verkeerde manier; namelijk dat ze alle certificaten uit de chain moeten accepteren om een valide verbinding op te kunnen zetten. Dus totaal niet hoe de Chain of Trust zou moeten werken.

Overigens heb ik niet eerder naar de root van LetsEncrypt gekeken, is inderdaad wel iets om eens mee te spelen. Momenteel kiezen we voor DigiCert, waarbij we televisies tot ~2012 minimaal kunnen supporten.

[mrcreatech]

Followup --> Philips televisies ondersteunen deze root niet volgens hun documentatie

[Bensimpel]

Moeten ze wel genoeg mensen hebben om die rekeningen te kunnen sturen, in feite moeten ze nu opeens dubbel zo veel mensen in personeel hebben, wat weer meer overhead kosten met zich mee brengen (Je moet die mensen ook weer ondersteunen met HR en ICT). Een rekening sturen an sich is niet zo moeilijk, maar de admin en sales daarintegen weer wel. Je moet ook weer mensen gaan opleiden hierin.

Het is niet simpel, we huren we eventjes 400 (random nummer) mensen in. Dan moet daar natuurlijk ook weer plaats voor zijn. Kantoorpand huren, infra regelen en noem maar op. Dan snap ik wel dat ze hier niet al te blij mee zijn. Onder de streep zullen ze zelfs waarschijnlijk maar een marginale extra winst pakken.

[PhoenixT]

De ironie is dat CA werk (ja, ook EV “validatie”) voor 99% geautomatiseerd is. Doe niet net alsof ze nu 2x zoveel mensen moeten aannemen. Die certificaten worden niet in het bos bij maanlicht gesmeed door elfjes.

[turbojet80s]

Ik snap wel dat ze hier niet blij mee zijn. Ik koop ongeveer 100 certificaten die 2 jaar geldig zijn per 2 jaar. Als je ze voor 2 jaar koopt krijg je 40÷ korting. Ik denk dat 90÷ van de certificaten nu vervangen gaan worden door let's encrypt certificaten. Aan mij gaan ze nu dus minder verdienen en dat is niet hun schuld, maar de schuld van Apple, Google en Mozilla.

[Cergorach]

dat is niet hun schuld, maar de schuld van Apple, Google en Mozilla.

Nee, dat is niet hun schuld, dat is jou schuld. Je bent opeens minder lui... ;-)

[Niet Henk]

Het maakt de stap naar een gratis certificaatprovider (lees LetsEncrypt) kleiner.

Als ik ofwel geautomatiseerd certificaten via LetsEncrypt kan opzetten en daar een dagje bezig mee ben met alles testen, of gewoon een bedrag neertel om 4 jaar goed te zitten bij een vertrouwd bedrijf, dan kan ik me die laatste keuze goed voorstellen.

Als je echter elk jaar moet vernieuwen, dan klinkt automatiseren ineens een stukje aantrekkelijker.

[GekkePrutser]

Je betaalt die certificaten toch al per jaar, maar nu moeten ze daar dus elk jaar ook wat voor doen

[SuperDre]

Nee, je betaalt doorsnee die certificaten per keer dat je ze aanschaft/vernieuwd.

[mgizmo]

Geldt dit ook voor interne CA's ?

[Tozz]

Dat lijkt mij wel, er is technisch namelijk geen verschil. Het enige verschil is dat je de 'interne CA' in je root certificates hebt opgenomen met de hand, in plaats van dat de browser dat lijstje al voor je heeft gevuld.

[mgizmo]

Klopt, maar ze kunnen het ook beperken tot de lijst aan CA's die ze zelf opvoeren ;-)

[Luc45]

Nee, dit geldt in ieder geval bij Chrome en Safari alleen voor publiekelijk vertrouwde CA's, bij Firefox heb ik hier niks over kunnen vinden. Het lijkt op zich wel logisch als zij hier ook in meegaan.

Enforce publicly trusted TLS server certificates have a
lifetime of 398 days or less, if they are issued on or after
2020-09-01.

https://chromium.googleso...1b23f6aa43c6a4e8e627de784

This change will affect only TLS server certificates issued from the Root CAs preinstalled with iOS, iPadOS, macOS, watchOS, and tvOS.

https://support.apple.com/en-us/HT211025

[Bor]

Zoals nu bekent geldt dit voor alle certificaten die de browsers voorgeschoteld krijgen waarbij er geen onderscheid wordt gemaakt op basis van oorsprong.

[maartend]

Ok. Waarom 398 dagen? Waarom niet 400? Of 365?

[DaanHetEendje]

Het idee is één jaar plus een maand om het te verlengen. Geautomatiseerde systemen verlengen de certificaten veelal zodra bekend is dat ze over 30/31 dagen verlopen.

Er zijn twee/drie dagen speling toegevoegd om te voorkomen dat een nieuw certificaat nog net een paar uur ongeldig is.

[maartend]

Duidelijk, bedankt

[WietsedeVries]

Mijn gok is dat die 2/3 extra dagen vrij specifiek zijn:

• 1 jaar: 365 dagen
• + schrikkeldag
• + 1 maand: 31 dagen (zodat je met een maand automatisch verlengen, maar 1 keer per jaar verlengt)
• + 1 time zone marge dag

[xares]

Ik kan niet vinden of dit ook voor al uitgegeven certificaten gaat gelden? Of alleen voor nieuwe certificaten?

[dakathefox]

Enforce publicly trusted TLS server certificates have a lifetime of 398 days or less, if they are issued on or after 2020-09-01.

Alleen voor nieuwe dus.

[Orion64]

Prettig dat ik voor mijn website gebruik maak van Let's Encrypt. Elke drie maanden een nieuw certificaat. No need to worry...

[Bor]

Het nadeel is dat Let'sEncrypt niet alle soorten certificaten aanbiedt en daardoor niet altijd bruikbaar is.

[VHware]

En welke soorten certificaten mis je dan? Certificaten met 1 common name (standaard), maar ook SAN-certificaten, multi-domain en wildcard-certificaten zijn mogelijk.

[lappro]

Soms heb je een certificaat nodig van een specifieke PKI authoriteit, bv de PKI Overheidscertificaten die verplicht zijn wanneer je DigiD op je site wilt implementeren.

En soms is een EV certificaat nog vereist, wat ook niet met LE kan. Dit zal waarschijnlijk wel een uitstervend ras certificaten zijn, maar voorlopig moet je wat.

[Bor]

OV/EV zijn bijvoorbeeld beide niet mogelijk bij Let's Encrypt. Tot nog niet zo lang geleden kon je ook geen wildcard certificaat aanvragen (hoewel die dingen op zich al niet zo slim zijn uit beveiligingsoogpunt).

[Sfynx]

Wat is er precies onveiliger aan een wildcard certificaat?

[Bor]

Dat is niet zo lastig voor te stellen. Een compromise van slechts één certificaat brengt direct meerdere servers in gevaar en maakt het mogelijk om alles onder een domein aan te bieden op basis van dat ene compromised certificaat dus ook bv passwordreset.domain.nl, hr.domain.nl, webmail.domain.nl etc.

Zie bijvoorbeeld: The Risks In Wildcard Certificates

[Reactie gewijzigd door Bor op 25 juli 2024 11:39]

[GieltjE]

Toch zijn ze soms brood nodig, we hebben waslijsten aan subdomeinen en we hebben gemerkt dat o.a. Chrome soms ineens breekt als er van een sub domein naar het hoofd domein gesurft word en daar een ander certificaat geldig is.

[Sfynx]

Dat is niet zo lastig voor te stellen. Een compromise van slechts één certificaat brengt direct meerdere servers in gevaar

Dus als ik het goed begrijp zijn wildcard certificaten onveiliger als deze qua domeinnaam overlappen met certificaten op andere servers. Gelukkig gebruik ik ze eigenlijk nooit op die manier, ik vind ze vooral nuttig als je een website hebt waarbij gebruikers hun eigen subdomein kunnen kiezen, of bijvoorbeeld op een ontwikkelserver waar je willekeurige sites wil kunnen aanmaken die wel TLS versleuteld moeten zijn. We lanceren bijvoorbeeld per pull request in GitHub een unieke website om mee te testen, dat kan je met Let's Encrypt zonder wildcard certificaat precies 50 keer doen in een week op hetzelfde hoofddomein en dan heb je een probleem.
Daar gebruik ik dan een uniek hoofdddomein voor welke ik nergens anders gebruik, en dat certificaat staat dan ook op een enkele plek, dat lijkt me dan prima.

[Reactie gewijzigd door Sfynx op 25 juli 2024 11:39]

[Rolfie]

Leuk voor een publieke webserver, echter er zijn een hoop devices die dit niet ondersteunen of als mogelijkheid hebben.

[lenwar]

Met DNS challange kan je ieder certificaat voor je domein aanvragen dat je wilt. Het doelapparaat hoeft niet met internet te praten en de naam op het certificaat hoeft op internet bekend te zijn. Alleen de domeinnaam zelf hoeft op internet bekend te zijn.

Ik heb privé allerlei certificaten in m'n LAN voor o.a. Plex, Home Assistant, Unifi Manager, enz. enz. Allemaal dingen die niet op internet toegankelijk zijn. De betreffende DNS-entries leven alleen in m'n thuisnetwerkje. Teven ook zaken als m'n mailserver (geen webserver dus) heeft een LE-certificaat.

[Rolfie]

Mits je DNS geautomatiseerd kan en mag updaten.
Waar ook bepaalde risico's aanzitten.

[lenwar]

Dat geldt in principe voor alles wat je volledig automatiseert op het internet. Echter is automatische DNS-provisioning wel goed uitgedokterd ondertussen. (Het is voor een aantal vormen van cloud-provisioning zelfs noodzakelijk om te kunnen)
De meeste grote DNS-providers hebben er APIs voor. Zelfs voor tools als dnsmasq en bind zijn (REST) APIs beschikbaar.

Het kunnen is het probleem niet. Veiligheid is dat goed uitgewerkt moet worden. Mogen is veelal een procedureel iets.

[VHware]

Betreft devices: Niet native misschien, maar valt (extern) te programmeren / scripten lijkt me. Aanvragen/renewen kan op een server en dan kan je de key/certificate files gewoon gebruiken...

[Rolfie]

Hangt ook allemaal weer van het device af, waarbij mogelijk met een firmware upgrade je aanpassingen moet doen.
En je iemand moet hebben, die dit kan scripten. Bij sommige devices kan dit gemakkelijker dan bij andere.

Maar het hangt er weer van je device af, of het mogelijk is.

[SuperDre]

En vertel, wat is het voordeel dat je certificaat maar 3 maanden geldig is?

[lenwar]

Technisch maakt het uiteraard niet uit.

Procedureel en administratief heeft het zeker voordelen:
- Mocht het certificaat om welke reden dan ook niet goed uitgegeven zijn, dan is de geldigheid korter (hoe korter het dan geldig is, hoe beter) - Idealiter zou je misschien zelfs maar een maand of een twee weken geldigheid moeten hebben.
- Het stimuleert geautomatiseerde verwerking van de certificaten (niet een procedure die iedere drie jaar door een nieuwe admin uitgevoerd moet worden op basis van documentatie van twee versies terug op die ene webtool die niemand echt goed kent)

Uiteraard kan je voor beiden volkomen terecht stellen dat er ook andere oplossingen zijn. Dit duwt in elk geval een bepaalde richting op.

[SuperDre]

Waarom zou een certificaat uberhaupt moeten kunnen verlopen? zolang het maar in te trekken is.

[lenwar]

Om verschillende redenen:
- Je client perse de lijst van ingetrokken certificaten controleren. Je internetverkenner doet dit wel, maar doet je e-mailprogramma dit, of willekeurige andere software? Ik zou het niet weten. Het feit dat ze het 'zouden moeten' doen is een ander verhaal.

- Er veranderd continu best een boel als het gaat om versleutelingstechnologie. Tot niet al te lang geleden werden de meeste certificaten ondertekend met SHA-1. Dit is ondertussen niet meer veilig. Alles moet nu SHA-256 (of meer) worden ondertekend.
Dan zou je kunnen zeggen: "We trekken alle SHA-1 certificaten in per die en die datum". Aangezien we mensen zijn gaat dit natuurlijk in de praktijk hartstikke mis. Heel veel diensten zullen dan ineens niet meer werken na die datum.
In plaats daarvan werden certificaten op een gegeven moment alleen nog maar SHA256 ondertekend, en de rest stierf een natuurlijke dood.

- Een bedrijf stopt ermee. Neemt niet de moeite om z'n certificaat te laten opheffen (denkt er niet aan, geen zin in, mag niet van de curator want kost geld (manuren)). Een ander bedrijf krijgt drie maanden later dezelfde domeinnaam. Maakt een certificaat en dan zijn er ineens twee geldige niet verlopen certificaten.

- Je sleutel en het certificaat worden gestolen zonder dat de eigenaar dat doorheeft. Met alleen de sleutel kan je 'dief' niets, want hij beheerd het domein niet, maar hij heeft nu wel een werkend certificaat dat tot in den einde der tijden geldig is totdat iemand er achter komt dat het is gestolen en het ingetrokken wordt

- Uiteraard zit er ook een commercieel belang bij de verkopers van certificaten. Bij bijvoorbeeld LetsEncrypt is dat natuurlijk niet het geval (gratis dienst). Zij propageren heel nadrukkelijk dat kort-levende certificaten veiliger zijn om onder andere de redenen hierboven.

Zo zijn er nog meer redenen te bedenken. Je hoeft het er uiteraard niet mee eens te zijn, maar dit is de theorie en uitvoering van het principe. Ik snap je redenatie overigens wel helemaal, maar dit vereist dat alle bovenstaande zaken waterdicht zijn afgevangen, en dan is het praktischer dat die dingen gewoon verlopen en eens in de zoveel tijd vervangen moeten worden.

[FrostyPeet]

Certificaten vervangen is toch voornamelijk scripts draaien voor zo'n certificaat uitgever? De eerste keer zullen ze wel meer werk hebben met betrekking tot controle van een persoon of bedrijf, rekening innen enzo. Vervolgens elke x jaar opnieuw een factuurtje sturen.

[Rolfie]

Behalve voor devices denk hierbij aan printers, management interfaces, appliances.
Eigenlijk alle interne webservers, die niet toegankelijk zijn vanaf het Internet.

En laatst had ik toch echt een webserver waarbij de renewal van Let's Encrypt niet gedaan was.

[PhoenixT]

Dit gaat niet over alle certificaten! Enkel browser certificaten.

[Rolfie]

Je bedoelt certificaten de embedded web servers op printers, remote management devices, appliances?
Die gebruiken allemaal https admin interfaces en dus een certificaat.

[lenwar]

Ik heb zelf meerdere appliances voorzien van LE-certificaten. Allemaal geautomatiseerd. Met DNS Challange kan je ieder certificaat dat je wilt aanvragen, zolang je het domein maar beheerd. De DNS-entries hoeven niet publiekelijk toegankelijk te zijn.
De enige eis is, is dat je apparaat gescript een nieuw certificaat kan ontvangen. (veel apparaten hebben wel iets van een API of ssh-toegang). Voor apparaten die dat niet hebben houdt het inderdaad op.

[Rolfie]

Zoals ik het lees, moet het een onderdeel zijn van je TLD. Dus zou dit in je publiek DNS server toegankelijk moeten zijn.

Dit zou inderdaad goed te automatiseren zijn, maar je moet in eens wel iets neerzetten om je publieke DNS servers aanpassingen te automatiseren.

Leuk bij een kleine omgeving, maar al een stuk lastiger bij grote omgevingen. Security technisch moet je ook alles goed regelen. Je kunt eventueel een aparte zone hiervoor weer maken, wat het risico limiteert.

Maar voor bijna al mijn devices, is LE gewoon geen oplossingen. Mijn (HP,canon) printers, ILO interfaces (of drac), Daar genereer ik voornamelijk een CSR op, wie ik weer gebruik bij een CA certificaat request.

Daarom LE is leuk, maar in de meeste omgevingen waar ik kom, wordt dit niet direct gebruikt.

[lenwar]

Stel dat je bedrijf "bedrijf.nl" hebt, en voor je interne netwerk gebruik je "intern.bedrijf.nl" (dus ilo123.intern.bedrijf.nl of printer1.internet.bedrijf.nl) voor al je apparaten, dan zou je dat zo kunnen afvangen. intern.bedrijf.nl bestaat bijvoorbeeld niet op internet, maar alleen in het bedrijfsnetwerk. Het enige collosale nadeel hiervan is, is dat al je interne apparaatnamen in de certiticate-transparancy logs komen die publiek zijn. (ditzelfde probleem heb je dan natuurlijk met de 'klassieke' manier van werken met certificaten)

Voor grotere omgevingen verwacht ik dan ook dat ze intern een eigen CA hebben die middels policies wordt gedistribueerd naar de desktops/servers voor de vertrouwensketen. Je zou dan zelf intern je eigen ACME-implementatie kunnen maken (je 'eigen letsencrypt' zegmaar), zodat je admins niet iedere keer hoeven te prutten met CSRs enzo. Het vereist natuurlijk wel dat je apparaten middels APIs ofzo hun certificaten kunnen bijwerken.

Met DRAC heb ik geen ervaring, maar ik weet dat je op ILOs certificaten kan distribueren zonder te hoeven hannissen met CSRs, dus dat is gewoon mogelijk. Printers heb ik zakelijk nooit beheerd. Mijn Xerox printertje thuis heb ik nooit naar gekeken of ik die met een API kan bijwerken.

[enver63]

Onderstaande vraag is waarschijnlijk off-topic, meer iets voor een GoT topic (wat ik niet heb gevonden).

Als je een LE certificate aanvraagt met DNS challenge voor een apparaat op je eigen netwerk, moeten http clients (meestal browsers) op dat netwerk het apparaat dan benaderen via je eigen DNS?
Ik denk dat, omdat je niet een certificaat kunt gebruiken voor een IP-adres, maar alleen voor een domein-naam. Maar ik heb er niet genoeg verstand van.

[lenwar]

Ja, dat klopt. Ik heb een publiek domein: Laten we zeggen domein.nl, waar ik onder andere mail.domein.nl en www.domein.nl op het internet publiek heb.

Ik heb in m'n 'thuis-DNS-server' dan ook dingen als 'printer.domein.nl' en 'homeassistant.domein.nl'. Die DNS-entries zijn niet bekend op internet, maar wel in m'n eigen netwerk. Ik kan dus thuis gewoon naar homeassistant.domein.nl gaan ipv 192.123.123.123.

(stuur even een PB als je er meer over wil weten)

[aikebah]

En laatst had ik toch echt een webserver waarbij de renewal van Let's Encrypt niet gedaan was.

Waar je door Let's Encrypt ook volautomatisch en bijtijds over geïnformeerd wordt, dus ik zeg: kan niet veel beter worden.

[Belgar]

Het is vervelend voor de klanten, maar de CA's moeten zeker niet zeuren. Er zijn al jaren pogingen geweest om revocation etc. sneller en veiliger te krijgen en de meeste CA's vinden alles teveel moeite.

Als GOOGLE meer moeite wil doen voor de veiligheid van hun klanten dan de bedrijven wiens werk het zou moeten zijn dan moet je toch ook echt naar jezelf kijken.

[lenwar]

De CAs zien natuurlijk een deuk in hun businessmodel geslagen worden. Koop een certificaat voor 15% minder (voor twee jaar). Wij hebben net zo veel werk aan jou gehad (namelijk 0.0, omdat de klant zelf z'n CSR bestandje moet uploaden), hebben meer geld van je op dit moment, en we kunnen je voor twee jaar aan ons klantenbestand toevoegen Leuk voor de statistiekjes.

Ook bij EV-certificaten hoeven ze niks 'meer' te doen voor één jaar of twee jaar geldigheid.

[joost00719]

Zal dit dan ook voor localhost debugging certificaten gelden?

[dakathefox]

Nee, het gaat om public certificates.