Let's Encrypt rondt vernieuwd acme-protocol af en voegt wildcardcertificaten toe

Let's Encrypt heeft bekendgemaakt dat het traject rond wildcardcertificaten is afgerond en dat deze nu ook beschikbaar zijn. Daarnaast heeft de organisatie zijn acme-protocol vernieuwd, waarmee gebruikers een certificaat voor hun website kunnen verkrijgen.

Josh Aas van de Internet Security Research Group, die achter Let's Encrypt zit, maakt de beschikbaarheid van wildcardcertificaten in zijn aankondiging bekend. Deze certificaten hadden eigenlijk al eerder beschikbaar moeten komen, maar werden uitgesteld. De aankondiging van de certificaten vond in de zomer van vorig jaar plaats. De toevoeging maakt het voor Let's Encrypt-gebruikers mogelijk om een enkel certificaat voor een domein inclusief alle subdomeinen te gebruiken, wat het makkelijker maakt om een heel domein van https te voorzien.

In de bekendmaking schrijft Aas dat bovendien het acme-protocol is vernieuwd in de vorm van acmev2, dat het IETF-standaardiseringsproces heeft doorlopen. Alleen met deze versie is het mogelijk om van de nieuwe wildcardcertificaten gebruik te maken. Een tweede vereiste voor deze certificaten is dat domeinvalidatie plaatsvindt aan de hand van een dns-01-challenge, die een aanpassing van de txt-record vereist. Om gebruik te maken van het vernieuwde protocol is bovendien een compatibele client nodig. Er zijn verschillende mogelijkheden op dat gebied, zoals de door Let's Encrypt aangeraden Certbot.

Op den duur moet er een volledige overgang naar acmev2 plaatsvinden, al is er nog geen end-of-life-tijdstip voor de voorganger vastgesteld. Let's Encrypt is een dienst die het mogelijk maakt om gratis certificaten voor een domein aan te vragen, om zo een beveiligde https-verbinding mogelijk te maken.

Uitgegeven Let's Encrypt-certificaten per dag, via Let's Encrypt

Reacties (88)

[MSalters]

Ik blijf het opmerkelijk vinden dat een club die HTTPS zo belangrijk vindt nog steeds geen HTTPS ondersteunt.

Om preciezer te zijn: acme v1 methode "HTTP-01" vereist dat je een file aanbiedt via HTTP poort 80, unsecured. Om met HTTPS te beginnen is dat logisch; het zou niet werken als je een HTTPS certificate moet hebben om je eerste HTTPS certificate aan te vragen.

Maar voor verlenging zou HTTP niet nodig hoeven zijn. Nadat je de server secured op poort 443 hebt, zou je poort 80 dicht moeten kunnen zetten. Dat is echter niet hoe acme v1 werkt. Er is geen "HTTPS-01" methode, die kregen ze niet werkend.

Ik snap dat HTTPS complex is. Het kost mij elk kwartaal ongeveer een halve dag om een nieuw certificate werkend te krijgen. De standaardisatie van zulke certificaten is tenenkrommend slecht. Zo ongeveer elke webserver heeft z'n eigen idee hoe een certificaat aangeleverd moet worden. Maar juist bij een club als Let's Encrypt zouden ze HTTPS goed genoeg moeten begrijpen om certificaat-verlenging via HTTPS te realiseren.

En als we toch software voor de 21ste eeuw aan het ontwerpen zijn: waarom moet je de certificaten voor een webserver aanleveren via het file systeem? Het is een webserver, de normale manier om data naar een webserver te versturen is HTTP POST.

[Blokker_1999]

En dan loopt er iets mis, zijn je certs ongeldig en gaat certbot proberen te vernieuwen op een ongeldige https verbinding waarna het systeem zegt: fail. Als http voldoende is voor de initiële setup zie ik niet direct wat het probleem is om de verlenging er ook mee te doen.

En stel jij nu werkelijk voor om bij initiële setup een HTTP POST te gaan gebruiken? Met andere woorden: verstuur alles maar zonder gebruik te maken van enige vorm van encryptie?

