Grundlegende Fragen zu https SSL/TLS

[Karl Heinz]

Hallo,

zu meiner Schande muss ich gestehen, dass ich mich bisher noch nie richtig mit https bzw. SSL/TLS beschäftigt habe. Ich habe mich nun etwas eingelesen, leider trotzdem ein paar Dinge noch nicht so ganz verstanden. Ich möchte meine Fragen anhand eines Beispiels aufzeigen.

1. Nehmen wir an ich nutze eine Webseite die https verwendet und trage dort etwas ins Kontaktformular ein. Anschließend schicke ich das Kontaktformular weg. Dazu müssen die Daten zunächst verschlüsselt werden. Für das Verschlüsseln erhalte ich den öffentlichen Schlüssel von der Zertifizierungsstelle wie z.B. Lets encrypt. Damit die Zertifizierungsstelle weiß welchen öffentlichen Schlüssel ich benötige muss ich der Zertifizierungsstelle zunächst das Zertifikat übersenden, das ich im Vorfeld vom Betreiber der https Webseite erhalten habe. Mit diesem öffentlichen Schlüssel werden nun die Daten aus dem Kontaktformular verschlüsselt und an den Betreiber der https Seite gesendet. Der Betreiber der https Seite muss die Daten nun entschlüsseln, dazu verwendet er seinen privaten Schlüssel, diesen privaten Schlüssel hat er von der Zertifizierungsstelle erhalten, als er das Zertifikat dort beantragt hat. Habe ich das so richtig verstanden?

2. Nehmen wir an der Webseitenbetreiber möchte Informationen an einen Nutzer der Webseite schicken. Bevor er diese Informationen verschickt müssen diese Informationen zunächst verschlüsselt werden. Wie bei Frage 1 wird für das Verschlüsseln der öffentliche Schlüssel der Zertifizierungsstelle verwendet. Nun hat aber der Nutzer der Webseite keinen privaten Schlüssel, dieser liegt doch nur dem Webseitenbetreiber vor, deshalb die Frage wie der Nutzer der Webseite die Daten ohne privaten Schlüssel entschlüsseln kann?

Viele Grüße

[Felix Riesterer]

Lieber Karl,

ich weiß nicht, ob ich den tatsächlichen Grund Deiner Frage(n) verstanden habe, aber zumindest kann ich Dir einen Praxistipp geben:

Die Kommunikation zwischen Browser und Webserver interessiert Dich als Entwickler nicht. Der HTTP-Traffic wird in eine SSL-Hülle verpackt, so dass eine serverseitige Geschäftslogik (CMS, Dein Programm in Perl/PHP/Ruby/etc.) sich nicht darum kümmern muss. Auf Browserseite kannst Du innerhalb von JavaScript weitere Ressourcen über HTTPS anfordern, unter Umständen sogar über HTTP ohne SSL-Hülle.

Möchtest Du serverseitig aus einer Geschäftslogik heraus eine verschlüsselte Verbindung zu einem anderen Server aufbauen, um Daten über diese HTTPS-Leitung zu versenden und/oder empfangen, dann ist das etwas anderes, wofür es auch Lösungen gibt. Einen solchen Anwendungsfall lese ich in Deinen Fragen aber nicht heraus...

Liebe Grüße,

Felix Riesterer.

[dedlfix]

Tach!

1. Nehmen wir an ich nutze eine Webseite die https verwendet und trage dort etwas ins Kontaktformular ein. Anschließend schicke ich das Kontaktformular weg. Dazu müssen die Daten zunächst verschlüsselt werden. Für das Verschlüsseln erhalte ich den öffentlichen Schlüssel von der Zertifizierungsstelle wie z.B. Lets encrypt.

Nein, dein Browser hat keinen Bedarf, mit der Zertifizierungsstelle zu kommunizieren. Der öffentliche Schlüssel wird dem Browser vom Webserver übermittelt als Teil des Verbindungsaufbaus.

Das Zertifikat für die Domain enthält weitere Zertifikate, die bis auf ein Root-Zertifikat zurückgehen, das auch dem Browser bekannt ist. Der hat eine Liste von solchen Root-Zertifikaten an Bord. Wenn der Browser das Domainzertifikat erfolgreich gegen eines seiner Rootzertifikate prüfen konnte, sieht er das Domainzertifikat als gültig an (zuzüglich weiteren Kriterien, wie Ablaufzeit).

