Apple-browsers gaan tls-certificaten weigeren die meer dan een jaar geldig zijn

Apple heeft besloten om in zijn Safari-browsers tls-certificaten die langer dan dertien maanden geldig zijn, vanaf september niet meer te accepteren. Vanaf dan mogen tls-certificaten een geldigheid hebben van maximaal 398 dagen.

Apple heeft de beslissing nog niet openbaar gepresenteerd, maar deed de aankondiging woensdag op een besloten bijeenkomst van onder meer browsermakers in de Slowaakse hoofdstad Bratislava, meldt Digicert. Op die bijeenkomst, CA/Browser, zei Apple dat de regel in september ingaat. Daarmee lijkt het een maatregel die voor Safari in komende versies van iOS en macOS gaat gelden.

Apple neemt de maatregel volgens een woordvoerder op CA/Browser om gebruikers te beschermen. Als een tls-certificaat wordt gestolen, is de periode dat misbruik mogelijk is, korter als een browser hem binnen een jaar niet meer accepteert. Google had die maatregel eerder voorgesteld in het CA/B Forum, maar toen bleek een meerderheid van de leden tegen te zijn.

De maatregel van Apple geldt voor certificaten die worden aangevraagd na 1 september van dit jaar, zodat websitebeheerders de tijd hebben om zich aan te passen. Veel sites maken gebruik van Let's Encrypt, dat standaard negentig dagen hanteert.

Reacties (143)

[mjtdevries]

Apple neemt de maatregel volgens een woordvoerder op CA/Browser om gebruikers te beschermen. Als een tls-certificaat wordt gestolen, is de periode dat misbruik mogelijk is, korter als een browser hem binnen een jaar niet meer accepteert. Google had die maatregel eerder voorgesteld in het CA/B Forum, maar toen bleek een meerderheid van de leden tegen te zijn.

Beetje zorgwekkend dat Apple in zijn eentje de rest wil dicteren hoe certificaten gebruikt moeten worden. Ga dan eens met de leden in het CA/B Forum praten waarom ze tegen zijn.

Sowieso is dit natuurlijk een belachelijk slechte oplossing tegen gestolen certificaten.
Alsof een jaar niet erg is.

We hebben toch al revocation lists? En als die om een bepaalde reden niet werken voor gestolen certificaten dan moet je een proces maken dat wel werkt.
Maar niet zo'n fake-oplossing als dit.

[Reactie gewijzigd door mjtdevries op 23 juli 2024 01:13]

[enzozus]

Misschien dat er ergens iets kwijtgeraakt is in de interpretatie. Voor zover ik begrijp is het doel om de "doorloop" van certificaten te versnellen, wat allerlei voordelen heeft:

• Kans is groter dat het geautomatiseerd wordt, zodat er geen certificaten blijven slingeren in mailboxen, harddisks, en git repositories van developers.
• Het wordt minder praktisch om het certificaat te cachen / te hardcoden in clients, wat vervangen makkelijker maakt en misbruik moeilijker.
• Aan revocation kleven vaak allerlei politieke bezwaren. Als je iets revoked dan veroorzaak je mogelijk extra werk / problemen voor iemand. Als de geldigheid korter wordt verkleint dat de hoeveelheid werk waar je iemand mee opzadelt (certificaten wisselen komt immers regelmatig voor) en maakt het minder schadelijk om in twijfelgevallen gewoon te wachten tot het certificaat ongeldig wordt.
• Op deze manier verklein je de tijd die een aanvaller heeft om aanvallen uit te voeren waar hij geen doorgaande toegang tot je server voor nodig heeft maar wel een certificaat. Dat maakt die niche van aanvallen minder praktisch en dus minder de moeite waard om tijd in te steken.

[Reactie gewijzigd door enzozus op 23 juli 2024 01:13]

[mjtdevries]

Fijn dat je inhoudelijk reageert om het punt waar het om gaat.

Kans is groter dat het geautomatiseerd wordt, zodat er geen certificaten blijven slingeren in mailboxen, harddisks, en git repositories van developers.

De certificaten waarmee ik gewerkt heb waren allemaal een jaar geldig en dat was allemaal handwerk.
Ik denk dat de kans uitermate klein is dat die tweejaarlijkse nu ineens geautomatiseerd worden.

Het wordt minder praktisch om het certificaat te cachen / te hardcoden in clients, wat vervangen makkelijker maakt en misbruik moeilijker.

Certificaten die zeer lange tijd gecached worden? Kun je daar wat meer toelichting op geven?
Ik ken geen voorbeelden van clients die certificaten hardcoded hebben. Natuurlijk een no-no voor coders, maar ik kan me voorstellen dat het bestaat. Maar ja, die hebben geen last van deze maatregel.

Aan revocation kleven vaak allerlei politieke bezwaren. Als je iets revoked dan veroorzaak je mogelijk extra werk / problemen voor iemand

Niet revoken van een gestolen certificaat veroorzaakt ook extra werk / problemen voor iemand. (op gebied van compliance/security).
Bij diefstal van een certificaat mag je er toch vanuit gaan dat de eigenaar van het certificaat zelf de opdracht geeft voor revoken.

[dakathefox]

De certificaten waarmee ik gewerkt heb waren allemaal een jaar geldig en dat was allemaal handwerk.
Ik denk dat de kans uitermate klein is dat die tweejaarlijkse nu ineens geautomatiseerd worden.

Alle grote aanbieders van certificaten ondersteunen het gebruik van het Acme Protocol. Ze kunnen het dus wel automatiseren. Het is dus meer de vraag hoe jouw leverancier het dus al aanbiedt. Ik kan het in ieder geval wel aanbieden.

[mjtdevries]

Nee, het is meer de vraag of je dat als afnemer wel wilt, en of je software die het certificaat gebruikt het wel kan.
En hoeveel tijd is het om dat uit te zoeken en grondig te testen, vs het eenmaal per jaar voor zo'n certificaat uit te voeren ipv eenmaal per 2 jaar.
Die business case veranderd erg weinig als je van 2 jaar naar 1 jaar gaat.

