SSL Zertifikat Anwendungsmöglichkeiten.

[t-flash]

Hallo liebes Syno-Forum,
da ich bislang meine Syno über HTTP + HTTPS ausgeführt hatte und beide Verbindungen möglich waren, jedoch die HTTPS über einen Fremdzertifikat von nem kostenlosen Aussteller wodurch ich das Problem , wo die Meldung, dass dem Netzwerk nicht vertraut wird immernoch hatte und nur die Verbindung verschlüsselt war am Ende.

Nun habe ich mir Testweise ein 30-Tages Zertifikat von nem autorisierten Aussteller (ssl-trust.com) ausstellen lassen und benutze diesen Testweise.
Bislang kann ich mich auch nicht beklagen, mehrere Tests durchgeführt mit unterschiedlichen Browsern, Mobiltelefon und SSL-Test Tools alles hat bislang funktioniert und zweifelsfrei das Zertifikat erkannt und keinerlei Fehlermeldungen oder ähnliches ausgegeben, so wie es ja eigentlich auch sein sollte.


Nun stelle ich mir jedoch die Frage, müsste man bei der Synology eigentlich SSL verwenden ? Also ab wann macht so eine Verwendung eigentlich Sinn um erlich zu sein ?
Und desweiteren frage ich mich, was alles wird durch das SSL-Zertifikat abgesichert überhaupt ? also was wird verschlüsselt ? Habe kenntniss, dass der Webserver + DSM-Weboberfläche über Port 5001 abgesichert wird.
Aber was ist mit den ganzen Apps wie, Filestation, Videostation, Photostation und all den anderen Zusatzanwendungen die man von außen erreichen kann ? Werden diese auch abgesichert , oder eher nicht ?


Und meine letzte Frage: Über SSL wird ja alles letzendlich verschlüsselt, was ist aber mit dem Aussteller, bei SSL werden durch das Zertifikat und dem Zertifizierungsserver auch die Daten über deren Server gejagt dort weitergegeben und weiterverschickt, oder ?
Oder verlaufen die Daten von A nach B direkt ohne jeweils andere Rechner / Server anzusteuern ? Bin mir bei diesem Funktionsprinzip noch nicht im klaren ...



Vielen Dank & Liebe Grüße,
T-Flash.

 

[Frogman]

...
Nun stelle ich mir jedoch die Frage, müsste man bei der Synology eigentlich SSL verwenden ? Also ab wann macht so eine Verwendung eigentlich Sinn um erlich zu sein ?

Sorry, hier verstehe ich nicht, was Du meinst?

...
Und desweiteren frage ich mich, was alles wird durch das SSL-Zertifikat abgesichert überhaupt ? also was wird verschlüsselt ? Habe kenntniss, dass der Webserver + DSM-Weboberfläche über Port 5001 abgesichert wird.
Aber was ist mit den ganzen Apps wie, Filestation, Videostation, Photostation und all den anderen Zusatzanwendungen die man von außen erreichen kann ? Werden diese auch abgesichert , oder eher nicht ?

Die SSL-Verschlüsselung (implementiert über OpenSSL) sichert alle verschlüsselt betriebenen Ports ab und damit die dahinter betriebenen Dienste. Port 5001 sicher den DSM-Zugriff, Port 443 üblicherweise den User-Webserver, über den Applikationen wie die Photo Station und andere vHosts laufen. 3rd-Party-Apps wie bspw. ownCloud erlauben ebenso die Nutzung der Verschlüsselung über entsprechend einstellbare Ports, sowohl für den Zugriff auf eine Weboberfläche oder auch WebDAV.
Die Synology-eigenen Apps wie Filestation usw. lassen sich entweder als Alias über den Port 5001 verschlüsselt aufrufen oder aber über einen separat einstellbaren https-Port (findest Du im Anwendungsportal in der Systemsteuerung).

 

[t-flash]

