Nederlandse overheid peilt meningen over verplicht gebruik ACME-standaard

Het Forum Standaardisatie is een internetconsultatie gestart om te onderzoeken of ACME verplicht kan worden bij certificaatbeheer bij de Nederlandse overheid. Het Forum wil weten of het Automatic Certificate Management Environment-protocol onder het 'Pas toe of leg uit'-principe kan vallen.

Het Forum Standaardisatie toetst in een consultatie of de standaard verplicht kan worden bij de overheid. Het Forum wil weten wat 'het draagvlak is voor adoptie van ACME door overheidspartijen' en of de standaard centraal kan worden gecoördineerd bij een nationale organisatie. Die organisatie zou er ook op toe moeten zien dat 'de Nederlandse belangen bij de doorontwikkeling van ACME' worden gewaarborgd.

Het Forum wil specifiek weten of ACME aan het 'Pas toe of leg uit'-principe moet voldoen. In dat geval zijn overheidsinstellingen verplicht ACME te gebruiken bij hun certificaatbeheer, tenzij ze kunnen verantwoorden waarom dat niet het geval is.

Het Automatic Certificate Management Environment-protocol is bedoeld om TLS-certificaten automatisch uit te geven en te vernieuwen. "Toepassing maakt het beheer van deze certificaten efficiënter en beduidend minder foutgevoelig", schrijft het Forum Standaardisatie. "Ook maakt het gebruik van ACME het overstappen naar een andere certificaatleverancier eenvoudiger."

De ACME-standaard werd in 2015 in het leven geroepen door Let's Encrypt, maar het Forum benadrukt in de consultatie dat het eventuele nieuwe beleid niet betekent dat de overheid alleen nog maar Let's Encrypt-certificaten mag gebruiken. "Het protocol wordt inmiddels breed ondersteund door alle grote certificaatautoriteiten", schrijft het Forum. Bovendien geldt de verplichting alleen voor certificaatbeheer en niet voor domeinvalidatie. Dat is onder ACME wel mogelijk, maar er zijn 'alternatieven en goedwerkende andere methoden voor beschikbaar'.

Reacties (35)

[Miepermans]

Buiten dat ACME een prima protocol is om te gebruiken, vind ik het bijzonder dat er nu gekeken wordt om een protocol voor certificaatdistributie te "verplichten". Er is maar genoeg apparatuur te vinden die hier niet mee overweg kan, en voor sommige certificaten (HSM gebaseerde) is het zelfs maar de vraag of dit uberhaupt gaat werken.

Het is weer een typisch gevalletje van "we hebben iets fancy's gehoord en daar willen we wat mee" wat mij betreft. Het enige probleem dat hiermee echt semi-opgelost wordt ,is het aldoor falend certificaatvernieuwingsprocess bij de overheid en aan de overheid gelieerde instanties. Dat is echter voor iedereen een issue

[Antipater]

Je doet forum standaardisatie en de overheid daarmee echt tekort vind ik. Je zegt zelf dat ACME een prima protocol is en dat het het aldoor falend certificaatvernieuwingsprocess deels kan oplossen. Maar dat is precies de motivatie om ACME te verplichten! Daarnaast noemt Forum Standaardisatie het gemakkelijker over kunnen stappen als voordeel.

De pas-toe-of-leg-uit richtlijn houdt optie open voor gemotiveerde afwijkingen, dus het argument van hsm certs zou daarmee afgedekt moeten zijn. Maar als dat niet zo is dan is er tijdens de consultatie voldoende gelegenheid om bezwaren op tafel te leggen. Ik vind dat een nette procedure.

Ik vind het jammer dat veel IT-ers een soort onderbuik afkeer van de overheid lijken te hebben en nog zelfs ongefundeerde kritiek uiten wanneer de overheid goede beslissingen neemt. Ik heb in mijn vijftien jarige carriere tot dusver vaak zat meegemaakt dat de overheid zijn zaakjes prima op orde had, en ook bij commerciele partijen gewerkt waarvan ik echt het gevoel had in een bananenrepubliek rond te lopen.