Mit diesem öffentlichen Schlüssel werden nun die Daten aus dem Kontaktformular verschlüsselt und an den Betreiber der https Seite gesendet. Der Betreiber der https Seite muss die Daten nun entschlüsseln, dazu verwendet er seinen privaten Schlüssel, diesen privaten Schlüssel hat er von der Zertifizierungsstelle erhalten, als er das Zertifikat dort beantragt hat. Habe ich das so richtig verstanden?

Nein, den privaten Schlüssel hat er Administrator vom Webserver erstellt. Den gibt er auch nicht an irgendwen heraus. Außerdem hat er eine Zertifikatsignierungsanforderung (CSR) erstellt, und nur die geht an die Zertifizierungsstelle. Daraus erzeugt selbige dann das Zertifikat.

2. Nehmen wir an der Webseitenbetreiber möchte Informationen an einen Nutzer der Webseite schicken. Bevor er diese Informationen verschickt müssen diese Informationen zunächst verschlüsselt werden. Wie bei Frage 1 wird für das Verschlüsseln der öffentliche Schlüssel der Zertifizierungsstelle verwendet.

Nö, wird nicht.

Nun hat aber der Nutzer der Webseite keinen privaten Schlüssel, dieser liegt doch nur dem Webseitenbetreiber vor, deshalb die Frage wie der Nutzer der Webseite die Daten ohne privaten Schlüssel entschlüsseln kann?

Eben deswegen wird das nicht mit dem öffentlichen des Webservers verschlüsselt, sondern mit einem öffentlichen Schlüssel, den der Browser zu einem privaten erstellt hat, und der beim Verbindungsaufbau zum Server geht (der öffentliche). Und mit dem privaten kann der Browser das entschlüsseln.

dedlfix.

[Karl Heinz]

@@dedlfix,

Nun hat aber der Nutzer der Webseite keinen privaten Schlüssel, dieser liegt doch nur dem Webseitenbetreiber vor, deshalb die Frage wie der Nutzer der Webseite die Daten ohne privaten Schlüssel entschlüsseln kann?

Eben deswegen wird das nicht mit dem öffentlichen des Webservers verschlüsselt,

OK, verstanden.

sondern mit einem öffentlichen Schlüssel, den der Browser zu einem privaten erstellt hat, und der beim Verbindungsaufbau zum Server geht (der öffentliche). Und mit dem privaten kann der Browser das entschlüsseln.

Das verstehe ich leider nicht, kannst es anders erklären, vielleicht anhand eines kleinen Beispiels?

[dedlfix]

Tach!

sondern mit einem öffentlichen Schlüssel, den der Browser zu einem privaten erstellt hat, und der beim Verbindungsaufbau zum Server geht (der öffentliche). Und mit dem privaten kann der Browser das entschlüsseln.

Das verstehe ich leider nicht, kannst es anders erklären, vielleicht anhand eines kleinen Beispiels?

Verschlüsselt wird mit einem öffentlichen Schlüssel, der zu einem privaten Schlüssel passt. Und das auf beiden Seiten in jeweils der anderen Richtung. Beide Teilnehmer brauchen also je solch ein Schlüsselpaar, von dem sie den öffentlichen an die Gegenstelle übermitteln. Der Sender verschlüsselt immer mit dem öffentlichen Schlüssel der Gegenseite.

dedlfix.

[Karl Heinz]

@@dedlfix,

Beide Teilnehmer brauchen also je solch ein Schlüsselpaar, von dem sie den öffentlichen an die Gegenstelle übermitteln.

Erfolgt dieser Schlüsselaustausch nur einmal am Anfang oder mehrfach?

[dedlfix]

Tach!

Beide Teilnehmer brauchen also je solch ein Schlüsselpaar, von dem sie den öffentlichen an die Gegenstelle übermitteln.

Erfolgt dieser Schlüsselaustausch nur einmal am Anfang oder mehrfach?

Am Anfang (je)der Verbindung. Da die Kommunikation zwischen Browsern und Servern in mehreren Verbindungen ablaufen kann, dann findest das also auch auch mehrfach statt, jeweils am Anfang jeder Verbindung.

dedlfix.

[Karl Heinz]

@@dedlfix,