[MSalters]

Yup. Ik stel bovendien voor om die HTTP post te doen via een beheersinterface, dus niet via de publieke poort 80. Encryptie is niet nodig als het LAN veilig is.

Maar vergeet niet: tijdens de initiele setup is de kans heel klein dat iemand je server spontaan ontdekt in het kleine interval dat je HTTPS opzet, en bovendien is er dan nog geen content online. Die twee combineren tot een miniscuul risico. (risico = kans x impact).

[Simkin]

Ben het met je eens en indien dns validatie niet toepasbaar is zou het volgende je mogelijk heel wat tijd kunnen besparen in de toekomst (fixed webroot validatie, werkt voor al je subdomeinen):

Redirect alles naar poort 443 behalve de Letsencrypt validatie calls:

<VirtualHost _default_:80>
RewriteEngine On
RewriteCond %{REQUEST_URI} !^\/.well-known\/
RewriteRule ^(.*)$ https://%{HTTP_HOST}$1 [R=301,L]
ProxyRequests Off

Alias /.well-known/acme-challenge/ "/var/lib/letsencrypt/.well-known/acme-challenge/"
<Directory "/var/lib/letsencrypt/">
AllowOverride None
Options MultiViews Indexes SymLinksIfOwnerMatch IncludesNoExec
Require method GET POST OPTIONS
</Directory>
</VirtualHost>

"/var/lib/letsencrypt/" zal worden gebruikt om de challenges van AL je vhosts te hosten

Vraag eenmalig je certificaten aan, e.g.
certbot certonly --register-unsafely-without-email --agree-tos --expand --webroot --webroot-path /var/lib/letsencrypt/ -d site2.domein.nl -d site1.domein.nl

Daarna cronjob toevoegen voor dagelijkse auto renewal poging:
0 1 1-31 * * /usr/local/bin/certbot renew --webroot --webroot-path /var/lib/letsencrypt/

[Reactie gewijzigd door Simkin op 23 juli 2024 16:47]

[job_h]

Dagelijkse auto renewal? De certificaten zijn 3 maanden geldig, dit lijkt me onnodige load opleveren voor letsencrypt. Eens in de maand lijkt me ruim voldoende, dan heb je alsnog 3 pogingen. Ik heb het zelf zo ingesteld dat ik na 2.5 maanden een renewal doe en een mail zou krijgen als het mislukt.

[David Mulder]

Zou gewoon overstappen op DNS-01 als ik jouw was. Werkt heerlijk als je alle domeinnamen via 1 club hebt staan (zelf gebruik ik bijv. de nameservers van DigitalOcean). Moest een extreem simpel command line scriptje maken om de records aan te maken en weer te verwijderen, maar was een stuk minder werk dan het werkend krijgen binnen verschillende web servers.

[MSalters]

Helaas, dat gaat niet werken in onze situatie. We hebben een niet-scriptable web interface om DNS te beheren.

[BCC]

In 2018? Tijd om over te stappen

[Verwijderd]

Met certbot en forward naar https zou dat toch automatisch kunnen?

[faim]

De meeste webservers ondersteunen een map met alle certificaten volgende de SNI naam.
Script schrijven, controleren welke certificaten er gewijzigd zijn of de return parameters van certbot gebruiken, eventueel samenvoegen en kopiëren naar de juiste map, vervolgens de webserver herstarten.
Dit is de manier waarop wij het doen en heb er bijna nooit omkijk naar.

[CyBeR]

Het kost mij elk kwartaal ongeveer een halve dag om een nieuw certificate werkend te krijgen.

Dan doe je iets grondig fout. Zelfs als je certs moet converteren omdat je rare software hebt zou je dat niet meer dan 5 minuten moeten kosten.

Het is een webserver, de normale manier om data naar een webserver te versturen is HTTP POST.

Certificaten zijn geen data maar configuratie. Die stuur je dus niet via POSTs op en bovendien private keys over een netwerksturen zonder beveiliging is het meest belachelijke idee wat ik ooit gehoord hebt. Jij bent geen sysdadmin of wel?

