Estou implementando um aplicativo multilocatário em que meu aplicativo hospeda e serve documentação técnica para o produto de um inquilino.

Agora, a abordagem que eu estava pensando era - eu sediar a documentação em docs.<tenant>.mycompany.come pedir meu inquilino para configurar um registro CNAME DNS para apontar docs.tenantcompany.compara docs.<tenant>.mycompany.com.

Desejo que o site seja ativado para SSL com o certificado do meu inquilino. Eu queria entender se minha empresa de locatários tem um certificado SSL curinga, ela funcionará com essa configuração ou será necessário adquirir um novo certificado SSL docs.tenantcompany.com?

O nome do certificado deve corresponder ao que o usuário digitou no navegador, não ao registro DNS 'final'. Se o usuário digitar docs.tenantcompany.com, o seu certificado SSL deverá cobri-lo.

Se docs.tenantcompany.comfor um CNAME para foo.example.com, o certificado não precisa cobrir foo.example.comapenas docs.tenantcompany.com.

A resposta de Jason está correta. Mas apenas para esclarecer um pouco os termos aqui, "redirecionamento de DNS" é um pouco impróprio. O DNS possui registros CNAME (também conhecidos como aliases), que são um nome apontando para outro nome. Mas não é um redirecionamento. A tradução de nome para nome para IP acontece em segundo plano e o seu navegador se importa apenas com o nome inicial.

A única coisa que redireciona são os servidores da Web em que o servidor está explicitamente dizendo ao seu navegador para ir para outro lugar. Se o seu servidor web foi realmente fazendo um redirecionamento para outro nome, você iria realmente precisa certs para ambos os nomes porque o seu navegador acabaria por ser a conexão com os dois separadamente.

Eu queria entender se minha empresa de locatários tem um certificado SSL curinga, ela funcionará com essa configuração ou se será necessário comprar um novo certificado SSL docs.tenantcompany.com?

Resposta curta: Não. Se a empresa locatária tiver um curinga no nome *.tenantcompany.com, isso é suficiente para instalar no servidor para cobrir acessos por esse nome. Se você quer fazer isso ou não, é outra história.

Um certificado no nome docs.<tenant>.mycompany.com(por exemplo, um certificado direto ou um curinga *.<tenant>.mycompany.com) é inútil se o acesso for sempre feito por meio do docs.tenantcompany.comnome.

Resposta mais longa

Suponha que você navegue https://docs.tenantcompany.comem um navegador razoável. O navegador executa o TLS pelo protocolo HTTP. Ele se importa especificamente com duas coisas; naquela:

• o subsistema DNS do navegador e do sistema operacional retorna o endereço IP de um host adequado, que está executando um servidor da web em uma porta adequada em outro local da rede local ou da internet. Para tráfego HTTPS (seguro), a porta padrão é, a 443menos que seja substituído de outra forma no URL.

• Quando o handshake TLS ocorre entre o navegador e o servidor remoto, o servidor apresenta um certificado confiável que permite fornecer um serviço TLS no endereço solicitado ( docs.tenantcompany.com).

DNS

O navegador vê o DNS como uma caixa preta. Ele faz uma chamada para uma biblioteca DNS adequada para solicitar um mapeamento de um nome de domínio totalmente qualificado (FQDN) para um endereço IP adequado (v4 ou v6). Não importa como ele obtém esse endereço IP. Se houver 20 CNAMEaliases no DNS entre o registro original e um Aou AAAA, o resolvedor de DNS os seguirá até que um endereço IP seja obtido.

TLS

Quando o navegador executa a TLS aperto de mão , ele precisa verificar se o servidor está se comunicando com está autorizado a fornecer um serviço de site seguro no FQDN solicitado: docs.tenantcompany.com.

Lembre-se: o navegador não se preocupa docs.<tenant>.mycompany.com- o resolvedor de DNS abstraiu todo o conhecimento da indireção por meio de um CNAMEregistro.

Nosso método de autorizar o servidor a servir sessões seguras docs.tenantcompany.comé por meio de um certificado SSL assinado por uma autoridade para a qual a confiança anterior foi estabelecida no armazenamento de certificados raiz do navegador. Essa nem sempre é a forma mais forte de autenticação de servidor para cliente - muitos podem dar errado no modelo de CA centralizado - mas é o melhor que temos no momento.

Existem mais duas advertências aqui:

Partilha de chaves

Muitos fornecedores comerciais de certificados SSL assinam apenas uma única solicitação de assinatura, o que efetivamente vincula o certificado curinga a uma única chave privada. A empresa inquilina pode não gostar de compartilhar isso fora de sua organização, pois qualquer pessoa que possua a chave privada pode obviamente comprometer a comunicação com os outros sistemas seguros da empresa inquilina.

Alguns fornecedores assinam várias solicitações de assinatura de certificado no mesmo certificado, o que permite que um único certificado curinga seja instalado em vários servidores e sistemas sem compartilhar a chave privada entre eles.

Mascarada

Se a empresa inquilina fornecer uma cópia do certificado curinga (compartilhando a chave privada ou assinando seu próprio CSR), você pode disfarçar como <anydomain>.tenantcompany.com, quebrando uma proteção importante que garante a integridade dos servidores identificados no tenantcompany.comespaço para nome DNS. Essa pode ser uma má posição para você e a empresa arrendatária serem inseridas, de uma perspectiva legal / de responsabilidade.