Let's Encrypt kondigt wildcardcertificaten aan

Vanaf januari 2018 verstrekt Let's Encrypt wildcardcertificaten. Volgens de organisatie zal het aanbod helpen bij het streven om het volledige www op https over te laten stappen. Wildcardcertificaten beveiligen meteen verbindingen van alle subdomeinen.

De Let's Encrypt-organisatie claimt veel verzoeken gehad te hebben om wildcardcertificaten te gaan leveren. Dit soort certificaten stelt beheerders in staat een enkel ssl-certificaat en een sleutelpaar voor een domein en alle subdomeinen te gebruiken, wat de implementatie van https eenvoudiger maakt. Let's Encrypt gaat de wildcards gratis verstrekken via het komende api-endpoint voor het acme v2-protocol.

De organisatie verstrekte in juni zijn honderd miljoenste ssl-certificaat sinds het begin van het project eind 2015. Die certificaten beslaan inmiddels 47 miljoen domeinen, waarmee het project een belangrijke bijdrage heeft geleverd aan de groei van het aantal versleutelde verbindingen. Het percentage webpagina's dat geladen wordt via https zou sinds eind 2015 gestegen zijn van 40 tot 58 procent.

Reacties (169)

[The Zep Man]

Dat is geweldig voor flexibel (sub)domeinbeheer. Vanaf dan is er eigenlijk geen reden meer om voor certificaten te betalen, tenzij men extended validation nodig acht of een langere geldigheidsduur wenst.

[Reactie gewijzigd door The Zep Man op 25 juli 2024 12:02]

[Verwijderd]

Er zal vast een reden zijn waarom bedrijven extended validation gebruiken. Een bank met LE zou ik niet vertrouwen.

[The Zep Man]

Er zal vast een reden zijn waarom bedrijven extended validation gebruiken. Een bank met LE zou ik niet vertrouwen.

Op technologisch vlak maakt EV niets uit. Het is een extra attribuut in het certificaat dat ervoor zorgt dat een browser ergens iets groens toont. Ongetrainde gebruikers letten hier niet op. De toegevoegde waarde is dus beperkt, behalve dat het 'professioneel' lijkt.

Voor een EV certificaat moet er in theorie wat meer administratie verzet worden. Dat is het enige verschil waardoor EV certificaten meer vertrouwd zouden moeten worden. Leuk in theorie, maar in de praktijk boeit het geen hond. Je mag al blij zijn als een gebruiker op 'het slotje' let.

[Reactie gewijzigd door The Zep Man op 25 juli 2024 12:02]

[nobraininvolved]

Je hebt helemaal gelijk.
Toch is het 'groene' balkje voor veel bedrijven nou net dat stukje extra's. Dat maakt het namelijk visueel voor klanten en groen betekent per definitie 'doorgaan', dus het geeft klanten een fijn en veilig gevoel.
't is dus meer een marketingdingetje geworden dan een noodzakelijk technisch dingetje.

[bbob]

Het is en blijft een klein groen dingetje en de massa heeft er niets eens verstand van.
Geloof ook niet dat je als website minder verkoopt als je geen groen puntje bij https hebt staan.

Waar ik me eerder zorgen om maak is bijv als een shop zelf creditcards afhandelt en opslaat en niet de payment provider

[Thijsmans]

Ik let er zelf wel op, maar misschien zijn Tweakers niet de meest gemiddelde consument Maar los van de vraag wat bezoekers ervan vinden, wordt wel aangenomen dat zoekmachines SSL-certificaten waarderen. SSL = hogere positie = meer bezoekers = meer bestellingen.

[bbob]

Ik let er zelf wel op, maar misschien zijn Tweakers niet de meest gemiddelde consument Maar los van de vraag wat bezoekers ervan vinden, wordt wel aangenomen dat zoekmachines SSL-certificaten waarderen. SSL = hogere positie = meer bezoekers = meer bestellingen.

Heb nog geen ssl en sta met veel zoekwoorden nog steeds op 1, ssl is voor zoekmachine slechts een klein puntje voor je ranking.
Omzet stijgt nog steeds zonder ssl, maar wie weet wordt het met ssl wel meer, dit jaar eens kijken.

Twekaers is een hele kleine groep die totaal niet de doorsnee consument is en helaas kunnen veel mensen zich hier ook niet inleven in de doorsnee consument die vaak met andere dingen bezig is

[Tha_Butcha]

SSL is toch verplicht voor webwinkels?

[seapip]

Niet als je gebruik maakt van een externe dienst die het betalingsverkeer verzorgd volgens mij.

[Verwijderd]

Fout,
Je slaat NAW gegeven op met koopgedrag, je verzamelt op deze wijze data. Daar draait het om wanneer je wel of geen SSL gaat toepassen.
Even heel zwart wit, maar zelfs een contactform zou als het daar om gaat al tellen..

[i-chat]

...... SSL is toch verplicht voor webwinkels? ...

Niet als je gebruik maakt van een externe dienst die het betalingsverkeer verzorgd volgens mij.

Dat valt nog maar te bezien, Zodra jij adresgegevens verwerkt en/of email adressen, ben je verplicht deze voldoende te beveiligen. Hoe je dit anders dan via ssl zou moeten doen ontgaat me maar ik vermoed dat je de wet hier keihard aan het breken bent. Ik raadt je klanten ook sterk af om zaken met je te doen tot dit is opgelost. privacygevoelige data zoals bestellingen, contact gegevens, en facturen hoor je gewoon netjes te beveiligen zelfs als de daadwerkelijke betaling via een 3rd-party gaat. Dit is echt NOT-DONE

[seapip]

Ja uiteraard is er nog de bescherming van persoonsgegevens wetgeving, ik doelde met mijn reactie vooral op bescherming van betalingsverkeer en de bijpassende info zoals facturen.

De bescherming van persoonsgegevens gaat vooral over de opslag en het informeren van de gebruiker waarvoor de gegevens gebruikt worden. Ik weet niet of hierbij ook daadwerkelijk ssl als een verplichting wordt gezien.

[Tha_Butcha]

Wel dus, ook WBP valt daar dus ook onder.

bron

[fastedje]

De echte kern van het probleem met persoonsgegevens is dat veel bedrijven en instanties deze voor waar aannemen zonder dat ze echt zeker weten dat de rechtspersoon de gegevens heeft aangeleverd. Wordt het niet een tijd dat de overheid smartcards met daarop een private/public key + cert gaat uitgeven? Iedereen mag mijn public key hebben, geen probleem. Nu mag er geen enkel lek zijn van je gegevens, iets wat in de praktijk onhaalbaar is doordat je gegevens op zeer veel plaatsen zijn opgeslagen.

[Rex]

Ik heb het opgezocht. Als je zelf persoonsgegevens (naam, adres, etc) verwerkt, dan moet dat beveiligd zijn. De wet verplicht het gebruik van SSL niet, maar in de praktijk kun je eigenlijk alleen maar met SSL/TLS gebruiken.
Zelfs contact-formulieren waar persoonsgegevens in verwerkt worden moeten beveiligd zijn.

[djwice]

Je weet dat google gepersonaliseerd toch?
Dus dat wat jij als zoekresultaten bij bepaalde zoekwoorden ziet, totaal anders kan zijn dan wat ik zie. En dat mensen die aan jou gerelateerd zijn, een grotere kans hebben meer gelijke resultaten te zien als jij.

Ik ben wel benieuwd welke site je hebt.

[nobraininvolved]

