ACME-clients op Linux voor eenvoudig SSL/TLS-beheer

Elke keer dat je een website bezoekt en dat hangslotje in de adresbalk van je browser ziet, SSL/TLS-certificaat Het certificaat doet stilletjes zijn werk: het authenticeert de server en versleutelt uw verbinding, zodat wachtwoorden, betaalgegevens en persoonlijke informatie privé blijven. Zonder dat certificaat valt de verbinding terug op gewoon HTTP, waardoor iedereen op hetzelfde netwerk uw verkeer in platte tekst kan lezen.

Jarenlang was het verkrijgen en behouden van die certificaten een ronduit moeizaam proces. Beheerders moesten ze genereren. cryptografische sleutelseen certificaatondertekeningsverzoek indienen bij een Certificate AuthorityZe moesten bewijzen dat ze de domeinnaam bezaten, het ondertekende certificaat downloaden, het op de server configureren en vervolgens het hele proces herhalen voordat het certificaat verliep.

Als die deadline wordt gemist, beginnen browsers certificaatfoutmeldingen weer te geven. Diensten vallen uit en gebruikers haken af.

ACME, de Automatische certificaatbeheeromgeving Het protocol is ontwikkeld om precies dat probleem op te lossen. In plaats van dat iemand certificaten aanvraagt ​​en vernieuwt, handelt een lichtgewicht softwareagent op de server het hele proces automatisch af. Deze agent communiceert rechtstreeks met de certificeringsinstantie (CA) zonder menselijke tussenkomst.

Wanneer je die agent op grote schaal gebruikt op tientallen of honderden Linux-servers, ontstaan ​​er nieuwe problemen: geen centraal overzicht, inconsistente configuraties en geen waarschuwingssysteem wanneer er iets misgaat. Dat is waar CertSecure Manager in beeld komt, door de beheerslaag toe te voegen die individuele ACME-clients nooit ontworpen waren om te bieden.

In deze blog bespreken we wat SSL/TLS-certificaten zijn, waarom ze verlopen, hoe het ACME-protocol werkt, welke Linux-clients je moet kiezen en wat er nodig is om ze te beheren. certificaat automatisering op ondernemingsniveau.

Wat zijn SSL/TLS-certificaten?

Denk aan een SSL/TLS-certificaat Het fungeert als een geverifieerd identiteitsbewijs voor een website, uitgegeven door een vertrouwde derde partij. Het doet twee dingen: het versleutelt het verkeer tussen de browser van een bezoeker en de server, en het bewijst dat de server daadwerkelijk is wie hij beweert te zijn.

Het cryptografische mechanisme hierachter berust op een sleutelpaar: een publieke sleutel die iedereen kan gebruiken om gegevens te versleutelen die naar de server worden verzonden, en een privésleutel die alleen de server bezit en gebruikt om de gegevens te ontsleutelen. Zelfs als iemand het verkeer onderschept, kan diegene het niet lezen zonder die privésleutel.

Wie geeft SSL/TLS-certificaten uit?

Certificeringsautoriteiten (CA's) Dit zijn de organisaties die browsers en besturingssystemen al vertrouwen om de betrouwbaarheid van websites te garanderen. Bekende openbare certificeringsinstanties (CA's) zijn onder andere Let's Encrypt, DigiCert en GlobalSign.

