ACME für ADCS — Add-ons und Bridge-Lösungen im Vergleich

Wie du dein Boardmittel doch noch ACME-tauglich bekommst — drei Wege, eine Empfehlung

Kurzfassung vorab

ADCS spricht von Haus aus kein ACME. Microsoft hat das auch nicht auf der Roadmap. Wer Auto-Renewal für TLS auf Linux, in Containern oder unter der 47-Tage-Grenze ab 2029 braucht, muss nachrüsten — sonst klickt sich jemand bis 2030 die Finger blutig. Drei Wege gibt es: ein Add-on direkt an die CA flanschen, eine ACME-Bridge davorhängen, oder gleich eine zweite, ACME-native CA parallel betreiben.

Meine Empfehlung für den typischen Microsoft-Mittelstand: ACME-Bridge auf der ADCS-Issuing-CA, Secardeo certEP oder acme2certifier als Open-Source-Alternative. Wer im Tech-Scaleup oder Cloud-First-Setup ist, fährt mit Smallstep step-ca oft besser als mit jeder Bridge-Konstruktion.

Abb. 1: ACME-Bridge zwischen Konsumenten und ADCS — die Bridge übernimmt die ACME-Logik, die CA bleibt unverändert.

1. ADCS und ACME — die Funktionslücke, die Microsoft nicht schließt

ACME — das Automatic Certificate Management Environment, definiert in RFC 8555 — ist der Mechanismus, mit dem Let’s Encrypt seit 2015 die TLS-Welt automatisiert. Ein ACME-fähiger Client redet direkt mit einer ACME-fähigen CA, beantragt Zertifikate, beweist die Kontrolle über die Domäne und bekommt das fertige Zertifikat zurück. Kein Webformular, kein CSR-Hochladen, kein Admin, der einmal pro Jahr klickt. Genau die Disziplin, die ADCS bis heute nicht beherrscht.

Das war jahrelang ein theoretisches Problem. Wer interne TLS-Zertifikate wollte, hat ein Webserver-Template kopiert, Auto-Enrollment angeschaltet und Ruhe gegeben. Seit dem CA/B-Forum-Beschluss vom April 2025 ist das vorbei: 47 Tage Maximal-Gültigkeit für öffentliche TLS-Zertifikate ab März 2029, gestaffelt heruntergebrochen über 200 Tage (März 2026) und 100 Tage (März 2027). Manuelle Verwaltung ist damit faktisch unmöglich, und der Druck schwappt auch in die internen Setups: Wenn der Browser auf 47 Tage normiert, fängst du dir interne Browser-Wechsel und „warum geht das jetzt nicht mehr“-Tickets ein, wenn deine interne CA noch ein Jahr ausstellt.

Microsoft selbst hat dazu kein offizielles Statement, das nach Roadmap aussieht. Auf den UserVoice-Forks und in den Tech-Community-Threads wird seit Jahren nach nativem ACME gefragt, die Antwort lautet konsequent „wir leiten das weiter“. Cloud-PKI als Teil der Intune Suite kann ACME — On-Prem-ADCS aber bisher nicht. Wer also bei ADCS bleiben will (und das wollen die meisten, weil S/MIME, Smartcard-Logon, NDES und die ganzen anderen Use Cases dort sitzen), muss die Lücke selbst füllen.

Info · Verweis · Was die Funktionslücke konkret bedeutet Linux-Webserver, Container, Kubernetes, F5- und NetScaler-Appliances erwarten heute ACME als Standard. Jeder Workaround dafür — händisches CSR, Skript mit certreq.exe, Python gegen die DCOM-API — ist ein Hack, den genau eine Person versteht und im Krankheitsfall die ganze Firma stillsteht. ACME ist hier kein Komfort, sondern Betriebsstabilität.

Die Frage ist also nicht mehr, ob du ACME für ADCS willst, sondern wie. Genau dafür gibt es inzwischen einen Markt aus Add-ons, Bridges und Alternativen — und der ist überraschend unübersichtlich.

2. Wie ACME im Kern funktioniert

Bevor wir auf die Lösungen schauen, kurz die Mechanik. ACME ist ein Protokoll mit drei Bewegungen: Account anlegen, Order stellen, Challenge erfüllen. Klingt simpel, weil es das auch ist. Die Stärke liegt in der Standardisierung, nicht in der Komplexität.