[Calamarain]

In de inleiding wordt het 'Pas toe of leg uit'-principe genoemd. Als de apparatuur het niet ondersteunt, is dat de uitleg.

[Reactie gewijzigd door Calamarain op 21 februari 2025 16:20]

[TijsZonderH]

Werkt dat zo? Ik zit niet helemaal in die wereld, maar ben wel benieuwd of zoiets onder dit principe valt.

[nzall]

Als ik het "pas toe of leg uit" principe goed begrijp, zou er al rekening gehouden moeten bij de aanschaf van een nieuwe dienst of product dat deze het betreffende protocol ondersteunt. Dus het zou niet gelden voor bestaande diensten en producten, maar als er een nieuwe dienst of product wordt aangeschaft zou deze wel het ACME protocol moeten gebruiken. Het "leg uit" principe speelt dan enkel een rol als alle op de markt beschikbare diensten of producten dit protocol niet zouden ondersteunen, of als de enige diensten of producten die het ACME protocol ondersteunen op andere manieren niet toereikend zijn.

[CAPSLOCK2000]

Werkt dat zo? Ik zit niet helemaal in die wereld, maar ben wel benieuwd of zoiets onder dit principe valt.

Ja, zo werkt dat. Helaas wordt "Pas toe of leg uit" meestal nogal zwakjes toegepast en vooral uitgelegd.
Het is op een aantal punten min of meer standaard (haha) om voor "leg uit" te kiezen. Meestal is de uitleg "onze leverancier ondersteunt het niet". Zo wordt er al jaren gesappeld met IPV6 en met e-mail standaarden van DMARC omdat MS die nog niet ondersteunde. Zoek hier op Tweaker maar eens naar het aantal artikelen waarin MS aankondigd dat ze het nu echt gaan doen, om het een jaar later opnieuw aan te kondigen.

Jaar na jaar geven alle gebruikers op "de leverancier suggereert dat het binnenkort beter wordt" en daar blijft het dan bij. Eigenlijk is dat niet voloende. Eigenlijk hoor je dan aan te geven wat je doet om te zorgen dat je voortaan wel gaat voldoen.

Natuurlijk is er een pijnlijke realiteit dat de overheid ook vast zit in venor lock-in, maar dat probeert deze organisatie juist te bestrijden. Door gebruik te maken van algemene standaarden (niet gebonden aan één leverancier) zou je vendor lock-in moeten bestrijden. Het is daarom erg teleurstellend dat vendor lock-in gebruikt wordt als argument om niet te voldoen.

Dat is als zeggen dat je niet op zwemles gaat omdat je bang bent te verdrinken. Dat is geen verstandige aanpak in een land vol slootjes en maakt je probleem op termijn alleen maar erger.

[TheDevilOnLine]

Pas toe
‘Pas toe’ betekent dat op het moment dat u ICT aanschaft(een dienst of en product), u de 'Pas toe of leg uit'-lijst moet raadplegen. Wanneer de aanschaf valt onder een toepassingsgebied dat voorkomt op deze lijst, moet u de standaard(en) toepassen. Een ICT-dienst of ICT-product valt vaak onder verschillende toepassingsgebieden. Dit betekent voor u dat meerdere standaarden relevant zijn voor uw uitvraag. Wilt u weten welke standaarden? Gebruik de Beslisboom Open Standaarden.
Leg uit
Afwijken van het gebruik van de voorgeschreven standaarden mag alleen als een dergelijke dienst of product in onvoldoende mate wordt aangeboden, onvoldoende veilig of zeker functioneert of om een andere reden die van bijzonder gewicht is. De afwijking en de reden daarvan moeten beschreven worden in de bedrijfsvoeringparagraaf van het jaarverslag. Dit is de betekenis van ‘leg uit’.