[dakathefox]

Uiteindelijk hebben we er allemaal baat bij dat het internet een zo veilig mogelijke plek is, zeker als het gaat om bedrijfskritische applicaties. Ook als afnemer zou je dat willen nastreven lijkt me. Een 2-jarig SSL Certificaat past daar niet bij vind ik persoonlijk.

[MarkII]

Als je vindt dat een 2-jarig certificaat daar niet bij past, zou je ook moeten vinden dat een 1-jarig certificaat
daar niet bij past.
Wanneer is het internet dan zo veilig mogelijk? Met een 1-dags certificaat?

[Ayporos]

Nee joh, al het internet verkeer moet door Steve Job's firewall gaan.

Ik sluit me erbij aan dat een 1-jarige geldigheid totaal geen verschil maakt ten opzichte van een 2-jarige geldigheid.

Als we het over internet security hebben dan is een jaar tijd een eeuwigheid. NIKS op het internet duurt langer dan een jaar. Internetbankieren is een kwestie van seconden. Iemand's gehele PC rippen en al zijn persoonlijke informatie buitmaken is binnen een dag gepiept. Een hele website rippen is binnen een dag gepiept. Een geïnfecteerde webhost kan normaliter binnen een week meer dan de helft van de frequente bezoekers treffen.... zelfs de dankest memes zijn binnen een jaar wel uitgeleefd.

Er is gewoon NIKS wat je gaat bereiken of veranderen door van 2 jaar naar 1 jaar te gaan.

[freaky]

Wat jij vind, zonder onderbouwing, is met alle respect van geen waarde.

Een certificaat dat niet uitlekt is na 10 jaar nog veilig.

En certificaat dat meteen uitlekt, maar een jaar geldig is en niet revoked wordt (of wel revoked maar waar niet op gecontroleerd wordt) is een jaar lang onveilig.

Belangrijkste punt, er is een forum hiervoor. Apple lijdt heftig aan grootheidswaanzin. Niet dat dat nieuws is , arrogantie is ze nooit onbekend geweest.

[StefSybo]

Certificaten die zeer lange tijd gecached worden? Kun je daar wat meer toelichting op geven?
Ik ken geen voorbeelden van clients die certificaten hardcoded hebben. Natuurlijk een no-no voor coders, maar ik kan me voorstellen dat het bestaat. Maar ja, die hebben geen last van deze maatregel.

Dat hardcoden zie je vaak in (kleine) embedded systemen, denk Arduino/ESP8266. Vanwege beperkingen in resources (vooral grootte van RAM en/of flash) kunnen/willen deze vaak niet de volledige validatie doen en dan hebben ze bijvoorbeeld de fingerprint van het certificaat hardcoded opgenomen om toch nog iets te controleren. Als dat op deze manier minder aantrekkelijk wordt is dat toch een win. In nieuwere microcontrollers is een volledige implementatie van TLS vaak geen probleem meer.

[--Andre--]

Als zo'n embedded systeem SNI ondersteund kun je hier een apart subdomein voor maken.

[torp]

Beetje zorgwekkend dat Apple in zijn eentje de rest wil dicteren hoe certificaten gebruikt moeten worden. Ga dan eens met de leden in het CA/B Forum praten waarom ze tegen zijn.

Hoezo “dicteren”? Ze bedienen hun eigen gebruikers. Waarom zouden ze moeten wachten op de rest?

[Chinco]

Ho ho, laten ze dan ook een apart internet bouwen. Consensus over iets dat we met z’n allen delen is absoluut beter. Die club van browserbouwers is er blijkbaar niet voor niets.

Als Google dit soort dingen doet (bv. www. weglaten) is dat niet minder erg of erger als Apple dit doet, dit dicteren van hoe het web eruit moet zien. Het IE 6 tijdperk willen we nooit weer terug.

[mjtdevries]

Omdat standarisatie erg handig is, en we in het verleden al genoeg last hebben gehad van grote bedrijven die hun eigen zin doordrijven.

[asing]

Ik snap het ook niet. Het probleem van gestolen certificaten is al opgelost in het systeem zelf. Dat heeft de Certificate Revocation List (CRL). Het enige wat je hoeft te doen is je certificaat bij de uitgever intrekken.

Het enige wat Apple nu doet is een dictaat opleggen dat iedereen maar jaarlijks de certificaten moet verversen. Persoonlijk heb ik er geen last van, ik gebruik tegenwoordig Let's Encrypt.

[sprankel]

Wat het dicteren betreft wat een standaard betreft, dat is een issue dat veel verder gaat dan dit. In het begin deed iedereen zijn eigen ding maar dan had je 5 verschillende tekstverwerkers en geen enkele kon het document lezen van een andere, met name door de komst van het internet werd iedereen verplicht een common ground te zoeken, al dan niet door een standaard af te kondigen of via opensource.

Om dan beslissingen te nemen krijg je een commite waar alle partijen samen zitten om een beslissing te krijgen. Maar wie bepaald wie er in het commite zit? En wat doe je als het commite niet overeenkomt of trage en zelfs domme beslissingen neemt? Wat als ik als burger foert zeg tegen hun standaard? Wat als een niet aangesloten bedrijf foert zegt? Of wat als het commite er niet meer is? Wie heeft er meer stemrecht, wie heeft er veto recht?

Vaak zie je 2 dingen gebeuren:
Niemand heeft de macht om iets te forceren waardoor het ofwel heel traag beweegt, IPV6, SMTP, FTP maar ook nieuwe zaken zoals Bitcoin
Ofwel doet iedereen gewoon zijn goesting, zie ook USB C