tsja...ik zeg eerlijk, ik ben geen marketeer en vind groen of niet groen zelf helemaal niet interessant, maar ik heb nu bij 2 commerciële bedrijven meegemaakt dat er daadwerkelijk marktonderzoek is gedaan en daar uit kwam dat het voor mensen zeker wel een overweging is om wel/niet van bepaalde sites gebruik te maken.
Op basis daarvan zijn deze certificaten aangeschaft bij die bedrijven.
Daarnaast zijn er ook een onvoorstelbaar aantal managers te vinden die (blijkbaar) kicken op groene balkjes (want dat geeft inzicht in en lijkt erg op de groene smileys uit hun rapportages) die graag een paar honderd euro per jaar extra uitgeven voor het kleurtje.
Vergeet niet...een paar honderd per 1 of 2 jaar is voor een beetje bedrijf verwaarloosbaar. Het vergaderen over en het nemen van de beslissing is vaak (in uren/salaris) duurder dan een paar van die certificaten aanschaffen.

[Kees]

Aan de andere kant, een iphone bijvoorbeeld geeft alleen de groene balk aan. Een EV moet je bedrijfsnaam zijn tegenwoordig, een handelsnaam mag niet meer. In het geval van bijvoorbeeld Tweakers zou dan bovenaan staan '[de Persgroep Online Services B.V.] Tweakers' en op een iphone zou je zelfs alleen maar 'de Persgroep Online Services' in het groen zien zonder indicatie in de URL balk dat je op tweakers zit.

En dat is een van de redenen dat wij hier geen EV gebruiken.

[pietermx]

Comodo hanteert "Handelsnaam (Bedrijfsnaam)", het zou dus bijvoorbeeld "Tweakers.net (de Persgroep Online Services B.V.)" zijn, niet andersom.

Geldt trouwens alleen voor rechtspersonen, bv. bij een eenmanszaak wordt alleen de handelsnaam weergegeven.

[Kees]

Dan overtreed Comodo de regels die begin dit jaar zijn ingegaan en kunnen ze een groot probleem krijgen

Je hebt gelijk, 'Handelsnaam (Statuaire naam)' mag, maar dan zou je alsnog 'Tweakers (de Persgroep Online Services)' krijgen, en dat staat niet bijzonder mooi. De 'groene' balk zou dan in veel gevallen een stuk langer zijn dan de URl zelf.

[Reactie gewijzigd door Kees op 25 juli 2024 12:02]

[PdeBie]

Maar als je als gebruiker naar www.tweakers.net surft en je ziet de site die je wenst, maar op de URL balk staat Tweakers (De Persgroep Online Services). Ik denk niet dat mensen daar over struikelen of het erg vinden.

[Rex]

Wat een gedoe omdat jullie 'de Persgroep Online Services' niet mooi vinden.
Jullie kunnen ook naar de KVK en Tweakers.net BV herinschrijven, en dan daarop de certificaat aanvragen.
Of niet.... Ik denk dat het voor Tweakers helemaal niets uitmaakt of jullie EV gebruiken of niet.

[bbob]

Het hangt denk ik helemaal af van het product waar het om gaat of mensen naar het groene puntje kijken of niet. Wat betreft veel van die onderzoeken, soms zijn ze leuk maar je moet eerst weten hoe zitten de vragen in elkaar.

De enige manier waarop je het zou kunnen testen is grote webshop, ene dag met groen andere dag zonder en dan kijken of er verschil in omzet zit.

Naast groen denk ik dat hoe de website in elkaar zit veel meer invloed heeft op het koopproces. Overzichtelijk, vertrouwd, makkelijk alles vinden, bestellen geeft denk ik meer waarde dan groene balkje.

Wat ik bijv ervaren heb is afschaffen van extra betaalkosten voor creditcard/paypal die 2-3,5% meer kosten als bedrijf toch meer omzet geeft als je ze niet in rekening brengt.

Maar goed die paar honderd euro is leuk voor 1 domein. Heb je een multishop en 15 domeinen praat je al snel over een paar duizend euro en ik twijfel er sterk aan of dat meer winst opbrengt.

[Blokker_1999]

Maar er zijn voldoende mensen die er wel verstand van hebben en het merken als er iets mis gaat. Ik let er bij mijn bank alleszins wel op dat het juiste EV cert er staat.

[Reactie gewijzigd door Blokker_1999 op 25 juli 2024 12:02]

[CAPSLOCK2000]

Je hebt helemaal gelijk.
Toch is het 'groene' balkje voor veel bedrijven nou net dat stukje extra's. Dat maakt het namelijk visueel voor klanten en groen betekent per definitie 'doorgaan', dus het geeft klanten een fijn en veilig gevoel.
't is dus meer een marketingdingetje geworden dan een noodzakelijk technisch dingetje.

Dat is de theorie, maar het is een beetje de vraag hoeveel mensen nou echt ooit naar "het slotje" of "het groen balkje" kijken. Het lijkt er op dat de meeste mensen dat nooit doen. Het is ook wel begrijpelijk, in 999/1000 gevallen is alles in orde. Na een paar honderd keer "voor niks" kijken gaat de bereidheid er flink van af. De kans dat de gebruiker die 1/1000 keer wel kijkt is nogal klein, en als het wel gezien wordt dan weet de gebruiker niet wat er moet gedaan moet worden. De kan is groot dat de gebruiker gewoon verder gaat, want de rekening moet wel worden betaald...

Dat is ook de reden dat moderne browser naast het slotje ook een enorme waarschuwingspagina laten zien en domweg de hele site niet meer laden en het de gebruiker moeilijk maken om de waarschuwing te negeren. Dan nog zijn er zat mensen die alleen weten wat ze moeten doen om de waarschuwing te laten verdwijnen zonder te beseffen waarom zie die waarschuwing krijgen.

[Verwijderd]

Het is dat gebruikers er niet op letten, maar voor die paar die dat wel doen biedt het wel meerwaarde.

Veel sites waar je een mail adres kan aanvragen staan bijvoorbeeld toe dat je [e-mail] kan aanvragen. En de wat simpele CA's sturen blind het ondertekende certificaat naar zo'n mailadres toe.

[hackerhater]

Tjah als dat domein van jouw is, waarom zou je niet het adres admin@ kunnen aanmaken?
Mijn klanten kunnen dat ook bij de domeinen die bij hun website horen.

Bij een klant was dat wel handig om de certs te kunnen vernieuwen. Even het adres aanmaken (had al volledige server beheer, dus een non-issue), cert vernieuwen, op de server zetten en klaar.

[Reactie gewijzigd door hackerhater op 25 juli 2024 12:02]

[totaalgeenhard]

Voor een EV certificaat moet er in theorie wat meer administratie verzet worden. Dat is het enige verschil waardoor EV certificaten meer vertrouwd zouden moeten worden. Leuk in theorie, maar in de praktijk boeit het geen hond

Voor bedrijven in meeste westerse landen is EV certificaat makkelijk aan te vragen omdat documenten vertrouwd worden.

Echter in andere landen moet men veel meer doen. Via door certificaat uitgevers aangewezen accountants of boekhouders associsties in land validatie laten doen. Via rechtbank gecertificeerde kvk uittreksel, vertalen door beeidigde tolk etc..

De meerwaarde zit hem erin dat het een gevalideerd bedrijf is die ook daadwerkelijk bestaat op moment van aanvraag. Dus bij problemen kan je tenminste dat bedrijf/adres/bestuurders vinden omdat ze daadwerkelijk bestaan.

