Wie stellt man ein gültiges offizielles SSL-Zertifikat für eine Serviceanwendung aus?

[sh17]

Bin mal wieder am Thema dran, gerade auch durch diesen Post hier

https://talk.remobjects.com/t/improv...ing-betas/9048

Wie macht man es nun richtig?

Ich habe einen Service ohne spezielle Domain, der über TCP/IP oder auch HTTPS erreichbar sein soll. Er ist bei x-Kunden auf ihren eigenen Servern
mit dynamischen IP-Adressen installiert und soll nun ein SSL-Zertifikat bekommen, welches nicht self-signed ist.
So können sich beliebige Clients ohne Zertifikat-Installation mit diesem Service verbinden können. (Ideal wäre sogar noch eine Client-Authentifizierung per Zertifikat, die dann auch die Anmeldung abdeckt.)

Ich würde noch verstehen, wenn für jeden Server ein eigenes Zertifikat erforderlich ist. Was aber ist mit den dynamischen IP-Adressen? Könnten DynDNS-Namen zertifiziert werden?

StartSSL z.B. bietet nichts derartiges an. Welche offizielle Zertifizierungsstelle macht sowas?

[Valle]

Ein SSL-Zertifikat ist nicht an die IP-Adresse, sondern nur an eine Domain gebunden.
Edit:// Zur Klarstellung: Das heißt es ist egal ob DynDNS oder nicht. Du musst das nicht speziell betrachten. Jede CA die deine Clients als vertrauenswürdig einstuft sollte für eine HTTPS-gesicherte Webseite genügen.

Die Webseite hinter deinem Link ist übrigens für Leute ohne Account bei RemObjects nicht einsehbar.

Welche Software wird denn Serverseitig als HTTP-Server eingesetzt?

[sh17]

Zitat:

Zitat von Valle (Beitrag 1336666)

Welche Software wird denn Serverseitig als HTTP-Server eingesetzt?

Ein RemObjectsSDK Service mit z.B. Delphi und den Indy-Componenten erstellt.

Das würde bedeuten, das ich für unserer Kunden quasi ein eigenes DynDNS-System aufsetzen müsste mit einer Hauptdomain meineseite.de und dann für diese ein Wildcard-Zertifikat kaufe?

[Valle]

Es gibt verschiedene Möglichkeiten. Ein Wildcard Zertifikat ist recht teuer, aber durchaus eine (vor allem einfache!) Möglichkeit.

Eine andere Möglichkeit (wenn das technisch für dich in Frage kommt) wäre ein Reverse Proxy. Eine Domain und ein SSL-Zertifikat genügt und du könntest die Kundenserver über einen zentralen Proxy ansprechbar machen.

Deine URLs würden wie folgt aussehen:

http://www.example.com/kundeA
http://www.example.com/kundeB

Dein Reverse Proxy würde Anfragen an /kundeA dann an den entsprechenden Server des Kunden A weiterleiten. Bedeutet natürlich, dass die Pfade sich ändern. Also eine beispielhafte Anfrage an /kundeA/delete/1234 würde beim Kundenserver an /delete/1234 weitergeleitet.

Das ist deutlich komplexer, aber auch deutlich billiger. Nur damit du auch eine Alternative zu Wildcard kennst.

Um eine sinnvolle Möglichkeit zu nennen, wären ein paar mehr Infos aber praktisch. Eventuell könnte auch ein Zertifikat pro Kunde eine Möglichkeit sein. Diese könntest du den Kunden in Rechnung stellen. Man muss eben ausrechnen, ab wann sich Wildcards lohnen.

Noch was anderes: Wenn du Kundenserver per HTTPS erreichbar machen willst, dann handelt es sich vermutlich um Webseiten (sprich: HTML) die ausgeliefert werden und von normalen Browsern aufgerufen werden? Denn es gibt nachwievor die Option Zertifikate nicht von einer CA zu kaufen, sondern eine eigene CA anzulegen und die Zertifikate von dieser unterschreiben zu lassen.

Entgegen allgemeiner Meinung ist das dann nicht weniger sicher, sondern bei richtiger Konfiguration sogar sicherer. Wenn du der Clientsoftware nur deine CA mitgeben kannst, dann ist auch nur deine CA dazu berechtigt, Zertifikate für deine Server auszustellen. Bei Browsern hingegen sind hunderte CAs hinterlegt und jede davon kann prinzipiell Zertifikate aussstellen, die dann akzeptiert werden. Ist auch nur eine der hunderten CAs nicht sicher, fällt die Sicherheit des gesamten Systems.

[sh17]

Danke für die umfangreiche Antwort. Also per Browser muss nicht zugegriffen werden. Nur über eigene Anwendungen/Apps. Bis jetzt also nur .Net und Android bei den Clients.
Mit einer eigenen CA hab ich auch schon geliebäugelt, die scheint durchaus Sinn zu machen. Bei Android können ja eigene Zertifikate in eine App integriert werden. Bei iOS weiß ich nicht, muss ich mich noch damit beschäftigen.

So ein Reverse Proxy wäre auch sowas hier?: https://github.com/thinktecture/relayserver An dem ist ja phoenix beteiligt, glaube ich.

[Valle]

Wenn du die Clients komplett selbst in der Hand hast, dann mach eine eigene CA. Ich sehe keinen Sinn dahinter, haufenweise Geld für virtuelle Waren auszugeben, deren einziger Vorteil darin liegt, dass die CAs in allen Browsern verfügbar sind, obwohl man nicht mal einen solchen Browser verwendet. Dafür kaufst du dir noch Unsicherheiten ein. Eine eigene CA ist kostenlos, schnell und sicherer.

Was den Reverse Proxy angeht; Da ich aus der Linuxserver Welt stamme, sind nginx und Apache HTTPd natürlich erste Wahl. Ich mutmaße ohne jede Ahnung, dass der IIS das aber auch können wird. Solltest du dich für eine eigene CA entscheiden, würd ich den Reverse Proxy Lösung aber vermeiden.

Wenn du die Clients programmierst, dann gibt es selbstverständlich für jede Plattform die Möglichkeit die CAs selbst zu wählen. Ich habe das selbst für mobile Plattformen noch nicht gemacht, aber es kann unmöglich vom Betriebssystem vorgegeben sein, welche CAs immer vertrauenswürdig sind. Du bist ja nicht der erste, der SSL/TLS in seiner App benutzt.

[sh17]

OK, Danke, da habe ich zumindest erst einmal eine Richtung, in die ich gehen kann.

Das Thema hier kann gern weiter offen bleiben für weitere Vorschläge. Wie gesagt, bin ja nicht der erste :)

[mjustin]

Zitat:

Zitat von sh17 (Beitrag 1336667)

Das würde bedeuten, das ich für unserer Kunden quasi ein eigenes DynDNS-System aufsetzen müsste mit einer Hauptdomain meineseite.de und dann für diese ein Wildcard-Zertifikat kaufe?

Was technisch möglich ist, aber von den Wildcard-Zertifikatanbietern in den Geschäftsbedingungen ausgeschlossen sein kann: das Zertifikat auf mehr als einem Server installieren. Was auch nachvollziehbar ist, denn alle Server würden den gleichen privaten Schlüssel benötigen.

https://forum.webhostlist.de/threads...server.103919/

[sh17]

Könnte man nicht die SSL-Zertifikate für jede Subdomain separat mit https://letsencrypt.org erstellen?

[mkinzler]

Sollte grundsätzlich funktionieren. Die Signaturen haben aber mit immer nur 3 Monate Gültigkeit.