Welche Arten von Zertifikaten kann ich selbst signieren? (Und sollte ich das wirklich?)

Stell dir vor, du gehörst zum Ingenieurteam des Todessterns (I). Es gibt ein Problem zu lösen: Es gibt keine Möglichkeit, die von dem riesigen internen Triebwerk erzeugte Hitze abzuleiten, ohne eine Abgasöffnung direkt ins All zu bauen.

"Sicherlich wird niemand diese winzige Schwachstelle finden", denkst du. "Es ist unmöglich, dass ein unerschrockener Jedi mit einem X-Wing einfliegt und alles zerstört, was ich mir so hart erarbeitet habe." 

Stellen Sie sich nun vor, Sie gehören zum Ingenieurteam des Todessterns (II). Der erste Arbeitsauftrag? Die Behebung des Problems mit der Abgasöffnung und jeder anderen Schwachstelle, die den Kernreaktor gefährden könnte, die kritische Infrastruktur, von der alle Ambitionen des Imperiums abhängen. 

Wenn es um die PKI in Ihrem Unternehmen geht, ist der fehlerhafte Abluftanschluss eine einfache Fehlkonfiguration oder ein Konstruktionsfehler, wie ein selbstsigniertes Zertifikat, das die Tests nicht besteht.

Es gibt viele Fälle, in denen selbstsignierte Zertifikate die bequemste Option zu sein scheinen, aber sie werden schnell zu einem Sicherheitsrisiko, wenn sie schlecht verwaltet oder, schlimmer noch, in Produktionsumgebungen eingesetzt werden. 

Not only do self-signed certificates lack the validation offered by Certificate Authorities (CAs), but improper certificate management practices leave security gaps when combined with other elements of poor PKI hygiene, such as lax key storage.

Anstatt selbstsignierte Zertifikate als niedrig hängende Früchte für böswillige Akteure zu betrachten, sollten Sie die Vorteile einer automatisierten, zentralisierten Lösung für die Verwaltung des Lebenszyklus von Zertifikaten nutzen, um Risiken zu minimieren und Ihr Unternehmen zu schützen. 

Zertifikate, die Sie selbst signieren können

In certain situations, self-signed certificates serve a useful purpose within an organization’s infrastructure: they offer a quick, cost-effective way to support SSL/TLS functionality without requiring CA infrastructure. Proceed with caution, however; these self signed certificates should be limited to very specific, codified internal uses to avoid the security risks associated with unvalidated / unvalidated certificates. 

Entwicklungs- und Testumgebungen

Selbstsignierte Zertifikate ermöglichen es Entwicklern in Testumgebungen, die Funktionalität von SSL/TLS schnell und kostenlos zu simulieren und sichere Verbindungen und Verschlüsselung zu testen, ohne eine Zertifizierungsstelle einzuschalten. Diese Umgebungen sollten von öffentlichen Netzwerken isoliert sein und nur bereinigte Testdaten enthalten, wodurch die Notwendigkeit, eine öffentliche Vertrauenskette oder die private Vertrauenskette Ihres Unternehmens aufrechtzuerhalten, verringert wird. Der Haken an der Sache: Es ist immer noch wichtig, die Autorität und Kontrolle über diese Art von Zertifikaten zu behalten, um zu verhindern, dass sie versehentlich in Produktionsumgebungen gelangen. 

Interne Dienste und Netze

Für ausgewählte interne Tools, Intranet-Sites und Anwendungen, auf die ausschließlich autorisierte Benutzer zugreifen, können auch selbstsignierte Zertifikate akzeptabel sein. In einer kontrollierten Umgebung, in der externe Benutzer und Geräte nicht auf interne Ressourcen zugreifen können, hat das Fehlen einer vertrauenswürdigen CA-Signatur nur minimale Auswirkungen. Doch auch bei interner Verwendung müssen selbst signierte Zertifikate sorgfältig verwaltet werden; das Ablaufen von Zertifikaten oder die versehentliche Veröffentlichung sind immer noch mögliche Probleme. Es wird jedoch immer noch empfohlen, eine interne private PKI über ein selbstsigniertes Zertifikat zu verwenden, falls verfügbar.

Kurzfristige oder vorübergehende Lösungen

Wenn ein Zertifikat für ein kurzfristiges Projekt oder eine zeitlich begrenzte Anwendung benötigt wird, ist die Selbstsignierung möglicherweise die einfachste Option. In Situationen, in denen ein Projekt intern oder privat für einen kurzen, bestimmten Zeitraum genutzt wird, bieten selbstsignierte Zertifikate eine schnelle Möglichkeit, sichere Verbindungen herzustellen. Wie bei allen vorherigen Beispielen sollten auch diese Arten von Zertifikaten den Praktiken des Zertifikatslebenszyklusmanagements unterliegen, um sie sicher außer Betrieb zu nehmen, wenn ihre Verwendung erschöpft ist.

As with many elements of cybersecurity (generally) and PKI (specifically), the use of self-signed certificates in your organization fall under risk management. With the right authority and maintenance, self-signed certificates can be a fast, handy solution; without a comprehensive CLM, these handy certs can quickly turn a useful tool into a devastating weakness. 

Zertifikate, die Sie NICHT selbst signieren sollten