Simpele domein certificaten doen niets meer/minder dan intregiteit van je datastroom garanderen. Het maakt je bezoek aan je site niet veiliger omdat je toch niet weet wie/wat je bezoekt.

Wildcard domeinen is een risico.

[hackerhater]

Wildcard een risico? Ligt er maar net aan waar je ze voor gebruikt.
Wij gebruiken als webhost er een die alle servers af dekt, de FTP, de mail, etc.
Allemaal op een subdomein onder het hoofddomein.

[totaalgeenhard]

Al je private keys van al je servers hetzelfde... handig...

[hackerhater]

Als ze zo ver kunnen doordringen dat ze aan die gegevens kunnen, hebben we wel grotere problemen dan dat certificaat.

[totaalgeenhard]

Met dien verschil dat je nu maar 1 server hoeft te rooten om verkeer van alle overige makkelijk te kunnen ontcijferen.

Overigens waarom geen controle paneel gebruiken dat let's encrypt automagisch voor je doet?

Je gebruikt nu toch ook geen 1 wachtwoord of 1 ssh private key voor al die servers?

[hackerhater]

Let's encrypt kan dingen als de FTP en email niet versleutelen. Het zijn simpele certificaten voor websites.
Zoals ik zei : als ze rootaccess weten te krijgen hebben we wel grotere problemen dan dat certificaat.
"If someone gets root-access to your machine, it is not your machine anymore"

[mmjjb]

Banken wijzen er altijd op om de naam in het slotje te controleren.
De rapportages die jij aanhaalde zijn allemaal gedateerd en na intensieve reclame's van de banken tegen internet oplichting, zijn naar mijn mening mensen zeker wel meer alert geworden.

Gebruikers letten hier zeken weten wel op, natuurlijk zijn er genoeg domme gebruikers die nergens op letten. Maar veel mensen in mij omgeving, voornamelijk wat oudere mensen zijn als de dood dat hun computer een virus heeft en dat haar bank accounts geplunderd worden.


Onderschat niet de waarde van een EV certificaat, iedereen kan een https certificaat nemen, ook malafide bankwebsite kunnen rustig een lets-encrpyt certificaat op haar domein zetten.

Een EV certificaat heeft extreem veel waarde, voor een klein webshopje maakt het niet veel uit, maar zaken zoals bankieren, daar wil je wel echt weten met wie je zaken doet!

[Reactie gewijzigd door mmjjb op 25 juli 2024 12:02]

[The Zep Man]

Banken wijzen er altijd op om de naam in het slotje te controleren.

Dat maakt ze geen getrainde gebruikers.

De rapportages die jij aanhaalde zijn allemaal gedateerd en na intensieve reclame's van de banken tegen internet oplichting, zijn naar mijn mening mensen zeker wel meer alert geworden.

Kan jij je mening ondersteunen met een academisch onderzoek?

Gebruikers letten hier zeken weten wel op,

Bron?

Onderschat niet de waarde van een EV certificaat, iedereen kan een https certificaat nemen, ook malafide bankwebsite kunnen rustig een lets-encrpyt certificaat op haar domein zetten.

OK. Wat is die waarde dan?

Een EV certificaat heeft extreem veel waarde, voor een klein webshopje maakt het niet veel uit, maar zaken zoals bankieren, daar wil je wel echt weten met wie je zaken doet!

Opnieuw, wat is die waarde? Op technologisch vlak is het namelijk niets.

[Reactie gewijzigd door The Zep Man op 25 juli 2024 12:02]

[GeniusDex]

Kan jij je mening ondersteunen met een academisch onderzoek?

Ik kan even snel geen recente papers vinden over dit onderwerp. De papers die jij aanhaalt zijn uit 2007-2009, en sindsdien is er aan de user interface van browsers en certification erg veel gesleuteld. De abstracts lijken ook te wijzen op een onderzoek naar user interfaces die destijds gebruikt zijn.

Volgens mij kun je geen conclusies trekken over de effectiviteit van de huidige interfaces, zonder een recent onderzoek. Hierbij is het ook relevant dat gebruikers inmiddels gewend zijn aan de huidige interfaces door er maanden/jaren mee te werken, en dat ze daarom wellicht ook effectiever zijn.

OK. Wat is die waarde dan?
[...]
Opnieuw, wat is die waarde? Op technologisch vlak is het namelijk niets.

De waarde zit ook in de administratie die in de techniek ligt: er horen alleen geldige EV-certificaten uitgegeven te worden namens bedrijven als die daadwerkelijk zelf de aanvraag hebben gedaan. Technisch kun je dat (momenteel) niet garanderen, dus vertrouwen is de enige manier om dat voor elkaar te krijgen.

[alt-92]

. De papers die jij aanhaalt zijn uit 2007-2009, en sindsdien is er aan de user interface van browsers en certification erg veel gesleuteld.

*kuch* niet ten goede overigens.
Probeer in een default Chrome maar eens met zo min mogelijk clicks de details van deze site op te vragen.

[Yugoos]

Probeer in een default Chrome maar eens met zo min mogelijk clicks de details van deze site op te vragen.

F12, click:<view certificate>

sneller dan dit zou ik ook niet weten.

[alt-92]

sneller dan dit zou ik ook niet weten.

Het zit nu weggestopt in DevTools ja. Terwijl het voor 51 nog vanuit de adresbalk zelf te doen was. 1 click.

[walkstyle]

Gebruiken banken geen open-source en gratis oplossingen in hun organisatie/bedrijf dan ?
wat maakt Apache/proftpd/exim/dovecot anders dan lets-encrypt, en waarom zou een website met Lets-Encrypt minder veilig zijn dan met Comodo ?

Ik snap dat EV betrouwbaar overkomt door de checks, mijn vraag was meer voor DV bedoeld.

[Reactie gewijzigd door walkstyle op 25 juli 2024 12:02]

[mmjjb]

Gebruiken banken geen open-source en gratis oplossingen in hun organisatie/bedrijf dan ?
wat maakt Apache/proftpd/exim/dovecot anders dan lets-encrypt, en waarom zou een website met Lets-Encrypt minder veilig zijn dan met Comodo ?

Ik snap dat EV betrouwbaar overkomt door de checks, mijn vraag was meer voor DV bedoeld.

De meeste professionele banken gebruiken geen of amper apache, proftpd, exim, dovecot.
-froftpd? Nee een bank upload niet zo eventjes wat bestanden op de ftp
-Apache? Bijna alle banken gebruiken een IBM web/applicatie server
-Exim / Dovecot? Lijkt met absoluut niet. Banken gebruiken of een IBM product of Exchange

Add:
Kwa veiligheid zullen ze redelijk gelijk zijn DV validatie van comodo en lets-encrypt.
Toch zal ik voor een belangrijke website liever een DV van Comodo kopen.
Ik doe liever zelf een certificaat aanvraag, waarbij het certificaat geldig is voor 1 of meerdere jaren, dan dat ik moet vertrouwen op een cron die elke XX dagen een nieuw certificaat moet aanvragen waarbij meer risico is dat er iets fout gaat.
Tuurlijk.. de kans is klein dat er wat fout gaat. Maar voor 10 euro prijs verschil, loop ik liever geen risico.

[Reactie gewijzigd door mmjjb op 25 juli 2024 12:02]

[r2504]

En voor die IBM web/applicatie server staat dan nog meestal een speciale application level firewall waar men al helemaal geen gebruik maakt van Let's Encrypt (wat niet echt gebruiksvriendelijk is in combinatie met dergelijke systemen).

[Kees]