Sorry, hier verstehe ich nicht, was Du meinst?

Habe mich dann etwas undeutlich wohl ausgedrückt, tut mir leid.
Also was ich damit meine ist, ist eine SSL-Verschlüsselung bei der Synology zwingend notwendig, oder wäre theoretisch gesehen eine unverschlüsselte Verbindung schon in Ordnung um genug Sicherheit zu gewähren ?
Ich denke mal starke Passwörter und alles reichen ja schon im größten Umfang aus, oder ? Muss also zwangsweise für mehr Sicherheit extra eine SSL-Verschlüsselung her ?
Die Standart unverschlüsselte Verbindung wird wohl hier nicht ausreichen sein, oder ? :S

Die SSL-Verschlüsselung (implementiert über OpenSSL) sichert alle verschlüsselt betriebenen Ports ab und damit die dahinter betriebenen Dienste. Port 5001 sicher den DSM-Zugriff, Port 443 üblicherweise den User-Webserver, über den Applikationen wie die Photo Station und andere vHosts laufen. 3rd-Party-Apps wie bspw. ownCloud erlauben ebenso die Nutzung der Verschlüsselung über entsprechend einstellbare Ports, sowohl für den Zugriff auf eine Weboberfläche oder auch WebDAV.
Die Synology-eigenen Apps wie Filestation usw. lassen sich entweder als Alias über den Port 5001 verschlüsselt aufrufen oder aber über einen separat einstellbaren https-Port (findest Du im Anwendungsportal in der Systemsteuerung).

Vielen Dank für diese Antwort,
das heißt also, selbst wenn ich z.b die Adresse http://meinedomain.**/file benutze ist es die Selbe wie http://meinedomain.**:7001 (falls port 7001 aktiviert und weitergeleitet wurde) ? und greift zusätzlich auf die SSL-Verschlüsselung zu ?

Wie sehe es den damit aus mit der Abhörsicherheit. Die Verschlüsselung wird ja vom Senderechner unternommen und beim Empfangsrechner wieder durch den jeweiligen SSL-Key entschlüsselt, richtig ?
Wäre ein Abhören oder Abfangen durch den Authority-Server des jeweiligen Zertifikatausstellers theoretisch möglich, oder nicht ?

 

[Frogman]

Also was ich damit meine ist, ist eine SSL-Verschlüsselung bei der Synology zwingend notwendig, oder wäre theoretisch gesehen eine unverschlüsselte Verbindung schon in Ordnung um genug Sicherheit zu gewähren ?
Ich denke mal starke Passwörter und alles reichen ja schon im größten Umfang aus, oder ? Muss also zwangsweise für mehr Sicherheit extra eine SSL-Verschlüsselung her ?

Ein starkes Passwort ist immer gut - ansonsten ist eine BruteForce-Attacke ein Kinderspiel. Der Sinn der Verschlüsselung ist allerdings ein anderer: sowohl Passworte als auch Inhaltsdaten können bei unverschlüsselten Ports mitgelesen werden - wenn es also jemand darauf anlegt, auf Deine DS und damit an die Daten zu kommen, wäre es für ihn recht leicht. Von daher solltest Du bei externem Zugriff immer die verschlüsselten Varianten verwenden.

...das heißt also, selbst wenn ich z.b die Adresse http://meinedomain.**/file benutze ist es die Selbe wie http://meinedomain.**:7001 (falls port 7001 aktiviert und weitergeleitet wurde) ? und greift zusätzlich auf die SSL-Verschlüsselung zu ?

Korrekt - wobei der Zugriff bei Verschlüsselung immer das 's' benutzt, d.h. https://...:7001 für die File Station.

Wie sehe es den damit aus mit der Abhörsicherheit. Die Verschlüsselung wird ja vom Senderechner unternommen und beim Empfangsrechner wieder durch den jeweiligen SSL-Key entschlüsselt, richtig ?
Wäre ein Abhören oder Abfangen durch den Authority-Server des jeweiligen Zertifikatausstellers theoretisch möglich, oder nicht ?