[MSalters]

Er is altijd wel iets mis met ownership, permissies, symbolic links, of dergelijke dingen. En meestal betekent openbaart zich dat in een webserver die simpelweg geen certificate serveert. Vervolgens ben je dus uren in logifles aan het graven, om vervolgens allemaal halve aanwijzingen te googlen, waarvan er dan hopelijk één de daadwerkelijke oorzaak oplevert.

Applicatie-servers als Tomcat hebben helemaal geen moeite met configuratie via HTTP. Ik kan een WAR uploaden, waarom geen HTTPS certificate?

[Verwijderd]

De reden dat dit via poort 80 moet is omdat dit anders op shared hosting andere websitebeheerders toestaat om certificaten aan te vragen voor jouw domein. Bron

[MSalters]

Ik ken het linkje. Dat is wat ik bedoel met "ze krijgen het niet werkend". Op één of andere manier kunnen ze wél de validatie via poort 80 koppelen aan een certificate voor poort 443, maar niet validatie via poort 443 en een certificate voor precies diezelfde poort 443 ?!

[Daan1510]

Wat is hun business model eigenlijk? Hoe kunnen ze dit gratis doen?

[Verwijderd]

Het 'business model' is 'we willen zo veel mogelijk https op het web', er is geen winstbejang, ze willen gewoon dat https de standaard word omdat je daarmee een behoorlijke drempel opwerpt voor simpele web hacks, die de laatste tijd maar al te vaak gebeuren.

Hoe ze het gratis kunnen doen is door alle grote partners, google, facebook, cisco, eff etc hebben gewoon allemaal wat geld in een pot gestopt en daarmee word de boel betaald. (en een certificaat kost uiteindelijk maar heel weinig, denk aan centen, dit zijn geen domein/certificaat boeren die weer eigen kosten hebben, dit is op top level de certificaten zelf toevoegen)

[JJ White]

Van de Let's Encrypt website:

quote: https://letsencrypt.org/about/

Let's Encrypt is a free, automated, and open certificate authority (CA), run for the public’s benefit. It is a service provided by the Internet Security Research Group (ISRG).
We give people the digital certificates they need in order to enable HTTPS (SSL/TLS) for websites, for free, in the most user-friendly way we can. We do this because we want to create a more secure and privacy-respecting Web.

En daarnaast het stukje over de ISRG:

quote: https://letsencrypt.org/isrg/

ISRG is a California public benefit corporation, and is recognized by the IRS as a tax-exempt organization under Section 501©(3) of the Internal Revenue Code. ISRG’s mission is to reduce financial, technological, and educational barriers to secure communication over the Internet.
ISRG is proudly sponsored by a diverse group of organizations, from non-profits to Fortune 100 companies. We believe we can set an example for how everyone interested in a more secure Internet can work together to provide digital infrastructure for the public’s benefit. See this page for more on our sponsors.

Lijkt er dus op dat het echt een goed doel is dat de veiligheid en privacy waarborging op het internet wil verbeteren. Het proces lijkt volledig geautomatiseerd, dus ik verwacht dat er weinig kosten aan verbonden. Ze hebben bijvoorbeeld ook geen support, naast een community forum en documentatie.

[Reactie gewijzigd door JJ White op 23 juli 2024 16:47]

[Verwijderd]

"Let’s Encrypt is a free, automated, and open certificate authority brought to you by the non-profit Internet Security Research Group (ISRG)."

https://letsencrypt.org/sponsors/
https://letsencrypt.org/become-a-sponsor/

[Reactie gewijzigd door Verwijderd op 23 juli 2024 16:47]

[Simkin]

Weet iemand of de dns-01-challenge string fixed is of moet deze per renewal ook aangepast worden? Indien niet fixed ben je al snel afhankelijk van API toegang tot je DNS beheerder voor automatische renewals. Voordeel van dns authenticatie is ook dat er geen hard requirement meer is voor port 80 validatie (lastig op SSL only servers) en dat je niet bepaalde servers hoeft te whitelisten (nmw geeft Letsencrypt geen duidelijke/volledige lijst met validatie servers op die je kan whitelisten)