Nein, dein Browser hat keinen Bedarf, mit der Zertifizierungsstelle zu kommunizieren. Der öffentliche Schlüssel wird dem Browser vom Webserver übermittelt als Teil des Verbindungsaufbaus.

Man muss bezogen auf eine sichere Verbindung zwei Varianten unterscheiden:

Variante 1:

Verschlüsselte Verbindung (grünes Schloss OHNE Angabe des Inhabers)

z.B. bei der selfhtml Seite:

Variante 2:

Verschlüsselte Verbindung (grünes Schloss MIT Angabe des Inhabers)

z.B. bei der Seite der Deutschen Bank:

Zu diesem Sachverhalt einige Fragen:

1. Aus welchem Grund wird nicht überall zusätzlich zum grünen Schloss auch noch der Name des Inhabers angegeben?

2. Warum nutzt Ihr beim selfhtml Forum nur das grüne Schloss und nicht zusätzlich "selfhtml" rechts neben dem Schloss?

3. Die beiden Schlüsselpaare (private key und public key) von Client und Server werden ja vom Client bzw. Server selbst erzeugt. Demnach brauche ich doch für eine verschlüsselte Verbindung eigentlich keine dritte Partei wie z.B. Lets Encrypt die mir ein Zertifikat erstellt. Für reine Verschlüssung könnte man dann doch eigentlich auf eine Zertifikat und damit auch auf die Nutzung von Lets Encrypt verzichten. Drittparteien wie z.b. Lets Encrypt benötigt man nur dann, wenn man zusätzlich zum grünen Schloss auch noch den Namen des Inhabers in der Adressleiste des Browser haben möchte. Ist das so korrekt?

[Auge]

Hallo

Man muss bezogen auf eine sichere Verbindung zwei Varianten unterscheiden:

Variante 1: Verschlüsselte Verbindung (grünes Schloss OHNE Angabe des Inhabers)

Variante 2: Verschlüsselte Verbindung (grünes Schloss MIT Angabe des Inhabers)

Zu diesem Sachverhalt einige Fragen:

1. Aus welchem Grund wird nicht überall zusätzlich zum grünen Schloss auch noch der Name des Inhabers angegeben?

Weil das eine nicht unerhebliche Menge Geld kostet.

2. Warum nutzt Ihr beim selfhtml Forum nur das grüne Schloss und nicht zusätzlich "selfhtml" rechts neben dem Schloss?

Weil das eine nicht unerhebliche Menge Geld kostet.

Bei der Ausstellung von Zertifikaten mit Verifikation z.B. einer Organisation werden Prüfungen von Einträgen in Handelsregistern und/oder Anrufe zur Verifikation des Antragstellers vorgenommen. Nur, wenn diese Prüfungen erfolgreich sind, gibt es ein Zertifikat, für das der Browser den grünen Balken erzeugt. Diesen Aufwand lassen sich die Zertifizierungsstellen (mMn fürstlich) bezahlen.

3. Die beiden Schlüsselpaare (private key und public key) von Client und Server werden ja vom Client bzw. Server selbst erzeugt. Demnach brauche ich doch für eine verschlüsselte Verbindung eigentlich keine dritte Partei wie z.B. Lets Encrypt die mir ein Zertifikat erstellt. Für reine Verschlüssung könnte man dann doch eigentlich auf eine Zertifikat und damit auch auf die Nutzung von Lets Encrypt verzichten. Drittparteien wie z.b. Lets Encrypt benötigt man nur dann, wenn man zusätzlich zum grünen Schloss auch noch den Namen des Inhabers in der Adressleiste des Browser haben möchte. Ist das so korrekt?

Nein.

Tschö, Auge

[Karl Heinz]

@@Auge,

Die beiden Schlüsselpaare (private key und public key) von Client und Server werden ja vom Client bzw. Server selbst erzeugt. Demnach brauche ich doch für eine verschlüsselte Verbindung eigentlich keine dritte Partei wie z.B. Lets Encrypt die mir ein Zertifikat erstellt. Für reine Verschlüssung könnte man dann doch eigentlich auf eine Zertifikat und damit auch auf die Nutzung von Lets Encrypt verzichten. Drittparteien wie z.b. Lets Encrypt benötigt man nur dann, wenn man zusätzlich zum grünen Schloss auch noch den Namen des Inhabers in der Adressleiste des Browser haben möchte. Ist das so korrekt?

Nein.