Bedrijven beheren vaak hun eigen private certificeringsinstanties (CA's) met behulp van Microsoft Active Directory Certificate Services of open-source alternatieven. Voordat een CA een certificaat uitgeeft, moet deze controleren of de aanvrager daadwerkelijk de eigenaar is van het betreffende domein. Zodra die controle is geslaagd, ondertekent de CA het certificaat digitaal en zal elke browser die die CA vertrouwt, de site automatisch ook vertrouwen.

Waarom verlopen certificaten?

Certificaten zijn per definitie niet permanent. Korte geldigheidsperioden beperken de schade die een gestolen privésleutel kan aanrichten, dwingen tot regelmatige controles of het domein nog steeds in hetzelfde bezit is en zorgen ervoor dat verouderde cryptografische standaarden worden vervangen.

Het CA/Browser Forum heeft steeds kortere geldigheidsperioden verplicht gesteld: certificaten van 200 dagen (vanaf maart 2026), certificaten van 100 dagen in 2027 en certificaten van 47 dagen in 2029. Naarmate verlengingen vaker voorkomen, worden handmatige processen volstrekt onhoudbaar, en dat is precies de reden waarom ACME bestaat.

Het traditionele probleem met certificaatbeheer

Voordat automatisering zijn intrede deed, betekende het verlengen van een certificaat het genereren van een Verzoek tot ondertekening van een certificaatHet indienen bij een certificeringsinstantie, het handmatig valideren van het domein, het downloaden van het ondertekende bestand, het implementeren ervan op de juiste server en het bijwerken van de webserverconfiguratie, dit alles met een deadline die de meeste teams bijhielden in een gedeeld spreadsheet of, erger nog, uit hun geheugen.

Voor één enkele website was dit beheersbaar. Maar voor een organisatie met vijftig servers verdeeld over drie omgevingen was het een ramp die stond te gebeuren. Gemiste verlengingen veroorzaakten daadwerkelijke storingen, en die storingen waren vaak het eerste teken dat iemand zich herinnerde dat een certificaat bijna verliep. De complexiteit van dat proces was de drijfveer achter de oprichting van ACME. U kunt meer lezen over de risico's van veelvoorkomende SSL-configuratiefouten en hoe ze daadwerkelijke veiligheidsrisico's creëren.

Wat is ACME en waarom is het opgericht?

ACME (Automatische certificaatbeheeromgeving) is een open standaard, gepubliceerd als RFC 8555Dat definieert hoe een server kan bewijzen dat hij een domein beheert en een certificaat kan aanvragen bij een certificeringsinstantie (CA) volledig zonder menselijke tussenkomst.

De server voert een ACME-client uit, de client voltooit een cryptografische uitdaging die door de certificeringsinstantie (CA) is opgesteld, en zodra de CA tevreden is, geeft deze het certificaat uit en stuurt het terug. Hetzelfde proces zorgt voor automatische verlengingen. ACME wordt tegenwoordig door tientallen CA's ondersteund en is wereldwijd de de facto standaard geworden voor certificaatautomatisering in Linux-omgevingen.

ACME werd op grote schaal geaccepteerd, grotendeels vanwege... Laten we versleutelen gratis Let's Encrypt is een openbare certificeringsinstantie (CA) die is gelanceerd door de Internet Security Research Group. Let's Encrypt betoogde dat HTTPS gratis en automatisch zou moeten zijn en gebruikte ACME als mechanisme om dat te realiseren.

Hoe ACME-clients op Linux certificaatautomatisering implementeren

Het ACME-protocol definieert de regels, maar het is de ACME-client, software die direct op de Linux-server draait, die ze uitvoert en certificaataanvragen, domeinvalidatie, installatie en verlenging afhandelt.

Linux is bij uitstek geschikt voor dit soort automatisering. De commandoregeltools, cron-planning en native integratie met webservers zoals Apache en Nginx Dit betekent dat ACME-clients met minimale configuratie in bestaande infrastructuren kunnen worden geïntegreerd. In de meeste gevallen kan de client de webserverconfiguratie ook zelf bijwerken wanneer een nieuw certificaat wordt uitgegeven, waardoor het hele proces volledig geautomatiseerd verloopt.

Hoe ACME-klanten automatische verlenging afhandelen

ACME-clients op Linux draaien doorgaans als geplande achtergrondtaken en controleren regelmatig of certificaten verlopen zijn. Wanneer een certificaat de verlengingsdrempel overschrijdt (meestal 30 dagen voor de vervaldatum voor Let's Encrypt-certificaten), neemt de client contact op met de certificeringsinstantie, voltooit de domeinvalidatie, ontvangt het vernieuwde certificaat, vervangt de oude bestanden en geeft de webserver het signaal om opnieuw te laden.

Het hele proces duurt slechts enkele seconden en verloopt zonder tussenkomst van een beheerder. Daarom hoeven teams die zijn overgestapt op ACME-gebaseerde automatisering zich zelden nog zorgen te maken over certificaatvernieuwingen, totdat er iets misgaat met de automatisering. En dat brengt ons bij de volgende vraag: waarom? bewaking nog steeds van belang is.

Waar worden SSL/TLS-certificaten op Linux opgeslagen?

Elke ACME-client hanteert zijn eigen directoryconventies. Certbot slaat actieve certificaten op onder /etc/letsencrypt/live/<domain>/, met vier standaardbestanden: cert.pem (het bladcertificaat), privkey.pem (de privésleutel), chain.pem (het tussentijdse CA-certificaat), en fullchain.pem (het blad plus de volledige keten).

Historische en bewerkte exemplaren bevinden zich in /etc/letsencrypt/archive/<domain>/.acme.sh gebruikt standaard de map ~/.acme.sh/ De meeste productieomgevingen verplaatsen certificaten echter naar systeemdirectory's zoals /etc/ssl/ of /var/lib/acme/ voor een beter beheer van de toegangsrechten. Wanneer een certificaat wordt vernieuwd, werken beide tools de bestanden ter plaatse bij, zodat applicaties die naar die paden verwijzen, blijven werken zonder dat er configuratiewijzigingen nodig zijn.

ACME-validatiemethoden op Linux

Voordat een certificeringsinstantie (CA) een certificaat kan uitgeven, moet worden bewezen dat u daadwerkelijk de domeinnaam beheert. ACME standaardiseert dit bewijsproces in drie verschillende soorten verificaties, elk geschikt voor verschillende omgevingen.

HTTP-01 Validatie

De ACME-client plaatst een klein tokenbestand op een bekende URL op de webserver. De certificeringsinstantie (CA) haalt die URL via HTTP op om te bevestigen dat het bestand aanwezig is en verleent vervolgens domeinbeheer.

Dit is de meest gangbare methode en werkt direct met Apache en Nginx op elke publiek toegankelijke server. De enige beperking is dat de server bereikbaar moet zijn op poort 80, waardoor deze methode niet geschikt is voor interne services en wildcardcertificaten.

DNS-01 Validatie

In plaats van een bestand op de webserver, maakt de ACME-client een bestand aan. _acme-challenge Een TXT-record in de DNS-zone van het domein. De certificeringsinstantie (CA) controleert dit record om het domeineigendom te bevestigen.

DNS-01 is de methode die gebruikt moet worden voor wildcardcertificaten, voor servers achter een firewall en voor elke service die niet rechtstreeks via HTTP bereikbaar is. Het nadeel is dat hiervoor ofwel API-toegang tot uw DNS-provider nodig is, ofwel een handmatige DNS-update.

TLS-ALPN-01 Validatie

TLS-ALPN-01 voert de validatiehandshake rechtstreeks via TLS uit op poort 443, met behulp van een speciale ALPN-extensie. Deze methode wordt minder vaak gebruikt dan de andere twee, maar is nuttig in omgevingen waar HTTP volledig is geblokkeerd en toegang tot de DNS API niet beschikbaar is.

Populaire ACME-clients op Linux en hun verschillen

Er zijn diverse volwaardige ACME-clients beschikbaar voor Linux, en de juiste keuze hangt af van uw omgeving.

Certbot, beheerd door de Electronic Frontier Foundation, is de meest gebruikte optie. Het integreert direct met Apache en Nginx, regelt automatisch de certificaatinstallatie en het herladen van de webserver, en is de meest gebruiksvriendelijke oplossing voor iedereen die een traditionele Linux-webserver beheert.

Als je een publiekelijk toegankelijke website beheert en alleen certificaten nodig hebt om te functioneren, is Certbot het juiste startpunt.

acme.sh kiest voor een andere aanpak. Het is volledig geschreven in POSIX shell en draait op elke Linux-distributie zonder enige extra afhankelijkheden.

Het ondersteunt een veel breder scala aan DNS-providers dan Certbot, integreert naadloos met Ansible, Docker en andere automatiseringstools, en geeft beheerders meer gedetailleerde controle over certificaatopslag en implementatie-hooks. Het is de voorkeurskeuze voor scriptomgevingen, interne services en cloud-native workloads.

Lego is een op Go gebaseerde client die is ontwikkeld voor dynamische infrastructuren. Het wordt vaak geïntegreerd in containerorkestratie-pipelines en CI/CD-systemen waar certificaten op aanvraag moeten worden aangevraagd en vernieuwd wanneer services worden opgestart en afgesloten.

Sommige platforms, waaronder bepaalde Kubernetes ingress controllers en load balancers, bieden ook ingebouwde ACME-ondersteuning. Dit kan de initiële installatie vereenvoudigen, maar biedt doorgaans minder inzicht en controle dan een dedicated client.

Certbot versus acme.sh op Linux: een praktische vergelijking

Zowel Certbot als acme.sh implementeren ACMEv2, ondersteunen wildcardcertificaten en automatiseren de volledige certificaatlevenscyclus. Het verschil zit hem in hun filosofie en geschiktheid.

Kenmerk	Certbot	acme.sh
Implementatie	Python-gebaseerd	POSIX-shellscript
afhankelijkheden	Vereist Python 3.4 of later.	Elke Linux-shell is geschikt, geen extra's nodig.
ACME-versie	ACMEv2	ACMEv2
Wildcard-certificaten	Ondersteund via DNS-01	Ondersteund via DNS-01
Apache/NGINX-integratie	Automatische installatie en herinstallatie	Alleen uitgifte, handmatige implementatiehaken
DNS-providerondersteuning	Beperkt aantal ingebouwde providers	Meer dan 150 aanbieders ondersteund
TLS-ALPN-01 Validatie	Niet ondersteund	ondersteunde
Vernieuwing	Volledig geautomatiseerd via systemd timer	Volledig geautomatiseerd via cron.
Beste pasvorm	Openbare webservers, snelle installatie	Gescripte pipelines, interne services, containers
Gecentraliseerd beheer	Alleen per server	Alleen per server

In de praktijk wint Certbot het op het gebied van eenvoud. Als je Apache of Nginx beheert op een handvol publiek toegankelijke servers, installeert Certbot zich binnen enkele minuten en draait het zichzelf. acme.sh wint het op het gebied van flexibiliteit: dankzij het shell-native ontwerp werkt het overal waar Linux draait, de ondersteuning voor DNS-providers is ongeëvenaard en met de implementatiehooks kun je elke gewenste actie na verlenging uitvoeren. Geen van beide tools is echter ontworpen met gecentraliseerd beheer in gedachten. Beide slaan certificaten lokaal op de server op en werken onafhankelijk, wat van groot belang is bij het beheren van certificaten op tientallen of honderden systemen.

ACME-clients op Linux, verder dan alleen websites: API's en interne services

De meeste mensen associëren SSL/TLS-certificaten met openbare websites, maar in een moderne Linux-omgeving zijn certificaten net zo belangrijk voor intern verkeer. REST API's, microservices, message brokers en interne tools hebben allemaal versleutelde, geauthenticeerde verbindingen nodig om te voorkomen dat aanvallers, die eenmaal toegang tot het netwerk hebben verkregen, gegevens onderscheppen of zich er lateraal doorheen verplaatsen.

Het aanvalsoppervlak dat ontstaat door onbeheerde aanvallen interne certificaten is belangrijk en wordt vaak over het hoofd gezien. ACME-klanten verwerken de interne uitgifte en verlenging van certificaten met hetzelfde automatiseringsmodel als openbare websites, waardoor consistentie wordt gewaarborgd. encryptie Een praktische realiteit binnen de gehele infrastructuur.

Beveiligingsaspecten bij het gebruik van ACME-clients op Linux

Automatisering vermindert menselijke fouten, maar neemt de noodzaak van goede beveiligingsmaatregelen niet weg. Een aantal gebieden verdienen bijzondere aandacht bij het draaien van ACME-clients op Linux in een productieomgeving.

• Bescherming van privésleutels: Dit is de belangrijkste stap. ACME-clients genereren privésleutels rechtstreeks op de Linux-server, en die bestanden vereisen beperkte toegangsrechten. Brede leesrechten op een privésleutelbestand vormen een kritieke kwetsbaarheid; iedereen die het kan lezen, kan zich voordoen als uw server. Raadpleeg onze handleiding over best practices voor het beschermen van SSL/TLS-certificaten voor een volledige checklist.
• Principe van minimale bevoegdheden voor het ACME-proces: De client heeft alleen toegang nodig om certificaatbestanden te schrijven en de webserver opnieuw op te starten, meer niet. Het uitvoeren met verhoogde rechten vergroot onnodig het aanvalsoppervlak.
• Vernieuwingsmonitoring: Verlengingen verlopen automatisch, totdat ze dat niet meer doen. Een DNS-wijziging, een nieuwe firewallregel of een verkeerd geconfigureerde challenge-response kunnen allemaal stille fouten veroorzaken, waardoor u met een verlopen certificaat blijft zitten zonder waarschuwing. Registreer de resultaten van verlengingen en stel een melding in bij fouten. Ons artikel over het controleren van de geldigheid van SSL-certificaten behandelt de monitoringkant in detail.
• CA en beleidsafstemming: In gereguleerde omgevingen heeft uw organisatie waarschijnlijk een lijst met goedgekeurde CA's, een vereist sleutelalgoritme en een minimale sleutellengte. ACME-clients handhaven deze regels niet zelf; ze gebruiken de CA waarnaar u verwijst en de standaardinstellingen waarmee ze worden geleverd. Zonder gecentraliseerd configuratiebeheer kunnen configuraties in de loop der tijd tussen servers verschillen.

Uitdagingen bij het beheren van ACME op bedrijfsniveau

ACME-clients op Linux werken uitstekend op één server of in een kleine vloot. De problemen beginnen zich echter te openbaren wanneer je op grote schaal opereert, verspreid over meerdere teams, omgevingen en platforms.

• Geen wereldwijde zichtbaarheid: Elke server beheert zijn eigen certificaten geïsoleerd. Er is geen centrale inventaris, geen uniform dashboard en geen eenvoudige manier om te achterhalen welke certificaten de komende 30 dagen verlopen op al onze systemen. Een team dat Certbot op 40 Nginx-servers en acme.sh op containerhosts gebruikt, heeft geen centrale plek om dit te controleren. Verweesde certificaten, certificaten die niet langer aan actieve services zijn gekoppeld, blijven stilletjes bestaan ​​als schaduwcertificaten, wat leidt tot risico's op het gebied van compliance en onnodige complicaties.
• Inconsistente configuraties: Beveiligingsbeleid voor bedrijven schrijft doorgaans specifieke certificeringsinstanties (CA's), sleutelalgoritmen en verlengingsperioden voor. Bij standalone ACME-clients wordt elke server onafhankelijk geconfigureerd. Het ene team gebruikt RSA-2048 van Let's Encrypt, het andere gebruikt ECDSA van een compleet andere CA, en uw compliance-audit moet deze handmatig met elkaar vergelijken.
• Mislukte implementatiecoördinatie: Het vernieuwen van een certificaat is slechts de helft van het werk. Het vernieuwde certificaat moet opnieuw worden geladen door elke service die het gebruikt: de webserver, de load balancer, de Tomcat-instantie en de interne API. ACME-clients beheren hun eigen herlaadmechanismen, maar in gedistribueerde omgevingen komt het vaak voor dat een certificaat op schijf wordt bijgewerkt en vervolgens niet automatisch ergens verderop in het proces opnieuw wordt geladen. Dit leidt tot onverwachte TLS-fouten die lastig te diagnosticeren zijn.
• Geen bedrijfsintegraties: ACME-clients zijn automatiseringstools, geen operationele platforms. Ze versturen geen meldingen naar uw SIEM, openen geen tickets in ServiceNow en integreren niet met uw monitoringstack. Een mislukte verlenging op een productieserver blijft onzichtbaar totdat er iets misgaat.

Waarom bedrijven gecentraliseerd ACME-beheer nodig hebben

De oplossing voor deze uitdagingen is niet om de ACME-klanten te vervangen; zij zijn immers erg goed in wat ze doen. Wat ontbreekt, is een gecentraliseerde beheerslaag die inzicht en controle biedt over het gehele wagenpark, zonder de werking van individuele klanten te veranderen.

Een gecentraliseerde laag biedt beveiligingsteams een uniform overzicht van alle via ACME uitgegeven certificaten, ongeacht welke server of client ze heeft geproduceerd. Verlopen certificaten zijn weken van tevoren zichtbaar in plaats van pas tijdens een storing te worden ontdekt. ​​De handhaving van het beleid wordt uniform: goedgekeurde CA's, vereiste sleutellengtes en verlengingsdrempels gelden overal, niet alleen voor servers die zorgvuldig zijn geconfigureerd.

Wanneer een certificaat moet worden ingetrokken vanwege een beveiligingslek, kunnen alle afhankelijke services op een gecoördineerde manier worden geïdentificeerd en bijgewerkt, in plaats van handmatig te moeten worden opgespoord. Bij een mislukte verlenging wordt direct een waarschuwing gegenereerd, in plaats van dat een incident in de productieomgeving het eerste teken is dat er iets mis is gegaan.

Hoe encryptieconsultancy kan helpen

CertSecure Manager is het certificaatlevenscyclusbeheerplatform van Encryption Consulting, speciaal ontworpen om precies de hierboven beschreven schaal- en governance-uitdagingen aan te pakken.

Het werkt naast uw bestaande ACME-clients in plaats van ze te vervangen. Certbot en acme.sh blijven doen wat ze doen, terwijl CertSecure Manager elk certificaat dat ze uitgeven bijhoudt, uw cryptografische beleidsregels afdwingt en u een uniform overzicht geeft van de volledige levenscyclus binnen uw Linux-infrastructuur.

CertSecure Manager integreert met openbare certificeringsinstanties zoals Let's Encrypt en met een eigen, op maat gemaakt ACME-eindpunt, waardoor de uitgifte en verlenging volledig geautomatiseerd blijven. Het vermindert ook certificaatgerelateerde storingen door configureerbare waarschuwingen van 30 dagen of langer van tevoren te bieden.

Wat de implementatie betreft, Ansible Playbooks beheren op consistente wijze de ACME-clientconfiguratie, certificaatimplementatie en serviceherlaadprocessen voor Apache, Nginx, Tomcat en IIS in zowel on-premises als hybride cloudomgevingen, en dat alles zonder handmatige tussenkomst.

Naarmate uw omgeving groeit, schaalt CertSecure Manager mee. Het biedt een uniforme certificaatinventaris, handhaaft cryptografische standaarden voor alle teams en biedt inzicht in gebeurtenissen gedurende de levenscyclus. De operationele integraties voor waarschuwingen, ticketing en auditregistratie transformeren certificaatbeheer van een reactieve noodoplossing naar een gecontroleerd en controleerbaar proces.

Conclusie

ACME Het heeft de manier waarop SSL/TLS-certificaten op Linux worden beheerd, echt veranderd. Wat voorheen een handmatige, deadline-gedreven klus was, is nu een geautomatiseerd achtergrondproces waar de meeste teams zelden aan denken.

De beste ACME-clients voor Linux, waaronder Certbot, acme.sh en vergelijkbare tools, verzorgen de uitgifte- en verlengingsprocedure betrouwbaar op Apache, Nginx, Tomcat en vrijwel elk ander Linux-gebaseerd platform. Nu de geldigheidsperioden richting de 47 dagen gaan, is automatisering niet langer een optie, maar essentieel.

De resterende lacune zit hem in de governance. Individuele ACME-clients zijn niet ontworpen om bedrijfsteams inzicht te geven in een complete vloot, consistent beleid af te dwingen of te integreren met de monitoring- en waarschuwingssystemen waarop de productie-infrastructuur vertrouwt.

CertSecure Manager vult die leemte op, en CBOM Secure, PKI-as-a-Serviceen HSM-as-a-Service Breid het platform uit tot een complete cryptografische beveiligingsstack voor de gehele onderneming.

Als u uw certificaatautomatisering wilt versterken, het beheer wilt aanscherpen of gewoon wilt anticiperen op de overgang naar kortere geldigheidsperioden voor certificaten, neem dan contact met ons op. Encryptie ConsultingWij helpen organisaties in elke fase van dat traject, van de eerste ACME-implementatie tot het beheer van de certificaatlevenscyclus voor de gehele organisatie.