Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 134 reacties

Let's Encrypt heeft tien maanden na de start van de dienst tien miljoen gratis ssl-certificaten uitgegeven. Ongeveer 5,4 miljoen certificaten zijn momenteel daadwerkelijk geldig. Het aantal ssl-certificaten dat niet verlopen is, ligt al enkele weken rond dit aantal.

Op zijn statistiekenpagina meldt Let's Encrypt op moment van schrijven 9,98 miljoen ssl-certificaten uitgegeven te hebben, maar op Twitter laat de dienst weten dat de grens van 10 miljoen overschreden is. De dienst begon begin december vorig jaar met de uitgifte, bij een open bèta, en begin maart werd het miljoenste certificaat uitgegeven.

Het aantal certificaten in omloop dat niet verlopen is heeft de afgelopen dagen te maken met een terugval en ligt weer op het aantal van 24 augustus: 5,38 miljoen. Ssl-certificaten van Let's Encrypt verlopen na negentig dagen. De dienst wil hiermee automatisch verlengen door systeembeheerders stimuleren en misbruik en andere problemen, zoals bij verlies of diefstal van sleutels, voorkomen.

Doel van het initiatief is om zoveel mogelijk sites https-ondersteuning te geven door gratis ssl-certificaten te verstrekken en implementatie makkelijker te maken. Naast de EFF werken Mozilla, Cisco, Akamai, IdenTrust en onderzoekers van de universiteit van Michigan aan het Encrypt the Web-project.

Let's Encrypt stats 10 september

Moderatie-faq Wijzig weergave

Reacties (134)

de vraag is of het gaat om bedrijven die nu eindelijk zijn overgehaald om te beveiligen of bedrijven die zijn overgestapt omdat het gratis is en er een kostenbesparing in zien
Ik denk dat het soms ook een combinatie is. Een bedrijf voor wie ik freelance werk doe, gebruikte voorheen certificaten van een commerciele partij, maar zijn overgestapt naar Let's Encrypt. Deels vanuit financieel oogpunt, deels vanuit de extra's die Let's Encrypt biedt. Daarmee bedoel ik bijvoorbeeld OCSP Must-Staple.

Ook is de automatische vernieuwing van Let's Encrypt fijn. Letterlijk set and forget. Commerciele certificaten zijn soms voor vijf jaar te koop, of drie jaar bij EV/wildcards, echter moet er na die tijd alsnog vernieuwd worden. Als dat om veel domeinen gaat, kost dat veel tijd. Ook een script bouwen dat het kan verlengen, via een API van een reseller, kost tijd.

Persoonlijk ben ik heel positief over Let's Encrypt. Het is in mijn ogen niet meer van deze tijd om geld te vragen voor een toch wel essentieel stukje techniek. Formulieren vul ik simpelweg nooit meer in als een site geen propere HTTPS config heeft.

En ja, ik mijd de term SSL, gezien dat eigenlijk niet meer van toepassing is. TLS is de juiste term, maar dat is nog geen 'common good'.
geld te vragen voor een toch wel essentieel stukje techniek

Internet is onderhand "essentieel", electriciteit is "essentieel", voedsel is "essentieel"

Maar daarvoor mag wel geld gevraagd worden? Lets encrypt heeft ook gewoon kosten die nu door donateurs/grote partijen gedekt worden die voor een veilig internet staan, maar zelfs voor een klein bedrag per jaar (desnoods wat ik nu al betaal ~12 euro/jaar voor personal) en het is set and forget

Maar gewoon maar ervanuit gaan dat alle "essentiele" dingen maar gratis moeten zijn vind ik niet goed persoonlijk, een non-profit organisatie is dan de goede oplossing.
Ik vind dat je een goed punt hebt! Ik heb zelf, bedrijfsmatig, ook een flinke donatie gedaan aan Let's Encrypt. Een bedrag dat een aantal keer hoger is dan het aantal certificaten in gebruik, als ze van een commerciŽle aanbieder zouden moeten komen.

Als ze in financiŽle problemen zouden komen, zou ik er ook echt graag voor betalen, mits het gemak, dat er nu is, niet onder te lijden heeft. Bijvoorbeeld via een top up of automatische methode.

Voor nu ben ik vooral blij dat het gratis is. Vooral omdat er nu geen goed excuus meer is om geen HTTPS te implementeren.

Hoewel de bewoording krom is, bedoelde ik meer dat veiligheid en daarmee een stukje privacy gratis zou moeten zijn, in plaats van simpelweg het essentiŽle. Gratis voor de eindgebruiker.
>> Vooral omdat er nu geen goed excuus meer is om geen HTTPS te implementeren.
Ja en nee. Het (huidige) probleem met Let's Encrypt zijn zaken waarbij je geen SSH of andere toegangsmethoden hebt, denk aan routers, IPMI e.d. Voor zulke zaken gebruik ik doorgaans StartSSL.
Die paar routers kun je dan gewoon nog handmatig doen met een reminder in de agenda...

Als je 300 websites op 1 server hebt staan is het wel prettig om met lets encryp "set and forget" te werken ;)
Toch zijn die certificaten helemaal niet zo duur
Tenzij je van Symantec ze afneem tja dan is er een groot verschil. Via comodo betalen wij 195euro per 3 jaar ofzo.
En dan vraag ik me weer af, neem nu dat er plots toch een kost voor het certificaat komt, blijven ze dan beveiligen tegen de meerprijs, of stappen ze er dan terug vanaf? ;-)
En dan vraag ik me weer af, neem nu dat er plots toch een kost voor het certificaat komt, blijven ze dan beveiligen tegen de meerprijs, of stappen ze er dan terug vanaf? ;-)
Waar zouden die kosten vandaan moeten komen? Het is nogal onwaarschijnlijk dat er opeens grote kosten ontstaan. Er zijn wel een beetje kosten maar die zijn goed te overzien en er is geen reden om aan te nemen dat dit gaat veranderen.
Voor het werk dat LE doet heb je drie dingen nodig:
  • een snelle server
  • een handige techneut
  • het vertrouwen van de hele wereld.
