it-swarm.com.de

Gibt es ein nicht ablaufendes SSL-Zertifikat?

Gibt es ein nicht ablaufendes SSL-Zertifikat? Unser Szenario ist, dass wir eingebettete Geräte entwickeln und verkaufen (denken Sie an "Internet der Dinge"). Auf diesen Geräten werden kleine Webserver ausgeführt, die bestimmte Verwaltungsfunktionen ermöglichen (wie ein Cisco-Heimrouter Administratoraktionen zulässt). Wir möchten eine gute Sicherheit auf diesen kleinen Webservern haben, d. H. Keine Klartextkennwörter weitergeben. Am einfachsten ist es, SSL zu verwenden, um das Kennwort in einer verschlüsselten SSL-Sitzung zu übergeben. Diese kleinen Webserver unterliegen jedoch nicht unserer Kontrolle, sobald wir sie an unsere Kunden verkaufen. Wie gehen wir mit ablaufenden SSL-Zertifikaten auf diesen Geräten um? Das Aktualisieren von SSL-Zertifikaten auf Systemen, die nicht unter unserer Kontrolle stehen, wäre nicht einfach. Gibt es eine bessere Möglichkeit, eine sichere Anmeldung für diesen Gerätetyp bereitzustellen? Wenn das "Internet der Dinge" wirklich abhebt, muss ich glauben, dass dies ein allgemeines Problem werden wird.

16
Keith Hill

Ja, Sie können Ihr eigenes Stammzertifikat generieren (d. H. Ihre eigene Zertifizierungsstelle werden) und dann jede SSR des SSL-Zertifikats mit dem Stammschlüssel signieren. Dann können Sie das Ablaufdatum für das zukünftige SSL-Zertifikat auf jedem Gerät festlegen (z. B. eine sehr optimistische Schätzung der Produktlebensdauer verwenden). Der einzige Vorteil der Salbe besteht darin, dass Ihr Stammzertifikat in jedem Client-Webbrowser, der auf die Administratorfunktionen zugreift, als vertrauenswürdiger Stamm installiert sein muss. Wenn dies für Ihre Benutzer zu kompliziert ist, können sie einfach vertrauen Sie jedem Zertifikat einzeln , was möglicherweise einfacher ist. Nachdem Sie etwas mehr darüber nachgedacht haben, müsste jedes einzelne Zertifikat ohnehin an einen bestimmten Hostnamen oder eine bestimmte IP-Adresse gebunden sein, um andere Browser-Warnungen zu vermeiden (z. B. Zertifikat-Hostname stimmt nicht mit dem tatsächlichen Hostnamen im Browser überein), also Ihren Hostnamen müsste in das Gerät "fest codiert" werden. Da dies nicht praktikabel ist, muss jeder Benutzer über die Browserwarnung hinaus klicken, um auf das Gerät zuzugreifen. Die Problemumgehung besteht darin, dass Sie es erstellen müssen, damit sie das Zertifikat selbst aktualisieren können, um die Browserwarnungen vollständig zu entfernen, oder dass das Gerät ein eigenes Zertifikat generieren kann.

Mein ZyXel NAS bietet die Funktionalität zum Generieren eines eigenen und ermöglicht das Festlegen des allgemeiner Name für das Zertifikat:

enter image description here

Das Generieren eigener Zertifikate bietet dieselben Verschlüsselungsvorteile wie die Verwendung öffentlicher Zertifizierungsstellen. Da die einzelnen Geräte ohnehin ihre eigenen privaten Hostnamen haben, ist diese Lösung möglicherweise besser geeignet als die Verwendung einer öffentlichen Zertifizierungsstelle. Intranet-Zertifikate sind verfügbar ( werden jedoch auslaufen ), aber da sie einen vollständigen Domainnamen oder eine vollständige IP-Adresse erfordern, müssten Ihre Kunden sie selbst auf dem Gerät aktualisieren.

Weitere Informationen zur Funktionsweise finden Sie unter dieser Artikel .

5
SilverlightFox