Die Entschlüsselung erfolgt wieder mit dem öffentlichen Key, den das Serverzertifikat darstellt, richtig.
Und zum Abfangen und Abhören durch den Zertifikatsaussteller: hier sprichst Du ein wichtiges Detail an. Dieses ist dann möglich, wenn man die Schlüsselerstellung dem Zertifikatsaussteller überläßt - was hier und da von CA auch angeboten und durch User (weil's ja so bequem ist) auch genutzt wird.
Deshalb Achtung! Das Schlüsselpaar sollte man immer selbst auf seinem Rechner erzeugen - der dabei entstehende private key (meist server.key genannt) sollte dabei den eigenen Hoheitsbereich niemals verlassen! Um ein "offizielles" Zertifikat zu erhalten, also ein von einer anerkannten CA signiertes Zertifikat, schickt man der CA ausschließlich einen CSR (Certificate Signing Request) - dieses enthält neben einigen zusätzlichen Angaben im Wesentlichen das öffentliche Serverzertifikat (häufig server.crt genannt) als Gegenstück zum private key.
Auf diese Weise ist gewährleistet, dass so einfach eine Kommunikation nicht abgehört werden kann. Es gibt dann zwar aufwendige Szenarien, wie man eine SSL-Verschlüsselung angreifen kann, aber auch dafür gibt es entsprechende Gegenmaßnahmen.

 

[t-flash]

Die Entschlüsselung erfolgt wieder mit dem öffentlichen Key, den das Serverzertifikat darstellt, richtig.
Und zum Abfangen und Abhören durch den Zertifikatsaussteller: hier sprichst Du ein wichtiges Detail an. Dieses ist dann möglich, wenn man die Schlüsselerstellung dem Zertifikatsaussteller überläßt - was hier und da von CA auch angeboten und durch User (weil's ja so bequem ist) auch genutzt wird.
Deshalb Achtung! Das Schlüsselpaar sollte man immer selbst auf seinem Rechner erzeugen - der dabei entstehende private key (meist server.key genannt) sollte dabei den eigenen Hoheitsbereich niemals verlassen! Um ein "offizielles" Zertifikat zu erhalten, also ein von einer anerkannten CA signiertes Zertifikat, schickt man der CA ausschließlich einen CSR (Certificate Signing Request) - dieses enthält neben einigen zusätzlichen Angaben im Wesentlichen das öffentliche Serverzertifikat (häufig server.crt genannt) als Gegenstück zum private key.
Auf diese Weise ist gewährleistet, dass so einfach eine Kommunikation nicht abgehört werden kann. Es gibt dann zwar aufwendige Szenarien, wie man eine SSL-Verschlüsselung angreifen kann, aber auch dafür gibt es entsprechende Gegenmaßnahmen.

Hallo,
bei dem Trial-Zertifikat hatte ich einen CSR von der Synology erstellen lassen "zertifikat erstellen -> Zertifikatsregistrierungsanforderung (CSR) erstellen" anwählen und die Felder ausfüllen damit die Synology eine .zip Datei mit der Anforderung erstellt die hierbei die *.csr und die .key datei enthält. Hierbei hatte ich ja nur den Inhalb in die Anforderungsbox (CSR) der *.csr datei eingefügt und die server.key datei später auf der Synology im Feld "Privater Schlüssel" wieder eingefügt.
Ist dieser Vorgang so richtig ? Oder sollte ich beim verlängerten Zertifikat anders vorgehen um mit dieser Abhörungen und Abfangmöglichkeiten ausschließe ?
Vom Aussteller hatte ich übrigens eine Server-Zertifikat und einen Root- bzw. Zwischenzertifikat erhalten, beides in *.crt-Datei Formaten.
Zusammen mit dem server.key File ergab es dann das komplette Zertifikat, richtig ?


Vielen Dank schonmal.
Liebe Grüße,

 

[Frogman]

...Hierbei hatte ich ja nur den Inhalb in die Anforderungsbox (CSR) der *.csr datei eingefügt und die server.key datei später auf der Synology im Feld "Privater Schlüssel" wieder eingefügt.
Ist dieser Vorgang so richtig ?

Ja, das ist richtig so.

...Vom Aussteller hatte ich übrigens eine Server-Zertifikat und einen Root- bzw. Zwischenzertifikat erhalten, beides in *.crt-Datei Formaten. Zusammen mit dem server.key File ergab es dann das komplette Zertifikat, richtig ?

Das Zertifikat ist immer nur das *crt. Ein Intermediate ist Teil desjenigen Zertifikats, mit dem Dein Serverzertifikat signiert wurde und stellt die Verbindung her zu einem der CA-Rootzertifikate her, welches sich in Browsern usw. befindet. Die server.key ist der private Teil des Schlüssels als Gegenstück zum Serverzertifikat uns sollte, wie schon gesagt, Deinen Hoheitsbereich nie verlassen.

PS: Wenn Du auf Posts antwortest, brauchst Du nicht den ganzen Post zitieren, gerade wenn er direkt darüber steht. Wenn Du zitierst, dann Ausschnitte, auf die Du direkt antwortet Das verbessert die Lesbarkeit...

 

[Peter_Lehmann]

Hallo T-Flash!

Schön, dass du dich für dieses Thema interessierst.
Frogman hat dir das ja alles gut und richtig erklärt. Aber eine Frage wurde nicht angesprochen: Was bezweckst du eigentlich?

Ich nenne nur mal drei Möglichkeiten:
1.) Du betreibst deine DS nur innerhalb deines Homenetzes. Es gibt keine Portweiterleitungen über den Router aus dem "bösen Netz" hinein in dein Homenet. => Dann kannst du dir die Verschlüsselung der Verbindung sparen. Wenn der Feind sich bei dir schon eingenistet hat, ist eh alles zu spät. Ansonsten bist du ja in einer vertrauenswürdigen Umgebung.
2.) Du stellst bestimmte, aus dem Internet erreichbare Dienste nur für dich oder eine Handvoll gute Freunde bereit.
3.) Du bist eine Firma oder du stellst die Dienste für "Jedermann" erreichbar, bereit.