De eerste twee zijn makkelijk en de kosten zijn erg voorspelbaar. Het derde punt, vertrouwen, is moeilijk. LE heeft zichzelf gekickstart door dat vertrouwen te kopen. Ze hebben een deal gesloten met een grote certificaatboer om mee te liften op de goede reputatie van dat CA. Dat clubs als Mozilla en Google achter het project staan heeft vast ook geholpen.
Nu LE zelf een goede reputatie heeft opgebouwd hebben ze die deal eigenlijk niet meer nodig. Het is nog even wachten tot alle browsers en OS'en zijn bijgewerkt om LE te (h)erkennen maar dan zijn ze zelfstandig. Het onwaarschijnlijk dat iets in de wereld verandert waardoor het werk van LE opeens duur wordt.
Naast het runnen van de server doet LE ook werk aan software, dat deel wordt inmiddels goed overgenomen door de community. Er zijn al tientallen clients geschreven en het is een kwestie van tijd voor er andere servers komen die hetzelfde protocol gebruiken.
Het is zo goed en makkelijk dat ik verwacht dat alle traditionele CA's het ook gaan gebruiken. Als LE dan ooit moet stoppen (of duur wordt) dan is het overstappen naar een ander zo eenvoudig als eenmalig de URL van de server aanpassen en klaar.
Als je plots toch zou moeten betalen zullen veel mensen van let's encrypt afstappen neem ik aan. Het min of meer enige echt onderscheidende aan let's encrypt is juist dat het gratis is.
Klopt gratis zorgt voor gebruikers en eerlijk is eerlijk ik zie niet in waarom ik 100 of zelf 300 of meer euro moet betalen voor een certificaat dat ook automatisch aangemaakt wordt. De controle op adres en andere zaken zijn soms ook een beetje een farce.
Goede zaak dat men dit nu gratis doet.
Bij een domein certificaat worden alleen email adres gecontroleerd om vast te stellen of je gemachtigd bent om namens betreffende domein certificaat aan te vragen.

Geen adres of wat dan ook.

Bij de business certificaten moet je gewoon KvK gegevens en iets actueels met adres verstrekken + geldige legitimatie.

Deze zijn dan ook niet instant.

Overigens SSL is alleen bedoeld om een "veilige" tunnel te bewerkstelligen niets meer en niets minder.

Beide eind punten zijn en blijven altijd de zwakke schakel in het geheel.
gratis, handig, vooral voor servers die je niet voor het grote publiek hebt opgezet, maar die wel encrypted moeten worden. Scheelt klauwen vol geld. Je moet nu eenmaal je salaris verdienen niet waar?
Zal er vanaf hangen.
Ik heb thuis 1 certificaat geinstalleerd op mijn nas van Let's Encrypt. Zodra ik daar voor moet gaan betalen, gaat dat certificaat er vanaf: het is voor mij een "nice to have", geen "must have".
Maar er zullen best bedrijven (en soms particulieren) zijn, die in de markt rond zullen gaan kijken zodra er een rekening op de (digitale) deurmat valt :)
Ik zou dan best moeten gaan schuiven. Alle websites die ik aanbied worden standaard met Let's Encrypt inschakelt geleverd. Al is het alleen al vanuit EEN oogpunt.
Voor bedrijven is het soms lastiger het echte betalen te regelen (moet immers door andere afdeling gedaan worden), dus wordt er liever een uurtje gestoken om letsencrypt aan de gang te krijgen.
Dat zijn ook de organisaties met een policy die niet voorzien in letsencrypt en je baan op de tocht zet als je dat buiten organisatie om gaat regelen.
dan ga je denk ook buiten het corporate policy om werken met "eigen oplossingen" wat niet echt gewaardeerd zal worden....
Soms worden voor de niet corperate kerntaken ook wel eens projectjes opgetuigd. Die misschien tijdelijk leven, en snel moeten staan niet onder wezijnfantastische.corperate.com maar onder wezijnfantantasichfeestje.com
Ik ben webdeveloper, en voorheen konden klanten ssl certificaten kopen/laten installeren en nu is het gratis en standaard. Uiteraard bieden we ook nog de betaalde versie aan omdat die ook meer kunnen bieden (betere verificatie/multidomain/wildcard)

Veel sites hebben het helemaal niet perse nodig maar krijgen het nu wel. De sites waar wij het wel nodig achten (sites waar je kunt inloggen of persoonlijke informatie heen stuurt) kregen altijd al het advies om een ssl certificaat af te nemen.

[Reactie gewijzigd door watercoolertje op 10 september 2016 10:13]

Veel sites hebben het helemaal niet perse nodig maar krijgen het nu wel.
Nodig of niet, feit is wel dat Google websites die via HTTPS geserveerd worden een hogere ranking geeft. SEO-wise is HTTPS dus zeker ook interessant geworden! Zie ook nieuws: Google gaat https-sites hoger zetten in zoekresultaten. Het resources excuus gaat anno 2016 ook niet meer op, het heeft een dusdanig kleine impact nu, dat het echt kinderspel is. Er is dus totaal geen reden meer om websites zonder HTTPS uit te rollen.

