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 , , 95 reacties
Submitter: Rafe

Het Let's Encrypt-project heeft de bètafase afgesloten en meldt dat er sinds september meer dan 1,7 miljoen certificaten zijn uitgegeven voor ongeveer 3,8 miljoen verschillende websites. Ook heeft het project een aantal nieuwe sponsors aan weten te trekken.

Let's EncryptZo hebben de sponsoren Cisco en Akamai opnieuw toegezegd het project te steunen; dit doen zij voor de komende drie jaar. Andere sponsoren die het project steunen zijn onder andere Gemalto en HP Enterprise, zo bericht Let's Encrypt. Volgens Stephen Ludin, Chief Architect bij Akamai, is deze mijlpaal het bewijs dat het project zijn doelstellingen waar kan maken en dat het een enorme invloed kan hebben op het ecosysteem van het internet.

Ongeveer een maand geleden gaf de Certificate Authority zijn miljoenste ssl-certificaat uit, toen lag het aantal van certificaten voorziene domeinen op 2,5 miljoen. Met het sluiten van de bètafase heeft de publieke bèta ongeveer vier maanden geduurd vanaf de aankondiging in december 2015. Het bèta-label werd gebruikt om aan te geven dat er nog het een en ander moest gebeuren voordat de dienst betrouwbaar werkt op een groot aantal platforms.

Het doel van Let's Encrypt is om uiteindelijk het hele internet veiliger te maken. Daarom is het belangrijk dat het uitgeven van de gratis ssl-certificaten zo eenvoudig en stabiel mogelijk verloopt.

let's encrypt stats april    de meest recente Let's Encrypt-statistieken

Moderatie-faq Wijzig weergave

Reacties (95)

Maak er zelf gebruik van. Echter kunnen sommige API services niet omgaan met de certificaten waardoor ik toch moest overstappen op een betaalde variant. Blijf het wel een top service vinden!
Daar heb ik nog niet van gehoord, de certificaten zijn standaard RSA/SHA256 normaalgezien. Buiten IE7- op Windows XP en Java 6 clients zou je geen problemen mogen ondervinden.

Kan je een voorbeeld geven van een dienst die niet werkt?
Bij mij werkt de certificaat niet met de Instagram API service en Skype API service. Deze keuren de certificaat van let's encrypt af. Let op, dit gaat dan vooral om webservices waarmee ik connect via PHP.
Klinkt alsof je je CA chain niet goed ingesteld hebt.
Heel mooi project, maar ik hoop wel op ondersteuning voor bijv. Apache voor Windows in de nabije toekomst. Ook vraag ik me af hoe je een certificaat kunt aanvragen (en automatisch verlengen) voor devices die niet direct aan het grote boze internet hangt, bijv. mijn Synology. Ze willen namelijk het apparaat kunnen benaderen voor zover ik kan zien.
Portforwarding en fatsoenlikke firewall voor poort 80 uit mn hoofd.
Het domein moet inderdaad bereikbaar zijn van buitenaf om te controleren of het wel van jou is.

Ik heb een situatie waar ik het certificaat op een lokale router nodig heb. Dus maak en update ik het certificaat op een webserver en met dit domein en kopieer het vervolgens naar de router. Op de router heb ik een static domeinnaam naar het lokale adres geconfigureerd.
Kan via de DNS ook, word er een TXT veld aangemaakt ...
Mooi. Weet iemand of er ergens al een handleiding online staat hoe je een Synology NAS kan configureren met Let's Encrypt?
Bedoel je iets als dit?

https://stefandingemanse....tificate-on-synology-dsm/

Alternatieve opties:
http://blog.mobile-harddi...ssl-certificaat-synology/

Waar ik trouwens tegenaan loop is dat ik drie Syno's achter de router thuis heb staan. Let's encrypt heeft directe toegang tot poort 80 nodig - en dat doorlopend vanwege de korte geldigheid/updates.

Heeft daar iemand tips over?

[Reactie gewijzigd door TRS-3 op 12 april 2016 19:50]