[akerssies]

Reactie van serverco op het forum van let's encrypt geeft aan dat er elke keer een nieuwe token gebruikt moet worden.

At the simplistic level, the client talks to the Let’s Encrypt ACME server and obtains a “token” that needs to be placed in a TXT record in your DNS. If your DNS provider has an API then this record can be added automatically, or you can do it manually. Once the TXT record is there, Let’s Encrypt verifies this and provides you with a certificate (via the same client).

You will need a new token every time you need to renew for a new certifcate though, hence automation is easier.

Which arguments you need to call depends on which client you are using.

https://community.letsenc...se-dns-01-challenge/28593

[Kees]

Ik check het nu met een nieuwe client, maar daar krijg ik tot nu toe elke keer dezelfde challenges terug zolang het domein en mijn key maar gelijk blijft

[CH4OS]

Wellicht wordt bij het token ook de datum (geen timestamp of datumtijd) meegenomen. Misschien is morgen het token dus wel anders.

[Reactie gewijzigd door CH4OS op 23 juli 2024 15:25]

[RobinF]

Deze was niet fixed, en vereiste eigenlijk API koppelingen. Voor enkele grote DNS aanbieders zijn er standaard scriptjes die hooken met certbot

[vinx77]

Vraagje. Hoe vind ik de DNS-aanbieders die APIs aanbieden die scriptbaar zijn, het liefst ook waar de domeinregistratie geregeld kan worden? Een gemiddelde domeinregistratie-bedrijf bied een template aan het het nieuwste van het nieuwste, tot zover ik heb gevonden. Vond alleen https://www.reddit.com/r/...3/dns_server_with_an_api/
Aanrader, tips? Toch maar zelf hosten met iets als PowerDNS?

[bkor]

Kijken op de website van de aanbieder. Ik gebruik bijvoorbeeld transip voor 1 simpele DNS-only domein en ze hebben een API. Ik neem aan dat alle grote DNS aanbieders zoiets zullen hebben.

[Simkin]

Gebruik zelf cloudflare maar het goede basis om te beginnen met zoeken is: https://www.sidn.nl/regis...ame=&country=&dnssec=true

[ddkiller0900]

De string is niet fixed. Je zal dus met een API moeten werken. Nu is het wel zo dat er redelijk wat (bekende) providers ondersteuning bieden hiervoor. Als je even zoekt vindt je clients die de dns via API kunnen wijzigen.

[WCA]

Ben benieuwd wanneer het zonder rare hoepels en externe programmatjes mogelijk wordt om op windows (via IIS) een autorenewal te realiseren. Dat is nu iets wat vaak gewoon niet fatsoenlijk werkt helaas.

[DdeM]

Momenteel gebruik ik zelf win-acme en dat werkt gewoon perfect. Binnen 3 minuten een certificaat + auto-renewal ingesteld voor de websites die ik op mijn server heb draaien.

https://github.com/PKISharp/win-acme

[PerfectionVR]

https://github.com/PKISharp/win-acme/issues/464 Er is al een feature request ACMEv2 en wellicht ook wildcards.

[Phyxion]

Jep, die werkt best goed inmiddels. De oudere versies wilden nog wel eens een certifcate aan een verkeerd domein koppelen maar eenmaal goed ingesteld werkt dat inmiddels prima.

Leuke dienst dit verder, bevalt prima.

[capsoft]

Ik gebruik hem ook al een hele tijd. Voorheen heette het let's encrypt win simple. Tegenwoordig zit ook daar de SAN optie in.

[Primuszoon]

Niet alleen voor Windows. Op men NAS werkt certbot ook niet (meer). Deze wil een container aanmaken via perl als ik het mij goed herinner, en na uren zwoegen om de juiste armel pakketten te vinden heb ik het maar opgegeven. Ik vraag me trouwens af waarom er een container geinstalleerd moet worden om een certificaat aan te vragen..