Hoezo? Ik gebruik ook een WAF, en die heeft gewoon een api. Letsencrypt is gewoon een kwestie van die api eens per maand aanspreken om een nieuw ssl certificaat te uploaden, dat is geen rocketscience.

[Zenomyscus]

Ik lees geen concrete argumenten waarom Lets Encrypt minder veilig zou zijn en daarnaast zie ik argumenten die lijken voort te komen uit angst in plaats van wetenschap. Die normale certificaten verlengen gaat overigens ook wel eens fout. Een van onze klanten heeft er meerdere dagen last van gehad omdat het verlengen van een normaal certificaat niet goed was gegaan. Tot nu toe heb ik in elk geval nog nooit last gehad van Lets Encrypt. Daarnaast kosten de meeste certificaten, zeker bij hostingpartijen, meer dan een tientje.

[Kees]

De Rabobank en SNS gebruiken Apache, Triodos gebruikt Varnish, ik zie Angular JS bij de ING, knab.
Triodos heeft jQuery in de source staan.

Hoezo gebruiken banken geen Open Source producten?

[Verwijderd]

IBM webserver gebruikt onder water ook gewoon Apache.
Natuurlijk wel eentje die vanuit IBM gesupport wordt, maar Apache wordt dus wel degelijk gebruikt.

Mbt. Open source, waar je 'Nee' ook op slaat; Bijna alle grote banken in Nederland maken gebruik van Linux.

Gratis zullen ze inderdaad niet veel gebruiken. Een professioneel bedrijf wil software met goede support. Of dat nu open source is of niet.

[mmjjb]

Had het een beetje verkeerd uitgelegd, mijn punt was niet dat ze totaal absoluut geen opensource oplossingen gebruiken, waar ik op doelde is dat je in een professionele omgeving waarbij je zekerheid wil, niet gaat draaien met een let's encrypt cron om een paar euro uit te sparen.

Aangezien de persoon waar ik op reageerde een associatie legde tussen grote infrastructuur in combinatie met een let's encrypt.

Ik wist overigens niet dat IBM webserver in de kern op apache draaide, dank je voor de nieuwe informatie

[alt-92]

Ik wist overigens niet dat IBM webserver in de kern op apache draaide, dank je voor de nieuwe informatie

IBM WebSphere is een Apache fork.
Met wat eigenzinnige nukken, maar that's IBM for you.
(IBM Connections, hun 'social platform' is overigens Lotus Notes onder de motorkap)

[atPDB]

Bij een EV certificaat is de aanvraag wel strenger. Verder is een verschil tussen betaalde certicaten en LE, dat de betaalde certificaten vaak een bepaald bedrag verzekeren mocht het toch mis gaan. Hoe hoger het bedrag hoe duurder het certificaat.

[Kees]

Als wat misgaat? Die verzekering is echte pure slangenolie.

En als men SSL vertificaten weet te kraken dan is dat mogelijk ongeacht de verzekering en kun je elk soortgelijk certificaat kraken.

[xleeuwx]

Het gedoe met het aanvragen via standalone (apache of nginx even uitzetten en weer aan na de aanvraag) is voor vele de 9 euro in het jaar niet waard. Als ik dit voor een klant moet doen kost het ze uiteindelijk meer als een gratis certificaat. Voor Prive projecten of kleine bedrijven is het echt ideaal en kosten besparend, maar de normale certificaten zijn ook niet echt duur meer.

[Bolk]

Waarom zou je de standalone variant gebruiken? Je kunt prima het .well-known path opvangen, het certificaat renewen via de webserver en dan een reload doen. Zonder enige downtime.

[xleeuwx]

Omdat er applicaties zijn die op poort 80 draaien die niet standaard de .well-known path hebben. Daarnaast heb je nog servers die niet van buitenaf benaderbaar zijn (interne productie servers) deze dienen voor test doeleinde ook gebruik te maken van HTTPS en dus hebben die ook een certificaat nodig.

[Reactie gewijzigd door xleeuwx op 25 juli 2024 12:02]

[The Zep Man]

Omdat er applicaties zijn die op poort 80 draaien die niet standaard de .well-known path hebben.

Daarvoor heb je een reverse proxy.

Daarnaast heb je nog servers die niet van buitenaf benaderbaar zijn (interne productie servers) deze dienen voor test doeleinde ook gebruik te maken van HTTPS en dus hebben die ook een certificaat nodig.

Daarvoor heb je een eigen interne CA (die intern vertrouwd wordt door de betreffende clients).

[Reactie gewijzigd door The Zep Man op 25 juli 2024 12:02]

[xleeuwx]

[...]
Daarvoor heb je een reverse proxy.

Ja dat is dus een extra service voor alleen HTTPS certificaat aan te vragen, service moet dus ook gemonitord worden.

[...]
Daarvoor heb je een eigen interne CA (die intern vertrouwd wordt door de betreffende clients).

Dat is inderdaad ook een mogelijkheid, maar nu hebben we gewoon even een crontab draaien die het van een aparte server afhaalt.

[Cilph]

Als je dus apache of nginx of een andere webserver gebruikt heb je geen andere service nodig. En wie zet er nou een Java of Node app direct open naar het internet.

[tormentor1985]

Ja dat is dus een extra service voor alleen HTTPS certificaat aan te vragen, service moet dus ook gemonitord worden.

Liever monitoring voor alle ssl certificaten op 1 server dan op 30 servers allemaal losse en lastig te beheren certificaten. Een reverse proxy is uberhaubt geen overbodige luxe, het maakt migreren makkelijker en het ontlast je applicatieserver omdat deze geen ssl hoeft te decrypten. Verder is het geen rocket science om even een nagios checkje te maken die je haproxy status checkt en je kan meteen checks bouwen om de gezondheid van je backend servers in de gaten te houden. Win Win

[Reactie gewijzigd door tormentor1985 op 25 juli 2024 12:02]

[Verwijderd]

Ik gebruik zelf een nginx reverse proxy, dedicated voor de SSL off-loading om hier de achterliggende docker-containers niet mee te hoeven belasten.
.well-known op 80 is niets anders dan een redirect die dynamisch bij de renew wordt aangemaakt.

Een cron-job vernieuwt alle certs elke maand.

Niemand hoeft ook maar ergens naar om te kijken.

[Guru Evi]

Je kunt altijd het .well-known path toevoegen. Ik heb ook applicaties draaien achter mijn nginx, het is maar een lijntje extra in de configuratie, je kunt het zowel in Apache als nginx globaal doen zodanig dat alle sites een .well-known path hebben zonder dat de individuele sites daarvan afweten.

[Blokker_1999]

Maar je haalt in je eerste post wel net enkel webservers aan waarin dit probleem zich dus niet stelt omdat je het snel kan afvangen. En wat je interne servers betreft heb je het probleem dat als ze echt enkel intern zijn je ook een probleem hebt omdat LE deze nooit kan aanspreken en verifiëren.

[aadje93]

die interne servers kun je makkelijk 's nachts dus even een reload laten doen á 1 minuutje "offline"

Daarnaast kan LE ze nooit bevoorraadden als je zo om je "beveiliging" zit door intern https te gebruiken, dan zou je alles al in je firewall blokkeren naar dat netwerk

[Reactie gewijzigd door aadje93 op 25 juli 2024 12:02]

[svennd]

of gewoon via DNS verificatie ... Lijkt erop dat je niet goed onderzoek hebt gedaan

[xleeuwx]

