SSL ist im Alltag längst eher TLS, aber die betriebliche Aufgabe dahinter bleibt dieselbe: Zertifikate müssen auffindbar, überprüfbar und rechtzeitig erneuert werden. Bei cert sh denken viele zuerst an crt.sh, also an die Suche in Certificate-Transparency-Logs; genau dort liegt der praktische Nutzen für Betreiber, Security-Teams und alle, die ihre öffentliche Zertifikatslandschaft sauber im Griff haben wollen. Ich ordne hier ein, was crt.sh wirklich kann, wie man die Einträge liest und warum ein ACME-Client wie acme.sh für die eigentliche Automatisierung oft die passendere Ergänzung ist.
Die wichtigsten Punkte zu Sichtbarkeit und Zertifikatsautomation
- crt.sh ist keine Stelle, die Zertifikate ausstellt, sondern eine Such- und Analyseoberfläche für Certificate-Transparency-Logs.
- Du findest dort vor allem öffentliche TLS-Zertifikate, nicht deine interne PKI.
- Wichtige Felder sind Domäne, SANs, Aussteller, Gültigkeit, Fingerprint und die crt.sh-ID.
- Für die automatische Ausstellung und Erneuerung brauchst du ein ACME-Tool wie acme.sh oder eine ähnliche Lösung.
- CT ist stark für Transparenz, aber kein Ersatz für Inventar, Monitoring und saubere Zuständigkeiten.
Was hinter crt.sh im Zertifikatsumfeld steckt
crt.sh gehört in die Welt der Certificate Transparency, also der öffentlichen Protokollierung von ausgestellten TLS-Zertifikaten. Diese Logs sind dafür da, dass Zertifikatsausstellungen nachvollziehbar werden und Fehl- oder Falsch-Ausstellungen schneller auffallen. Technisch ist das ein wichtiger Baustein der Web-PKI: Die Logs sind öffentlich verifizierbar und als append-only ausgelegt, damit nachträgliche Manipulationen auffallen.
Der entscheidende Punkt ist die Abgrenzung: crt.sh ist kein Zertifizierungsdienst und kein Lifecycle-Management-System. Das Tool zeigt dir, was in öffentlichen CT-Logs auftaucht, und macht diese Daten durchsuchbar. Du kannst dort nach Domänen, Organisationsnamen, Fingerprints oder einer crt.sh-ID suchen. Für den Alltag bedeutet das: Sichtbarkeit ja, Ausstellung nein.
Genau diese Trennung wird oft übersehen. Wer nur auf die Browserwarnung kurz vor Ablauf reagiert, verwaltet Zertifikate reaktiv. Wer CT-Logs mit Inventar und Automation kombiniert, arbeitet deutlich sauberer. Und damit ist der Blick auf die Einträge selbst der nächste logische Schritt.
Wie ich Einträge in crt.sh richtig lese
Ein Eintrag ist mehr als nur ein Treffer. Ich schaue zuerst auf die Namen im Zertifikat, dann auf den Aussteller und schließlich auf die Laufzeit. So lässt sich schnell einschätzen, ob der Fund erwartbar ist oder eher nach einem vergessenen System, einer Schatten-Umgebung oder einer falschen Ausstellung aussieht.
| Worauf ich achte | Was es bedeutet | Typische Fehlinterpretation |
|---|---|---|
| Domäne und SAN | SAN steht für Subject Alternative Name und zeigt die Namen, die das Zertifikat abdeckt. | Ein einzelner Treffer ist nicht automatisch ein einzelner Host. |
| Aussteller | Die Zertifizierungsstelle, die das Zertifikat signiert hat. | Ein unbekannter Aussteller kann ein Hinweis auf Fremdbezug oder Schatten-IT sein. |
| Gültigkeit | Der Zeitraum, in dem das Zertifikat technisch gültig ist. | Ein CT-Eintrag sagt nichts darüber aus, ob das Zertifikat gerade aktiv eingesetzt wird. |
| Fingerprint | Der Hashwert des Zertifikats, also ein eindeutiger Fingerabdruck. | Mehrere ähnliche Einträge können dennoch unterschiedliche Zertifikate sein. |
| crt.sh-ID | Die interne Referenz des Logeintrags. | Das ist keine Management-ID deiner Infrastruktur, sondern nur der Verweis im Log. |
Wenn du mehrere ähnliche Einträge siehst, ist das nicht automatisch ein Problem. Erneuerungen, Reissues und Wildcard-Zertifikate erzeugen schnell mehrere Datensätze, die auf den ersten Blick gleich aussehen. Ich prüfe deshalb immer, welcher Eintrag historisch relevant ist und welcher wirklich zum aktuellen Betrieb gehört. Genau dieses Lesen trennt nützliche Analyse von bloßem Datenrauschen.
Wofür ich das Tool im Alltag nutze
In der Praxis setze ich crt.sh vor allem dort ein, wo öffentliche Zertifikate ein Hinweis auf unbekannte oder vergessene Angriffsfläche sein können. Das ist kein offensiver Blick, sondern eine sehr nüchterne Form von Bestandsaufnahme. Besonders hilfreich ist das in gewachsenen Umgebungen, in denen Cloud, On-Prem, Dienstleister und einzelne Fachbereiche nebeneinander arbeiten.
- Vergessene Subdomains finden - Wenn ein altes System noch ein öffentliches Zertifikat bekommen hat, steckt dahinter oft mehr als nur ein technischer Rest.
- Ungeplante Ausstellungen erkennen - Taucht ein Zertifikat von einer CA auf, die ich nicht einsetze, wird geprüft, ob das Absicht, Fehlkonfiguration oder ein echter Vorfall ist.
- Migrations sauber vorbereiten - Vor einem Umzug sehe ich, welche Namen öffentlich bereits zertifiziert wurden und wo ich Namensräume konsolidieren muss.
- Incidents schneller einordnen - Nach einem Vorfall hilft die Zertifikatsspur, den öffentlichen Fußabdruck einer Domain oder Marke zu rekonstruieren.
- Ownership klären - CT-Daten machen sichtbar, ob ein Zertifikat zwar vorhanden, aber intern niemandem sauber zugeordnet ist.
Gerade für deutsche Organisationen mit vielen Schnittstellen ist das wertvoll: Nicht, weil das Tool Magie liefert, sondern weil es eine zusätzliche, verlässliche Sicht auf öffentlich ausgestellte Zertifikate schafft. Und genau da liegt auch die Grenze des Ansatzes.
Wo crt.sh aufhört zu helfen
So nützlich CT-Transparenz ist, sie ersetzt kein vollständiges Zertifikatsmanagement. Der häufigste Denkfehler ist, aus einem Logeintrag zu viel abzuleiten. Ein Fund in crt.sh beweist weder, dass ein Dienst noch online ist, noch dass das Zertifikat gerade produktiv verwendet wird. Es zeigt vor allem, dass es öffentlich ausgestellt und geloggt wurde.
| Frage | Was crt.sh beantwortet | Was du zusätzlich prüfen musst |
|---|---|---|
| Ist ein öffentliches Zertifikat für diese Domain ausgestellt worden? | Ja, sehr gut sichtbar. | Nur noch den aktuellen Status im Inventar und am Dienst selbst. |
| Ist der Dienst aktuell erreichbar? | Nein. | Monitoring, Port-Checks oder HTTP-Checks. |
| Gehört das Zertifikat zu meiner internen PKI? | In der Regel nicht. | Separates internes Inventar und interne Trust-Strukturen. |
| Ist das Zertifikat widerrufen oder ersetzt? | Nur indirekt ableitbar. | Revocation-Status, Laufzeit, Deployment-Stand. |
Für mich ist das die wichtigste Klarstellung: CT ist eine Sichtbarkeits- und Kontrollschicht, kein vollständiges Betriebswerkzeug. Wenn du das sauber trennst, vermeidest du falsche Sicherheit. Wenn du es vermischst, entstehen Lücken, die man erst bemerkt, wenn ein Zertifikat tatsächlich ausläuft oder ein fremder Name öffentlich auftaucht.
Warum acme.sh in derselben Diskussion auftaucht
Der zweite Teil der Verwirrung kommt meist von acme.sh. Das ist ein ACME-Client, also ein Werkzeug, das Zertifikate über das ACME-Protokoll automatisch ausstellen, erneuern und installieren kann. Es ist als Shell-Skript umgesetzt und damit sehr leichtgewichtig. Für mich ist das die andere Hälfte des Problems: crt.sh zeigt, was sichtbar ist, acme.sh sorgt dafür, dass Zertifikate überhaupt sauber entstehen und rechtzeitig erneuert werden.
Wenn ich die Rollen nebeneinanderstelle, wird es schnell klar. crt.sh ist Recherche und Transparenz. acme.sh ist Automatisierung. Wer Zertifikate produktiv betreibt, braucht oft beides, aber eben nicht aus demselben Grund.
| Werkzeug | Rolle | Stärke | Grenze |
|---|---|---|---|
| crt.sh | Suche und Analyse von CT-Logs | Öffentliche Zertifikate schnell sichtbar machen | Keine Ausstellung, keine Erneuerung, keine interne PKI |
| acme.sh | ACME-basierte Ausstellung und Verlängerung | Automatisierung, wenig Abhängigkeiten, gut für Wildcard- und SAN-Zertifikate | Nur sinnvoll, wenn die CA und der Einsatzfall ACME unterstützen |
| Certificate Lifecycle Management | Zentrales Management für große Umgebungen | Inventar, Richtlinien, Eskalationen und Ownership in einem Prozess | Mehr Einführungsaufwand und mehr Prozessdisziplin |
Wenn dein Ziel also ist, Zertifikate automatisch zu beantragen und zu verlängern, ist die Antwort nicht crt.sh, sondern ein ACME-Client wie acme.sh oder eine vergleichbare Plattform. Wenn dein Ziel ist, die öffentliche Zertifikatslandschaft zu verstehen, ist crt.sh genau der richtige Einstieg.
Ein praxistauglicher Ablauf für 2026
2026 reicht es mir nicht mehr, Zertifikate nur irgendwann zu erneuern. In einer gemischten Infrastruktur mit Cloud, Containern, Legacy-Systemen und externen Dienstleistern funktioniert für mich ein einfacher Dreiklang am besten: Sichtbarkeit, Automation und Ownership.
- Inventar pflegen - Ich halte fest, welche Domains, Subdomains und internen Namen wirklich existieren und wem sie gehören.
- Öffentliche Zertifikate regelmäßig prüfen - crt.sh nutze ich als zusätzliche Kontrolle für öffentlich sichtbare Namen und unerwartete Aussteller.
- Erneuerung automatisieren - Für öffentliche, ACME-fähige Zertifikate setze ich auf automatische Verlängerung statt manuelle Einzelpflege.
- Puffer einplanen - Ich arbeite intern meist mit 30 Tagen Vorlauf, bei komplexen Umgebungen eher mit 45 bis 60 Tagen.
- Ausnahmen getrennt behandeln - Interne PKI, Spezialgeräte und manuelle Zertifikate laufen bei mir in einem separaten Prozess, nicht im selben Topf wie öffentliche Web-Zertifikate.
Gerade in deutschen Umgebungen, in denen häufig mehrere Teams, Provider und Plattformen zusammenkommen, ist diese Trennung entscheidend. Sie reduziert Überraschungen, macht Verantwortlichkeiten sichtbar und verhindert, dass ein öffentlich ausgestelltes Zertifikat erst dann auffällt, wenn der Betrieb schon unter Druck steht.
Was ich aus dem Werkzeugmix mitnehme
Mein Fazit ist pragmatisch: crt.sh zeigt dir, was öffentlich über deine Zertifikate bekannt ist, acme.sh oder ein ähnlicher ACME-Client sorgt dafür, dass die Zertifikate sauber und automatisiert laufen. Dazwischen liegt die eigentliche Betriebsarbeit, also Inventar, Zuständigkeit, Monitoring und klare Ausnahmen. Genau diese Schichten zusammen machen aus Zertifikatsverwaltung einen belastbaren Prozess statt einer Sammlung einzelner Notlösungen.
Wenn du nur mit einem Schritt starten willst, nimm zuerst die Sichtbarkeit ernst: öffentliche Namen prüfen, Abweichungen dokumentieren und dann die Erneuerung konsequent automatisieren. Der größte Gewinn entsteht nicht durch das einzelne Tool, sondern durch die saubere Trennung von Beobachtung, Betrieb und Verantwortung.