Warum benötige ich für die reine Verschlüsslung eine Drittpartei?

[Auge]

Hallo

Die beiden Schlüsselpaare (private key und public key) von Client und Server werden ja vom Client bzw. Server selbst erzeugt. Demnach brauche ich doch für eine verschlüsselte Verbindung eigentlich keine dritte Partei wie z.B. Lets Encrypt die mir ein Zertifikat erstellt. Für reine Verschlüssung könnte man dann doch eigentlich auf eine Zertifikat und damit auch auf die Nutzung von Lets Encrypt verzichten. Drittparteien wie z.b. Lets Encrypt benötigt man nur dann, wenn man zusätzlich zum grünen Schloss auch noch den Namen des Inhabers in der Adressleiste des Browser haben möchte. Ist das so korrekt?

Nein.

Warum benötige ich für die reine Verschlüsslung eine Drittpartei?

Mein „Nein“ bezog sich auf die letzten paar Sätze.

Drittparteien wie z.b. Lets Encrypt benötigt man nur dann, wenn man zusätzlich zum grünen Schloss auch noch den Namen des Inhabers in der Adressleiste des Browser haben möchte. Ist das so korrekt?

Aber bitte, auf der erste Teil trifft nicht zu.

Die beiden Schlüsselpaare (private key und public key) von Client und Server werden ja vom Client bzw. Server selbst erzeugt. Demnach brauche ich doch für eine verschlüsselte Verbindung eigentlich keine dritte Partei wie z.B. Lets Encrypt die mir ein Zertifikat erstellt.

Der Betreiber des Webservers erstellt die Schlüssel, damit hat er aber noch kein Zertifikat. Ohne letzteres vertrauen die Browser der verschlüsselten Verbindung nicht, da sie dann von einem Angriff ausgehen. Aktuell kann man in einigen Verdachtsfällen die Vorgabe des browsers überstimmen und einem für den Browser nicht vertrauenswürdigen Zertifikat vertrauen, aber ich würde mich nicht darauf verlassen wollen, dass es dabei bleibt.

Tschö, Auge

[Karl Heinz]

@@Auge,

Der Betreiber des Webservers erstellt die Schlüssel, damit hat er aber noch kein Zertifikat. Ohne letzteres vertrauen die Browser der verschlüsselten Verbindung nicht, da sie dann von einem Angriff ausgehen.

OK, das heißt ich brauche IMMER ein Zertifikat von einem Drittanbieter wenn ich verschlüsselt übertragen möchte. Wenn mir IMMER ein Zertifikat von einem Drittanbieter vorliegt liegt doch auch IMMER eine Verifizierung des Inhabers der URL vor, damit könnte doch eigentlch auch IMMER der Name des Inhaber zusätzlich zum grünen Schloss angegeben werden, es liegt ja IMMER eine Verifzierung vor. Warum ist das in der Praxis nicht so, warum wird z.B. bei selfhtml nicht "selfhml" als Inhaber in der Adresszeile vom Browser angeben, obwohl eine Verifzierung von selfhtml erfolgt ist?

Aktuell kann man in einigen Verdachtsfällen die Vorgabe des browsers überstimmen und einem für den Browser nicht vertrauenswürdigen Zertifikat vertrauen, aber ich würde mich nicht darauf verlassen wollen, dass es dabei bleibt.

Wie würde man denn ein Zertifikat erstellen das als nicht vertrauenswürdig eingestuft wird?

[Auge]

Hallo

@@Auge,

Der Betreiber des Webservers erstellt die Schlüssel, damit hat er aber noch kein Zertifikat. Ohne letzteres vertrauen die Browser der verschlüsselten Verbindung nicht, da sie dann von einem Angriff ausgehen.

OK, das heißt ich brauche IMMER ein Zertifikat von einem Drittanbieter wenn ich verschlüsselt übertragen möchte.

Nein, du könntest auch ein selbst erstelltes Zertifikat benutzen, das willst du aber aus praktischen Erwägungen nicht. Die Browser machen es dem Nutzer nämlich ungemein schwer, Zertifikaten, die sie selbst nicht als sicher ansehen, zu vertrauen. Fernab von der Verwendung für verschlüsselte Verbindungen im Browser gibt es aber andere Anwendungszwecke für eigene Zertifikate, bei denen es keine Rolle spielt, ob sie von einer Stelle ausgestellt oder beglaubigt wurden, denen Browserhersteller trauen. Also ja, für einige Zwecke sind selbst erstellte Zertifikate benutzbar.