Indien er dominante spelers zijn die de markt kunnen forceren waar dominante browsers ideaal voor zijn, dan gaat het goed vooruit en worden zaken snel aangepakt;
Soms gaat het wel is serieus de mist in zoals iexplore 6 maar er gaan meer en meer stemmen op om chrome tot nieuwe iexplore 6 te bekronen. Als je het over switches hebt dan kom je bij Cisco uit.

Meestal valt het bij de dominante spelers niet op omdat hun wijzigingen vaak vrij snel vertaald worden als de nieuwe standaard, het is eigenlijk pas als dat niet gebeurd dat er serieuze problemen ontstaan.

Nu kan je namen gaan opnoemen en allerhande voorbeelden gaan uispitten maar het is simpel, heel de industrie is er schuldig aan, de vraag is hoe los je dat op, iets waar niemand echt een antwoord op lijkt te hebben.

[Reactie gewijzigd door sprankel op 23 juli 2024 01:13]

[Het.Draakje]

Je zou het ook beetje zorgwekkend kunnen vinden dat Apple in zijn eentje heeft beslist om de audioport van een telefoon te verwijderen. Of geen computers met BluRay disks te maken. Of....

Beetje net als Google die besluit om bepaalde delen van de url niet meer te tonen.

Apple heeft een visie. En dan nemen ze gewoon het voortouw. Als Apple vindt dat certificaten langer dan 1 jaar niet bepaald bijdragen aan de veiligheid, dan gaan ze dat gewoon niet ondersteunen. En als een deel van het CA/B forum daar bezwaar tegen hebben, dan hoeft Apple zich daar voor hun eigen browser zich niets van aan te trekken.

Het is aan de makers van web-sites om daarin te volgen of niet. Maar als je Safari gebruikers (ook) als klant wil, dan weet je nu al dat over een half jaar nieuwe certificaten korter dan een jaar geldig mogen zijn.

[Het.Draakje]

Ze maken helemaal niets stuk van anderen. Ze maken alleen maar dat (bedraad) koptelefoons op hun device niet werken. Dus waar jij die analogie vandaan haalt?

[SqyD]

Ik heb hier wat dubbele gevoelens bij. Ik adviseer al jaren om geen certificaten met meerjarige geldigheid omdat het zowel het risico op misbruik vergroot maar ook omdat het de kans vergroot dat de organisatie vergeet hoe dit proces werkt. Dus wat mij betreft een goeie zaak maar wel vreemd dat Apple dit nu lijkt af te dwingen. Die horen hier niet over te gaan. Aan de andere kant zijn we ze nog steeds dankbaar door de doodsteek van Flash.

Op zich is Let's Encrypt een prima idee maar het zou eigenlijk niet nodig moeten zijn. De meeste gebruikers van Let's Encrypt kunnen die paar tientjes per jaar prima missen. En dat uurtje per jaar dat je nodig hebt om je beveiliging en betrouwbaarheid van al je communicatie met de rest van de wereld te regelen zou ook niet het probleem moeten zijn. Toch gaat het heel vaak fout. Meestal omdat het vernieuwen van een certificaat ergens op een todo stapel van een voormalig systeembeheerder is blijven liggen.

Op zich is het vernieuwen van een certificaat helemaal niet moeilijk maar toch komt dit vrijwel altijd op het bord van een toch al overbeladen IT team terecht. Ik raad altijd aan om het neer te leggen bij een finance or compliancy afdeling binnen een groot bedrijf. Die zijn veel beter in het op tijd doorlopen van bepaalde administratieve processen. Dat doen ze immers ook met alle andere belastingen, vergunningen en andere zaken die volgens wet en/of regelgeving goed geregeld moeten zijn. Ook het vernieuwen van domain namen e.d. is meestal beter belegd bij dit soort administratief ingestelde teams.

[PatrickH89]

Automatiseren van zaken die prima te automatiseren zijn zou je niet handmatig moeten doen. Computers zijn nog beter in het uitvoeren van taken op de geplande datum dan een menselijk team. Zo kun je van alle automatisering zeggen dat het 'eigenlijk niet nodig zou moeten zijn'. Het verbetert de consistentie en het kost minder tijd, dat is altijd genoeg reden om te automatiseren, hoe complex de handeling ook is.

[SqyD]

Prima punt als het gaat om een simpele "is dit certificaat inderdaad voor de host en domein waar het voor aangevraagd wordt?" check. Een extended validation check is als het goed niet te automatiseren en nog steeds niet heel veel werk.

[PatrickH89]

Uiteraard, maar je gaf aan dat iets als Let's Encrypt niet nodig zou moeten zijn en daar ben ik het dus niet mee eens. Automatiseren waar het kan. Let's Encrypt is ook niet geschikt voor certificaten met extended validation.

[rijnsoft]

Voor het aanvragen van sommige certificaten, waarmee je vroeger zo'n groen vakje met de bedrijfsnaam erin kon krijgen, moet je best wel wat doen. Dan is het handig als je dit maar eens in de twee jaar hoeft te doen, i.p.v. nu eens per jaar. En de 2-jaar geldende certificaten zullen waarschijnlijk gewoon verkocht blijven worden. Iemand die niet oplet koopt dan dus een kat in de zak. Zou die zijn geld na een jaar terug krijgen?

[Reactie gewijzigd door rijnsoft op 23 juli 2024 01:13]

[Askerian]

Of je hebt er vrede mee dat alleen Safari users niet meer bij je site kunnen. Gezien het marktaandeel van die browser (minder dan IE volgens deze site) lijkt me dat je dat risico wel aan wilt gaan als een tweejarig certificaat zoveel tijd en moeite zou schelen.. Ik hoop niet dat Apple hiermee een trend zet.

[rijnsoft]

Als je de grafiek verandert van 'Desktop/Laptop' naar 'Mobile' stijgt het percentage opeens naar 27.28%. Dat kun je niet zo makkelijk negeren als 3.60%. En ook dat willen de meesten waarschijnlijk niet negeren. Het zou bijvoorbeeld betekenen dat je zo'n 4% van je online advertentie-uitgaven in het water gooit. Dat kan snel over vele duizenden Euros gaan.