In de ideale wereld zou dat kunnen ja, maar soms heb je gewoon niet de rechten om bij een domein van een groot bedrijf even de records aan te passen. Zoals ik in me vorige comment zei is dit voor kleine bedrijven en prive projecten echt een geniaal product maar voor grote bedrijven waar DNS beheer, server beheer en development geheel gescheiden en via 28 formulieren geregeld moet worden een hell. Dan kan je betere even voor 9 euro een certificaat kopen, heb je niks met de DNS beheerder te maken.

[Guru Evi]

Bij de meeste providers moet je toch wel kunnen aantonen dat je de site onder beheer hebt. Je kunt niet zomaar een certificaat aanvragen zonder enige toestemming of papieren werk.

LE is vooral gemakkelijk in grote bedrijven omdat je enkel maar de host waar je het certificaat nodig hebt moet controleren, als je toch een certificaat moet installeren is het veelal sneller en gemakkelijker om een LE aan te vragen dat volledig technisch geregeld wordt dan via de administratieve weg een certificaat te regelen.

Waar ik werk hebben we bijvoorbeeld een "approved vendor" EUR 180 per jaar voor een certificaat wordt aan je departement gerekend, als je na enkele maanden moet vernieuwen vanwege veiligheidsredenen, opnieuw 180. Je moet het aanvragen, dat wordt dan tussen de 24 and 48u later 'toegelaten' en krijg je via e-mail een ondertekend certificaat dat je dan moet downloaden, converteren of kopiëren naar de server etc. Met LE heb ik binnen 5 minuten een nieuw certificaat, veel veiliger, veel gemakkelijker en veel goedkoper en ik moet bijna niets doen, het is volautomatisch.

[Reactie gewijzigd door Guru Evi op 25 juli 2024 12:02]

[idef1x]

Waarom inderdaad niet je certificaten in DNS zetten ipv een externe CA te gebruiken? Wordt voor DKIM ook al gedaan, dus als het voor email kan.....

[Dorank]

Dat heet DANE/TLSA (en heb je DNSSEC nodig om het betrouwbaar te maken), voor zover ik weet zijn er precies 0 browsers die dat standaard ondersteunen.

Begrijp me niet verkeerd, ik zou het geweldig vinden als het van de grond zou komen. Ik heb allerlei certs/fingerprints in DNS staan, maar ik heb niet de ilussie dat er ook maar 1 persoon anders dan ikzelf ooit gebruik van maakt.

[idef1x]

Hmm ja DKIM is signeren van de mail en heeft niets met de connectie te maken..

maar ik heb niet de ilussie dat er ook maar 1 persoon anders dan ikzelf ooit gebruik van maakt.

Dan moet ik je illusie teniet doen, want ik maak er ook gebruik van, maar alleen voor smtp.

[alt-92]

ING doet DKIM, SPF & DMARC, . Da's niemand.

[Reactie gewijzigd door alt-92 op 25 juli 2024 12:02]

[Ghost81]

Waarom zou je dat allemaal met de hand doen? Dat alles kun je prima met een script automatiseren. Doe ik nu ook.

[Ronnerd]

Je hoeft je webserver helemaal niet te stoppen, dus als je dat met je script op dit moment wel doet dan zou ik nog even de documentatie goed doorlezen, en dan het deel over "stand-alone". (stand-alone mode gebruiken met een reverse proxy op /.well-known/acme-challenge/ en een reload van je webserver ipv restart)

[Reactie gewijzigd door Ronnerd op 25 juli 2024 12:02]

[xleeuwx]

Dit is wel iets waar we op hebben zitten wachten.

[walteij]

Dit is voor mij eigenlijk de enige reden dat ik nog niet naar LetsEncrypt was overgestapt.
Een wildcard certificaat maakt een hoop dingen makkelijker.
Niet meer moeilijk doen over een hostnaam en een apart certificaat aan moeten vragen, maar gewoon het gratis letsencrypt wildcard certificaat aanvragen, distribueren over de (web)servers waar je het certificaat nodig hebt en doorgaan maar.

De LetsEncrypt certificaten zijn maar 90 dagen geldig. Nu kun je het certificaat automatisch vernieuwen met een cronjob (zelf nog nooit gedan trouwens), maar wat ik me dus afvraag is of je bij de verlenging van het certificaat daadwerkelijk de geldigheid van het bestaande en geinstalleerde SSL certificaat verlengt, of dat je het certificaat vernieuwt en vervangt door het nieuwe certificaat.
In het laatste geval is het automatisch verlengen natuurlijk helemaal niet praktisch, omdat je dan het nieuwe certificaat ook op al je servers moet gaan vervangen.

[sieem]

Bij Siteground zit er een module in het cPanel van let's encrypt die het automatisch vernieuwen voor jou afhandelt. Dat is ook het doel van let's encrypt, dat proces ook gemakkelijk automatiseren. Vandaar dat let's encrypt zo'n tools aanbiedt aan hostingproviders. Vernieuwen is voor mij dus een non-issue geworden.

[Reactie gewijzigd door sieem op 25 juli 2024 12:02]

[invic]

Weet je ook of er voor dotnet nuke ook een module is die het verleng proces vernieuwd. De geldigheid van 90 dagen is wel heel erg kort. Waarom ze niet minimaal 1 jaar doen snap ik niet.

[Snake]

Als iets geautomatiseerd is maakt het toch niet uit hoe vaak je het moet doen, iedere dag, om de week, of om het jaar.

Laten we zo stellen: als jouw private key wordt gestolen kan iemand jouw domein maar 3 maanden impersonaten, ipv 1 jaar, gelijk jij wilt.

[aadje93]

het gaat volledig automatisch, je hebt er na opzetten praktisch geen omkijken meer naar (hoogstens de status mails van je cron job even filteren op het woord error/failure )

Mijn voorkeur zou zelfs maandelijks zijn, dan is je private key "slechts" 1 maand geldig ipv een jaar of meer zoals nu vaak gedaan word bij traditioneel gekochte certificaten.

[MadEgg]

Je kunt certificaten niet verlengen - de geldigheid zit erin opgeslagen. Je zult ze dus inderdaad moeten vervangen.

[walteij]

Dat de geldigheid in het certificaat zit was me bekend, ik ben alleen niet bekend met het automatische vernieuwingsproces dat gebruikt wordt met de lets encrypt certificaten. Maar als dit een 'gewone' vernieuwing is, zijn de wildcard certificaten dus niet praktisch voor zakelijk gebruik, tenzij het automatisch vernieuwings proces aangepast kan worden, zodat je het certificaat op meerdere servers tegelijkertijd kunt vervangen, maar dat lijkt me toch lastig.

[MadEgg]

Klopt. Al kun je dat natuurlijk ook automatiseren - één master-server die het certificaat aanvraagt en daarna pusht naar de andere servers.

[walteij]

Hmm, ik zit me net te bedenken dat het ook nog anders zou kunnen dan het certificaat pushen.
Namelijk door op iedere server waar het certificaat gebruikt wordt een cronjob te maken die het volgende doet:

• Controleer of er een nieuw certificaat op de master server staat (via https)
• Als dit er staat, haal dit op via SCP
• Installeer het nieuwe certificaat op je webserver
• Herstart je webserver

Dus pull ipv push. Je zult alleen dan zelf wel moeten monitoren of de cronjobs goed verlopen, hoewel je de resultaten van de job ook gewoon kunt laten mailen.,

[cavey]

Dan is een push toch handiger, wat @MadEgg ook al voorstelt?

Zeker als je overal al SCP hebt, dan heb je je key-infrastructuur ook al geregeld (misschien is zelfs een rsync nog handiger, die kan je elke dag laten lopen, en dan vervangt die het alleen als bron nieuwer is dan doel).