Geen idee of dit werkt, maar je zou een synology als reverse proxy http requests op basis van opgevraagde domeinnaam kunnen doorsturen naar een andere synology :)
De moeite waard om te proberen, dank
Het is wellicht mogelijk om de webroot methode te gebruiken, deze methode plaatst een bestandje in de root van de web directory (i.e. /var/www) die via HTTP beschikbaar wordt gemaakt.

Meer informatie: https://letsencrypt.readt...latest/using.html#webroot
Waar ik tegenaan loop is dat ik drie Syno's achter de router thuis heb staan. Let's encrypt heeft directe toegang tot poort 80 nodig - en dat doorlopend vanwege de korte geldigheid/updates.

Heeft daar iemand tips over?
Niet aangegeven, maar het klinkt of je werkt met een enkel (IPv4?) IP Heb je IPv6? Dan heb je vast meer dan een IP en kun je ze allemaal direct op poort 80 benaderen.
je kan met DNS ook verifiëren ...
Control panel / Security / Certificate / Add.
Create new, Lets Encrypt staat bij de eerste optie.
Daarna de stappen even doorlopen, het is simpel en werkt.

Als je een VPN naar je NAS had moet je wel even het nieuwe certificaat aanmelden bij die verbinding natuurlijk.
Duckduckgo staat vol met succes verhalen
Zie ook in de commentaar sectie van het DSM 6 artikel: downloads: Synology Disk Station Manager 6.0 build 7321
Thanks, waar de meeste mensen aangeven dat je een eigen domain moet hebben staat hier uitgelegd dat het ook om de service van Synology zelf werkt.
Super simpel!
in de laatste DSM zit het al ingebouwd; gewoon aanzetten
1,7 miljoen certificaten zijn uitgegeven voor ongeveer 3,8 miljoen verschillende websites
Dat is gemiddeld 2,2 website per certificaat. Ik vraag me af hoeveel van die certificaten voor website.tld en daarnaast www.website.tld zijn. Ik denk verreweg de meeste.
Hoeft niet: website.tld en www.website.tld kunnen op basis van DNS naar dezelfde site verwijzen en dan is er dus maar 1 site en certificaat nodig :)
Klopt, maar dat zijn wel twee SAN-namen in één certificaat. Vermoedelijk telt Let's Encrypt die mee, anders komen ze toch nooit op zo'n hoog aantal sites?
Dat denk ik ook. Bijvoorbeeld met DirectAdmin worden deze twee al automatisch aangevraagd bij het inschakelen van Let's Encrypt.
Erg fijne organisatie. Ik heb nu al een tijdje de let's encrypt plesk-plugin draaien. Appeltje eitje om een certificaat aan te vragen. Het vernieuwen ervan (half jaarlijks uit mijn hoofd?) gaat automatisch.

Enige jammere is dat het niet werkt voor de mailserver, maar gelukkig zijn er altijd andere met het zelfde probleem: https://github.com/Powie/plesk_mailcert

Ik ben er erg tevreden mee, als lichte gebruiker.
90 dagen is je certificaat geldig.
90 dagen geldig, op Plesk wordt dit elke maand geforceerd :)
Is er eigenlijk al goede ondersteuning voor NGINX en Public Key pinning? Want als je certificaat telkens verandert kan het wel lastig zijn voor Public Key Pinning denk ik.
Zolang je steeds dezelfde keys gebruikt voor je certificaat is pubkey pinning niet vervelend, certificate pinning juist wel.

Voor nginx zijn er vanaf dag 1 al diverse oplossingen te vinden, even googlen ;)
HPKP pint de public key, niet het certificaat. Je hoeft je keys niet elke keer opnieuw te genereren, dus LE staat het gebruik van HPKP niet in de weg.

Overigens meen ik dat je ook de CA key kunt pinnen ipv jouw key, dat maakt 't nog makkelijker.
Maar websites met een Let's Encrypt certificaat krijgen een 'onveilig' slotje in Firefox (security certificate can not be verified). Wat is daar het nut dan van? (voorbeeld)

[Reactie gewijzigd door Kalief op 12 april 2016 19:23]