[pennywiser]

Meh? Certbot op commandline werkt prima. Pak de laatste versie uit Git.

[svennd]

https://github.com/lukas2511/dehydrated

Bash werkt wel ? Er is vrijwel voor iedere scripting/programmeer taal een ACME client beschikbaar.

[Apache]

Deze doet het bij mij nochtans enorm goed: https://github.com/jetstack/cert-manager
Moet je wel bereid zijn om je home omgeving op kubernetes om te zetten
Support voor v2 zit in de pipeline: https://github.com/jetstack/cert-manager/pull/309

[Reactie gewijzigd door Apache op 23 juli 2024 16:47]

[Cilph]

Waarom zou je in hemelsnaam Kubernetes draaien op een thuisserver voor serieuze doeleinden (super-power-users daargelaten). Waarom niet gewoon certbot in cert-only mode, met een geconfigureerde nginx/apache die alle relevante validatie files serveert vanaf een bepaalde map?

[Apache]

Omdat je daarmee eindelijk een gemakkelijke abstractie hebt om iets thuis te draaien, op amazon, op gke, met een single command a la apt get?

Vanaf dat je kubernetes draait doe je "helm install odoo" of "helm install owncloud" en je krijgt een draaiende applicatie, beschikbaar op een url op je infra met automatische letsencrypt certificaten.

Kan ook gewoon op bvb een synology nas draaien: https://forum.synology.com/enu/viewtopic.php?t=108264

[Atomsk]

Is lets encrypt ook bruikbaar voor <mijnNAS>.nasfabrikant.com type subdomeinen trouwens? Heb net een NAS, dus nog enigszins noob op dat gebied.

[ouweklimgeit]

Meestal zorgt een fabrikant daar zelf voor, je kunt zelf niet een certificaat genereren voor een domeinnaam waar je geen controle over hebt, dat certificaat moet namelijk geïnstalleerd worden op de webserver. Je kunt beter een eigen domeinnaam gebruiken, die via DNS doorzetten naar het IP van je NAS en daarna op de NAS een certificaat genereren.

Op mijn Syno thuis kan ik probleem LE certificaten genereren, sinds kort ook voor sub-sub domeinen zoals https://nas.thuis.domein.nl, dit was eerder ook niet mogelijk.

[ASS-Ware]

Meestal zorgt een fabrikant daar zelf voor, je kunt zelf niet een certificaat genereren voor een domeinnaam waar je geen controle over hebt, dat certificaat moet namelijk geïnstalleerd worden op de webserver.

Weet je dat zeker?
Let's Encrypt check via poort 80 of de domeinnaam match met het IP adres waar de NAS achter zit en zijn nas zit achter <mijnNAS>.nasfabrikant.com.
Ik denk dat het wel gaat werken.
...
5 min later
Ik heb het getest met een Synology NAS en dat ging prima, er staat nu een certificaat op voor <MijnNAS>.synology.me.

[Verwijderd]

Ja, maar je NAS fabrikant moet dit ondersteunen gezien zij dit domein faciliteren.

De meeste fatsoenlijke NAS-en hebben dit ingebouwd of draaien dit via 3rd party apps. Een voorbeeld:
https://www.synology.com/...er/connection_certificate

[ASS-Ware]

Niet alleen voor Windows. Op men NAS werkt certbot ook niet (meer). Deze wil een container aanmaken via perl als ik het mij goed herinner, en na uren zwoegen om de juiste armel pakketten te vinden heb ik het maar opgegeven. Ik vraag me trouwens af waarom er een container geinstalleerd moet worden om een certificaat aan te vragen..

Op mijn Synology nassen werkt het prima.

[ThoffeGast]

Want je wil dat het magisch gaat? Of dat Microsoft iets voor je bouwt? Waarom zouden ze dat doen, doen ze toch ook niet voor betaalde certificaten via andere partij...

Geef het geld wat je bespaart uit aan een programmaatje, en die worden dan vanzelf beter. Ondervind zelf inmiddels weinig problemen meer op onze servers.