Wenn mir IMMER ein Zertifikat von einem Drittanbieter vorliegt liegt doch auch IMMER eine Verifizierung des Inhabers der URL vor, damit könnte doch eigentlch auch IMMER der Name des Inhaber zusätzlich zum grünen Schloss angegeben werden, es liegt ja IMMER eine Verifzierung vor. Warum ist das in der Praxis nicht so, warum wird z.B. bei selfhtml nicht "selfhml" als Inhaber in der Adresszeile vom Browser angeben, obwohl eine Verifzierung von selfhtml erfolgt ist?

Wie schon gesagt, werden für den grünen Balken neben der Prüfung der Identität des Antragstellers zusätzliche Prüfungen durchgeführt. Die muss man zusätzlich bezahlen. Wenn man das nicht will, hat man ein Zertifikat, das eine verschlüsselte Verbindung des Browsers mit einem Webserver ermöglicht, aber keine zusätzliche Bestätigung, dass man man selbst ist. Für weitere Details befrage bitte eine Zertifizierungsstelle. Die sollten wissen, was sie warum machen.

Aktuell kann man in einigen Verdachtsfällen die Vorgabe des browsers überstimmen und einem für den Browser nicht vertrauenswürdigen Zertifikat vertrauen, aber ich würde mich nicht darauf verlassen wollen, dass es dabei bleibt.

Wie würde man denn ein Zertifikat erstellen das als nicht vertrauenswürdig eingestuft wird?

Man kann Zertifikate wie gesagt auch selbst erstellen. Man hat dann aber keine Zertifikatskette, die zu Zertifierungsstellen führt, denen die Browser vertrauen. Das Zertifikat kann man für andere Zwecke als der Verschlüsselung einer Verbindung im Browser genre verwenden, im Browser fehlt aber die Vertrauensstellung, Also wird es dort (mindestens einmal) angemeckert.

Zudem muss man sich bei einem eigenen Zertifikat um dessen Aktualisierung kümmern, schließlich hat es ein Ablaufdatum. Mir selbst sind schon ein paar Seiten mit abgelaufenen Zertifikaten untergekommen (üblicherweise kümmert sich der Hoster darum ond doch passiert sowas!). Auch das wird von den Browsern bemängelt und üblicherweise kann man ein abgelaufenes Zertifikat nicht akzeptieren und die Seite bleibt bis auf die Fehlermeldung leer.

Tschö, Auge

[Felix Riesterer]

Lieber Karl,

OK, das heißt ich brauche IMMER ein Zertifikat von einem Drittanbieter wenn ich verschlüsselt übertragen möchte.

ja. Wie schon gesagt deshalb, damit der Browser die Schlüssel der Gegenseite als vertrauenswürdig einstuft und nicht meckert.

Wenn mir IMMER ein Zertifikat von einem Drittanbieter vorliegt liegt doch auch IMMER eine Verifizierung des Inhabers der URL vor,

Nein! Es liegt nur vor, dass das erstellte Zertifikat auch tatsächlich nur mit dieser URL genutzt wird. Wer der Inhaber ist, wird nicht überprüft, sondern nur, dass der Inhaber, der das Zertifikat angefordert hat, auch tatsächlich diese Domain inne hat, also der Inhaber ist.

damit könnte doch eigentlch auch IMMER der Name des Inhaber zusätzlich zum grünen Schloss angegeben werden,

Der Name des Inhabers ist bei der Anforderung des Zertifikats unbekannt. Es ist ein rein technisches Prüfverfahren, bei dem es um Zugriffsberechtigungen geht. Ich erinnere mich noch, als ich für Google Maps einen speziellen String in ein meta-Element aufnehmen musste, damit die API auch brav die Karte lud. Das war auch eine solche Prüfung, ob ich, der ich den Google-Maps-API-Schlüssel anfordere, auch der bin, der die Website kontrolliert. Mit den SSL-Zertifikaten ist es im Grunde genau so.

es liegt ja IMMER eine Verifzierung vor.

Aber was genau wird denn verifiziert...?!

So, und jetzt denken wir über Subdomains nach. Stellen wir uns doch folgende Subdomains vor: blog, forum, src, wiki. Wie wird das dann mit dem "Namen hinter dem Schloss"?