[Reactie gewijzigd door CH40S op 10 september 2016 11:24]

En het recente bericht dat alles wat login doet, aankomend jaar door Chrome wordt gemarkeerd als onveilig als op het moment dat je het login scherm krijgt, geen HTTPS gebruikt.

Dus ik zie voor iedereen gewoon het voordeel van deze partij. Ik biedt het ook standaard aan. Elke klant/website van mij geeft HTTPS aanstaan en een A+ ranking op SSL labs.
Zoals ik Watercoolertje begrijp, gebruiken zij al SSL op het moment dat er een login of gegevens gevraagd worden. ;) Ik doelde meer op het feit, dat het ook gewoon handig is om het standaard erbij te doen, ivm een hogere / betere SEO.
hogere betere seo. ssl is 1 klein onderdeel van het google algoritme en natuurlijk help het mee maar het doet geen wonderen.
Daarnaast is er met ssl ook nog de eeuwige discussie dat het eerste contact met een website iets langer kan duren dan zonder ssl.
Snelheid is ook een sleutel in seo en dus kun je stellen aan de ene kant punten voor ssl, aan de andere kant door iets minder snelheid aftrek'.
Blijft natuurlijk koffiedik kijken maar er zijn belangrijkere zaken van ssl als je een hogere ranking wil krijgen.
Anno 2016 is performance ook niet echt een issue meer voor TLS / SSL en aan de andere kant, mede daarvoor is HTTP/2 in het leven geroepen. Als je toch al SSL / TLS gebruikt, is HTTP/2 implementeren slechts een kwestie van oude ciphers er tussenuit halen (oude browsers ondersteunen toch al geen HTTP/2).

Daarnaast is 'eerste contact' ook zo spannend niet meer, men wil het liefste natuurlijk gelijk de gehele webpagina binnen hebben. ;)

[Reactie gewijzigd door CH40S op 10 september 2016 14:22]

ssl is imho echt niet wezenlijk trager dan kaal, ja er zijn enkele extra uitwisselingen voor de eerste zichtbare bytes binnenvloeien

Maar mijn websites (volledig TLS beveiligd op alle pagina's) laden in <1sec volgens pingdom tools uit stockholm, zweden (targetmarkt NL) gewoon gehost op een grote hoster z'n shared server's. Met pagina groottes van hoogstens een half MB....
Het SEO aspect van TLS is inderdaad een zeer klein deel van Googles algoritme. Nauwelijks de moeite waard.

Qua performance is TLS tegenwoordig nauwelijks meer langzamer dan non-TLS, met de juiste instellingen. Zie hiervoor https://istlsfastyet.com/

Als je eenmaal TLS gebruikt is het nog maar een kleine stap naar HTTP/2 en ben je zelfs sneller dan simpele HTTP.

Ik denk dat HTTP/2 daarom de drijvende kracht gaat zijn waarom mensen de komende maanden TLS gaan implementeren. Vanaf 2017 zal de toekomstige "This site is not secure" Chrome UI ook mee gaan helpen.
Klopt, ben het met je eens. Was even ter informatie op jouw bericht om te verduidelijken waarom HTTPS echt aan te raden is, buiten het feit dat het gratis is, en het nu voor iedereen toegankelijk is.
Zoals ik Watercoolertje begrijp, gebruiken zij al SSL op het moment dat er een login of gegevens gevraagd worden. ;)
Dat was de situatie voor let's encrypt ;) Staat toch echt dat het nu dus standaard is het juist wel te doen.

[Reactie gewijzigd door watercoolertje op 11 september 2016 00:06]

En het recente bericht dat alles wat login doet, aankomend jaar door Chrome wordt gemarkeerd als onveilig als op het moment dat je het login scherm krijgt, geen HTTPS gebruikt.
Met een zoek machine heeft Google ondertussen ook weinig meer te maken.
Onderzoek heeft inmiddels aangetoond dat websites waar HTTPS wordt ingeschakeld niet hoger gaan ranken.. Ben de link kwijt, maar iemand had een honderdtal websites gevolgd na het inschakelen van HTTPS en er werd geen stijging in de zoekresultaten waargenomen die kon worden toegeschreven aan HTTPS...
Klopt. Er werd ook altijd gezegd dat het minder dan 1% van de zoekresultaten zou beinvloeden (google webmasters zelf). Het waren de media bedrijfjes en grotere organisaties die allerlei artikelen publiceerde om zo men massaal op betaalde https te verkrijgen.

HTTPS is overigens niet even installeren en klaar is kees, je moet een redirect instellen vanaf http naar https, je moet je code omver gooien om alles vanaf http naar https om te zetten, en vaak de content ook wijzigen dat van http naar https af moet komen.

Meestal kan dat met een find & replace, maar ik ken genoeg situaties dat het exporteren van een wordpress database prima lukt, maar importeer het dan maar eens. ALTIJD testen op een proef-DB of je deze er weer probleemloos in krijgt.
toch ervaar ik het anders, kan toeval zijn. Maar sommigen van mijn pagina's (informatie site met redelijk kleine niche) staan toch wezenlijk hoog in de results terwijl er sites tussen staan op plek 2-3-4 die >5 jaar oud zijn en nog veel bijgewerkt worden. Mijn site mobielvriendelijk/volledig TLS beveiligd, de anderen totaal neit mobielvriendelijk en niet beveiligd (op desktop gekeken)
Mobielvriendelijk is ook iets waardoor je site hoger gaat ranken tov sites die dat niet zijn. De vraag is dus, is dat hoger ranken van jouw sites het gevolg van mobielvriendelijk zijn of van https ? ;-)