[WCA]

Andere certificaten zijn wel vier keer zo lang geldig. Daarnaast is het prima mogelijk om een autorenewal te realiseren, er is alleen geen officiele client voor zover ik weet. Op linux is deze er wel.

Ben harstikke blij met Let's Encrypt, maar voorlopig heb ik nog gewoon een betaald certificaatje (kost ook de kop niet)

[Reactie gewijzigd door WCA op 23 juli 2024 16:47]

[The Zep Man]

De tooling die je moet installeren zorgt er ook voor dat je certificaten automatisch verlengen. Het is een kleine investering in tijd aan het begin om er vervolgens niet meer naar om te kijken (ook niet na zoveel jaar) en niets meer voor te betalen. En als de tooling niet meer werkt (om wat voor reden dan ook), dan stuurt Let's Encrypt zelfs (ruim op tijd) een mailtje van welke domeinen de certificaten dreigen te verlopen. Ideaal!

[Reactie gewijzigd door The Zep Man op 23 juli 2024 16:47]

[Blokker_1999]

Al ben ik heel blij dat ze eindelijk wildcard certs toestaan. Heb vorig jaar een hobbyproject met complexe webserver structuur en tientallen subdomeinen moeten doen en heb er toch redelijk wat tijd moeten insteken, zeker omdat sommige services die op een subdomein zitten geen echte webserver hebben maar er 1 gebruiken ingebouwd in de applicatie. Kon ik weer een proxy gaan opzetten om de .well-known te gaan afvangen.

[LocoRoco]

Certbot op Linux distro's doet het perfect inderdaad!

[Terrestrial]

En niet alleen IIS maar gewoon voor elke software die op windows draait en een certificaat kan gebruiken. Nu kun je dat wel creëren met de hand, maar je gaat niet elke 3 maanden met de hand vernieuwen, dat is te lastig.

[Reactie gewijzigd door Terrestrial op 23 juli 2024 16:47]

[Anonymoussaurus]

Zoveel tijd kost een certificaat aanmaken niet in IIS. Ben je met 5 minuutjes mee klaar. Dat het niet gebruiksvriendelijk is, is wat anders.

[To_Tall]

Volgens mij kan je dat makkelijk met powershell automatiseren.

Ik heb een reverseproxy draaien via nginx. Met een crontab job heb ik een bash script dat m’n nginx stopt certbot laat ik m’n certificaten controleeen en vernieuwen. Daarna start nginx weer op en hoppa nieuw certificaat.

Door de reverse proxy komt het verkeer op 443 binnen maar wordt redirect naar de webserver over 80. Voor de end User is het verkeer hiermee wel netjes encrypten alleen intern netwerk niet.

[Reactie gewijzigd door To_Tall op 23 juli 2024 16:47]

[Anonymoussaurus]

Jup, bijna alles kan met PowerShell . Alleen zijn sommige stappen best complex (voor PowerShell) en zal er best een lang script tegenaan gegooid moeten worden, denk ik.

[Reactie gewijzigd door Anonymoussaurus op 23 juli 2024 16:47]

[To_Tall]

Dat valt volgens mij wel mee.
daarnaast is het 1 keer zo'n script maken al dan niet van internet te kopieeren en aan te passen.

en je hebt er Jaren plezier van

[RobinF]

Wat zelfs nog op te lossen is door over 443 te sturen naar de webserver, die een self-signed te geven en die in de nginx-proxy vast te zetten.
Iets wat omslachtig maar als het om wat voor reden dan ook nodig is.,

[HansvDr]

Via: https://letsencrypt.org/docs/client-options/ vind je diverse tools hiervoor.

Dat zijn geen rare hoepels maar gewoon prima tools die het werkt doen.

[.oisyn]

Tja, het nadeel van wildcard certs is dat je die wel moet uitrollen over alle services die er gebruik van willen maken. En met LE certs is dat dus om de drie maanden, dus dat wil je imho wel kunnen automatiseren.