[Reactie gewijzigd door rijnsoft op 23 juli 2024 01:13]

[Askerian]

Excuus, daar had ik inderdaad geen rekening mee gehouden.
In dat geval wordt het wel interessant om je geld na een jaar terug te vragen als je per ongeluk een langer geldend certificaat hebt gekocht. Zou dat kunnen? Ik vond dat namelijk wel een interessante gedachte van je.

[Chinco]

Niet na een jaar, het certificaat is überhaupt niet geldig volgens Apple!

[Intrepidity]

Het is niet alsof 2 jaar geldige certificaten die je in het verleden gekocht hebt ineens niet geldig meer zijn, het gaat om 2 jaar geldige certificaten uitgegeven ná een bepaalde datum die in de toekomst ligt. Dus dat is dan gewoon een kwestie van hier in de toekomst rekening mee houden.

[--Andre--]

Het is dus een afweging, wie is je doelgroep, zit die op mobiel?

[Stroper]

In het artikel staat
Google had die maatregel eerder voorgesteld in het CA/B Forum, maar toen bleek een meerderheid van de leden tegen te zijn.

Het lijkt mij dus aannemelijk dat Chrome snel zal volgen.

[Marcel3X]

Safari is by far, de grootste mobiele browser op tablet, volgens mij is het mobiele marktaandeel belangrijker dan 't desktop aandeel...

[Reactie gewijzigd door Marcel3X op 23 juli 2024 01:13]

[Capital_G]

Hoe kan Safari de grootste mobiele browser zijn als iOS maar ~13% (op basis van een snelle google search) marktaandeel heeft. Volgens mij gaat je statistiek over alle iOS devices, wat een stuk aannemelijker klinkt.

[Timo002]

Het verschilt vast per bron waar je naar kijkt, maar hier zie je dat iOS in NL groter is dan Android.

https://deviceatlas.com/d...e/country/nl/type/os_name

[Aaargh!]

Er is een verschil tussen marktaandeel in aantal verkochte devices, en marktaandeel op het web. Ik denk dat het verschil makkelijk te verklaren is.

• iOS devices zijn relatief duur, iemand die z'n telefoon of tablet bijna niet gebruikt zal niet zo'n duur apparaat aanschaffen.
• Niet-smartphones zijn er nauwelijks meer. Mensen die alleen willen bellen kopen over het algemeen een goedkope Android telefoon maar gebruiken deze nooit voor iets anders dan bellen en SMSen.
• Er zullen veel goedkope Android tablets verkocht worden die vervolgens ongebruikt in een la verdwijnen. Android op tablets is gewoon nooit van de grond gekomen, mensen kopen een Android tablet (want goedkoop) en komen dan tot de conclusie dat de UX waardeloos is en gebruiken 'm niet meer.

[PPie]

Hier liggen 2 zaken aan ten grondslag:

• Het verschil tussen installed base en market share
• Het daadwerkelijk gebruiken van een device. iOS gebruikers zijn actiever dan Android gebruikers, veel mensen kopen een Android telefoon en gebruiken deze dan niet als een smartphone

[Groningerkoek]

https://gs.statcounter.co...et-share/mobile/worldwide

Chrome bijna 3x zo vaak gebruikt.

[monojack]

Nee hoor.

Safari 52.93%
Chrome 32.42%

https://gs.statcounter.co...et-share/tablet/worldwide

[Groningerkoek]

Ik en anderen hebben het verkeerd gelezen, en dat komt vooral door zijn vreemde keuze om "mobiele browsers op tablet" te gebruiken. Alsof er ook niet mobiele browsers voor tablets bestaan...

[Euronitwit]

Daar vond hij blijkbaar het hoogste percentage in het voordeel van Apple.

Selectieve interpretatie heet dat.

[darkfader]

De standaard browser kun je op iPadOS ook niet instellen. Dus na het klikken van een link uit andere app krijg je toch weer die Safari.

[kdhoe]

Je ziet ook dat het marktaandeel van Safari op tablets daalt sinds sept 2019. Dat komt omdat vanaf iPadOS 13 Safari zich identificeert als desktop browser. De standaard user agent op mijn iPad is bv Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_4)...

[Moosjes]

uhm, dat lijkt mij heel sterk. Volgens mij is Chrome op mobiel een stuk groter

[monojack]

niet op tablet

[mjz2cool]

Dat lijkt me sterk, het marktaandeel van de iPhone is een stuk kleiner dan dat van Android telefoons, dan kan Safari nooit een groter marktaandeel hebben. Dan zal Chrome een stuk groter marktaandeel hebben.

[monojack]

Hij zei tablet, niet smartphone

[mjz2cool]

Mijn fout.

[elmariachi]

Wat met iPad's? Die worden misschien ook als mobiele toestellen gezien...

[mjz2cool]

Klopt, ik had het verkeerd gelezen, en niet aan iPads gedacht.

[Hulliee]

Als je het filter op die grafiek weghaalt, is het 18% aandeel voor Safari. Da’s significant.

[xdizzy12]

Dat hangt ernstig af van welke doelgroep je hebt. Ik heb gewerkt in de detailhandel voor dingen zoals camera's en tevens maatwerk geleverd voor scholen, en in beide segmenten is Safari op sommige dagen aan kop met Chrome. Dus reken maar dat we die beide ondersteunen.

[Donstil]

Markt veranderd, nog niet zo lang geleden waren wildcards ook nog drie jaar geldig. Dat is nu al twee en zal wel 1 worden. Geen verkeerde zet als je het mij zou vragen.

[bertware]

Die certificaten hebben ook minder waarde tegenwoordig, dat groen vakje met bedrijfsnaam wordt vaak niet eens meer getoond. Het hele concept van "een groen slotje dus veilig" slaat ook enkel op de transport layer, en die extended validation certificaten die de bredrijfsnaam tonen kunnen nog eens extra misleidend zijn.