Ein ACME-Client (certbot, acme.sh, win-acme, cert-manager, Posh-ACME) registriert sich beim ACME-Server, stellt eine Order für einen oder mehrere Hostnamen, bekommt eine oder mehrere Challenges zurück und beweist damit, dass er den Hostnamen tatsächlich kontrolliert. Drei Validation-Typen sind in der Praxis relevant:

HTTP-01 — der Client legt eine Datei unter /.well-known/acme-challenge/<token> ab, der ACME-Server zieht die Datei per HTTP. Funktioniert für jeden Webserver, scheitert hinter Firewalls.

DNS-01 — der Client setzt einen TXT-Record _acme-challenge.<host> im DNS. Funktioniert auch für interne und Wildcard-Hostnamen, braucht aber API-Zugriff auf den Nameserver.

TLS-ALPN-01 — der Client bindet sich kurzzeitig per TLS-ALPN an Port 443 mit einem speziellen ALPN-Wert. Nische, aber sauber für reine TLS-Hosts ohne HTTP-Endpoint.

Nach erfolgreicher Validation schickt der Client den CSR, die CA stellt das Zertifikat aus, der Client zieht es ab. Renewal läuft genauso, nur automatisch — der Client startet die Order, sobald das alte Zertifikat in den letzten Dritteln seiner Laufzeit ist.

Abb. 2: Der typische HTTP-01-Order-Flow gegen eine ADCS-Bridge — neun Schritte vom newOrder bis zum signierten Zertifikat.

Praxis-Tipp · Aus dem Beratungsalltag · DNS-01 ist die produktiv tragfähige Validation für interne PKI HTTP-01 funktioniert technisch, aber jeder interne Dienst, der nicht zufällig einen erreichbaren HTTP-Endpunkt hat, fällt raus. DNS-01 ist universell einsetzbar, deckt Wildcards ab und funktioniert auch für Geräte ohne eigenen Webserver. Voraussetzung: dein DNS muss API-fähig sein. Microsoft DNS kann das mit dem PowerShell-Modul oder über RFC 2136 (sec key updates). Bei Infoblox, BIND oder PowerDNS ist die Anbindung ohnehin Standard.

3. Drei Lösungswege im Überblick

Wer ACME für ADCS produktiv machen will, hat drei strategische Optionen. Sie unterscheiden sich nicht in der Funktion, sondern in der Architektur — und vor allem darin, wie viel von deinem heutigen Setup du dafür anfasst.

Ansatz	Was wird verändert	Stärke	Schwäche
Add-on auf der CA	Software-Modul direkt auf der Issuing CA	Tiefste Integration, ACME-Account kann auf Template gemappt werden	Bindet sich an Microsoft-Servicekonto, Patch-Pflege liegt komplett bei dir
ACME-Bridge davor	Eigener Server (Linux oder Windows) als RA vor der CA	Klar getrennt, OSS-Optionen vorhanden, Bridge kann gepatcht werden, ohne CA anzufassen	Zusätzlicher Server, Berechtigungsmodell muss sauber gebaut werden
Parallele ACME-CA	Zweite CA (Smallstep, EJBCA, Cloud-PKI) für ACME-only Use Cases	Native ACME-Funktion, keine Bridge-Latenz, gut für DevOps-Teams	Zweite Trustchain im Umlauf, Endgeräte müssen beiden Roots vertrauen

Welcher Ansatz für dich passt, hängt nicht von der Größe der Umgebung ab, sondern davon, ob du ADCS als Single Source of Trust behalten willst oder ob du bereit bist, eine zweite Vertrauenswurzel zu betreiben. Im Mittelstand ist die Antwort fast immer „bei ADCS bleiben“ — also Bridge oder Add-on. Im Scaleup mit Container-First-Setup landet man oft bei der parallelen CA, weil DevOps-Teams ACME als Naturzustand erwarten und nicht extra Härtungsprozesse für eine geflanschte Bridge wollen.

4. Die wichtigsten Lösungen im Detail

Es gibt mehr Angebote, als man auf den ersten Blick vermutet — und mehr gescheiterte Projekte, als man auf den zweiten Blick vermutet. Die folgende Auswahl deckt die Optionen ab, die in meinen Projekten regelmäßig auf den Tisch kommen.

Abb. 3: Vergleich der wichtigsten Lösungen — Bewertung aus Sicht eines mittelständischen Microsoft-Stacks.

Secardeo certEP