Veelal is een certificaat per subdomein praktischer, ook omdat je dan ook geen hooks nodig hebt om de dns records aan te passen.

[Reactie gewijzigd door .oisyn op 23 juli 2024 16:47]

[DrClaw]

Je kunt ervoor kiezen om de wildcard certificates op een gateway te laten termineren, waarbij de gateway vervolgens als proxy fungeert richting jouw applicatieservers. Enterprise-niveau gateways kunnen van allerlei netwerkfuncties voorzien worden, waaronder bv SSL offloading of access policy functionaliteit die inspectie van het verkeer noodzakelijk maakt, en wildcard certs kunnen het beheer van dit soort gateways vereenvoudigen.

Daar tegenover staat dat SSL encryptie tegenwoordig gewoon in de moderne CPU afgehandeld kan worden, dus offloading is niet meer zo noodzakelijk als dat het vroeger was. End to end encryptie kan dus gewoon gemeengoed zjin. Echter, gezien de hoeveelheid data die uit organisaties lekt lijkt het mij verstandig om toegang tot data alsnog op meerdere lagen te controleren, waaronder dus op zo'n access gateway.

[Reactie gewijzigd door DrClaw op 23 juli 2024 16:47]

[onedutch]

1 van de nadelen, wie controleert de "Enterprise-niveau gateway" , indien die valt dan kun je best wel veel verkeer 'zien'.

[CyBeR]

Veelal is een certificaat per subdomein praktischer, ook omdat je dan ook geen hooks nodig hebt om de dns records aan te passen.

Dat is alleen voor niet alle use-cases mogelijk (dynamische subdomeinen m.n.) dus dat ze nu ook wildcards ondersteunen is wmb zeer fijn.

[.oisyn]

Ik wil ook niet beweren dat wildcard cerst nooit nodig zijn . Alleen het uitrolgedeelte kan mogelijk een beperking zijn om daar LE voor te gebruiken, omdat dat om de 3 maanden moet gebeuren ipv om de 1 of 2 jaar zoals bij menig met de hand aangeschafte wildcard certs.

Als dat op 1 device plaatsvindt is het natuurlijk geen enkel probleem. Maar ja, dan heb je ook weer een DNS hook nodig om de challenge in te stellen.

[Reactie gewijzigd door .oisyn op 23 juli 2024 16:47]

[AW_Bos]

Dat belooft nog interessant te worden als er per verlenging de DNS-records aangepast moeten worden.
Bij veel hostingproviders wordt namelijk gebruik gemaakt van een aparte beheerpaneel om de DNS-settings in te wijzigen, en gebruiken ze een speciaal webhostingsysteem zoals DirectAdmin of Plesk die de CertBot-scripts heeft draaien.

Ik ben benieuwd hoe dat getackeld kan worden.

[Reactie gewijzigd door AW_Bos op 23 juli 2024 16:47]

[Verwijderd]

Onder water maken DirectAdmin en ik denk Plesk ook, gebruik van Bind9.
Ik neem aan dat dit dus in principe niet heel veel uitmaakt als de certbot van Let's Encrypt zelf de bind9 configuratie zou aanpassen voor hosts.

[AW_Bos]

DirectAdmin staat voor zover ik weet los van Bind9! Althans. Het zit niet in hun custombuild update-scripts.

[Verwijderd]

Volgens mij maakt Directadmin gebruikt van named, wat een alias is voor bind9.
Zie ook bijvoorbeeld https://help.directadmin.com/item.php?id=40

[AW_Bos]

Dan zou het inderdaad kunnen. Maar als je de DNS op een apart controlepaneel bedient, dan gelden die regels binnen de DNS-settings in DirectAdmin weer niet?

[Verwijderd]

Klopt inderdaad; als de nameserver ingesteld staat op een andere dan de eigen server. (geregeld op domein-niveau)
Wel is het zo dat ik een keer problemen had met mx-records die in Directadmin stonden, terwijl de nameserver een andere server was.
Alle records zouden genegeerd moeten worden maar de e-mail werd toch richting het lokale mx-record verzonden door Exim. Na het verwijderen van het mx-record werden de 'echte' records gerespecteerd.