Zodra je namenlijk je certificaat op de master server vervangt, kan je meteen alle slaves updaten. Scheelt je bij houden welke cronjobs nou goed lopen, en je kan in een lijst (of database) bijhouden welke servers een certificaat moeten ontvangen.

[Falcon]

Even noob vraag misschien, maar heb je dan een paar seconden 2 certificaten?.. kan mij voorstellen dat je niet eerst de oude weggooit voordat de nieuwe er op komt te staan. Zal wel 's nachts gebeuren, maar het risico is hierdoor anders altijd aanwezig dat je de bezoeker van je site raakt?

[hackerhater]

Normaal blijft het vorige in het geheugen staan tot je de webserver het commando geeft deze opnieuw in te laden.
Je overschrijft dus het huidige cert + key
En erna geef je een config reload commando aan je webserver. De certs zijn erna geldig.

[aadje93]

Ervanuitgaande dat je linux gebruikt;

je kunt elke minuut een Rsync op de master laten lopen (cron job). Push ipv pull is mijn voorkeur, 1 contab waar alles instaat, en één mail met alle "sucess' meldingen of fouten.

Master certificaat word door lets encrypt cron job vernieuwt, na maximaal 1 minuut ziet de rsync job dat het cert. nieuwer is, en pusht deze naar alle "clients" (de web server(s) ga ik vanuit).

Het vernieuwingsproces kun je volgensmij customizen, al heb ik letsencrypt zelf alleen uitgebreid gebruikt in Plesk, alleen in het begin bare-metal gehad waarbij je zelf een vernieuwings commando moest doen (dus elke maand een cron job laten lopen)

In het geval van plesk word de job wekelijks gedaan, en indien een cert minder dan 30 dagen geldig is word deze vernieuwd, dus 3 pogingen tot je cert niet meer geldig is.

[Ronnerd]

nah.. 1 'master'-server die renew doet en je zou via een renew hook dan een shell script kunnen runnen na de renew de nieuwe certs pushed naar de rest van de servers, maar als het een cluster is die regelmatig veranderd (nieuwe nodes etc) en de master weet niet hoeveel servers er precies zijn, dan is het beter om simpelweg de overige servers elke nacht een rsync te laten doen van de certs op de master naar zichzelf.

[Reactie gewijzigd door Ronnerd op 25 juli 2024 12:02]

[servies]

V.z.i.w wordt een certificaat vernieuwd en vervangen
Bij mij staat er nu in ieder geval een lijstje certificaten in die map en iedere keer wanneer het cerficaat moet ik de httpd server herladen/herstarten...

[Guru Evi]

Ik dacht dit ook eerst, maar het LE script kan gemakkelijk enkele tientallen hostnames aan. Enkel voor intern gebruik was LE nog lastig omdat het interne hostnames niet kan verifiëren maar dat is waarschijnlijk de enige reden dat ik een wildcard ga aanvragen.

Wildcards hebben inherent risico, als je per abuis je sleutel kwijt of publiek maakt moet je ALLE hosts gaan vernieuwen.

[aadje93]

een simpel Rsync jobje maken, die het zowieso al pusht naar alle clients en je bent klaar, handmatig even het script aanroepen en de rest gaat in luttele minuten (denk zelfs tot een 10-20 hosts binnen 1 minuut) vanzelf

[Blokker_1999]

In een complexere omgeving zal het wat tijd kosten om alles goed op te zetten, maar ergens hoop ik dat je vandaag al de deployment voor een groot stuk geautomatiseerd hebt. Of je cert nu 90 dagen geldig is of 2 jaar, je moet ze vroeg of laat toch vervangen.

En certbot geeft je een hoop mogelijkheden om te helpen in dat automatisatieproces. Bij mij loopt elke dag een cronjob die certbot lanceerd voor vernieuwing. En indien er ook effectief nieuwe certs worden gedownload zal certbot zelf een script aanroepen dat in staat voor de verdere verspreiding naar de juiste servers en het herladen van die servers. Alles loopt geautomatiseerd.

En loopt het proces toch ergens mis, dan stuurt LE je een mailtje om te waarschuwen dat je certificaten op vervallen staan. Goed op tijd zodat je tijdig actie kan ondernemen om het probleem te verhelpen.

[Blokker_1999]

Mjah, ik heb een tijd terug een heel weekend kunnen spenderen om de servers te herconfigureren om LE certificaten mogelijk te maken met alle subdomeinen die we hebben, en nu komen ze hier mee af. Had ik dat enkele weken vroeger geweten had ik met plezier nog een jaar een betaald wildcard cert genomen...

[Verwijderd]

Is er iemand die gebruik maakt van een NL webhost die voorziet in lets-encypt?
Die van mij doet daar nog steeds niet aan mee.

[Reactie gewijzigd door Verwijderd op 25 juli 2024 12:02]

[Koekstra]

Ja, ik heb een vserver in beheer waar Plesk op geinstalleerd staat. In plesk is een extentie beschikbaar die het hele proces voor je doorloopt. Inclusief automatisch vernieuwen.

Je klikt al je domeinen (en subdomeinen aan) en zodra je op 'toepassen' klikt ben je klaar om te gaan

[hackerhater]

In mijn geval het omgekeerde.
Wij hebben de plugin aangezet in DA voor onze klanten
En verschillende klanten hebben de plugin al gebruikt ˆ_ˆ

[Spinal]

Dreamhost, Antagonist, en nog een boel anderen

[phochs]

Er bestaat een CPanel plugin die ondersteuning voor Let's Encrypt certificaten toevoegt. De webhoster Neostrada maakt er bijvoorbeeld gebruik van. Werkt erg fijn.

[henk717]

Ik kan je van harte HawkHost aanraden mits je omtrend de nederlandse wetgeving met persoonsgevoelige data uitsluitend een nederlandse host dient te hebben. Hoewel HawkHost een canadees bedrijf is bieden zij wel nederlandse hosting aan gehost in Amsterdam houdt wel rekening bij het bestellen dat je deze locatie kiest op het bestel formulier.

Hawkhost biedt Shared Hosting met cPanel aan, binnen cPanel hebben zij de Lets Encrypt plugin geïnstalleerd. Je geeft dus aan dat je voor dat domein Lets Encrypt wilt gebruiken en de cPanel bot regelt het voortaan vanzelf, je hoeft dan ook geen rekening te houden met te verlopen certificaten tenzij de LetsEncrypt verificatie wordt verstoord door een foutieve .htaccess rule (Bijvoorbeeld een redirect of onterechte 403 op de map waar lets encrypt verifieerd).

De reden dat ik initieel voor HawkHost koos was de grote transparantie die zij bieden voor je een hosting pakket afneemt. Zij hebben publiek de uptime beschikbaar maar ook voor al hun datacenters een speedtest aanbiedt. Een volledige lijst met features is ook te vinden.

Ik heb over de jaren heen meerdere hosts gehad maar nog nooit zo erg tevreden over de latency en totale doorvoersnelheid als bij HawkHost. Zij hebben over het jaar heen een aantal korte downtimes gehad, dit is meestal binnen 5 minuten zonder het maken van een support ticket opgelost. De enige keer dat het langer duurde had het datacenter problemen met hun (nood)stroomtoevoer.

Tip : Ga niet direct door met kopen maar klik een beetje rond en doe daarna alsof je naar een andere site wilt gaan, je krijgt een popup met een lifetime coupon.

[Reactie gewijzigd door Bor op 25 juli 2024 12:02]

[RobbyTown]

