Wdrażam aplikację dla wielu dzierżawców, gdzie moja aplikacja obsługuje i udostępnia dokumentację techniczną produktu dzierżawcy.

Teraz, podejście, że rozważa było - ja gospodarzem w dokumentacji docs.<tenant>.mycompany.comi zapytać mojego lokatora skonfigurować rekord CNAME DNS punktu docs.tenantcompany.comdo docs.<tenant>.mycompany.com.

Chcę, aby witryna miała obsługę SSL przy użyciu certyfikatu mojego najemcy. Chciałem zrozumieć, czy moja firma dzierżawiąca ma certyfikat SSL z wieloznaczną kartą, czy będzie działał z tą konfiguracją, czy będzie trzeba kupić nowy certyfikat SSL docs.tenantcompany.com?

Nazwa certyfikatu musi być zgodna z tym, co użytkownik wprowadził w przeglądarce, a nie „ostatecznym” rekordem DNS. Jeśli użytkownik wejdzie, docs.tenantcompany.comcertyfikat SSL musi to obejmować.

Jeśli docs.tenantcompany.comjest to CNAME foo.example.com, certyfikat nie musi obejmować foo.example.com, tylko docs.tenantcompany.com.

Odpowiedź Jasona jest poprawna. Aby jednak nieco wyjaśnić warunki, „przekierowanie DNS” jest trochę błędne. DNS ma rekordy CNAME (aliasy), które są nazwą wskazującą na inną nazwę. Ale to nie jest przekierowanie. Tłumaczenie z nazwy na nazwę na IP odbywa się w tle, a Twoja przeglądarka dba tylko o początkową nazwę.

Jedyne, co powoduje przekierowania, to serwery sieciowe, na których serwer wyraźnie mówi przeglądarce, aby poszła gdzie indziej. Jeśli serwer WWW został rzeczywiście robi przekierowanie do innej nazwy, to byłoby rzeczywiście potrzebują certyfikatów dla obu nazw, ponieważ przeglądarka będzie ostatecznie podłączenia do obu z nich oddzielnie.

Chciałem zrozumieć, czy moja firma dzierżawiąca ma certyfikat SSL z wieloznacznym kodem, czy będzie on działał z tą konfiguracją, czy będzie trzeba kupić nowy certyfikat SSL docs.tenantcompany.com?

Krótka odpowiedź: Nie. Jeśli najemca ma w nazwie symbol wieloznaczny *.tenantcompany.com, wystarczy zainstalować na serwerze, aby uzyskać dostęp za pośrednictwem tej nazwy. Czy chcesz to zrobić, czy nie, to inna historia.

Certyfikat w nazwie docs.<tenant>.mycompany.com(np. Certyfikat bezpośredni lub symbol wieloznaczny *.<tenant>.mycompany.com) jest bezużyteczny, jeśli dostęp zawsze odbywa się za pośrednictwem docs.tenantcompany.comnazwy.

Dłuższa odpowiedź

Załóżmy, że przeglądasz https://docs.tenantcompany.comw rozsądnej przeglądarce. Przeglądarka obsługuje TLS przez protokół HTTP. Dbają w szczególności o dwie rzeczy; że:

• podsystem DNS przeglądarki i systemu operacyjnego zwraca adres IP odpowiedniego hosta, który obsługuje serwer WWW na odpowiednim porcie w innym miejscu w sieci lokalnej lub Internecie. W przypadku ruchu HTTPS (zabezpieczonego) domyślnym portem jest 443adres URL, chyba że inaczej zostanie zastąpione.

• Gdy uzgadnianie TLS odbywa się między przeglądarką a serwerem zdalnym, serwer przedstawia zaufany certyfikat, który pozwala mu świadczyć usługę TLS pod żądanym adresem ( docs.tenantcompany.com).

DNS

Przeglądarka widzi DNS jako czarną skrzynkę. Dzwoni do odpowiedniej biblioteki DNS z prośbą o mapowanie przyjaznej, w pełni kwalifikowanej nazwy domeny (FQDN) na odpowiedni adres IP (v4 lub v6). Nie ma znaczenia, w jaki sposób uzyskuje ten adres IP. Jeśli CNAMEw DNS znajduje się 20 aliasów między oryginalnym rekordem a rekordem Alub AAAA, program rozpoznawania nazw DNS podąży za nimi do momentu uzyskania adresu IP.

TLS

Kiedy przeglądarka wykonuje uzgadniania TLS , musi sprawdzić, czy serwer jest komunikowanie się z upoważniony jest do zapewnienia bezpiecznego usługę internetową na FQDN o: docs.tenantcompany.com.

Pamiętaj: przeglądarka nie dba o to docs.<tenant>.mycompany.com- program rozpoznawania nazw DNS pozbył się wszelkiej wiedzy na temat pośrednictwa poprzez CNAMEzapis.

Nasza metoda autoryzacji serwera do obsługi bezpiecznych sesji docs.tenantcompany.comodbywa się za pomocą certyfikatu SSL podpisanego przez organ, dla którego ustanowiono wcześniejsze zaufanie w głównym magazynie certyfikatów przeglądarki. Nie zawsze jest to najsilniejsza forma uwierzytelniania między serwerem a klientem - w scentralizowanym modelu CA wiele błędów może się nie powieść, ale obecnie jest to najlepsza opcja.

Istnieją dwa dalsze zastrzeżenia:

Udostępnianie kluczy

Wielu komercyjnych dostawców certyfikatów SSL podpisuje tylko jedno żądanie podpisania, co skutecznie wiąże certyfikat wieloznaczny z jednym kluczem prywatnym. Firma dzierżawcy może nie być w stanie udostępnić tego poza swoją organizacją, ponieważ każdy, kto posiada klucz prywatny, może oczywiście zagrozić komunikacji z innymi zabezpieczonymi systemami firmy dzierżawcy.

Niektórzy dostawcy podpisują wiele żądań podpisania certyfikatów w ramach tego samego certyfikatu, co pozwala na zainstalowanie jednego certyfikatu wieloznacznego na wielu serwerach i systemach bez współdzielenia klucza prywatnego między nimi.

Maskarada

Jeśli firma najemcy dostarczy Ci kopię swojego certyfikatu wieloznacznego (przez udostępnienie klucza prywatnego lub podpisanie własnego CSR), możesz podszywać się pod <anydomain>.tenantcompany.com, niszcząc ważną ochronę, która zapewnia integralność serwerów zidentyfikowanych w tenantcompany.comprzestrzeni nazw DNS. Z punktu widzenia prawa / odpowiedzialności może to być zła pozycja dla Ciebie i najemcy.