[e.dewaal]

Bij mijn webhoster gaat de DNS ook via DirectAdmin. Ik heb nog geen bericht gehad dat wildcards ondersteund worden, maar ik verwacht niet dat dit al te lang gaat duren.
Webhosting: Vimexx

[xleeuwx]

Best kans dat DirectAdmin dit zelf oppakt, echter is dit dan waarschijnlijk alleen voor de services die op DirectAdmin draaien.

[Neko Central]

Ik gebruik hier Acme.sh voor met cloudflare DNS api integratie.
1 keer de info instellen en alles wat ik met de flag "--dns dns_cf" aanvraag wordt automatisch in mijn cloudflare ingesteld ook bij de renewals.

[pennywiser]

Zijn wildcards dan ook gratis?

[RobinF]

Ja!

[pennywiser]

Dank, ik kon het niet vinden hier: https://community.letsenc...ate-support-is-live/55579

[MAdD]

Nu hopen dat Synology snel dit oppakt en in DSM gaat verwerken..... (naast natuurlijk dat je zelf een TXT recortd moet aanmaken in je DNS entry van je domain)

[gastje01]

Dit zou ik dan ook graag zien. Het aanmaken van een txt-record is een eenmalige actie, dat is wel te doen. Ik heb zelf meerdere subdomeinen actief waar verschillende services onder hangen, allemaal via Nginx.

Is dit per se iets wat Synology moet verwerken of is de fout die je krijgt een doorgeschoven melding van LE?

[ASS-Ware]

Dit zou ik dan ook graag zien. Het aanmaken van een txt-record is een eenmalige actie, dat is wel te doen. Ik heb zelf meerdere subdomeinen actief waar verschillende services onder hangen, allemaal via Nginx.

Is dit per se iets wat Synology moet verwerken of is de fout die je krijgt een doorgeschoven melding van LE?

Nu checken ze gewoon of het IP adres achter de domeinnaam hetzelfde is als het IP adres van de aanvrager.
Dat is net zo veilig/goed als een TXT record aanmaken.
Poort 80 moet open staan.

[Mattashii]

> Alleen met deze versie is het mogelijk om van de nieuwe wildcardcertificaten gebruik te maken. Een tweede vereiste is dat domeinvalidatie plaatsvindt aan de hand van een dns-01-challenge, die een aanpassing van de txt-record vereist

Dit is niet geheel correct, of verwarrend geschreven: Normale certificaten kunnen nog steeds met de http://<host>:80/.well-known/acme-challenge/ -challenge gedaan worden, maar voor wildcardcertificaten kan je enkel een dns-01 -challenge gebruiken:

> Additionally, wildcard domains must be validated using the DNS-01 challenge type. This means that you’ll need to modify DNS TXT records in order to demonstrate control over a domain for the purpose of obtaining a wildcard certificate.

[omkelderman]

Ik heb bij wijze van test net even een certificaat aangevraagd met de volgende SAN regels:

• domain1.nl
• domain2.nl
• *.domain1.nl
• *.domain2.nl

Voor zover ik kan zien werkt ie goed, maar ik kan geen informatie vinden of het hebben van meerdere wildcard domains in één certificaat de bedoeling is. Wordt dit een beetje goed ondersteund door browsers enzo? Lijkt er dus wel op, maar kan me vaag iets herinneren dat het een probleem was om meerdere wildcard domains in één cert te hebben, maar misschien heb ik dat verkeerd onthouden

[RobinF]

Voorheen werkte dat niet helemaal goed (~2010), maar volgensmij werkt het nu overal goed!

[TvL2386]

A single certificate can have wildcard DNS names for multiple base domains, and can also mix in non-wildcard names.

Source: https://community.letsenc...vironment-wildcards/55578

[plind]

Dit heb ik ook hard nodig en volgens het Let's Encrypt forum zou dit gewoon ondersteund moeten worden.