Het is niet zo easy als je denkt.

Hier een heel verhaal hoe ze het bij Antagonist hebben gedaan.
https://www.antagonist.nl/help/nl/ssl/letsencrypt

[GertMenkel]

Als je matige kwaliteit zoekt en zo min mogelijk geld uit wilt geven kan ik je Versio aanraden. Versio heeft let's encrypt ingebouwd in het DirectAdmin control panel.

Volgens mij geldt dat voor de meeste webhosts met een recente versie van DirectAdmin trouwens, maar dat weet ik niet zeker.

[Verwijderd]

Gaat Tweakers hiervan gebruik maken?

[mg_1999]

Tweakers maakt al gebruik van een Let's Encrypt certificaat.

[DYX]

Correct, maar geen wildcard certificaat. Verwacht dat @Verwijderd daar op doelt

[AW_Bos]

De Tweakblogs van gebruikers hebben geen LetsEncrypt maar van een andere SSL-certificaten boer. En ook begrijpelijk op dit moment, omdat het tijdrovend is om voor elke subdomein een LE-certificaat aan te maken.

[Reactie gewijzigd door AW_Bos op 25 juli 2024 12:02]

[Falcon]

Wat nu dan toch opgelost is met deze wildcard variant?

[Kees]

Klopt, daarom kan ik ook niet wachten tot volgend jaar zodat ik het op kan zetten

Scheelt toch weer +/- 135 euro per jaar per wildcard

[Reactie gewijzigd door Kees op 25 juli 2024 12:02]

[Sebazzz]

Nadeel is wel dat het voorlopig enkel via DNS validatie kan. Dat betekent dat je zelf je DNS niet geautomatiseerd kan beheren, je om de 60 dagen handwerk hebt.

[Kees]

Ik kan mijn DNS prima scripten, geen problemen mee

[Roel911]

Zie: https://certbot.eff.org/all-instructions/. Hoofdstuk/paragraaf Automating renewal

[Reactie gewijzigd door Roel911 op 25 juli 2024 12:02]

[xoniq]

Volgend jaar?

[quote]Vanaf januari 2018 verstrekt Let's Encrypt wildcardcertificaten.[/quote]

Het is vrijdag, de geest is niet zo sterk op een dag als vandaag.

[Reactie gewijzigd door xoniq op 25 juli 2024 12:02]

[Kees]

Tenzij ik onbewust een hele lange tijd heb geslapen is het nu nog 2017, en is 2018 aan te merken als 'het jaar dat op dit jaar volgt' oftewel volgend jaar.

[xoniq]

Oh sorry, ik las 't als 2019 (het is vrijdag, dan draait 't allemaal niet zo lekker bovenin)

[xFeverr]

tel daarbij op dat er rate limits zijn, waardoor het eigenlijk niet te doen is om alle tweakblogs te voorzien van certificaten.

[Soldaatje]

Huidige tweakblogs certificaat geldig tot april 2019, dus ergens daarvoor overzetten dan.

[Bamsebjorn]

Ik denk dat de vraag was of Tweakers een wildcard certificaat gaat gebruiken.

[Raymond Deen]

Tweakers gebruikt al Let's Encrypt certificaten hoor.
De sub-domeinen en alternatieve domeinnamen staan netjes in het "Subject Alternative Name" veld.

Of bedoel je de vraag of ze deze lijst dan niet meer hoeven opnemen? Want dan zouden ze voor de alternatieve domeinnamen weer aparte certificaten moeten aanmaken en dat is juist weer extra werk...

[Reactie gewijzigd door Raymond Deen op 25 juli 2024 12:02]

[Kees]

Ja

[mclegodude]

Tweakers maakt al gebruik van let's encrypt!

[MartyLooterKing]

Tweakers.net gebruikt in ieder geval al Lets Encrypt.

[Reactie gewijzigd door MartyLooterKing op 25 juli 2024 12:02]

[Upquark]

Ik zie dat het nog niet gepost is, en daarom: Tweakers maakt al gebruik van Let's Encrypt!

[RoestVrijStaal]

Liever niet. Let's Encrypt wordt door al die populariteit een Single Point of Failure.

Zowat iedereen gaat over op Let's Encrypt, want het is gratis.

Hier wordt de certificaten markt erg monolithisch van, wat kwaliteit en daardoor beveiliging niet te goede komt.

[Ronnerd]

Sorry, maar wat een enorme bak met onzin. Waar baseer je dit op? Is Comodo ook een single point of failure in jouw ogen? Verdiep je eerst in de materie alvorens je het af gaat kraken.

[RoestVrijStaal]

Ik val Let's Encrypt aan. Niet de techniek van TLS e.d.

Het gaat er mij om dat steeds meer mensen gaan vertrouwen op een gratis dienst waarvan het onzeker is in hoe lang het nog blijft bestaan, of het nog gratis blijft en of de beveiliging van die organisatie zelf op orde is en blijft.

Als steeds meer mensen kiezen voor Let's encrypt, wordt het een steeds interessantere doel voor cybercriminelen en overheden die willen tappen.

[CH4OS]

De grafiek in de afbeelding is op meerdere manieren. Je ziet weliswaar dat het gebruik van HTTPS-packets in Firefox toenemen of niet, maar dat hoeft niet per se te komen door een stijgende inzet van het gebruik van HTTPS op webservers. Het kan ook zijn, dat er meer gebruikers zijn die Firefox zijn gaan gebruiken, waardoor HTTPS-packets in Firefox uiteraard ook toenemen. Het zegt dus niet per se iets over het gebruik van HTTPS in het algemeen!

[Reactie gewijzigd door CH4OS op 25 juli 2024 12:02]

[ThinkCreative]

Maar het gaat over het percentage HTTPS-pageloads, niet over het totale aantal. Dus mensen bezoeken meer HTTPS pagina's ten opzichte van reguliere HTTP pagina's. Websites gaan dus danwel over naar HTTPS of mensen stoppen met het bezoeken van websites die geen HTTPS bieden.

[CH4OS]

Als het gebruikers aantal toeneemt, neemt het aantal pageloads logischerwijs ook toe (al dan niet in mindere mate).

Geldt ook voor de reacties van @farlane, @Eupeodes.

[Eupeodes]

Het absolute aantal pageloads neemt inderdaad toe, 'Percent of pageloads over HTTPS' is echter een relatief getal en neemt dus niet per definitie toe met het aantal gebruikers.

[CH4OS]

Vandaar de 'al dan niet in mindere mate'. Dat het niet evenredig toeneemt is logisch.

[Reactie gewijzigd door CH4OS op 25 juli 2024 12:02]

[Eupeodes]

Een toename in aantal gebruikers kan zelfs een afname in de grafiek betekenen. Als er ineens veel gebruikers komen die in firefox enkel nu.nl, nos.nl en buienradar.nl 100 keer per dag refeshen neemt het relatieve aantal HTTPS pageloads zelfs af.

[farlane]

Het gaat om het percentage HTTPS pagina's, niet absolute aantallen.

[Eupeodes]

Het gaat om een relatief getal, dus welke deel van de pageloads in Firefox is https. Of er 100 loads zijn waarvan 50 via https, of 1000 waarvan 5000 via https maakt daarvoor niet uit. Meer of minder gebruik van Firefox zou de grafiek dus niet moeten beïnvloeden.

[Verwijderd]

Dus bij de eerste de beste DNS hack kan er, 'beschermd' door een lets encrypt wildcard certificaat, een malafide subdomain gecreëerd worden.... Ik weet het niet hoor. Het is allemaal wel lekker makkelijk, maar je mag bidden dat je DNS server (of DNS management console) niet gecompromitteerd wordt.