In one demonstration, researcher incorporated a business called "Stripe, Inc." in Kentucky and showed that browsers display it similarly to how they display certificate of payment processor "Stripe, Inc." incorporated in Delaware.

(bron)

Interessant leesvoer: https://www.troyhunt.com/...on-certificates-are-dead/

[Blokker_1999]

De benodigde controles zijn gelukkig bij meerder CA's wel gewoon 2 of 3 jaar geldig waardoor je een nieuw certificaat kunt aanvragen zonder je opnieuw te laten controleren.

[CAPSLOCK2000]

Voor het aanvragen van sommige certificaten, waarmee je vroeger zo'n groen vakje met de bedrijfsnaam erin kon krijgen, moet je best wel wat doen. Dan is het handig als je dit maar eens in de twee jaar hoeft te doen, i.p.v. nu eens per jaar. En de 2-jaar geldende certificaten zullen waarschijnlijk gewoon verkocht blijven worden. Iemand die niet oplet koopt dan dus een kat in de zak. Zou die zijn geld na een jaar terug krijgen?

Maar wat is de meerwaarde van dat groene vakje nu echt? In theorie kunnen mensen daar zien wie de eigenaar van een site is, maar hoeveel mensen doen dat nu echt? Van de mensen die het doen, hoeveel zijn er in staat die informatie ook echt te beoordelen? Is "Cooperatieve Rabobank U.A." echt de Nederlandse bank? Moet dat U.A. er bij of niet of is het dan opeens uit buitenlandse bank?
Op die vragen is wel een antwoord, maar hoeveel mensen doen daar in praktijk iets mee?

[rijnsoft]

En veel browsers hebben dat groene vakje, met de bedrijfsnaam, niet eens meer. Bijvoorbeeld Chrome en Firefox. Ik denk ook dat hierdoor deze certificaten niet meer echt zinvol zijn, maar mijn klanten willen ze toch.
Uiteindelijk blijft het natuurlijk wel een manier om zeker te zijn dat je op de site van de "Cooperatieve Rabobank U.A." zit, iemand anders mag die naam immers niet gebruiken. Dat wordt best streng gehandhaafd. Daarom kosten die certificaten meer en is het meer werk om ze te verkrijgen.

[CAPSLOCK2000]

Voor de echt techneuten werkt het tot op zekere hoogte, maar dan nog blijft het lastig.
Hoeveel mensen weten dat dit bedrijf officieel "Cooperative Rabobank U.A." heet?
Als er nu "Collectief Rabo A.U." had gestaan, hoeveel mensen hadden dan begrepen dat dit niet de bank is?

Of minder fictief, hoeveel mensen weten het verschil tussen "Ajax R", "Ajax AFC", en "Ajax CC"?
Dat zijn allemaal echte merken (respectievelijk een schoonmaakmiddel, een voetbalclub en een brandblusser)?

[rijnsoft]

De namen in de certificaten voor die eerste twee Ajaxen zouden zoiets worden als: "COLGATE-PALMOLIVE CO CL", "AFC Ajax N.V.", de derde kan ik niet vinden. Het moet de bedrijfsnaam zijn, geen handelsnaam of merknaam. Echt veel helpt het inderdaad niet, maar bijvoorbeeld in Duitsland zijn deze certificaten nog best populair.

[Heimdallr]

Hmm, ik lees een aantal maal dat Let's Encrypt als het gouden ei wordt gezien, maar voor veel organisaties is Let's Encrypt dat niet. OV, EV en persoonlijke certificaten worden niet door Let's Encrypt uitgegeven. Daarnaast is er geen Let's Encrypt ondersteuning op met Windows platform met native tools van Microsoft.

* Heimdallr beheert verschillende sites met EV certificaten die gebruik maken van IIS.

[Capital_G]

EV's zijn gewoon een mechaniek voor het upsellen van certificaten. Het voegt geen voordeel toe voor de eindgebruiker, puur voor meer inkomsten voor de certificaat boeren. Dan kies ik liever voor Let's Encrypt.

[Blokker_1999]

Daar ga ik niet mee akkoord. Certificaten kunnen voor 2 dingen gebruikt worden:
- Beveiligen van data
- Bevestigen met wie je communiceert

Voor HTTPS heb je in de eerste instantie het eerste nodig. Daarmee weet je met zekerheid dat tussen jouw en het eindpunt waarmee jij communiceert niemand de communicatie kan afluisteren. Maar het zegt spijtig genoeg niets over met wie je aan het communiceren bent. Heb je bijvoorbeeld iemand die DNS hijacking doet of zit je op een publiek access point en doet iemand een intercept van het verkeer dan kan men alsnog alles inkijken. Daar komen EV certificaten van pas. Hiermee is niet alleen de communicatie beveiligd, maar heb je ook bevestiging met wie je communiceert. Toch net even handiger als je inlogt bij je bank dat je zeker bent dat je communiceert met je bank.

[WCA]

Behalve dat browsers tegenwoordig niets meer weergeven om te verifieren dat ik daadwerkelijk bij bijvoorbeeld de Rabobank verbonden ben. Dat groene labeltje met de naam is er simpelweg niet meer.

[mg794613]

Heel veel mensen in dit topic vergeten dat de browser niet de enige plek is voor certificaten.
De EV is weldegelijk een extra waarde voor sommige b2b diensten.

[Sfynx]

Heb je bijvoorbeeld iemand die DNS hijacking doet of zit je op een publiek access point en doet iemand een intercept van het verkeer dan kan men alsnog alles inkijken. Daar komen EV certificaten van pas. Hiermee is niet alleen de communicatie beveiligd, maar heb je ook bevestiging met wie je communiceert. Toch net even handiger als je inlogt bij je bank dat je zeker bent dat je communiceert met je bank.