Deutsches Add-on, das direkt als Policy-Modul-Erweiterung an die ADCS-Issuing-CA gebunden wird. Vorteil: ACME-Account kann auf ein vorhandenes Zertifikatstemplate gemappt werden, die Issuance läuft über die normale ADCS-Pipeline inklusive Auto-Enrollment-kompatibler Ausstellung. Du behältst dein gesamtes Setup, nur die ACME-Anschlussstelle kommt obenauf. In Audits ist es vergleichsweise leicht zu rechtfertigen, weil keine zweite CA, kein zweiter Trust Anchor, keine zweite Schlüsselzeremonie.

Lizenzmodell ist klassisch pro Server und Volumen — was die Sache je nach Größe entweder fair oder schmerzhaft macht. Für die Musterwerk-Klasse mit ein bis zwei Issuing CAs und einem überschaubaren ACME-Volumen sehr gut investiertes Geld. Für ein Scaleup mit tausenden Container-Zertifikaten pro Monat lohnt der Blick auf Alternativen.

acme2certifier

Open-Source-Bridge in Python, Apache 2.0, gepflegt von Grindsa auf GitHub. Läuft als WSGI-Anwendung hinter einem nginx oder Apache, kann verschiedene CA-Backends ansprechen — darunter ADCS via DCOM/WCCE über das Python-Paket pyADCSproxy. Wer schon mal eine Python-Anwendung mit systemd, einem Reverse-Proxy und einer Bridge-Konfiguration in Produktion gebracht hat, fühlt sich hier wie zu Hause.

Stärken: kein Lizenzmodell, transparent, gut anpassbar. Schwächen: keine Hersteller-Hotline, kein offizieller Support, Patches sind dein Job. Für tech-affine Mittelständler (Trendforge-Klasse) eine sehr brauchbare Option — für Steuerkanzleien ohne Linux-Affinität nicht die erste Wahl.

Warnung · Klassische Falle · Open-Source-Bridges sind kein Spielzeug Wer acme2certifier oder vergleichbare OSS-Lösungen einsetzt, übernimmt Betriebsverantwortung für eine Komponente, die zwischen einem öffentlichen ACME-Endpoint und der eigenen CA hängt. Eine Schwachstelle in der Bridge ist eine Schwachstelle in der CA. Patches, Logs, Monitoring, Härtung — alles wie bei der CA selbst, nicht wie bei einem internen Tool.

Keyfactor Command

Enterprise-PKI-Management-Plattform, die sich vor existierende CAs setzt — darunter auch ADCS. ACME, SCEP, EST, REST-APIs, Discovery, Reporting, Renewal-Orchestrierung. Das volle Programm. Wenn du tausende Endpoints in mehreren Tochterfirmen hast und schon vorher überlegt hast, ob du eine PKI-Management-Plattform brauchst: ja, dann brauchst du eine, und Keyfactor ist eine der ernstzunehmenden.

Wirtschaftlich landet das in einer Größenordnung, in der man nicht mehr „mal eben testen“ kann. Für Großunternehmen und Konzerne passend, für den klassischen Mittelstand meistens nicht. Bonus: Keyfactor hat auch eigene Open-Source-Komponenten wie EJBCA (siehe unten).

Smallstep step-ca

ACME-native Open-Source-CA in Go, MIT-lizenziert. Klein, schnell, gut dokumentiert. Spricht ACME nativ inklusive aller relevanten Challenges, bringt einen eigenen Client (step), unterstützt JWK-, X5C- und OIDC-Authentifizierung für ACME-Accounts. Vorteil gegenüber Let’s Encrypt: läuft komplett bei dir und macht auch interne Hostnamen, Wildcards und kurze Laufzeiten.

Empfehlung in DevOps-lastigen Umgebungen: step-ca als zweite CA parallel zu ADCS aufstellen. ADCS bleibt für User-, Computer-, Smartcard- und S/MIME-Zertifikate zuständig, step-ca übernimmt die TLS-Zertifikate für Linux, Container und alles, was sowieso eher Cloud-Charakter hat. Endgeräte müssen beiden Roots vertrauen, das wird per GPO ausgerollt — kein Drama.

EJBCA