[Falcon]

Ik heb zó'n vermoeden dat als men bij je DNS server kunnen, je wel een veel groter probleem hebt dan een malifide subdomain.

Maar je hebt een punt, dat is een risico met wildcard certificaten in het algemeen.. maar weegt het op tegen de beheerkosten bij allemaal certificaten per subdomain?.. ik denk het niet.

[Reactie gewijzigd door Falcon op 25 juli 2024 12:02]

[Verwijderd]

Heeft niets met wildcards te maken, kan ook gewoon bij single domains!

[CAPSLOCK2000]

Dus bij de eerste de beste DNS hack kan er, 'beschermd' door een lets encrypt wildcard certificaat, een malafide subdomain gecreëerd worden.... Ik weet het niet hoor. Het is allemaal wel lekker makkelijk, maar je mag bidden dat je DNS server (of DNS management console) niet gecompromitteerd wordt.

Dat kan toch ook zonder LetsEncrypt? De meeste CA's controleren door mail te sturen naar een vast adres of door een bepaalde URL op te vragen. Als je controle hebt over DNS is het een eitje om die controles te onderscheppen en naar je eigen systemen om te leiden. Wat dat betreft zie ik geen verschil tussen LE en traditionele goedkope certificaten.

[Verwijderd]

Dat is precies het probleem met wildcard certs. Zodra die wildcard cert is ingesteld, wordt met dat ene certificaat ieder ander subdomein gevalideerd.

[Blokker_1999]

Tjah. Maar als je de DNS kunt hacken en records kunt aanpassen, wat belet je om een non wild card cert aan te vragen bij LE op dat moment? Juist ja, niets.

DV certificaten dienen voor het versleutelen van de communicatie tussen server en client. NIET als verificatie of je met de juiste server aan het communiceren bent. Daar heb je EV certificaten voor.

[Guru Evi]

Dat maakt niet uit wie je certificaten doet, als je DNS om zeep is kun je bij veel bedrijven wildcards aanvragen. Als je ooit dat probleem hebt waar je DNS gehackt is en je denkt dat iemand rondloopt met een SSL certificaat, moet je bij alle providers opvragen of ze een certificaat hebben voor jouw en dat dan de-valideren.

Bij LetsEncrypt is er ten minste een publiek ledger zodat je kunt zien of je domein daar tussen staat, veel andere bedrijven hebben echt geen verificatie van domeinen die ze ondertekenen, sommigen ondertekenen zelfs google.com zonder problemen.

[mclegodude]

Wat zijn die rare dippen in het eerste kwartaal van 2017?

[MMaster23]

Certs verlopen automatisch na 3 maanden. Zullen veel "even proberen" certs zijn die dan verlopen.

[xiphoid]

En mensen zonder geduld, die niet doorlezen en een crontab aanmaken.

[jopiek]

Super, met name voor IoT toepassingen e.d. i.s.m. IPv6 ie ik voor mezelf hier veel voordelen van, nu betaal ik SSL certificaten voor zulke toepassingen.

[MadEgg]

Er is geen relatie tussen IPv6 (of IPv4) en SSL certificaten dus ik snap niet helemaal wat je hiermee bedoelt. Certificaten hebben betrekking op domeinnamen, niet op IP-adressen.

Voor IoT-oplossingen is het mijns inziens ook geen oplossing - dergelijke apparaten moeten niet rechtstreeks aan internet hangen en zouden uitsluitend via een VPN benaderbaar moeten zijn. Daarmee biedt een SSL-certificaat weinig meerwaarde.

[MrMonkE]

Maar zonder via VPN benaderbaar te zijn heeft een SSL certificaat natuurlijk enorm veel meerwaarde.
Alhoewel je die net zo goed zelf kan maken, tenzij de halve wereld erbij moet kunnen.

[jopiek]

Met IPv4 zul je vaak NAT gebruiken en stuur je uiteindelijk via router. Met IPv6 is dat niet meer nodig en kun je elk device gewoon een uniek adres geven -> deze koppelen aan een URL e.d. Als je dan direct met een app wilt verbinden met een device (zonder een of andere Cloud service o.i.d.) dan is het wel verstandig (Apple stelt het zelfs verplicht) om SSL te gebruiken. Wildcard certificaat is wel héél erg prettig, dus hoewel er technisch geen koppeling is, is het functioneel wel degelijk meer nuttig bij IPv6. (Toepassingsvoorbeeld: weerstationnetje met eigen webservertje).

[Reactie gewijzigd door jopiek op 25 juli 2024 12:02]

[MadEgg]

Zoals ik al zei zou die rechtstreekse verbinding er sowieso niet moeten zijn. Die IoT apparaten hebben al veelvuldig aangetoond een veiligheidsrisico te zijn en dat zal ook zo blijven. Dat moet via ren VPN.

Overigens heb ik voor al mijn interne hosts een certificaat. Mijn domeinnaam is geregistreerd en gekoppeld aan mijn publieke IPv4 adres. De webserver die het verkeer op poort 80 en 443 doorkrijgt op mijn interne netwerk vraagt de LE certificaten aan, de andere hosts gebruiken die via NFS. Geen IPv4 voor nodig, en ook dat wordt eenvoudiger met wildcard certificaten.

Domeinnamen kun je registreren en certificaten voor krijgen onafhankelijk van het IP-adres of protocolversie.

[henk717]

Gaaf om te horen, ben wel benieuwd hoe it gaat werken met shared hosting waarbij subdomeinen worden gebruikt. Wie kan dan wat aanvragen?

Tweakers, gaan jullie nu ook de Tweakblogs voorzien van LetsEncrypt? Ik las destijds in het .plan dat dit enkel niet mogelijk was door het ontbreken van wildcard certificaten.

[Verwijderd]

Ik denk dat in het geval van wildcard-records iets strengere regels gelden.
Denk aan web/post/hostmaster@[domein] (een van de registrars e-mailadressen) verplicht verifiëren, of een DNS-TXT record met een token moeten toevoegen a là Google Analytics.

Dan bewijs je dat jij de server-admin bent, zegmaar.

[Reactie gewijzigd door Verwijderd op 25 juli 2024 12:02]

[WienerBlut]

Ik zou eigenlijk wel willen dat ik meer kan doen met Let's Encrypt als alleen HTTPS... bijv. code signing enzo... (of kan dat al?)

[Blokker_1999]

Code signing vereist EV omdat je daarmee net je identiteit wilt kunnen bewijzen. Zeker belangrijk voor wanneer je kernel drivers wenst. Dat zal dus nooit met gratis certificaten gebeuren tenzij je in een firma werkt, je eigen infrastructuur kunt opzetten en in al je clients je eigen root cert kunt importeren.

[xrf]

Zoals @Blokker_1999 zegt is is verificatie van je identiteit verplicht om een codesigning-certificaat aan te vragen, iets wat Let's Encrypt in ieder geval voorlopig niet zal kunnen automatiseren.

Er is wel een Pools bedrijf dat gratis certificaten aanbied aan opensourceontwikkelaars, maar omdat ze de identiteit van de aanvrager handmatig moeten controleren zullen ze dit ook niet kunnen volhouden als het te populair wordt.

[Reactie gewijzigd door xrf op 25 juli 2024 12:02]

[Blokker_1999]

Die is leuk, ik betaal al jaar en dag voor mijn certificaat voor onze FOSS. Als ik moet verlengen weet ik ineens waar ik moet zijn