Ik heb zelf laatst een nieuwe versie geinstalleerd van ISPConfig (soort van controlepaneel als Directadmin). De nieuwe versie heeft support voor Lets Encrypt ingebouwd. Het enige wat je hoeft te doen om het werkend te krijgen met https is het aanvinken van een checkbox. Aanvragen van het certificaat en installeren daarvan doet het controlepaneel. Heb zo een vijftigtal websites omgezet en heb eigenlijk niets gemerkt. Had wel eens gelezen dat omdat je pagina's met http uit de index verdwijnen en worden vervangen door https pagina's je tijdelijk een terugval in je rankings kunt zien. Heb dat niet waargenomen. Maar hogere rankings ook niet...
ik had geen terugval bij de switch gezien ik een 301 in htacces had voor alle reuquests, waarbij http door https vervangen word, ja zorgt voor extra requests, maar op een gegeven moment is google volledig om (enkele dagen) en komt er geen http request meer binnen uit zoekmachines, alleen wat oude links van forums etc.

verkeer ging stabiel door, en werd meer. Mobiel vriendelijk was hij al vanaf het begin dus daar kan ik geen oordeel over doen ;)

[Reactie gewijzigd door aadje93 op 11 september 2016 11:45]

Geen reden? Ondersteunt LE onderussen dan ook IIS?
Blijkbaar wel; https://weblog.west-wind....crypt-with-IIS-on-Windows Eerste hit met Google.

[Reactie gewijzigd door CH40S op 11 september 2016 07:12]

Ik vermoes dat het veelal om particulieren gaat ipv bedrijven. Deze laatste wensen vaak meer controle of een beter geverifieerd certificaat wat minder vaak verlengt hoeft te worden.
Verlengen gaat gewoon automatisch met een script. De redenatie van 'het is gratis dus het is slecht' slaat ook nergens op. Kijk naar Tweakers, Tweakers gebruikt ook gewoon Let's Encrypt.
Die redenatie doe ik dan ook helemaal niet :? Ik vind let's encrypt een heel mooi initiatief. Er zitten grote voordelen maar ook nadelen aan de implementatie en support etc. Het is aan een ieder om een keuze te maken op basis van zijn / haar eigen wensen en eisen.
Wat zijn dan precies de nadelen? Ik zat namelijk te denken om het ook eens te proberen ipv mijn huidige nogal dure uitgever.
Wellicht is mijn ervaring intussen al outdated, maar ik vond het een hele poos terug een heel groot nadeel dat je site op poort 443 bereikbaar moest zijn, Let's Encrypt checked op dat poortje of je site actief is. (auto-renew)
Als om bepaalde redenen een custom poort adres wilt gebruiken kan dat dus niet zomaar.
Dat zal niet voor iets zijn dat publiekelijk toegankelijk hoeft te zijn maar enkel voor jezelf. Dan kan het ook prima met een self-signed certificaat neem ik aan.
Een webpagina met SSL bedoeld voor publiek, is altijd op poort 443 bereikbaar.
Een webpagina met SSL bedoeld voor publiek, is altijd op poort 443 bereikbaar.
Hoeft niet perse. Er zijn ook genoeg devices met remote management dat SSL ondersteund, die wil je niet altijd public op 443 hebben. Hoewel self-signed op zich prima werkt, is een signed cert soms fijner, al is het maar vanwege de 'waarschuwingen' waar oa. Chrome je mee dood gooit ;)
Dat is dan dus niet voor publiek. Ik geef je wel gelijk dat de optie een poort aan te kunnen geven bij aanvraag ook niet zoveel moeite zou zijn, maar over het algemeen bestellen mensen signed certificates voor public use. Je kunt een self signed certificaat in je eigen browser ook whitelisten zodat je van die 'waarschuwingen' af bent bij je remote management.
Ik heb ongeveer hetzelfde probleem, maar auto-renew kost me praktisch een minuut downtime per 2 maanden.

nginx config wisselen, nginx reloaden, lets encrypt starten, nginx config terugwisselen en weer reloaden.

Uiteraard moet Nginx dan wel de mogelijkheid hebben om naar poort 443 te luisteren.
Ik heb ongeveer hetzelfde probleem, maar auto-renew kost me praktisch een minuut downtime per 2 maanden.