Bron: https://www.forumstandaardisatie.nl/pas-toe-leg-uit-beleid

[ro4sho]

Uiteraard gaat het wat verder, en zul je ook moeten uitleggen waarom er met dergelijke apparatuur wordt gewerkt. Wellicht wordt er gevraagd wat het plan is om de apparatuur te vernieuwen. Maar in principe is dit de werking van 'Pas toe of let uit'.

[scsirob]

Nou, je zal toch echt een stapje verder moeten gaan. Je zal moeten uitleggen en mogelijk aantonen dat er geen efficiënte vervanger voor die apparatuur is.

[Miepermans]

Dat klopt, En daar zal ook zeker gebruik van gemaakt worden. Dat neemt echter niet weg dat het risico dat certificaatrenewals vergeten worden steeds groter wordt wanneer men over de overige 95% van de omgeving geen handmatige actie hoeft te ondernemen.

En dan heb ik het nog niet eens gehad over PKP (outdated) en andere oplossingen waarbij er een certificaatvalidatie plaatsvind op basis van serienummer enz.

Al met al, bijzondere wending. Ik ben van mening dat we het ondersteunen van ACME zeker moeten promoten maar niet op deze manier.

[Frame164]

Dat is de uitleg van mensen die snel alle vinkjes willen kunnen zetten om zo aan het proces te voldoen. Inhoudelijk houdt het uiteraard geen stand.

Pas toe of leg uit is een prima principe, het is alleen geen doel maar een middel. Helaas vinden veel mensen, niet alleen bij de overheid maar ook in de particuliere sector het makkelijker om de binnenbochten van een proces te zoeken dan een probleem op te lossen.

[CAPSLOCK2000]

Buiten dat ACME een prima protocol is om te gebruiken, vind ik het bijzonder dat er nu gekeken wordt om een protocol voor certificaatdistributie te "verplichten". Er is maar genoeg apparatuur te vinden die hier niet mee overweg kan,

Een van de redenen om een standaard te hebben is om te zorgen dat er geen apparatuur meer gekocht wordt die niet aan de standaard voldoet. Dat probleem lost zich vanzelf op.

Het enige probleem dat hiermee echt semi-opgelost wordt ,is het aldoor falend certificaatvernieuwingsprocess bij de overheid en aan de overheid gelieerde instanties. Dat is echter voor iedereen een issue

Is dat niet de moeite waard dan? Veel fouten worden juist veroorzaakt doordat het certifificaat-proces handwerk is. Automatiseren is daar een oplossing voor.

[PeeCee]

Laten we niet vergeten dat het niet een 'standaard' kan worden, maar standaard toegepast bij de kan worden bij de overheid.

[..]
Een van de redenen om een standaard te hebben is om te zorgen dat er geen apparatuur meer gekocht wordt die niet aan de standaard voldoet. Dat probleem lost zich vanzelf op.

Persoonlijk zie ik niet in wat de invloed van de Nederlandse overheid op de ontwikkeling van apparatuur gaat hebben.

[..]
Is dat niet de moeite waard dan? Veel fouten worden juist veroorzaakt doordat het certifificaat-proces handwerk is. Automatiseren is daar een oplossing voor.

En het feit dat de overheid faalt op dit gebied, gaat het toepassen van een standaard geen soelaas bieden. Volgens mij voldoet de overheid tot op de dag van vandaag niet volledig aan het eigen cookiebeleid.

[ANdrode]

Certbot kan via een CSR. Via een pkcs#11 provider kan je dan prima een key in een HSM gebruiken.

(Merk op dat je voor FIPS mode ook een token in de HSM moet hebben voor het genereren van een nieuwe key, dus unattended processen zijn sowieso lastig)

Je zou ook de private key buiten HSM kunnen genereren en importeren in een HSM die niet in FIPS mode gebruikt wordt. In een threat model waar het provisioningsproces in een veiligere omgeving gebeurt dan gebruik heeft dat mogelijk ook waarde.