Liebe Grüße,

Felix Riesterer.

[Julius]

Hallo Karl Heinz,

ist zwar ein bisschen spät, aber vielleicht nützt ja folgende Veranschaulichung etwas:

Stell dir die X.509-Zertifikate wie Ausweise vor, die eine bestimmte Einrichtung oder Staat ausstellt. Die sogenannten „Reichsbürger“ akzeptieren nicht die Ausweise der BRD und alle anderen Staaten wiederum nicht die von den „Reichsbürgern“ gebastelten. Ob die Ausweise anerkannt werden, hängt davon ab, ob der Überprüfende die ausstellende Stelle akzeptiert und ihr vertraut (Fälschungssicherheit, Ausweise nur berechtigte Personen ausstellen).

Gruß
Julius

[dedlfix]

Tach!

Man muss bezogen auf eine sichere Verbindung zwei Varianten unterscheiden:

Variante 1:

Verschlüsselte Verbindung (grünes Schloss OHNE Angabe des Inhabers)

Variante 2:

Verschlüsselte Verbindung (grünes Schloss MIT Angabe des Inhabers)

Jein, nicht in Bezug auf die Verschlüsslung. Der Unterschied ist im Grad des Vertrauens begründet.

Beim Verschlüsseln ist Vertrauen eine wichtige Komponente. Die kommt meist nicht richtig zur Geltung, weil der Browser das für die Anwender regelt. Jeder Browser hat eine Sammlung von Root-Zertifikaten von diversen Zertifizierungsstellen rund um den Globus. Wenn eine Webseite nun mit einem Zertifikat daherkommt, das sich auf eines dieser Root-Zertifikate zurückführen lässt, dass vertraut der Browser darauf und zeigt dir an: "Alles sei gut." Aber die eigentliche Frage wäre, ob du als Anwender Vertrauen entgegenbringen kannst. Meist wirst der Anwender da gutgläubig auf den Browser vertrauen, weil den meisten das Verständnis von der Problematik fehlt.

Zu diesem Sachverhalt einige Fragen:

1. Aus welchem Grund wird nicht überall zusätzlich zum grünen Schloss auch noch der Name des Inhabers angegeben?

2. Warum nutzt Ihr beim selfhtml Forum nur das grüne Schloss und nicht zusätzlich "selfhtml" rechts neben dem Schloss?

Bei einfachen Zertifikaten macht die Zertifizierungsstelle nur einen einfache Prüfung, ob der Antragsteller die Gewalt über die fragliche Domain hat. Das geht oftmals vollautomatisch und kostet deshalb wenig bis nichts.

Beim Dunkelgrün hingegen spricht man von erweiterter Validierung. Da prüft dann tatsächlich ein Mensch, ob die Angaben stimmen, beispielsweise durch das Prüfen eines Gewerbescheins oder ähnlicher Dokumente. Das kostet und brings am Ende rein technisch gesehen auch nicht wirklich.

3. Die beiden Schlüsselpaare (private key und public key) von Client und Server werden ja vom Client bzw. Server selbst erzeugt. Demnach brauche ich doch für eine verschlüsselte Verbindung eigentlich keine dritte Partei wie z.B. Lets Encrypt die mir ein Zertifikat erstellt.

Richtig, aber das Zertifikat für den öffentlichen Schlüssel muss von einer der Zertifizierungsstellen signiert sein, die ihre Rootzertifikate im Browser hinterlegt haben, damit der Browser für dich die Arbeit des Vertrauens abnehmen kann. Der eigentliche Verbindungsaufbau geht ohne dritte Parteien.

Für reine Verschlüssung könnte man dann doch eigentlich auf eine Zertifikat und damit auch auf die Nutzung von Lets Encrypt verzichten.

Ja, aber dann vertrauen die Browser nicht und jammern laut rum. Es sei denn, du selbst hinterlegst beim Browser, dass dieses selbst signierte Zertifikat vertrauenswürdig ist.

Drittparteien wie z.b. Lets Encrypt benötigt man nur dann, wenn man zusätzlich zum grünen Schloss auch noch den Namen des Inhabers in der Adressleiste des Browser haben möchte. Ist das so korrekt?

Nein, generell wenn die Browser nicht jammern sollen.

dedlfix.