Ich habe ein kleines SaaS, bei dem jeder Kunde eine eigene Anwendungsinstanz erhält. Jede Anwendungsinstanz hat einen DNS wieUnternehmen.beispiel.com.
Ein Kunde (sagen wir X) fragte mich, ob er stattKundeX.example.com kann er seine Anwendungsinstanz seiner Domäne zuordnen lassen: etwa app.his-domain.com
Mein erster Gedanke war, ihn zu bitten, einen CNAME-DNS-Eintrag wie diesen einzufügen:
CNAME: app.his-domain.com -> customerX.example.com
und füge auf meiner Site einen neuen Servernamen für nginx hinzu:
server { server_name customerX.example.com app.his-domain.com; proxy_pass: https://backend; }
Aber das funktioniert nicht, weil TLS-Zertifikatenur für .example.com Subdomains!
Frage:
wie soll dieses DNS-Mapping-Ding funktionieren? Ich habe sogar Schwierigkeiten, danach zu googeln, weil ich die „offiziellen Begriffe“ dafür nicht kenne. Die Idee mit CNAME stammt aus meiner begrenzten Erfahrung mit DNS. Es könnte also völliger Unsinn sein …
Antwort1
Sie verwechseln CNAMES mit HTTP-Umleitung. Ein CNAME wird während der DNS-Suche nur in eine IP übersetzt, aber wenn der Client die HTTPS-Sitzung zum Server initiiert, verwendet er weiterhin den ursprünglichen DNS-Namen in den HTTP-Headern. Daher erhalten Sie einen Zertifikatsfehler, weil NGINX das Zertifikat für bereitstellt .example.com.
Um dies zu beheben, müssen Sie den Client lediglich bitten, ein Zertifikat auszustellen, app.his-domain.comund Ihr NGINX dieses Zertifikat den Clients bereitstellen lassen, die die Site anfordern app.his-domain.com.
Eine andere Möglichkeit, dies zu beheben, besteht darin, eine Umleitung auf Ihrem Server zu hosten, bei der NGINX dem Client die Meldung „301 Permanently Moved to“ (Dauerhaft verschoben nach) mitteilt. client.example.comDies hat jedoch den Nachteil, dass Ihr Client dies dann client.example.comin der Adressleiste des Browsers sehen würde, was den ganzen Sinn einer benutzerdefinierten Domäne zunichte macht.