Hier muss erst einmal bei dir Klarheit herrschen.
zu 1.) Hier kannst du die Verbindung verschlüsseln, musst aber nicht.
zu 2.) (= meine eigene Variante *) Bei nur eigener Nutzung bzw. der Nutzung durch Bekannte, Familie und Freunde erachte ich es als völlig ausreichend, selbst eine kleine CA aufzusetzen und Zertifikate zu produzieren. Das ist mit einem kleinen Programm wie "XCA" wirklich problemlos und auch ohne große Fachkenntnisse möglich - und genau so sicher, wie bei den Zertifikaten von einem öffentlichen TrustCenter. Auf jedenfall ist es sicherer, als auch den private key produzieren zu lassen. Und deiner Handvoll Nutzer übergibst du per Mail das Herausgeberzertifikat deiner Privat-CA, und eine kleine Anleitung, wie sie dieses in ihren Browser (beim Fx) oder in den Zertifikatsstore des Betriebssystems (der WinDOSe oder dem Mac) importieren können. Das kann mit der Anleitung jeder ONU in zwei Minuten. Und dieser bewusste Import des Herausgeberzertifikates ist allemal "wertiger" als diese vermaledeiten Ausnahmeregeln. Da es sich bei dem Herausgeberzertifikat um einen öffentlichen Schlüssel handelt, kannst du diesen sogar auf deiner etl. vorhandenen Webseite bereitstellen. ((*) Um es genau zu sagen, bei mir gibt es überhaupt keinen Durchgriff aus dem INet in mein Homenet. Ich mache alles per VPN)
zu 3.) Selbstverständlich würde das auch bei einem Kleinbetrieb funktionieren. Aber da betrachte ich das eher als unseriös. (Keinesfalls hinsichtlich der Sicherheit! Aber es wirkt irgendwie "billig".) Hier würde ich unbedingt auf das kostenpflichtige Angebot eines seriösen Trustcenters eingehen. Auch die kostenlosen Lockangebote bestimmter Trustcenter betrachte ich als "billig". Niemand hat etwas zu verschenken! Und Kostnix ist nicht unbedingt gut.