Java-basierte Enterprise-PKI-Suite von Keyfactor (früher PrimeKey), kann ACME, läuft als komplette CA-Plattform. Wer ADCS komplett ablösen oder eine separate hochregulierte CA für KRITIS-/eIDAS-Szenarien aufbauen will, schaut sich EJBCA an. Für „ich brauche nur ACME für meine ADCS“-Use-Cases ist das Overkill — und dann sind wir nicht mehr beim Spoke-Thema, sondern bei einer kompletten Migration.

Cloud-PKI als ergänzende ACME-CA

Microsoft Cloud PKI (Teil von Intune Suite), AWS Private CA, GCP Certificate Authority Service: alle drei können ACME nativ, alle drei sind aber primär Cloud-Lösungen mit eigener Trust-Hierarchie. Sinnvoll als Add-CA neben einer bestehenden ADCS-Umgebung, wenn du sowieso schon Intune oder eine der Hyperscaler-Welten produktiv hast. Achtung: Microsoft Cloud PKI ist als ACME-Lösung für allgemeine Linux-Hosts und Container heute noch eingeschränkt — die Stärke liegt bei Intune-verwalteten Geräten.

5. Entscheidungsmatrix — was wann passt

Aus zwei Fragen ergibt sich die Empfehlung in den meisten Projekten. Erstens: Hast du ADCS schon produktiv im Einsatz und willst es behalten? Zweitens: Greift ein regulatorischer Rahmen (BSI IT-Grundschutz, NIS2, KRITIS), der gegen Cloud-Lösungen oder gegen OSS-Bridges spricht?

Abb. 4: Entscheidungsbaum für die ACME-Strategie — vier typische Endknoten, eine eindeutige Empfehlung je Pfad.

Ein typisches Missverständnis vorab: Let’s Encrypt funktioniert intern nicht ohne weiteres. Auch wenn die Versuchung groß ist, einfach den kostenlosen Klassiker zu nehmen — Let’s Encrypt braucht entweder einen aus dem Internet auflösbaren FQDN für HTTP-01 oder DNS-01 über einen Nameserver, der von außen erreichbar ist. Für interne Dienste mit internen Namen ist das keine Option, außer du baust dir eine Konstruktion, die jedem Auditor die Tränen in die Augen treibt.

6. Stolperfallen aus dem Beratungsalltag

Was in den Hochglanz-Datenblättern der Hersteller nicht steht, sammele ich hier. Punkte, die in echten Projekten Zeit, Nerven oder Vertrauen gekostet haben.

Template-Mapping falsch geplant. Jede ACME-Bridge braucht eine Logik, welches Zertifikatstemplate sie für welchen ACME-Account verwendet. Wer das vergisst, landet bei allen Hosts auf dem Standard-Webserver-Template — inklusive falscher Schlüssellänge, falscher EKU oder fehlender SAN-Validierung. Erste Aufgabe vor dem Rollout.

Berechtigungen auf der CA zu weit aufgemacht. Die Bridge muss per Servicekonto Zertifikate anfordern dürfen — und sonst nichts. Wer dem Bridge-Konto „Read“ und „Issue and Manage Certificates“ am CA-Server gibt, baut sich eine Backdoor in die eigene CA. „Enroll“ auf den freigegebenen Templates reicht — mehr nicht.

ACME-Account-Disziplin vergessen. Jeder ACME-Account ist ein Schlüsselpaar. Wenn du allen Hosts denselben Account-Key gibst, wird das nach drei Monaten ein Drama. Ein Account pro Team, pro Anwendung oder pro Gerätegruppe — und das Onboarding standardisieren.

SAN-Härtung übersehen. ACME-Clients reichen die SANs hoch, die sie wollen. Ohne serverseitige Validation kann ein kompromittierter Webserver einfach mal einen SAN für mailserver.intern.example.com mitbeantragen. TameMyCerts als Policy-Modul oder ein striktes Template mit Subject-Validation sind hier Pflicht.

Renewal-Fenster unterschätzt. Bei 47 Tagen Laufzeit ist ein einzelner ausgefallener Renewal-Lauf am Wochenende eine kritische Eskalation am Montag. Monitoring und Alarmierung auf das Renewal-Verhalten, nicht nur auf die Zertifikatsablaufzeit.

Wer ACME für ADCS einführen will, wird mit hoher Wahrscheinlichkeit auf einer der ersten produktiv genutzten Strecken einen ACME-Client mit win-acme einsetzen. Win-acme ist der etablierte Windows-Client für ACME, läuft als Scheduled Task und kann auch gegen private ACME-Endpoints arbeiten. Das folgende Beispiel zeigt die Konfiguration gegen eine interne ACME-Bridge auf https://acme.intern.musterwerk.de:

PowerShell — win-acme gegen interne ACME-Bridge konfigurieren # win-acme im unattended-Modus konfigurieren # Voraussetzungen: WACS.exe ausgepackt nach C:\Tools\win-acme # Bridge erreichbar unter https://acme.intern.musterwerk.de # DNS-01-Validation via Microsoft DNS (Posh-ACME-Plugin)   $wacs = "C:\Tools\win-acme\wacs.exe" $acmeUrl = "https://acme.intern.musterwerk.de/directory" $mailbox = "pki-admin@musterwerk.de" $target = "webapp.intern.musterwerk.de"   # Erstkonfiguration: ACME-Server registrieren und Account anlegen & $wacs ` –baseuri $acmeUrl ` –emailaddress $mailbox ` –accepttos   # Order anlegen mit DNS-01-Validation und IIS-Installation & $wacs ` –target manual ` –host $target ` –validation dns-01 ` –validationmode dns-01 ` –store certificatestore ` –certificatestore My ` –installation iis ` –installationsiteid 1   # Renewal-Task wird automatisch unter "win-acme renew" angelegt # Prüfen: Get-ScheduledTask -TaskName "win-acme renew (acme-v02.api.letsencrypt.org)"

Praxis-Beispiel — Trendforge Digital GmbH

Trendforge ist ein Tech-Scaleup mit knapp 400 Beschäftigten, mehrheitlich in Engineering. Die interne ADCS-Umgebung ist Bestand seit der Gründung — Offline Root, eine Issuing CA, klassische Templates für Computer- und User-Zertifikate. So weit so gut. Der Auslöser kam aus dem Plattform-Team: Die Kubernetes-Cluster, die seit zwei Jahren produktiv laufen, brauchen Zertifikate für etwa 600 interne Services, alle mit cert-manager und Wildcard-SAN-Bedarf. Die Bestellung lief bis dahin über ein internes Ticket an den ITSM, der dann manuell CSRs gegen ADCS einreichte. Renewal-Zyklus: ein Jahr. Aufwand pro Renewal-Welle: zwei Wochen.

Die Empfehlung war eindeutig. ADCS bleibt Single Source of Trust für alles, was User-Identität und Geräte-Authentifizierung berührt. Für die TLS-Zertifikate der Container-Workloads kommt eine acme2certifier-Bridge auf einem dedizierten Linux-Host vor die Issuing CA, gemappt auf ein neues Template „TLS-Container-90Days“. Cert-manager im Cluster bekommt einen ClusterIssuer mit DNS-01-Validation gegen die interne BIND-Resolverschicht. Der gesamte Aufbau inklusive Härtung, Monitoring und Übergabe an den Betrieb war in acht Personentagen erledigt.

Ergebnis nach drei Monaten: 600 Zertifikate mit 90 Tagen Laufzeit, automatisch erneuert, null manuelle Tickets, ein Dashboard im Grafana für die ACME-Bridge. Das Plattform-Team hat seitdem den Renewal-Workshop aus dem Sprintplan gestrichen. Die nächste Ausbaustufe — DNS-01 auch für die Linux-Hosts außerhalb von Kubernetes — wurde vom Team selbst umgesetzt, weil das Muster jetzt verstanden und etabliert ist.

Verwandte Themen

Pillar-Seite: Active Directory Certificate Services — der komplette Leitfaden → /adcs-leitfaden/

Schwester-Spoke 6.1: Cloud-PKI vs. On-Prem ADCS — die ehrliche Entscheidungsmatrix → /adcs-cloud-vs-onprem/

Schwester-Spoke 6.2: Microsoft Cloud PKI in der Praxis — was es wirklich kann → /adcs-cloud-pki/

Schwester-Spoke 2.3: TameMyCerts als Policy-Modul — wann sinnvoll, wann übertrieben → /adcs-tamemycerts/

Häufige Fragen (FAQ)

Warum unterstützt ADCS kein natives ACME?

Microsoft hat sich nie öffentlich dazu positioniert. Inoffiziell sieht es so aus: ADCS ist auf Auto-Enrollment per GPO und auf Computer-/User-Identitäten ausgelegt — also auf die klassische Microsoft-Welt. ACME kommt aus dem Web-/Cloud-Kontext und passt nicht in das Modell, in dem AD die Identität liefert. Ob sich das mit zukünftigen Windows-Server-Releases ändert, ist offen — verlassen würde ich mich darauf nicht.