Heb je een test uitgevoerd op ssllabs.com? Daar komt meestal uit wat er aan de hand is, bijvoorbeeld of er compatibiliteitsproblemen zijn met specifieke browsers. Chrome geeft bij mij een groen slotje.
Is een goede tip.
Mijn FF en Chrome geven 'onveilig' maar TOR geeft groen licht.
SSLlabs suggereert een firewall-iets.
Gebruik je een oude versie van Firefox? Bij het voorbeeld dat je gaf krijg ik in Firefox 45.0.2 gewoon een groen slotje.
Wellicht staat of stond er inhoud op deze pagina welke niet werd ingeladen via HTTPS (bijvoorbeeld een extern ingeladen afbeelding, stylesheet, etc.). De ene browser laadt deze inhoud simpelweg niet, andere browsers geven het wel weer maar tonen een waarschuwing en / of geen slotje meer.
ook hier geen enkel probleem met firefox, ook niet het voorbeeld dat je gaf
Met Chrome en Firefox ook gewoon een groen slotje hier.
Mooie dag! Erg mooi project.
Is nu dat limiet van x-certificaten per domein ook opgehoogd/weg?
Waarom?
Je hebt maar 1 certificaat nodig en je kunt 100 subdomeinen aanmaken. Per domein kun je 5x per week een certificaat aanvragen en dat lijkt mij meer dan genoeg. Een keer per 80-90 dagen even automatisch vervangen en klaar weer.

Er is trouwens een optie om te testen zodat je niet de eerste dag door je limiet heen gaat. Je krijgt dan een 'hack' certificaat.
Als je voor meer dan 5 subdomeinen een certificaat wil moet je dat over meerdere weken uitsmersen. Dat is bijzonder onpraktisch.

Edit: Toevoeging iets verder naar beneden.

[Reactie gewijzigd door Alpha Bootis op 12 april 2016 19:57]

Nee je begrijpt het niet. Per certificaat kun je 100 subdomeinen opgeven. Dus heb je maar één certificaat nodig.
Excuus ik had daarbij moeten toevoegen dat het dan ook gaat om verschillende machines gaat in mijn geval.
In de praktijk kan dat vorm krijgen in bijvoorbeeld een virtuele host met een hele sloot gevirtualiseerde applicaties in hun eigen containers.
Dan is het nog niet nodig. Je maakt het certificaat één keer en zet een kopie op alle andere machines.
Dat werkt alleen als ze allemaal achter hetzelfde IP adres zitten. En dan zit je ook nog met de verversing van die certificaten elke 90 dagen.

[Reactie gewijzigd door Alpha Bootis op 12 april 2016 20:14]

Volgens mij is een certificaat niet IP gebonden toch? (kan het mis hebben)
Klopt, het IP adres maakt niets uit. Gewoon kopiëren en klaar.

Overigens kan dat met betaalde certificaten meestal ook.
Dat is beveiligingstechnisch en in dit geval onderhoudstechnische zeker niet de aanbevolen oplossing! Je private keys wil je juist private houden, en het bijwerken van de certificaten gaat, tegen stelling tot de machine waarop de aanvraag gedaan wordt, niet automatisch.
@BobV
Wat is dat nou weer voor kletskoek. Als je niet eens je machines onderling kunt beveiligen dan is er iets heel anders grondig fout.

Er is niets op tegen om op een plek de certificaten aan te maken en vervolgens te distribueren.
Je kunt het zeer eenvoudig automatiseren en onderhouden. Sterker nog, het onderhoud van de certificaten op één plek zou mijn voorkeur juist hebben vanwege het onderhoud.

Het wordt ook met betaalde certificaten gedaan en daar is op zichzelf ook niets mis mee.
Je snapt duidelijk niet wat de gevolgen kunnen zijn van het delen en versturen van de private keys over een netwerk.

Zodra je private key onderschept wordt (en dat hoeft maar ergens te zijn, een van de servers hoeft maar een klein lekje te hebben), zijn gelijk alle servers getroffen.