MfG Peter

 

[t-flash]

Hallo ihr lieben,
vielen Dank für eure Antworten.

@ frogman: sorry zwecks der Lesbarkeit .. Wird beim nächsten Mal mehr in die Mitte rücken dieses Kriterium ..

@ Peter: Also um mal deine Fragen und Punkte konkret zu beantworten, ich betreibe einen Netzwerkserver (NAS) in meinem Heimnetzwerk von Synology und habe diesen auch schon über nen Jahr im Betrieb auch mit der Verbindung nach außen indem ich die jeweiligen Ports geöffnet habe. Genutzt wird dieser als Zentraler Speicher für alle Daten von den unterschiedlichsten Rechnern innerhalb des Heimnetzwerkes und zusätzlich als Speicher für all die Dokumente, Videos, Bilder und wichtigeren Dokumente. Aus dem Netz sind all diese Daten per Usernamen und streng verstärkten Passwörtern zugänglich. Ich habe keinerlei Benutzer im System die ein schwaches Password benutzen, jeder hat ohne Ausnahme ein hoch-kompliziertes Passwort zu verwenden, ob man dieses sich merken kann oder nicht ist für mich zweitrangig, ich weiss wie schnell so ein Passwort mittels Hackangriffen geknackt werden können und was sichere Passwörter letzendlich enthalten müssen. Jedes Password beinhaltet somit Sonderzeichen, Groß- und Kleinschreibung und Zahlenkombinationen immer in Abwechselnder Richtung also keine Buchstaben oder Zeichen öfters hintereinander. Jeder Buchstabe, jede Zahl wird dahinter mit dem entsprechhenden Gegensatz gesichert, z.B folgt nach einem Buchstaben entweder ein anderer Buchstabe nur halt dann groß oder kleingeschrieben oder jeweils eine Zahl oder sonderzeichen.. Abwechslung ist also drinne.
Was am Ende rauskommt ist ein sicheres Password wo kein Buchstabe an das nächste anknüpft und somit echt sehr stark wirkt am Ende.

Jedoch bekomme ich aus Japan, China, Niederlande, USA und anderen Ländern vereinzelnt Angriffe, durch den Einsatz von Portscannern werden meine offenen Ports gefunden. Inzwischen habe ich den standart-Port von SSH, Telnet und einigen anderen Diensten umgestellt auf eines das nicht Standartisiert ist. Und die Angriffe sind weniger geworden im Schnitt bekomme ich nur noch 1-2 Angriffe in 1-2 Monaten Abständen. Also nicht viel aber dennoch finde ich die Sicherheit ein Wichtiges Kriterium.
Um dies zu erhöhen habe ich mir vorgenommen eine SSL-Verbindung nun einzuführen und alle unverschlüsselten Ports nach außen aus meiner Fritzbox wieder zu entfernen so das diese unverschlüsselten Ports nur innerhalb des Netzwerkes zugänglich sind und von außerhalb alles nur noch per SSL abläuft.
Klar kann ich jetzt mir ein kostenloses Zertifikat einfügen und diesen benutzen. Aber all diese Daten auf dem Server werden mit Freunden, Familie und einigen besonderes Personen die weder von Familie noch von Freunde sind, also Public eher gesagt dazu. Um hier verbesserte Sicherheit zu bieten, fühle ich mich besser, wenn ich SSL benutze und den Kram mit unverschlüsselt langsam mal abschalte.
Ich lege ziemlich großen Wert auf Sicherheit und deswegen auch die Stärke und Länge meiner Passwörter, ich benutze zum Beispiel kein Passwort das Schwach ist.