Een domein-gevalideerd certificaat beschermt daar ook gewoon tegen, want die hacker kan niet zomaar een publiek vertrouwd certificaat regelen voor een willekeurige domeinnaam.

[kozue]

EV certificaten zijn toch redelijk nutteloos tegenwoordig. En waarom maakt het wat uit dat MS geen native tools voor LE maakt? Je kunt toch gewoon de tools van LE installeren?

[Sysosmaster]

Native tools van Microsoft ondersteunen ook enkel Microsoft certificaat en self signed. Als je er een van iemand anders wilt gebruiken heb je al meer tooling nodig.

Overigens op https://letsencrypt.org/docs/client-options/ zijn er genoeg tools die werken met IIS. Bekijk de IIS sectie maar eens. EV,OV en persoonlijke certificaten zijn al langer niet meer toevoegend in waarde tenzij je een specifiek waarde toevoegend doel er mee hebt.

Persoonlijke certs werken beter als ze niet van een CA afkomen. (Internal CA of PGP/GPG)
Validatie moet je namelijk toch zelf doen.

[Anoniem: 120539]

Best vreemd.
Kennelijk is het wel acceptabel dat (bijvoorbeeld) een 3 maanden oud certificaat nog 9 maanden wordt misbruikt.
Veel malware-zaken zijn natuurlijk hit-and-run; geen langlopende zaken, maar opzetten, net zo lang misbruiken totdat je betrapt bent of dat er mitigaties zijn, en hup, door naar de volgende site / het volgende certificaat om te misbruiken.

M.a.w.: serieus misbruik wordt hier niet mee ondervangen.

[lilmonkey]

Heeft niet zo veel met 'acceptabel' te maken, het is gewoon niet praktisch om certificaten slechts, zeg, één dag geldig te laten zijn.

[Jerie]

het is gewoon niet praktisch om certificaten slechts, zeg, één dag geldig te laten zijn.

Dat hangt van het doel af. In deze context niet, nee.

[flabber]

Kennelijk is het wel acceptabel dat (bijvoorbeeld) een 3 maanden oud certificaat nog 9 maanden wordt misbruikt.

Als van een certificaat bekend is dat het is gecompromiteerd, dan zijn er andere methoden: CRL en OCSP.
Dat wil niet zeggen dat er niet allerlei haken en ogen aan de technieken zitten, maar daar gaat dit stuk niet over.

Deze maatregel houdt in dat certificaten die een langere geldigheid hebben per definitie niet worden niet geaccepteerd, los van het feit of ze eventueel misbruikt worden.
Een (self-signed) certificaat van 10 jaar - wat vroeger echt heel geregeld voor kwam - is dan niet meer mogelijk. En daarmee is misbruik pas echt heel lang mogelijk...

[kozue]

Veel sites maken gebruik van Let's Encrypt, dat standaard negentig dagen hanteert.

Maar die vergelijking slaat nergens op, want LE kun je automatiseren, (de meeste) andere aanbieders niet. Niemand wil handmatig iedere 2 maanden een certificaat updaten. En omdat het voor de meeste bedrijven een handmatig proces is, zijn certificaten van 2 jaar wel zo handig. En dan komt Apple even voor ons bepalen dat we nóg meer werk moeten gaan doen om die handmatig gekochte certificaten te updaten? Gaat nog wel als je 1 site beheert, nauwelijks te doen als je er een heleboel hebt.

En dat terwijl hun argumenten geen hout snijden. Een uitgelekt certificaat is voor 1 maand net zo'n drama als voor 1 jaar. Binnen die maand is zo'n malafide site allang al uit de lucht gehaald.

[PhoenixT]

Waarom stap je niet over naar een CA die automatisering ondersteunt? Klinkt alsof je dat een hoop werk zou schelen.

[Adion]

Zelfs met certificaten die 2 jaar geldig zijn zou je die toch bij het vaststellen van een lek liefst zo snel mogelijk kunnen vervangen door een nieuw certificaat.
Dus zelfs dan kan je maar beter je procedures op orde hebben om een certificaat makkelijk te kunnen vervangen, en of het dan om het jaar of om de 2 jaar is maakt dan ook niet veel meer uit.

[Jan_Klaassen768]

" Veel sites maken gebruik van Let's Encrypt, dat standaard negentig dagen hanteert."

Bron?

[TheSanderZone]

https://letsencrypt.org/docs/faq/

What is the lifetime for Let’s Encrypt certificates? For how long are they valid?
Our certificates are valid for 90 days. You can read about why here.
There is no way to adjust this, there are no exceptions. We recommend automatically renewing your certificates every 60 days.

(overigens geen bron over de statement 'veel sites')

[Reactie gewijzigd door TheSanderZone op 23 juli 2024 01:13]

[Power2All]

Veel sites die er geen geld aan een SSL cert willen uitgeven, kiezen over het algemeen LetsEncrypt.
Sommige pre-made CMS's en cPanel e.d. bieden LetsEncrypt aan via automatisering, dus logisch dat een hele boel sites gewoon LetsEncrypt, of de gratis oplossing van CloudFlare hanteren.

[Cilph]

Ik kies voor Let's Encrypt puur omdat het 1) automatiseerbaar is en 2) niet minder veilig

[fifnih]

Een SSL-certificaat duidt op2 zaken:
- encryptie van de verbinding
- betrouwbaarheid: het geeft een bepaalde zekerheid dat je echt met de juiste partij te maken hebt

Betrouwbaarheid is bij een letsencrypt-certificaat discutabel.
Als je het alleen doet omdat je de verbinding encrypted wilt hebben: top!
Gaat het om betrouwbaarheid dan is letsencrypt misschien niet de beste optie.

[Euronitwit]

Betrouwbaarheid is bij een letsencrypt-certificaat discutabel.
Als je het alleen doet omdat je de verbinding encrypted wilt hebben: top!
Gaat het om betrouwbaarheid dan is letsencrypt misschien niet de beste optie.