Ja, het kan om het te delen. Nee, het is zeker niet de aanbevolen methode.
Ik snap het juist heel goed. Je moet er ook niet onvoorzichtig mee omgaan. Dus een key over een onbeveiligde verbinding versturen is niet zo'n goed plan nee. Maar als je verbinding wordt onderschept, gekraakt of op wat voor andere manier open staat, dan helpt een certificaat sowieso niet erg goed.

Je moet niet iets niet doen omdat je onderbuik zegt dat het misschien onveilig zou kunnen zijn. Je kan beter de boel goed op orde hebben en weten waar de eventuele problemen zijn.
Klopt, het IP adres maakt niets uit. Gewoon kopiëren en klaar.

Overigens kan dat met betaalde certificaten meestal ook.
Inderdaad, ik heb zelf net ook even gekeken hoe dit zit.

Je kan gewoon de certificaat aanvragen op de server waar het hoofd domein draait, en daarna die certificaat eventueel ook kopiëren naar je andere servers waar je subdomeinen draaien.
Je hebt blijkbaar gelijk, misvatting van mijn kant, maar volgens mij alsnog onwenselijk.
Die certificaten hebben een hoog verloop dus moet je ook weer een uitwisseltraject gaan automatiseren tussen al die containers terwijl het isoleren van al die containers nou net één van USP's is van op die manier werken. ;)

LE moet gewoon dat limietje een beetje ophogen, dat is de meest elegante oplossing. Ik weet niet beter dan dat dat limiet er alleen voor de beta was, vandaar dat ik er ook over begon. Ik wil niet pretenderen ergens recht op te hebben verder maar als ze willen dat iedereen LE certificaten gaat gebruiken overal... :)

[Reactie gewijzigd door Alpha Bootis op 12 april 2016 20:23]

Gewoon op elke container een cron die elke dag even via SCP het certificaat ophaalt en het op de juiste plek zet.

Maar dat had je misschien zelf ook al bedacht. ;)

Ik geef toe het is niet ideaal, maar het is wel makkelijk op te lossen.
Kan wel, 'mag niet'. Vaak staat er bij de meeste certificaatboeren dat een SSL certificaat per server geldt. Maar ik denk niet dat er iemand is die dat ook echt doet, aangezien het amper te controleren is (en volgens mij ook niet wordt gedaan).
Nee, per subdomain kan je gewoon een request doen.

Misschien heb je hier wat aan: letsencrypt.org - Multiple subdomains

[Reactie gewijzigd door defixje op 12 april 2016 19:58]

Misschien als 'grootgebruiker' dan toch maar betalen bij een van de andere 600+ CA's O-)

Of een wildcard certifciaat aanvragen ...
Misschien ook niet. LE's certificaten voldoen verder prima.
Zeker voor ad-hoc toepassingen erg handig.
Ik heb flink getest met LE en we hebben het nu ook in een SaaS oplossing in productie genomen.

Op een gegeven moment hadden we 70 (sub)domeinen in 1 certificaat. Dat was verre van ideaal omdat de handshake dan erg lang duurt. Nu hebben we voor elk domein een apart certificaat met alleen subdomeinen van dat betreffende domein en dat gaat uitstekend.
Waarom niet gewoon een wildcard certificaat?
Wordt niet ondersteund door Let's Encrypt op dit moment.
Geweldig project! Samen met de Caddy webserver heb ik nu een aantal sites geheel gratis en geheel probleemloos out of the box met SSL draaien. Kan dit van harte aanbevelen aan elke developer / beheerder.
Werkt natuurlijk ook prima met andere webservers, maar dan is wel wat configuratie vereist.
Ik draai zelf al een tijdje Caddy en was altijd enorm fan. Maar de ondersteuning voor automatische SSL certificaten mbv Let's Encrypt heeft Caddy enkel maar beter gemaakt.

Ondertussen komen al mijn certificaten van LE en draait (bijna) alles op Caddy.

Op dit item kan niet meer gereageerd worden.



Nintendo Switch Google Pixel Sony PlayStation VR Samsung Galaxy S8 Apple iPhone 7 Dishonored 2 Google Android 7.x 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