Nein, und dafür gibt es mehrere Gründe:

  • Ein Zertifikat enthält nicht nur Informationen zum Eigentümer, sondern auch seinen öffentlichen Schlüssel. Der übereinstimmende private Schlüssel ist nur dem Eigentümer des Zertifikats bekannt, und mithilfe der Kryptografie mit öffentlichem Schlüssel kann überprüft werden, ob der Endpunkt der SSL-Verbindung tatsächlich der Eigentümer ist (oder zumindest derjenige, der über den privaten Schlüssel verfügt). Das Zertifikat selbst wird von einer Zertifizierungsstelle signiert, der der Browser vertraut (dies ist alles vereinfacht). Die kryptografische Stärke all dieser Dinge hängt jedoch von der Größe der Schlüssel und den verwendeten Algorithmen ab. Eine größere Größe macht alles langsamer, eine geringere Größe macht alles weniger sicher. Und weil Computer schneller werden und Krypto-Experten nur besser werden und neue Wege finden, um einen Algorithmus zu knacken, wird der kryptografische Schutz des Zertifikats mit der Zeit schwächer. Daher muss jedes Zertifikat ablaufen, bevor der Schutz zu schwach wird.

  • Ein Zertifikat kann kompromittiert werden, z. Ein Bösewicht oder eine Agentur erhält möglicherweise den privaten Schlüssel und identifiziert sich so als Eigentümer oder entschlüsselt den gesamten Datenverkehr. In diesem Fall wird das Zertifikat widerrufen und die Widerrufsinformationen werden öffentlich zugänglich gemacht. Wenn das Zertifikat niemals ablaufen würde, müssten diese Informationen für immer aufbewahrt werden, und der benötigte Speicher und die Zeit, ein Zertifikat auf Widerruf zu prüfen, würden zunehmen. Auf diese Weise haben billigere Endbenutzerzertifikate eine kürzere Ablaufzeit als teurere Zertifikate, da billig denkende Endbenutzer wahrscheinlich auch ihren privaten Schlüssel nicht schützen. Daher ist es gut, dass ihre Widerrufe nach dem Ablaufdatum weggeworfen werden können.

5
Steffen Ullrich

RFC 5280, Abschnitt 4.1.2.5 ("Gültigkeit") beantwortet Ihre Frage technisch genau.

Kurz gesagt, ein Zertifikat mit einem Ablaufdatum von 99991231235959Z (23:59 GMT am 31. Dezember 9999) entspricht genau Ihren Anforderungen. RFC 5280 erfordert jedoch auch, dass Sie dieses Zertifikat widerrufen können müssen, um den Zertifizierungspfad zu durchbrechen ( dh durch Widerruf des Zertifikats) vor diesem Datum.

Das Ablaufdatum wird auch als Datum angesehen, an dem der Benutzer überprüfen sollte, ob die vorhandenen technischen Maßnahmen noch den aktuellen Standards entsprechen (z. B. ob ein Upgrade von einem 1024-Bit-Modul auf ein 2048-Bit-Modul oder ein Upgrade seines Servers von DES an AES).

Aus dem gleichen Grund erklären sich kommerzielle Zertifizierungsstellen damit einverstanden, für einen Zeitraum von mehr als drei Jahren keine Zertifikate mehr auszustellen, und verlangen öffentlich auflösbare DNS-Namen im öffentlichen IP-Bereich. höchstwahrscheinlich sind diese beiden Anforderungen für Sie Blocker.

Am Ende gibt es also nur zwei Möglichkeiten:

  • werden Sie Ihre eigene Stammzertifizierungsstelle und stellen Sie solche Zertifikate automatisch aus. Eine Richtlinie zum Ausstellen von Zertifikaten "für immer" entspricht nicht den Sicherheitsaspekten von Browser- und Betriebssystemanbietern. Daher müssen Ihre Benutzer Ihre Stammzertifizierungsstelle letztendlich manuell importieren. Das Empfehlen Ihrer Benutzer, Ihrer Stammzertifizierungsstelle zu vertrauen, ist ein sensibler Vorgang und wird von Ihren Benutzern möglicherweise nicht so gut angenommen. Die Zertifizierungsstelle verwendet möglicherweise x509-Namensbeschränkungen (daher sind ausgestellte Zertifikate nur für einige Domänen oder IP-Subnetze gültig), aber jeder, der etwas Sicherheit im Auge hat, wird sich immer noch fragen, ob es eine gute Idee ist, diesen Weg zu gehen. Kurz gesagt: Dies kann sehr komplex, knifflig und riskant werden - tun Sie dies nicht.

  • generieren Sie bei der Herstellung oder "Zurücksetzen auf die Werkseinstellungen" einen individuellen privaten Schlüssel auf und/oder für jedes Gerät und stellen Sie ein selbstsigniertes Zertifikat mit einem Ablaufdatum von z. 10 Jahre in die Zukunft (oder das oben genannte Sonderdatum). In der Dokumentation müssen Ihre Benutzer aufgefordert werden, zuvor installierte Zertifikate nach dem Zurücksetzen auf die Werkseinstellungen zu entfernen und dieses bestimmte Zertifikat zu importieren, um die Browserwarnung zu vermeiden. Zusätzliches Karma, um dem Benutzer zu erklären, warum dies getan werden muss :)

Beachten Sie, dass das Zertifikat bei Verwendung des Datums "für immer" möglicherweise immer noch "weniger sicher" oder "ungültig" wird. Beispielsweise schreiben Browser und Betriebssysteme eine Mindestschlüssellänge oder (defekte) Algorithmen vor, um diese Anforderungen entsprechend abzulehnen und zu aktualisieren. Im Moment können 1024 Bit "funktionieren", aber Browser zeigen Verbindungen mit weniger als 2048 Bit an, um "nicht sicher" oder als "ungültig" zu sein. Und Algorithmen brechen auch so weit, dass Browser ihnen kein Vertrauen mehr schenken. Wenn Ihr selbstsigniertes Zertifikat davon Gebrauch macht, müssen Sie es entsprechend aktualisieren.

3