Da aber im Freundes- und Familienkreis auch laien sind und einige von denen keinen blassen Schimmer haben wie sie sowas importieren oder einfügen sollen, könnte ich um es übertrieben auszudrücken eine Weltgeschichte erzählen und selbst dann ist nicht sicher ob die sowas kapieren ..
Um es ernster aufzufassen: Ich habe keine Interesse jedem einzelnen von denen persönlich zu assestieren weil ich jetzt schon weiss, selbst wenn ich eine Anleitung schreiben sollte es die wenigsten verstehen werden (<- Eigene Erfahrung).. Und daher finde ich ich steige auf einen richtigen Zertifikataussteller um. Ich finde solche Zertifikate solange es keine Wildcard-Zertifikate sind auch nicht wirklich sonderlich teuer.

Somit wäre nun bei mir eine Frage offen:
Ich würde gerne ein Zertifikat von Comodo, RapidSSL oder Thawte benutzen, da bei diesen Anbieter der Preis und ich hoffe auch die Leistung im Rahmen sind und nicht wie bei z.B Symantec die Preise für solche Zertifikate bis zu 400 € und mehr sind. Das ist deutlich außerhalb meines verfügbaren Budgets ..

Hätte eventuell jemand von euch Erfahrungen, Meinungen oder Bewertungen parrat zweck dieser 3 Anbieter ? oder Produkten von diesen ?
Ich habe mal versuch im Internet was zu finden. Aber da sind die Meinungen ziemlich gespalten. Manche sagen Comodo (positiveSSL) manch anderer wiederum Thawte.
Welches würdet ihr nun euch kaufen wollen, von welchem Anbieter ?


Vielen Dank,
LG, T-Flash.

 

[Frogman]

...
Jedoch bekomme ich aus Japan, China, Niederlande, USA und anderen Ländern vereinzelnt Angriffe, durch den Einsatz von Portscannern werden meine offenen Ports gefunden. Inzwischen habe ich den standart-Port von SSH, Telnet und einigen anderen Diensten umgestellt auf eines das nicht Standartisiert ist. Und die Angriffe sind weniger geworden im Schnitt bekomme ich nur noch 1-2 Angriffe in 1-2 Monaten Abständen. Also nicht viel aber dennoch finde ich die Sicherheit ein Wichtiges Kriterium.

Hier geht's schon - wenn Du die DS als Datenspeicher nutzt (und das auch von extern), benötigst Du keine Portweiterleitung für Telnet und SSH, schon gar nicht auf Strandardports! Grundregel: einen Port NUR dann öffnen, wenn man ihn WIRKLICH benötigt.

...
Um dies zu erhöhen habe ich mir vorgenommen eine SSL-Verbindung nun einzuführen und alle unverschlüsselten Ports nach außen aus meiner Fritzbox wieder zu entfernen so das diese unverschlüsselten Ports nur innerhalb des Netzwerkes zugänglich sind und von außerhalb alles nur noch per SSL abläuft.

...hui - was bedeutet, Du hast bisher telnet und SSH unverschlüsselt von extern genutzt. Was immer Du nun zukünftig noch anstellst - Deine eingangs beschriebenen starken Passwörter sind damit alles andere als stark, weil praktisch nichts wert und Du solltest sie alsbald erneuern, da Du annehmen musst, dass sie durch die bisher fehlende Verschlüsselung bekannt sind.

 

[t-flash]

...hui - was bedeutet, Du hast bisher telnet und SSH unverschlüsselt von extern genutzt. Was immer Du nun zukünftig noch anstellst - Deine eingangs beschriebenen starken Passwörter sind damit alles andere als stark, weil praktisch nichts wert und Du solltest sie alsbald erneuern, da Du annehmen musst, dass sie durch die bisher fehlende Verschlüsselung bekannt sind.