nginx config wisselen, nginx reloaden, lets encrypt starten, nginx config terugwisselen en weer reloaden.
Dat klinkt alsof je let's encrypt je config aan laat passen. Werkt het niet door gewoon een --certonly aan te vragen/renewen en die lokatie van de opgeslagen certs in je nginx/apache config plempen? Hoef je na een renew maar eenmalig je nginx/apache te restarten/reloaden lijkt me?
Nee, dat is jammer genoeg nog steeds zo :)
Maar je kan eventueel DNS challenges gebruiken dan. Is wel iets complexer om op te zetten.
Alternatieve methodes om te valideren komen nog, zoals via DNS. Dat zou in jouw geval moeten helpen.
Draai vanaf de beta mee, eigenlijk geen nadelen tegengekomen, maar dat is alleen mijn ervaring. Sinds de integratie in DirectAdmin etc is het beheer iig makkelijker geworden.
Tevens vind ik dat er goed geluisterd wordt naar de wensen door de ontwikkelaars.
Voor een gratis alternatief is het zeker de moeite waard om eens uit te proberen.
Vooral in DA is het ideaal. Domein aanmaken, SSL aan, en de hele mikmak is volledig ingericht Incl. HTTPS en wordt ook nog eens automatisch vernieuwd.
In het begin was vooral de verificatie vanuit browser nog niet 100%. Dit stadium zijn ze allang voorbij sinds ze uit bŤta zijn. Dus verder zie ik weinig nadelen, behalve dan dat je geen wildcard certificaten hebt.
Alle sites voor onze klanten zijn over op Let's Encrypt waar geen ander type certificaat nodig is. Het scheelt ons een hoop tijd met het uitgeven en vernieuwen van certificaten. En het is nog gratis en geautomatiseerd ook.
De certificaten van Let's Encrypt zijn ook slechts 3 maanden geldig. De meeste betaalde certificaten zijn minimaal een jaar geldig, vier keer zo lang dus. Hierdoor geeft Let's Encrypt logischerwijs ook meer certificaten uit.
LE maakt het mogelijk dat applicaties zelf een SSL-certificaat aanvragen. Dat maakt het niet alleen goedkoper maar ook veel makkelijker. Dat laatste is misschien wel een belangrijker dan het eerste. Je bent niet meer afhankelijk van de goede wil (en het gezond verstand) van een beheerder maar de applicatie doet gewoon zelf wat nodig is.
Precies, de communicatie over het validatieproces is voor ons als webhoster veel vervelender dan de aanvraag en installatie. Je kunt kiezen uit een handvol e-mailadressen en de meeste klanten hebben aan die adressen geen mailbox gekoppeld. Het proces is daardoor nauwelijks te automatiseren.

Let's Encrypt maakt het zo makkelijk dat we een certificaat kunnen aanvragen, valideren ťn installeren binnen 5 seconden. De reverse-proxy https://traefik.io/ kan dat bijv. volledig automatisch doen voor alle domeinen waarvoor requests binnen komen. Zodra een klant hun DNS omzet en een request binnenkomt is het certificaat een paar seconden later werkend.
Let's Encrypt maakt het zo makkelijk dat we een certificaat kunnen aanvragen, valideren ťn installeren binnen 5 seconden. De reverse-proxy https://traefik.io/ kan dat bijv. volledig automatisch doen voor alle domeinen waarvoor requests binnen komen. Zodra een klant hun DNS omzet en een request binnenkomt is het certificaat een paar seconden later werkend.
Ik ben zelf erg blij met de optie om verficatie via DNS te doen. Daarvoor kun je de validatie centraal regelen in plaats van dat iedere server zelf een client moet installeren bereikbaar zijn via het web. Mijn management systeem zet de juiste namen en tokens in DNS en zet uiteindelijk het kant-en-klare certificaat op de servers. Als een applicatie om een certificaat met een bepaalde naam vraagt dan wordt dat "just in time" aangemaakt. Erg prettig.
Vůůr Let's Encrypt gebruikte ik de gratis Startssl.com, elk jaar verlengen.
Nu Let's encrypt geintegreerd is in mijn webhosters DirectAdmin, is het allemaal nog makkelijker.
Eenmalig aanzetten en automatisch vernieuwen, makkelijker kan het niet.

[Reactie gewijzigd door Soldaatje op 10 september 2016 11:15]

Het kŗn makkelijker, door SSL van hen direct te activeren bij het aanmaken van een domein in DA. Nu moet je apart daarvoor naderhand naar SSL toe om 't aan te zetten :+.
Blijkbaar erg populaier hierzo op tweakers :)
Vraagje, hoe werkt dit dan met loadbalancers. Zjn er load balancers die agents ingebouwd hebben, die de certificaten automatisch vetnieuwen ?

En op hun site zie ik bv dat firefox hun certificaten nog niet ondersteund, hoe kun je deze dan implementeren in productie omgevingen ?
https://letsencrypt.org/2...e-trusted-by-mozilla.html

[Reactie gewijzigd door klakkie.57th op 10 september 2016 11:08]

Met loadbalancers werkt het op dit moment niet, ik had een tijd geleden dezelfde vraag uitgezet bij TRUE waar o.a. Tweakers ook hun hosting heeft.

Daar kreeg ik het volgende antwoord op;
Op dit moment bieden wij nog geen support voor LetsEncrypt voor een load balanced opstelling zoals jullie die draaien. De ssl offloading vindt immers al plaats op jullie loadbalancers. Aangezien de certificaten op beide loadbalancers geinstalleerd moeten worden, zodat in een geval van fail-over de boel ook nog blijft werken, vereist dit wat aanpassingen aan de manier waarop LetsEncrypt nu werkt.

Uiteraard zijn we hier wel al wat testjes mee aan het doen en zijn we ook naar de mogelijkheden aan het kijken om dit een een load balanced setup in te kunnen zetten. Wanneer we dit officieel gaan supporten is op dit moment nog niet bekend.
Als je het goed leest staat er dat de certificaten op dit moment wel vertrouwd worden omdat ze met IdenTrust root-certificaat samenwerken:
Getting a new root trusted and propagated broadly can take 3-6 years. In order to start issuing widely trusted certificates as soon as possible, we partnered with another CA, IdenTrust, which has a number of existing trusted roots. As part of that partnership, an IdenTrust root “vouches for” the certificates that we issue, thus making our certificates trusted. We’re incredibly grateful to IdenTrust for helping us to start carrying out our mission as soon as possible.
Dus in Firefox werkt het ook.

[Reactie gewijzigd door Soldaatje op 10 september 2016 11:14]

