Ich implementiere eine mandantenfähige Anwendung, in der meine Anwendung die technische Dokumentation für das Produkt eines Mandanten hostet und bereitstellt.
Der Ansatz, über den ich nachdachte, war: Ich hosten die Dokumentation unter docs.<tenant>.mycompany.com
und fordere meinen Mandanten auf, einen CNAME-DNS-Eintrag einzurichten, auf den verwiesen werden docs.tenantcompany.com
soll docs.<tenant>.mycompany.com
.
Ich möchte, dass die Site mit dem Zertifikat meines Mandanten SSL-fähig wird. Ich wollte wissen, ob mein Mandantenunternehmen ein Wildcard-SSL-Zertifikat hat. Funktioniert es mit diesem Setup oder muss ein neues SSL-Zertifikat gekauft werden docs.tenantcompany.com
?
*.mycompany.com
*.example.com
nicht übereinstimmendocs.tenantname.example.com
! Der Platzhalter ist nur für eine "Unterdomäne" gültig. es wirddocs-tenantname.example.com
zum Beispiel passen . Der S3 von Amazon ist ein gutes Beispiel dafür: Das*.s3.amazonaws.com
Zertifikat schlägt fehl, wenn auf einen Bucket mit einem Punkt zugegriffen wird, z. B.www.example.com
(der mit einem Hostnamen wie z. B. endetwww.example.com.s3.amazonaws.com
). Solche Bucket-Namen sind für das S3-Webhosting erforderlich.Antworten:
Der Zertifikatname muss mit der Eingabe des Benutzers im Browser übereinstimmen, nicht mit dem endgültigen DNS-Eintrag. Wenn der Benutzer eingibt, muss
docs.tenantcompany.com
Ihr SSL-Zertifikat dies abdecken.Wenn
docs.tenantcompany.com
ein CNAMEfoo.example.com
, wird das Zertifikat nicht abdecken müssenfoo.example.com
, nurdocs.tenantcompany.com
.quelle
Jasons Antwort ist richtig. Aber nur um die Begriffe hier ein bisschen zu klären, ist "DNS-Umleitung" ein bisschen eine Fehlbezeichnung. DNS hat CNAME-Einträge (auch bekannt als Aliase), bei denen es sich um einen Namen handelt, der auf einen anderen Namen verweist. Aber es ist keine Umleitung. Die Übersetzung von Name zu Name zu IP geschieht alles im Hintergrund und Ihr Browser kümmert sich nur um den Anfangsnamen.
Das Einzige, was umgeleitet wird, sind Webserver, bei denen der Server Ihrem Browser ausdrücklich anweist, woanders hinzugehen. Wenn Ihr Web - Server wurde tatsächlich eine Umleitung auf den anderen Namen zu tun, Sie würden tatsächlich Zert müssen für beide Namen , weil Ihr Browser letztlich an beide separat anschließen würde.
quelle
Server A
mit Domainexample.com
. Ich habe eine Website für ihn erstellt und die Website in gepflegtServer B
. Mein Client hat seinen DNS konfiguriert,A Record
derdog.example.com
auf die IP-Adresse meines Servers verweistServer B
. Jetzt bekommt mein Client SSL fürdog.example.com
. Meine Frage ist, muss mein Kunde mir die SSL-Zertifizierung geben, damit ich sie einbinden kannServer B
? Oder muss er es einfach reinsteckenServer A
? Oder was sollen wir sonst noch tun? Wir sind beide verwirrt, danke!dog.example.com
direkt auf die IP Ihres Servers verweist, dann ja. Ihr Server muss das Zertifikat und den privaten Schlüssel für diesen Namen enthalten. Server A in Ihrem Beispiel ist irrelevant.dog.example.com
und mir das Zertifikat und den privaten Schlüssel zugesandt. Ich lege diese hineinServer B
und konfiguriere Nginx, um sie zu verwenden. Und jetzt funktioniert alles gut. Danke!Kurze Antwort: Nein. Wenn Ihr Mieterunternehmen einen Platzhalter im Namen
*.tenantcompany.com
hat, reicht dies aus, um die Installation auf Ihrem Server durchzuführen und die Zugriffe über diesen Namen abzudecken. Ob Sie dies tun möchten oder nicht, ist eine andere Geschichte.Ein Zertifikat im Namen
docs.<tenant>.mycompany.com
(z. B. ein direktes Zertifikat oder ein Platzhalter*.<tenant>.mycompany.com
) ist unbrauchbar, wenn der Zugriff immer über dendocs.tenantcompany.com
Namen erfolgt.Längere Antwort
Angenommen, Sie suchen
https://docs.tenantcompany.com
in einem vernünftigen Browser nach. Der Browser führt TLS über das HTTP-Protokoll aus. Es geht speziell um zwei Dinge; Das:Das DNS-Subsystem des Browsers und des Betriebssystems gibt die IP-Adresse eines geeigneten Hosts zurück, auf dem ein Webserver an einem geeigneten Port an einer anderen Stelle im lokalen Netzwerk oder im Internet ausgeführt wird. Für HTTPS-Verkehr (gesichert) wird der Standardport verwendet,
443
sofern in der URL nichts anderes angegeben ist.Wenn der TLS-Handshake zwischen dem Browser und dem Remote-Server stattfindet, zeigt der Server ein vertrauenswürdiges Zertifikat an, mit dem er einen TLS-Dienst an der angeforderten Adresse (
docs.tenantcompany.com
) bereitstellen kann .DNS
Der Browser sieht DNS als Blackbox. Es ruft eine geeignete DNS-Bibliothek auf, um eine Zuordnung von einem freundlichen vollqualifizierten Domänennamen (FQDN) zu einer geeigneten IP-Adresse (v4 oder v6) anzufordern. Es ist egal, wie es diese IP-Adresse bekommt. Befinden sich
CNAME
im DNS zwischen dem ursprünglichen Eintrag und einemA
oder Eintrag 20 AliaseAAAA
, folgt der DNS-Resolver diesen, bis eine IP-Adresse erhalten wird.TLS
Wenn der Browser die führt TLS - Handshake , braucht es , um zu überprüfen , dass der Server mit kommuniziert wird ermächtigt , einen sicheren Website - Dienst auf dem FQDN verlangt , um:
docs.tenantcompany.com
.Denken Sie daran: Der Browser kümmert sich nicht darum
docs.<tenant>.mycompany.com
- der DNS-Resolver hat das gesamte Wissen über die Indirektion über einenCNAME
Datensatz entzogen.Unsere Methode zur Autorisierung des Servers für die Bereitstellung sicherer Sitzungen
docs.tenantcompany.com
erfolgt über ein SSL-Zertifikat, das von einer Behörde signiert ist, für die im Stammzertifikatsspeicher des Browsers eine vorherige Vertrauenswürdigkeit hergestellt wurde. Dies ist nicht immer die stärkste Form der Authentifizierung von Server zu Client - im zentralisierten CA-Modell können viele Probleme auftreten - aber es ist die beste, die wir derzeit haben.Hier gibt es zwei weitere Einschränkungen:
Schlüssel teilen
Viele kommerzielle SSL-Zertifikatsanbieter signieren nur eine einzelne Signaturanforderung, wodurch das Platzhalterzertifikat effektiv an einen einzelnen privaten Schlüssel gebunden wird. Das Mieterunternehmen hat möglicherweise Schwierigkeiten, dies außerhalb seiner Organisation zu teilen, da jeder, der über den privaten Schlüssel verfügt, offensichtlich die Kommunikation mit den anderen gesicherten Systemen des Mieterunternehmens beeinträchtigen kann.
Einige Anbieter signieren mehrere Zertifikatsignieranforderungen unter demselben Zertifikat, sodass ein einzelnes Platzhalterzertifikat auf mehreren Servern und Systemen installiert werden kann, ohne den privaten Schlüssel zwischen ihnen zu teilen.
Maskieren
Wenn das Mandantenunternehmen Ihnen eine Kopie seines Platzhalterzertifikats zur Verfügung stellt (entweder durch Freigabe des privaten Schlüssels oder durch Signieren Ihres eigenen CSR), können Sie sich als maskieren
<anydomain>.tenantcompany.com
und einen wichtigen Schutz aufheben, der die Integrität der imtenantcompany.com
DNS-Namespace identifizierten Server gewährleistet . Dies könnte sowohl für Sie als auch für das Mieterunternehmen aus rechtlicher / haftungsrechtlicher Sicht eine schlechte Position sein.quelle