Gaarne onderbouwing.

[Blokker_1999]

Certificaten die uitgegeven worden op domeinnaam hebben geen enkele verificatie van wie dat certificaat heeft aangevraagd. En soms is het zelfs mogelijk om de CA te laten denken dat je controle hebt over dat domein terwijl dat niet het geval is. Met een EV certificaat ligt dat een heel stuk moeilijker. Dan moet een aanvaller al in staat zijn om een vertrouwd root certificaat op je machine te krijgen om je te doen denken dat zijn "valse" certificaat toebehoord aan het doelwit, omdat die enkel maar door CAs worden uitgegeven na grondige controle en na het betalen van een hoog bedrag.

[Snake]

Niet waar. Je moet absoluut valideren dat je de eigenaar bent van het domain. https://letsencrypt.org/docs/challenge-types/

[fifnih]

Het zit hem in de mate en wijze van validatie. Gaat letsencrypt op basis van KvK-gegevens periodiek jouw organisatie controleren of de organisatie en de aanvrager wel bestaan? Of ze contact met je kunnen krijgen en of anderen kunnen bevestigen dat jij voor die organisatie certificaten goed mag keuren? Dacht het niet.
Een normale certificatenboer doet dat wel. Er is een reden dat letsencrypt geen EV-certificaten aanbiedt.

[Snake]

Normale certificatenboer doet dat niet.

Enkel bij EV certificaten wordt dat gedaan.

[Henk Poley]

Tsja, de browser makers geven geen speciale aandacht meer aan EV certificaten (t.o.v. 'normale'), want in de praktijk bleek voor bezoekers van een site het weinig toe te voegen.

[Cilph]

betrouwbaarheid: het geeft een bepaalde zekerheid dat je echt met de juiste partij te maken hebt

Iets waar bij normale betaalde SSL certificaten helemaal geen sprake van is. Dan moet je echt richting EV certificaten en de vraag is maar hoeveel dat toevoegt.

[Blokker_1999]

Voor betrouwbaarheid moet je al naar EV certificaten kijken. En zelfs daar zijn uitzonderingen op.

[GateKeaper]

3) gratis

[mOrPhie]

Dat het gratis is klopt natuurlijk, maar net als met andere gratis diensten die hun inkomsten niet uit advertenties halen, doe ik jaarlijks met plezier een donatie.

[The Zep Man]

Volgens deze site zou Let's Encrypt een marktaandeel van 0,1% hebben. Dus 1 op 1000 sites zou het gebruiken.

Zelf vind ik dat best wel laag.

[edit]
Blijkt niet te kloppen. Het was mogelijk 50% (ergens mid-2019).

[Reactie gewijzigd door The Zep Man op 23 juli 2024 01:13]

[Zoop]

cPanel pushed tegenwoordig hun eigen "autossl" certificaten van Sectigo, in sommige gevallen vervangt deze zelfs automatisch LetsEncrypt mocht je dat gebruiken.
LetsEncrypt moet je in ieder geval (zo ver ik weet) altijd zelf handmatig installeren (al zit er wel een kant-en-klaar script ervoor erbij), die cPanel certs zijn er wel al default.

[Jester-NL]

Ik ben niet bekend met cPanel. Wel met DirectAdmin en Plesk, en op die twee platforms is het initieel installeren van een LetsEncrypt minder werk dan wanneer ik een certificaat van (zeg) een Sectigo wil installeren (CSR maken, wachten op validatie, plaatsen van certificaat en eventueel de rest van de keten en ergens onderweg een factuur betalen).
Daarbij komt dat dat Certigo-certificaat een jaar geldig is, en je dan door dezelfde hoepels moet springen.

LE vraagt om wat vinkejes en is vervolgens set & forget. Zodra het certificaat 60 dagen oud is, zal het script op de server proberen om de boel te vernieuwen

[Zoop]

cPanel Sectigo cert werkt precies hetzelfde, vinkje aan, en hup gaan maar (LE AutoSsl moet je nog (eenmalig) installeren met een script), aangezien Plesk van dezelfde eigenaren zijn, kan ik mij voorstellen dat ze daar het zelfde gaan pushen...
https://blog.cpanel.com/lets-talk-autossl-the-updates/
Helpt wellicht ook dat cPanel hun eigen certificaat meer "sterretjes" geeft waardoor LE als slechter overkomt ...

Werkt naar mijn inziens prima, enige "nadeel" is met LE is dat een nieuw certificaat aanvragen je maar x aantal keer per dag mag "proberen" dus als de aanvraag niet helemaal lekker gaat (meestal met ipv6 te maken, of DNS die nog niet helemaal door is), mag je het een dag later nog eens proberen.
Is maar een klein nadeel natuurlijk, moet je spullen gewoon goed ingesteld hebben staan, dan gaat dat gewoon in 1x goed.

[thijsjek]

Daarvoor heb je in cli certbot --dry-run. Test alles behalve de aanmaak van het certificaat.

[joeri1]

Ik heb wat statistieken gevonden: https://trends.builtwith.com/ssl/LetsEncrypt

Edit: Dit was bedoeld op de 'Veel sites maken gebruik van Let's Encrypt'.

[Reactie gewijzigd door joeri1 op 23 juli 2024 01:13]

[The Zep Man]

Een taartdiagram van die site. Let's Encrypt zou gebruikt worden door 56% van alle sites.

[sweebee]

https://letsencrypt.org/d...r-how-long-are-they-valid

[Jan_Klaassen768]

Eens, het gaat mij om het 1e stukje van het statement: "Veel sites maken gebruik van Let's Encrypt'. Zal de volgende keer concreter zijn.

[The Zep Man]

Veel is relatief. Let's Encrypt is niet super populair. "Used by fewer sites, used by medium traffic sites" is de beste vertaling van de grafiek op die pagina.

[edit]
Blijkt niet te kloppen. Het was mogelijk 50% (ergens mid-2019).