Goed om te weten !
Maar is het dan niet zo dat wanneer er een haar in de boter zo komen tussen beide partijen , plots alle certificaten van let's encrypt niet meer geldig zouden zijn ?
Ja. Of als Mozilla het IdenTrust-certificaat eruit haalt, ongeldig verklaard.
Zoals met DigiNotar, hopelijk is daarvan geleerd.
Ik begrijp nogsteeds niet wat een SSL-certificaat precies is. Wie of wat bepaalt wanneer iets gecertificeerd is?

[Reactie gewijzigd door SoundByte op 10 september 2016 16:44]

Wie of wat bepaalt wanneer iets gecertificeert is?
Dat bepaal je zelf!!!!!!!!!

Bij het opzetten van een beveiligde verbinding (TLS, in de volksmond nog steeds SSL) stuurt de server een certificaat op waarin de identiteit en de publieke sleutel (public key) van de server vermeld zijn. Met deze sleutel kan de client het verkeer over de beveiligde verbinding versleutelen.

Echter: hoe weet de client dat het van de server ontvangen certificaat authentiek is. Ofwel: hoe weet je dat er geen man-in-the-middle is die zich middels een vals certificaat als de server voordoet?

Om die reden zijn de certificaten digitaal ondertekend door een certificaat autoriteit, ofwel Certificate Authority, kortweg aangeduid als CA. Door de digitale CA-handtekening in het server-certificaat te verifiŽren kan bepaald worden of het van de server ontvangen certificaat authentiek is.

Echter, om de digitale handtekening van het server-certificaat te verifiŽren heb je het (publieke) certificaat nodig van de CA (CA-Certificate). En zo krijg je een beetje een kip-en-ei verhaal, want hoe weet je of het CA-Certificate authentiek is?

In een ideaal-veilige omgeving bepaal je zelf of een CA-Certificate authentiek is, en vervolgens sla je het CA-Certificate op in een trust-store (opslag met vertrouwde CA-Certificaten) zodat ze door de computer/telefoon/tablet/webbrowser gebruikt kunnen worden voor het verifiŽren van server-certificaten.

Echter, niemand houdt met de hand de trust-store bij die door z'n computer/telefoon/tablet/webbrowser gebruikt word. In vrijwel alle gevallen word gebruik gemaakt van de trust-store die met het operating-systeem/web-browser meegeleverd word. In dat geval bepaal je zelf dat je de leverancier van het OS of de browser kunt vertrouwen met de taak de meegeleverde CA-Certificaten te verifiŽren.

In feite bepalen dus Google, Microsoft, Apple, Mozilla, enz. wat er wel/niet gecertificeerd is. Omdat het CA-Certificate van Let's Encrypt is opgenomen in de standaard meegeleverde trust-stores valt je browser je niet langer lastig met beveiligings-waarschuwingen wanneer je een site bezoekt die gebruik maakt van een door Let's Encrypt getekend server-certificate.

In het kort: we hebben massaal bepaald dat we ons vertrouwen bij voorkeur delegeren naar bedrijven als Google, Microsoft, Apple, Mozilla, enz.
Een mooie mijlpaal! Voor het grootste deel natuurlijk gehaald omdat het gratis is. Ik vind let's encrypt een mooi initiatief maar ben ook van mening dat er nog stappen gezet kunnen worden om het geheel nog gebruiksvriendelijker te maken. Het proces rond aanvragen en verlengen zou geoptimaliseerd kunnen worden. Ook hoop ik op meer ondersteuning vanuit software en hardware leveranciers zodat je bijvoorbeeld vanuit router firmware direct een certificaat kunt verkrijgen. O.a. Synology biedt ondersteuning voor let's encrypt in hun DSM software maar raar genoeg niet in de SRM voor hun routers.
Verstrekt Let's Encrypt dan ook certificaten voor lokale subnet-ranges, dan wel niet bestaande domeinnamen? Dat lijkt me een significant probleem. LE kan niet de authenticiteit van 192.168.0.1 oid garanderen omdat er daar miljoenen van zijn. Daarmee is een certificaat dus ook waardeloos. Een self-signed certificaat is daarmee eigenlijk beter, dan krijg je (eenmalig) de waarschuwing en gelegenheid om handmatig de authenticiteit te valideren, en daarna niet meer (als je de bevestiging opslaat natuurlijk).

Voor publieke subnetten en IPv6 wordt dat een heel ander verhaal natuurlijk.
Op dit moment worden certificaten op basis van domeinnaam uitgegeven. Let's encrypt gebruikt hier het ACME protocol voor.

https://letsencrypt.github.io/acme-spec/
En dat werkt niet voor https://192.168.0.1/ ofwel voor https://router.lan/ omdat die niet middels email, DNS of webserver geverifieerd kunnen worden. Dat maakt LE vrij nutteloos voor gebruik in (home) routers. Wat zou Synology er dan mee in SRM moeten?
Volgens mij wordt dat sowieso door geen enkele partij geaccepteerd. Deze domeinen zul je lokaal met een eigen CA moeten doen.
Als je eigenaar bent van het externe domein(dat je dan enkel intern gebruikt) kan dit natuurlijk wel gewoon.

Moet je zelf wat afwegen of een intern domein opzetten en die 8 euro per jaar register kosten erbij nemen wel de moeite waard zijn ..
Klopt, maar in dit geval ging het om .lan en .local
ja, was maar puur ter info voor de minder technische mensen hier dat dit wel kan voor je intern netwerk als je eender welk publiek domein in je bezit hebt.

Vond de originele comment van MadEgg ietwat bizar, certificaten gaan natuurlijk altijd waardeloos zijn bij iets waarvan niemand kan controleren of het wel geldig is, certs in een intern netwerk is pure quality of life, niet zoveel met security te maken in dat geval.
Je kan gewoon een echt domeinnaam gebruiken intern en gebruik maken van DNS validation om zo een certificaat te krijgen.