Most certificates should not be self-signed. Low risk is not the same as no risk; self-signed certificates fail to meet compliance standards, often are poorly minted with extensions asserted, are easy for bad actors to spoof, and cannot be trusted in many environments due to the fluid nature of most enterprise networks trying to get a new certificate pushed to all the trust stores.

Bei öffentlich zugänglichen Anwendungen, kundenorientierten Diensten, Code Signing und Produktionsumgebungen sind Zertifikate, die von einer vertrauenswürdigen Zertifizierungsstelle ausgestellt wurden, für die Sicherheit, das Vertrauen und eine reibungslose Benutzererfahrung unerlässlich. 

Öffentlich zugängliche Websites (SSL/TLS Zertifikate)

On the internet, certificates from publicly trusted CAs are critical for secure, verifiable connections. Browsers and other clients do not recognize self-signed certificates as legitimate, greeting visitors with warnings that the site connection is “not secure.” These warnings erode user trust, detract from user experience, and discourage users from engaging with the website for their own protection. More importantly, self-signed certificates on public sites create an opportunity for in man-in-the-middle attacks, in which malicious actors intercept and manipulate data sent between the website and its visitors.

Recommendation: It’s a best practice to use CA-issued SSL/TLS certificates for public websites to protect against impersonation and maintain user confidence in your site (and, by extension, your brand). These types of certificates have short expiration windows; with a centralized CLM, you can automate the issuance, renewal, and revocation processes to save time and prevent human error.

Kundenseitige Anwendungen und Dienste

Any application or service that interacts with clients or external users should use publicly trusted certificates. When client applications, browsers, or APIs communicate over HTTPS or other secure protocols, self-signed certificates trigger security warnings if they’re not rejected outright. This disruption of connectivity impacts trust, with clients perceiving the service as insecure or unprofessional. Moreover, if a self-signed certificate is used and bypassed in these settings, user data may be at risk from potential attackers who could exploit the lack of trusted verification. 

Recommendation: Certificates issued by a trusted CA protect your clients from insecurity warnings and enable a consistent, secure connection to the apps and services they need. 

Code-Signatur-Zertifikate

Diese Zertifikate bestätigen die Authentizität von software und stellen sicher, dass der Code seit seiner Signierung nicht verändert wurde, was den Übergang von der "Test-" zur "Produktionsumgebung" anzeigt. Die meisten Betriebssysteme und Anwendungsspeicher akzeptieren keinen selbstsignierten Code, da dieser keine Gewähr für die Identität des Entwicklers bietet. Wenn ein selbstsigniertes Zertifikat zum Signieren von Code verwendet wird, erhalten die Benutzer wahrscheinlich Warnungen, die darauf hinweisen, dass software aus einer nicht vertrauenswürdigen Quelle stammt, was zu Zögern und potenziellen Sicherheitsbedenken führt. 

Recommendation: Use CA-issued signing certificates to avoid security alerts and facilitate smooth installations, maintaining user trust in the software. 

Produktionsumgebungen

The goal of development and testing is to get to the production environment, in which your application, software, or service is externally exposed. Production demands a high level of reliability, visibility, and security; even test environments that connect to production resources often need to establish an elevated level of trust to reduce security risks. Using self-signed certificates in production—or testing environments that mirror production—introduces unnecessary vulnerability, increasing the risk of operational disruptions if certificates expire or become compromised. 

Recommendation: Use authoritative, CA-issued certificates for production environments such as the corporate trusted PKI for internal use cases or a publicly trust CA for external user access use cases.. A trusted CA should offer scalable solutions that provide these types of certificates on demand, effectively eliminating the barrier of issuing CA-signed certs for internal resources. For added security, use trusted certificates wherever possible.

Beseitigen Sie mit PKIaaS den Bedarf an selbstsignierten Zertifikaten

Self-signed certificates might offer a quick fix for small teams or low-risk internal applications, but as your organization scales and digital operations grow more complex, they become a liability – introducing vulnerabilities and creating management headaches.

Mit der PKI-as-a-Service von Keyfactorkönnen Sie auf selbstsignierte Zertifikate vollständig verzichten. Unsere Zertifikatsautomatisierung und die zentrale Verwaltung vereinfachen die Ausstellung, die Verfolgung des Ablaufs und die Erneuerung für alle Ihre digitalen Assets. Das Ergebnis? Eine effiziente, skalierbare und sichere PKI, die sich mit Ihrem Unternehmen weiterentwickelt.

Verlassen Sie sich nicht nur auf unser Wort. Keyfactor wurde im Frost Radar™-Bericht 2024 für Wachstum und Innovation unter den PKIaaS-Anbietern auf Platz 1 gesetzt. Sicherheitsteams, die unter zunehmendem Druck stehen, kritische Systeme zu schützen, wenden sich an Keyfactor für einen Cloud-first-Ansatz, der PKI nach Bedarf bereitstellt.

Close the exhaust port and secure your Death Star – err, organization – with professionally managed PKI infrastructure that leaves nothing to chance. Build user trust, protect your systems, and stay ahead of tomorrow’s challenges with Keyfactor.

Machen Sie Ihre nächsten Schritte 

Curious to know more? We’re here to help! You can request a demo to brainstorm with our team, get your questions answered, and discover which solution best fits your needs.