Das ist richtig, anscheind war es bislang falsch .. Ich werde mich sowieso dieses Wochenende ransetzen und alle Administrativen und Systempasswörter unverzüglich ändern.
Ich hätte da aber noch die Frage welchen Aussteller ich wählen sollte ? Thawte oder lieber Comodo ?
Weil mir ist auch die Browser-Abdeckung wichtig. Hier habe ich einige Optionen von SSL-Zertifikaten wo ich meines auch gerne bestellen würde. von PSW hört man ja auch positives, stößt also eigentlich nichts dagegen.
Nun sehe ich dort aber die SHA 1 Abdeckung, (ich weiss SHA-1 ist sowieso veraltet) aber es gibt ja einige die laufen noch mit alten Betriebssystemen und Browsern eben rum, und daher dachte ich mir ich sollte auch darauf bezogen rücksicht nehmen eventuell damit auch bei denen das Zertifikat erkannt wird.
Da macht thawte mir einen ganz guten Eindruck von der Abdeckung her. Von SHA-2 ist sowieso alles bestens von welchem Aussteller man auch immer seinen Zertifikat ausstellen lässt.


Und desweiteren wäre eine weitere Frage offen dem Support von Thawte welches auf Englisch ist konnte ich das nicht so ganz beibringen worauf ich hinaus will. Eventuell hat einer von euch hier Erfahrung damit.
Ich habe ja mein Netzwerkservr hier daheim per Dyndns-Adresse im Netz angeschlossen. Angenommen meine dyndns Adresse lautet meinserver.meinedomain.com und ich würde gerne das Zertifikat für die Domain meinserver.meinedomain.com ausstellen lassen, würde dies (wie ich denke) als Wildcard-Zertifikat gelten obwohl es eher eine Dyndns-Adresse statt eine echte Sub-Domain ist oder doch eher als ein Single Domain Zertifikat ?
Ich denke mal die Anforderungen bei Single Domain Zertifikaten muss so sein, dass keine sub-domain Angaben vor der Domain sein dürfen und er die Addition von "meinserver" als sub-domain anerkennt , richtig ? :S...

Was wäre, wenn ich ein Zertifikat nun für meinserver.meinedomain.com bestelle aber nicht als wildcard sondern als single-domain zertifikat ? würde man dieses ablehnen weil es nicht eine single-domain darstellt sondern eher eine Sub-Domain oder würde man darauf kaum achten weil eine Domain-Verifizierung ja per E-Mail Robot stattfindet ?


Desweitere wird die E-Mail ja an z.b admin@meinserver.meinedomain.com versendet statt die E-Mail vom dyndns-Ausgeber zu verwenden die ja in den Whois-Abfragen hinterlegt sind, wodurch ich aber nicht erreichbar wäre und die Verifizierungsemail nie ankommen würde. Oder kann man auch die E-Mail z.b admin oder administrator@meinserver.meinedomain.com nutzen ?


Vielen Dank schonmal im voraus.

Liebe Grüße,

 

[Frogman]

...Ich habe ja mein Netzwerkservr hier daheim per Dyndns-Adresse im Netz angeschlossen. Angenommen meine dyndns Adresse lautet meinserver.meinedomain.com und ich würde gerne das Zertifikat für die Domain meinserver.meinedomain.com ausstellen lassen, würde dies (wie ich denke) als Wildcard-Zertifikat gelten obwohl es eher eine Dyndns-Adresse statt eine echte Sub-Domain ist oder doch eher als ein Single Domain Zertifikat ? Ich denke mal die Anforderungen bei Single Domain Zertifikaten muss so sein, dass keine sub-domain Angaben vor der Domain sein dürfen und er die Addition von "meinserver" als sub-domain anerkennt , richtig ? :S...