Gestel ik gebruik domeinnaam murfy-ops.net voor lokale zooi, bijvoorbeeld lokale-prut.murfy-ops.net, dat is niet publiek toegankelijk dan. Via DNS validation kan ik toch een SSL certificaat automatisch verkrijgen op dat domein omdat het wel echt bestaat.

De opzet ervan is wel iets complexer maar eens het opgezet is verloopt het toch automatisch.
Er is domeinnaam validatie nodig volgens de site van let's encrypt. Anders zou het ook geen meerwaarde bieden tegenover self signed certificaten.
Ik kon in virtualmin alleszins geen certificaat aanmaken indien het niet mogelijk was om een identificatie bestand van de domeinnaam te downloaden.
Verstrekt Let's Encrypt dan ook certificaten voor lokale subnet-ranges, dan wel niet bestaande domeinnamen? Dat lijkt me een significant probleem. LE kan niet de authenticiteit van 192.168.0.1 oid garanderen omdat er daar miljoenen van zijn. Daarmee is een certificaat dus ook waardeloos.
Volgens mij zijn er niet veel CA's die dat wel nog doen. Ook de CA's willen een vorm van bewijs dat jij (de enige) eigenaar van een domein bent.
Een self-signed certificaat is daarmee eigenlijk beter, dan krijg je (eenmalig) de waarschuwing en gelegenheid om handmatig de authenticiteit te valideren, en daarna niet meer (als je de bevestiging opslaat natuurlijk).
In theorie wel, ik praktijk zullen de meeste gebruikers altijd op "ACCEPT" klikken, ook al is het derde keer die dag dat ze een ander certificaat krijgen.

Er is een mooie oplossing: DANE/TLSA. Je publiceert de fingerprints van je certificaat (of van je CA) in DNS. Langs die weg kunnen bezoekers (automatisch) controleren of ze het juiste certificaat hebben gekregen. Je hebt wel DNSSEC nodig maar in .NL is dat geen probleem.
Wat bedoel je met geoptimaliseerd worden? Er zijn zovele scripts die het proces bijna volautomatisch laten verlopen dat ik zelf nog weinig ruimte voor verbetering zie.
Een script is handig maar nog steeds niet eenvoudig genoeg voor een doorsnede eindgebruiker. Echt makkelijk te gebruiken applicaties voor het afhandelen van de life cyclus van een certificaat zijn er niet of te technisch nog. Op bijvoorbeeld hardware waar geen directe ondersteuning is voor de aanvraagprocedure blijft het voor veel mensen aanmodderen met externe scripts.

[Reactie gewijzigd door Bor op 10 september 2016 10:15]

Wat ik dan wel weer een erg positieve stap vind is dat bijvoorbeeld hosting provider vimexx let's encrypt in de directadmin omgeving heeft ingebouwd. Schijnbaar zijn zulke simpele oplossingen toch mogelijk..
Zulke oplossingen zijn zeker mogelijk en vaak zelfs ook nog redelijk eenvoudig te realiseren omdat er gewoon scripts geleverd worden voor het aanvragen en verlengen etc.
Er zijn stiekem best wel wat Nederlandse hostingproviders die Let's Encrypt aanbieden. Tegenwoordig zit het volgens mij zelfs standaard in DirectAdmin en cPanel/WHM, voorheen was het via een 3rd party script mogelijk om alsnog een interface te bieden waarmee klanten met 1 klik een Let's Encrypt certificaat aan konden vragen.
Het zit inderdaad standaard in DirectAdmin sinds versie 1.5.

De implementatie is tussenin wel eens gewijzigd maar het werkt voor de rest feilloos (bij mij toch).
Ik begrijp wat je zegt maar ik denk dan ook dat de 'doorsnee' gebruiker geen certificaten gaat installeren, het lijkt me dat een it-specialit dit uitvoert. Ik verwacht niet dat de marketing afdeling de ssl-certificaten gaat installeren. En als een it-specialist niet met externe scripts om kan gaan, mag die wel ff gaan bijscholen.
Een script is handig maar nog steeds niet eenvoudig genoeg voor een doorsnede eindgebruiker. Echt makkelijk te gebruiken applicaties voor het afhandelen van de life cyclus van een certificaat zijn er niet of te technisch nog. Op bijvoorbeeld hardware waar geen directe ondersteuning is voor de aanvraagprocedure blijft het voor veel mensen aanmodderen met externe scripts.
Grote applicaties zoals CMS en admin panels zijn allemaal druk bezig met LE-modules die het aanvragen van een certificaat helemaal automatiseren. Perfect zal het nooit worden maar het gaat momenteel wel hard met de verbeteringen.
Er zijn nog redelijk wat punten waarbij het beter kan. Tuurlijk: het simpelste namelijk aanvragen en vernieuwen werkt prima maar er zijn meer aspecten. Bijvoorbeeld: public key pinning (hpkp) i.c.m. LE kan veel beter. (Of Dane/TLSA bijvoorbeeld.)

[Reactie gewijzigd door neokarasu op 10 september 2016 16:03]

Voor DANE/TLSA veranker ik aan de intermediate CA "Let's Encrypt Authority X3" via de "2 1 1" usage flag. Met een LE-certificaat dat zo vaak vernieuwd wordt is het moeilijk om het 'leaf'-certificaat zelf te verankeren. Als je kunt zorgen dat je telkens dezelfde CSR gebruikt kun je dat overigens wťl doen, maar dat vereist wat aanpassing bij de meeste LE-clients.