[Reactie gewijzigd door ANdrode op 21 februari 2025 15:41]

[Vaevictis_]

Verplichting is goed en als het echt niet kan kun je (deels) afwijken. Ik zie acme ook niet werken met embedded apparatuur daar is het ook niet echt voor bedoeld.

[spil]

De HSM beschermd de private keys, niet de certificaten.

Je gebruikt de HSM om je private key het certificate signing request te laten ondertekenen.
Die CSR zet je om in een certificate (beide zijn publiek, niet private). Wat je vervolgens met dat certificate doet moet je zelf weten. Laad het weer terug in de HSM wellicht?

(of je bent bv. een hyper-moderne cloud provider zoals Microsoft Azure, en eist dat je voor een Application Gateway een PKCS#12 importeert. Mag je dan weer aan elkaar lijmen via de Graf-API)

[Muncher]

Het Forum Standaardisatie is een adviescommissie met deskundigen uit diverse overheidsorganisaties, het bedrijfsleven en de wetenschap. De leden worden op persoonlijke titel benoemd door het Ministerie van Binnenlandse Zaken en Koninkrijksrelaties. Het Forum wordt ondersteund door een secretariaat, het Bureau Forum Standaardisatie (BFS). Dit bureau is gehuisvest bij Logius, de dienst digitale overheid van het ministerie van Binnenlandse Zaken en Koninkrijksrelaties.

https://www.forumstandaardisatie.nl/over-ons

Voor wie geen idee heeft wat het Forum is (zoals ik).

[Umbrah]

Dit lijkt me een uitstekend idee, voor eigenlijk alles in de keten. Certificaten gaan natuurlijk verder dan enkel TLS. Wat je merkt is dat veel techbedrijven eigenlijk al in hun producten verwerken (denk aan de browsermakers: (Apple wil dat certificaten max 47 dagen geldig zijn: https://www.sectigo.com/r...0reach%20just%2047%20days. -- de industrie wil zelfs nog korter), gewoon omdat historie aangeeft dat artikelen als dit constant door voorkomen: nieuws: DigiCert trekt meer dan 80.000 certificaten in na DNS-validatiefout

Vanzelfsprekend is een verkeerd verstrekt/toegepast certificaat funest voor eigenlijk elke laag security -- een lekkend PKI-certificaat kan ook enorm schadelijk zijn.

De ACME challenge is verre van perfect, het is eigenlijk voornamelijk een DNS/ownership validatie, maar het is tenminste iets. En door dit soort zaken, maar ook aan te dringen op automatisering, en zelfs processen als CI/CD en "open core" principes aan te hangen is de overheid transparant, veilig, maar ook in potentie verantwoordelijker.

De wind "waait" nogal de kant van de SAAS op, waarbij fortuinen aan dataverwerking voor kernprocessen (kuch, https://www.rtvnoord.nl/p...en-en-provincie-miljoenen, kuch) buiten de deur wordt gezet. Om te voorkomen dat SAAS voor Silo As A Service staat lijkt het me juist belangrijk dat gedachtengoed als Common Ground, maar ook: zaken als ACME verplicht stellen (geloof me, zullen een paar processen vrij snel daardoor moeten automatiseren en daardoor ook hun beheerfouten verlagen) "pas toe of leg uit" worden.

[Liger]

De ACME challenge is verre van perfect, het is eigenlijk voornamelijk een DNS/ownership validatie, maar het is tenminste iets.

Vergeet niet dat je óók bij gebruik van ACME nog OrganisatieValidatie kan gebruiken, dat gaat dan door middel van External Account Binding. Behalve Let's Encrypt hebben alle grote CA's hier ondersteuning voor. Het advies gaat puur over het verplichten van het protocol voor uitgifte e.d., en maakt expliciet géén keuzes over validatieniveaus, soorten certificaten of CA.

[Waswat]

Edit: Ik besloot net na de inleiding van het artikel proberen uit te vogelen wat acme nou inhoudt maar ik zie dat het halverwege het artikel werd uitgelegd. Nu is mijn comment een beetje nutteloos, sorry daarvoor

Voor de mensen (zoals ik) die onbekend zijn bij ACME (behalve als bedrijf waar Wile E. Coyote altijd zaken mee doet):

Het Automated Certificate Management Environment (ACME)-protocol is een gestandaardiseerde manier om het proces van het verkrijgen en vernieuwen van SSL/TLS certificaten. Hiermee kunnen webservers eigendom van domeinen bewijzen en certificaten ontvangen zonder handmatige tussenkomst. ACME automatiseert de uitgifte en vernieuwing van certificaten, verbetert de websitebeveiliging, vermindert menselijke fouten bij certificaatbeheer en wordt breed ondersteund door certificaatautoriteiten en webservers.

https://www.ssl.com/nl/dit-artikel/wat-is-het-acme-protocol/

[Reactie gewijzigd door Waswat op 21 februari 2025 15:22]

[blorf]

Ik dacht aan een Wile E Coyote bouwpakket.

[Killemov]

Yep. A Company that Makes Everything. Meep meep!

[GeeBee]

Volgens mij is het niet dat acroniem, maar is het Grieks voor de beste/ top/ hoogtepunt.
Het is misschien wel een acroniem, maar dan iets met ‘de beste’ en ‘naam’.

[StGermain]

Amazon avant la lettre

[ODF]

Bij ACME moet ik altijd eerst denken aan Acme uit de Looney Tunes.
Wikipedia: Acme (fictief bedrijf)
Verder geen bijdrage aan dit nieuws

[CamelKnight]

Nou ja, ik vroeg me serieus af of ze die naam bewust hadden gekozen. ACME blijkt echter in het Engelse vaak gebruikt te worden voor een fictief bedrijf. Er schijnt overigens ook wel een supermarktketen met die naam te zijn.
De associaties die het bij, vermoedelijk veel, mensen oproept is waarschijnlijk inderdaad Looney Tunes/Road Runner. Ik vraag me af of die naamkeuze dan zo handig is geweest.

[kodak]

Er zijn al jaren verschillende mogelijkheden om automatisch certificaten aan te vragen, vernieuwen en in te trekken. Die mogelijkheden worden niet zomaar toegepast.

In het verzoek om reacties om mogelijk al die andere manieren uit te gaan sluiten vraag ik me af waarom dat nu opeens nodig zou zijn. Ook omdat het nogal eenzijdig in gaat op de vermeende voordelen.

Zijn er dan andere implementaties ontdekt waarbij aantoonbaar te veel risico is genomen? Past bijna iedereen binnen de overheid het al toe naast andere implementaties die allemaal tijd en geld kosten? Is de overheid al betrokken bij de ACME standaard en willen ze daar duidelijker en meer budget voor hebben waar deze verplichting voor kan zorgen?

[Dark Angel 58]

ACME??? Seriously???
Ik zou het naam iets anders aanpassen… als mensen het ziet, denken dat het bericht vast nep of scam is. Niet bepaald slim, nietwaar?
ACME is fictief bedrijf voor tekenfilms/games en soms tv series.

[Frame164]

Het wordt ook professioneel gebruikt om bijvoorbeeld een bedrijfsnaam niet te noemen omdat bepaalde zaken onder NDA zitten.

[DaRealRenzel]

Automatic Certificate Management Environment, gewoon een gedefinieerde afkorting.

Wikipedia: Automatic Certificate Management Environment

[Burgertrut]

ACME, dat was toch van Road Runner en Wile E. Coyote?

American Company that Manufactures Everything.

[DaRealRenzel]

Het probleem is niet zozeer dat ACME geen goed mechanisme zou zijn, maar de support van ACME door de certificaat leveranciers loopt gewoon enorm achter. Zelfs PKI Overheid ondersteund het niet.
Daarnaast is het met ACME niet mogelijk om Extended Validation certificaten uit te geven, simpelweg omdat de Extended Validation ontbreekt.
Waarom niet gewoon een end to end Certificate Lifecycle Management systeem verplicht stellen, ipv dit op een enkel protocol vast te pinnen

[Liger]

Zelfs PKI Overheid ondersteund het niet.

Voor de overheid intern is PKI Overheid misschien nog relevant, maar om dat nou als graadmeter voor support van leveranciers te nemen... Verder ondersteunen alle grote leveranciers het.

Daarnaast is het met ACME niet mogelijk om Extended Validation certificaten uit te geven

Jawel, met External Account Binding (https://datatracker.ietf.org/doc/html/rfc8555#section-7.3.4). Hiermee kan de CA een ACME-account linken aan de gegevens die bekend zijn bij de CA. Hiermee mogen via ACME uitgegeven certificaten ook OV of EV krijgen.

[DaRealRenzel]

PTOLU is mijns inziens een Overheidsrichtlijn, PKI Overheid is met name bedoeld voor interne en externe overheidscommunicatie (Logius: PKI voor de overheid, kortweg PKIoverheid, zorgt voor een veilige gegevensuitwisseling en verbinding tussen overheid, burgers en bedrijfsleven en tussen overheden onderling. Het is een van de bouwstenen van de Generieke Digitale Infrastructuur (GDI) van de Digitale Overheid ), dus als diezelfde Overheid een standaard wil voor het beheer van certificaten, en dat middels ACME wil regelen, dan zal PKI Overheid het toch eerst ook zelf moeten ondersteunen lijkt me.

Dat PKI Overheid de laatste jaren aan relevantie heeft ingeboet is ook een bel;eidskeuze geweest. In plaats van PKI Overheid voor alle overheid verplicht te stellen, heeft men ook toegestaan om elders (goedkopere) certificaten aan te schaffen. PKI Overheid certificaten waren vaak vele malen duurder dan die van Digicert, of Lets Encrypt. en de burger merkt er toch niks van. Tja, dan graaf je je eigen gat.

Last but not least, ook al ondersteund je preferred CA dan ACME, dan nog is ook het automatisch 'binden' van je services aan het via ACME uitgegeven certiifcaat niet altijd even opportuun. ACME is maar de helft van de oplossing als je het over end to end certificate management hebt.

[Nightan]

Ik begrijp de opmerking niet over certificaatbeheer en geen domeinvalidatie. Door ACME wordt de lifecycle van certificaten een commodity omdat het volledig geautomatiseerd is. Bedoelen ze dat met het beheer?

Het protocol doet aan domeinvalidatie door een uniek token op de webserver of in DNS te plaatsen. Hierdoor kan het certificaat veilig worden uitgegeven. Dus hoezo zou je dat niet doen? Kun je net zo goed geen ACME gebruiken.
Ik beheer een CLM bovenop een interne CA van een groot bedrijf. Deze oplossing biedt ACME zonder HTTP/DNS-01 validatie, maar is volgens mij custom. Je gaat dan met een shared secret werken wat op het publieke Internet (bijvoorbeeld Let's Encrypt) niet schaalt.

En welke andere 'goedwerkende alternatieve methoden' dan ACME zijn er dan wel beschikbaar? Handmatig in Excel? Success met steeds korter geldende certs.

Er zijn andere certificaatprotocollen langer beschikbaar maar zijn naar mijn mening beperkt. ACME is niet voor niets voor Web PKI bedacht door de ISRG, de stichting achter LE.

Veder heb je nog SCEP en EST. De S van SCEP staat letterlijk voor Simple en wordt in principe alleen gebruikt voor MDM-oplossingen. Denk aan Azure Intune i.c.m. MS NDES on-prem als RA.
EST is wat moderner maar kom ik amper tegen. Wellicht meer in de OT-industrie maar in IT is het een niche.