Es hängt von den Anbietern ab, welche Varianten an Zertifikaten angeboten werden, da musst Du einfach auf die Webseiten dort schauen. Aber vorweg: für eine DynDNS-Domain kannst Du kein Zertifikat bekommen. Du musst dafür immer eine Domain besitzen, für die Du dann entweder auf die Domain selbst oder Subdomains die Zertifikate bekommst. Oftmals wird bei einem Zertifikat für eine Subdomain die eigentliche Hauptdomain eingeschlossen (wie es bspw. das kostenlose StartSSL auch macht). Darüber gibt es dann - wenn Du mehrere Subdomains verwenden willst - auch Multi-Domain-Zertifikate bis hin zu Wildcard-Zertifikate, bei denen Du beliebig viele Subdomains mit dem gleichen Zertifikat benutzen kannst (und dann entsprechend teuer sind).

 

[Peter_Lehmann]

Frogman hat ja alle Fragen schon korrekt beantwortet.
Ich werde dir aus bestimmten Gründen auch keine Empfehlung für einen bestimmten Zertifikatsdiensteanbieter geben. Ich will dir nur so viel sagen, dass ein seriöser Anbieter alles zumutbare unternimmt, um sicherzustellen, dass nur der ein Zertifikat für einen bestimmten Server bekommt, der nachweisen kann, dass er/seine Firma eben jenen Server betreibt. So ist es in Deutschland (bei eben den seriösen Anbietern) üblich, dass du dem TrustCenter einen notariell beglaubigten Handelsregisterauszug mit den entsprechenden Angaben vorlegen musst, aus dem eben das hervorgeht. Genau so, wie bei einem Personenzertifikat gemäß SigG §5 eine "sichere Personenidentifizierung anhand eines amtlichen Lichtbildausweises" zu erfolgen hat. Und genau dieser Aufwand ist neben den extrem hohen Anforderungen hinsichtlich technischer, baulicher und personeller Sicherheit an ein TrustCenter auch der Grund für den oftmals für den Laien unverständlich hohen Preis für diese Leistung. Du kannst mir glauben, dieser Preis ist gerechtfertigt!
Andersrum sollte es zu bedenken geben, wenn ein Anbieter eben jene Leistung verschenkt. Manchmal kommen auch Erkenntnisse hoch, wenn du gründlich im Netz recherchierst, wessen Firmenausgründung das eine oder andere TrustCenter ist. Bei manchem würde ich es mir gründlich überlegen ... .

Ich komme noch einmal auf meine dreistufige Auswahl zurück. (Danke für deine ausführliche Antwort!)
Für mich passen auf deine Nutzung die Kriterien meiner Stufe 2! Ich lese heraus, dass es alles eingetragene Nutzer deiner DS sind. Sie haben also alle einen Benutzernamen und ein Passwort auf deiner DS, damit alles "Bekannte"!
Deshalb wirklich meine Empfehlung, dir selbst eine kleine CA aufzusetzen (ich kann dich dabei gern nterstützen) und deinen Nutzern eine kleine Anleitung zur Hand zu geben. Auch dabei kann ich dir helfen.
Passieren kann dabei ja überhaupt nichts. Du musst ja nicht apruppt auf https umschalten. Denke mal, auch bei der DS kann man erst einmal zweigleisig (http und https) fahren. (Ich habe das aber nie getestet, man möge mich korrigieren, wenn es nicht so ist!)
Die Nutzer darauf vorbereiten, gute Anleitung mit Screenshots - und bei denen, die es wirklich nicht packen, kannst du ja per Teamviewer helfend eingreifen.


MfG Peter

 

[Frogman]

...Denke mal, auch bei der DS kann man erst einmal zweigleisig (http und https) fahren. (Ich habe das aber nie getestet, man möge mich korrigieren, wenn es nicht so ist!)
...

Das ist problemlos möglich.