Voor mij zou het toevoegen van DNS-validatie nog wel gemak toevoegen.
Een mooie mijlpaal! Voor het grootste deel natuurlijk gehaald omdat het gratis is.
En dat je eens in de drie maanden het certificaat moet vervangen ipv jaarlijks. Gelukkig kan het geautomatiseerd, maar daardoor heb je wel 4 certificaten per jaar nodig ipv 1. De dienst is nu 10 maanden bezig, dat betekend dus, als je een actieve domein hebt vanaf het begin, dat je nu al aan je vierde certificaat zit, doe dat voor meerdere domeinen (en eventuele subdomeinen) en dan gaat het gewoon keihard.
Ik heb een vraag,
Hoe kun je een Let's Encrypt certificaat in een FreeNAS server importeren en gebruiken?
Momenteel gebruik ik een eigen certificaat maar dit is niet handig als ik bijvoorbeeld Owncloud wil bereiken op school (daar gebruiken we alleen Chrome en Internet explorer geen Firefox helaas anders kon ik een uitzondering toevoegen).
Je kan op de CertBot site kiezen wat je wilt signen en dan op wel os je dat wilt doen.

Bijv CLI op FreeBSD: https://certbot.eff.org/#freebsd-other maar even rond kijken online zal vast wel een plugin bestaan om dit automatisch te doen naderhand
Kan je op FreeNAS geen cronjob instellen? Mijn Linux bak thuis met van alles en nog wat incl gitlab server heeft nu ook Let's Encrypt met auto renewal.
Ja dat kan. Ik weet alleen niet hoe dat werkt in combinatie met de OwnCloud plugin. Waarschijnlijk zul je dan wat custom werk moeten verrichten.
Ik gebruik nu een aantal certificaten van let's encrypt op mijn Mumble servers, maar alleen omdat het gratis is en ik het een fijn gevoel vind om er een te hebben. Zou ik er voor moeten betalen dan zou ik deze certificaten nooit instaleren. Fijn om te hebben, maar voor mijn niet zo'n noodzaak dat ik er veel geld voor over zou hebben, wat ook niet zou moeten, het is niet meer van deze tijd om geld te vragen voor een beetje veiligheid op het web.
Het is meer dan alleen een fijn gevoel. Het is veiliger. Ik heb in cPanel van mijn web hoster voor alle domeinen een LE certificaat aangemaakt. Dat is met een paar keer klikken gebeurd en dan heb je er geen omkijken meer naar. Alle domeinen verwijzen automatisch door naar HTTPS middels een paar regels code in .htaccess. Zelfs de cpanel, whm en webmail logins gaan automatisch naar HTTPS omdat je heel makkelijk per subdomain een apart certificaat kunt aanmaken. Op deze manier kan er nooit iemand meekijken wat er over de verbinding gaat en zo zijn wachtwoorden ook meteen een heel stuk veiliger.

De web hoster (Neostrada) stapt binnen een maand of twee ook over op HTTP2 / SPDY. Op die manier worden de websites ook nog eens een stukje sneller omdat het aantal server requests flink zal dalen. Zo heeft Let's Encrypt meerdere voordelen voor de eindgebruiker. Prachtig initiatief.
Voor mijn vrienden site heb ik het afgelopen week geregeld, werkt perfect.
Nog een weetje van de statussite:
Dat 1,35% (4412 certificaten) van alle certificaten op een .nl-domein zijn geregistreerd.
Bij .com-domeinen is dit 28,5% (zo'n 92,851 certificaten).

Het is een goed initiatief voor het beveiligen van alle websites zonder dat het (veel) geld kost.
Je ziet al snel dat het voor alleen voor Domeinvalidatie al snel §10,- per jaar is en dat je bij TransIP voor Domeinvalidatie met al je subdomeinen al §65,- per jaar betaald. Dan nog geen eens over de uitgebreidere pakketten gehad. Uitgebreide validatie: TransIP: §100,-/jaar PCextreme: §33.- tot §288,- per jaar.
Op deze manier zijn SSL-certificaten een stuk bereikbaarder.
Ik betaal voor een betaalde certificaat 4 dollar per jaar (COMODO). Voor dat geld hoef je dus niet vier keer per jaar te verlengen. Ok, inmiddels zijn er scripts die LE automagisch doen verlengen, maar toentertijd heb ik expliciet er voor gekozen om toch een betaalde cert te nemen, want ik beheer een tientallen domeinen.

Misschien toch uit kosten overweging toch eens kijken naar LE. Kan me gemiddeld 120 dollar per jaar opleveren, maar dan moet het automatiseren van het verlengen wel feilloos gaan anders zit ik nog met al dat werk :)
DirectAdmin schijnt tegenwoordig een script te hebben waarmee je certificaten automatisch verlengd worden en je ze direct via de software kan aanvragen en installeren ;) Op het forum van TransIP staat een tutorial hierover: https://www.transip.nl/forum/post/prm/4543

DirectAdmin: https://www.directadmin.com/
Van de week op windows 2012 een command line tool gezet die alles automatisch doet. Geen omkijken meer naar.
Ik gebruik het omdat het gratis is en omdat het zo makkelijk gaat. Met de officiŽle plugin van DirectAdmin heb je met een paar tellen klikken een certificaat wat nog automatisch verlengd wordt ook. Voor echte serieuze websites adviseer is nog steeds een betaalde omdat die ook garanties bied.
Mooi om te lezen. Ik heb net gisteren een stel van mijn sites op https gegooid via Let's Encrypt. :)


Om te kunnen reageren moet je ingelogd zijn



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True