Was kostet eine ACME-Bridge im Mittelstand realistisch?

Open-Source-Bridges wie acme2certifier kosten an Lizenz nichts, an Aufbau und Härtung kalkuliere ich drei bis fünf Personentage. Kommerzielle Add-ons wie Secardeo certEP liegen in der Lizenz im niedrigen vier- bis mittleren vierstelligen Bereich pro Jahr, plus zwei bis drei Personentage Implementierung. Größere Suites wie Keyfactor sind in einer anderen Liga — fünfstellig aufwärts.

Kann ich ACME für öffentliche Zertifikate von Let’s Encrypt einsetzen, wenn ich schon ADCS habe?

Ja, das schließt sich überhaupt nicht aus. ADCS bleibt für interne Zertifikate, Let’s Encrypt liefert die öffentlichen Zertifikate für die Internet-zugewandten Dienste. Die ACME-Clients sind dafür dieselben — win-acme, certbot, cert-manager — nur der ACME-Endpoint ist ein anderer. Wichtig: getrennte Account-Keys, klare Trennung im Monitoring.

Wie sicher ist HTTP-01-Validation im Intranet?

HTTP-01 setzt voraus, dass die Bridge das Validation-Target per HTTP erreicht. Im Intranet ist das in der Regel kein Problem, aber jeder, der sich einmal in das Subnetz zwischen Bridge und Target setzen kann, kann theoretisch fremde Tokens ausliefern. DNS-01 ist robuster, weil die Manipulation auf den autoritativen DNS-Server beschränkt ist — der hoffentlich ohnehin gehärtet ist.

Funktionieren alle ACME-Clients mit jeder ADCS-Bridge?

Im Prinzip ja, weil ACME ein Standard ist. In der Praxis gibt es kleine Unterschiede: Bridge-Lösungen interpretieren die Account-Authentifizierung leicht unterschiedlich, Wildcard-SANs werden nicht von allen Clients gleich behandelt, und die EAB-Erweiterung (External Account Binding) ist nicht überall implementiert. Vor dem Rollout immer den Ziel-Client gegen die geplante Bridge testen — am besten mit dem Original-Workload.

Brauche ich ACME für ADCS wirklich vor 2029?

Wenn du Linux-Webserver, Container oder Network Appliances mit TLS-Zertifikaten aus ADCS versorgst — ja, und zwar lieber gestern als heute. Die 47-Tage-Grenze 2029 trifft öffentliche Zertifikate, aber der Trend zu kürzeren internen Laufzeiten kommt mit. Wer heute noch ein Jahr ausstellt, fängt sich spätestens 2027 die Frage, warum die interne CA die externen Standards ignoriert.

Nächste Schritte mit boddenberg.de

ACME für ADCS ist kein Tagesprojekt, aber auch kein Großprojekt. Wer die Mechanik einmal verstanden und die Bridge sauber aufgesetzt hat, bekommt eine Komponente, die sich auf Jahre auszahlt. Drei Wege, das aus meiner Werkstatt zu bekommen:

ADCS-Health-Check · Standortbestimmung deiner bestehenden PKI inklusive der Frage, ob und wo eine ACME-Bridge sinnvoll ist. Architektur, Härtung, Audit-Readiness in einer Bestandsaufnahme.

Architektur- oder Redesign-Workshop · Vom Ist-Zustand zur Zielarchitektur, mit konkretem Fokus auf die ACME-Strategie. Welche Bridge, welche Templates, welches Berechtigungsmodell.

Implementierungs- oder Migrationsbegleitung · Praktische Unterstützung beim Aufbau der Bridge inklusive Härtung, Monitoring, Übergabe an den Betrieb und Einarbeitung des zuständigen Admin-Teams.

Wer den TLS-Anteil seiner Zertifikatslandschaft systematisch erneuern will — gerade an IIS, Exchange, ADFS und Co. — sollte sich zusätzlich CertBinder anschauen (siehe Spoke 5.2). Atomare TLS-Erneuerung ist die natürliche Ergänzung zur ACME-Bridge, wenn die Endgeräte nicht selbst ACME sprechen.

Kontakt: Uli Boddenberg · boddenberg.de · Dortmund