[Reactie gewijzigd door The Zep Man op 23 juli 2024 01:13]

[svennd]

200M certificaten is niet "niet super populair";
https://letsencrypt.org/stats/

[mjtdevries]

Een beetje onzinnig getal natuurlijk. Als het allemaal sites van particulieren met 1 pagina zijn omdat brouwers certificaten afdwingen, dan kan je daar niet mee zeggen dat het populair is.

En als je certificaten maar kort geldig zijn dan krijg je ook automatisch hogere getallen dan anderen die standaard een jaar gebruiken.

[Groningerkoek]

Had je even geklikt dan had je gezien dat er ook meer dan 113 Miljoen certificaten nu actief zijn.

[mjtdevries]

Dat bevestigt alleen maar wat ik eerder zei.

[pennywiser]

Oa. Tweakers gebruikt Letsencrypt.

[Step]

https://en.wikipedia.org/wiki/Let's_Encrypt

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

Had je even kunnen googlen...

[Reactie gewijzigd door Step op 23 juli 2024 01:13]

[Jay-v]

Bijvoorbeeld: https://techcrunch.com/20...ow-secures-75-of-the-web/

[Hero of Time]

Lekker voor de zakelijke interne systemen als IT een eigen PKI omgeving heeft. Die heeft wel wat beters te doen dan elk jaar alle certificaten te moeten vernieuwen. Daarbij is de standaard in een enterprise PKI omgeving (iig bij AD CS met templates) de duur van een certificaat minimaal 2 jaar.

Ze kunnen beter wat doen aan certificaten die een gazillion alternative names hebben. De browser die ik zelf standaard gebruik klaagt wel eens dat een site geen geldig certificaat heeft. Ga ik kijken naar de eigenschappen ervan, dan zie ik tientallen namen als alternative opgegeven.

Wil je gebruikers beschermen, doe dat dan daarmee. Niet beheerders pesten en ze meer werk geven. Want effectief bescherm je de gebruiker er echt niet mee. Zoals eerder al is genoemd kan na korte tijd zo'n certificaat gestolen worden en ben je de rest van het jaar alsnog het bokkie. CRLs is daar juist de oplossing voor.

[Bor]

De standaard duur van een certificaat is 1 jaar. Daarbij kan je auto-enrolment doen afhankelijk van het doel van het certificaat.

By default, the lifetime of a certificate that is issued by a Stand-alone Certificate Authority CA is one year.

[Paul]

De standaard die Microsoft hanteert als je het installeert, dat klopt. Maar ik heb nog niet veel bedrijven gezien waar ze niet als één van de allereerste acties een kopie maken van het webserver-template en die 1 veranderen in een 2, of er een 0 achter plakken

[Hero of Time]

Ik heb de afgelopen week een eigen PKI omgeving opgezet op m'n werk en certificaten gemaakt. De machine certificaten die ik kreeg, aan de hand van guides, waren 2 jaar (hoewel ik 3 in de template had gezet, maar dat is een ander dingetje). Ook de webserver certificaten zijn twee jaar. Van eentje moet ik het even controleren want die heb ik met het oorspronkelijke template laten maken.

En let er ook op, ik zeg specifiek 'enterprise', niet stand-alone.

[Euronitwit]

Volgens mij moet je als je LetsEncrypt gebruikt voor elk (sub)domein een eigen certificaat hebben.

[bunnybugs_007]

Volgens mij moet je als je LetsEncrypt gebruikt voor elk (sub)domein een eigen certificaat hebben.

Nee hoor. Ik heb op mijn privé-server 1 LE-cert voor zowel het hoofddomein als alle subs. Het is wel een optie om per sub een eigen cert aan te vragen, maar dit heeft in mijn geval geen meerwaarde.

[WhatsappHack]

Nope. En ze ondersteunen ook wildcard tegenwoordig.

[Henk Poley]

Sinds januari 2018.

[downtime]

Ik mag hopen dat dat alleen geldt voor certificaten die na september 2020 uitgegeven zijn. Anders gaan een boel sites voor Safari-gebruikers op zwart.

[Inproba]

Ja dat staat ook in het artikel:

De maatregel van Apple geldt voor certificaten die worden aangevraagd na 1 september van dit jaar

of uit de bron:

Any certificates issued before Sept. 1, 2020 will still be valid, regardless of the validity period (up to 825 days).

[Reactie gewijzigd door Inproba op 23 juli 2024 01:13]

[Dennism]

Dat staat gewoon in het artikel

De maatregel van Apple geldt voor certificaten die worden aangevraagd na 1 september van dit jaar, zodat websitebeheerders de tijd hebben om zich aan te passen. Veel sites maken gebruik van Let's Encrypt, dat standaard negentig dagen hanteert.

[Metro2002]

Handig voor RDW erkenninghouders. De RDW certificaten zijn namelijk 2 jaar geldig.

[Mattashii]

Gelukkig maakt dat helemaal niet uit

> de RDW ondersteunt het gebruik van Apple producten niet [0]

Daarnaast lijkt het er op dat de RDW-certificaten client-certificaten zijn, en dat heeft heel andere beveiligings-eisen dan een server-certificaat

[0] https://www.rdw.nl/zakeli...ndleiding-rdw-certificaat

[Wolfos]

Je hebt ook Internet Explorer nodig en een schijflade. Denk dat beiden over 10 jaar niet meer bestaan.

[zzzzap]

Het gaat bij Apple om TLS-certificaten, niet om client-certificaten

Edit: Mattashii was mij al voor

[Reactie gewijzigd door zzzzap op 23 juli 2024 01:13]

[Sysosmaster]

Client certificaten kunnen ook gewoon een tls certificaat zijn hoor. Maar ik snap dat je bedoelde dat het gaat om server certificaten

[sweebee]

Wordt ook een keer tijd dat ze dat veranderen, wat omslachtig is die RDW omgeving.