Estou implementando um aplicativo de multilocação no qual meu aplicativo hospeda e atende a documentação técnica do produto de um locatário.
Agora, a abordagem que eu estava considerando era: eu hospedo a documentação em docs.<tenant>.mycompany.com e peço ao meu inquilino para configurar um registro DNS CNAME para apontar docs.tenantcompany.com para docs.<tenant>.mycompany.com .
Eu quero que o site seja ativado por SSL com o certificado do meu inquilino. Eu queria entender se minha empresa de locatário tem um certificado SSL curinga, funcionará com essa configuração ou será necessário comprar um novo certificado SSL para docs.tenantcompany.com ?
O nome do certificado deve corresponder ao que o usuário inseriu no navegador, não ao registro DNS 'final'. Se o usuário digitar docs.tenantcompany.com , seu certificado SSL precisará cobrir isso.
Se docs.tenantcompany.com for um CNAME para foo.example.com , o certificado não precisará cobrir foo.example.com , apenas docs.tenantcompany.com .
A resposta de Jason está correta. Mas apenas para esclarecer um pouco os termos aqui, "redirecionamento de DNS" é um pouco inapropriado. O DNS tem registros CNAME (apelidos a.k.a.), que é um nome que aponta para outro nome. Mas não é um redirecionamento. A tradução de nome para nome para IP ocorre em segundo plano e seu navegador só se preocupa com o nome inicial.
A única coisa que redireciona são servidores da Web em que o servidor informa explicitamente ao seu navegador para ir para outro lugar. Se o seu servidor da Web estivesse realmente redirecionando para o outro nome, você precisaria de fato precisar de certificados para ambos os nomes porque o navegador estaria conectando-se a ambos separadamente.
I wanted to understand if I my tenant company has a wildcard SSL certificate, will it work with this setup or a new SSL certificate has to be purchased for
docs.tenantcompany.com?
Resposta curta: Não. Se a sua empresa de locatário tiver um caractere curinga no nome *.tenantcompany.com , isso será suficiente para instalar no seu servidor para cobrir os acessos através desse 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 caractere curinga *.<tenant>.mycompany.com ) é inútil se o acesso for sempre feito por meio do docs.tenantcompany.com name.
Suponha que você navegue até https://docs.tenantcompany.com em um navegador razoável. O navegador executa o TLS pelo protocolo HTTP. Ela se importa especificamente com duas coisas; isso:
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 algum outro local na rede local ou na Internet. Para o tráfego HTTPS (seguro), a porta padrão é 443 , a menos que seja sobrescrita 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 ).
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 e amigável (FQDN) em um endereço IP adequado (v4 ou v6). Ele não se importa como esse endereço IP é obtido. Se houver 20% de aliasesCNAME no DNS entre o registro original e um A ou AAAA , o resolvedor DNS seguirá até que um endereço IP seja obtido.
Quando o navegador executa o handshake TLS , ele precisa verificar se o servidor com o qual está se comunicando está autorizado para fornecer um serviço de site seguro no FQDN solicitado: docs.tenantcompany.com .
Lembre-se: o navegador não se importa com docs.<tenant>.mycompany.com - o resolvedor de DNS abstraiu todo o conhecimento da indireção através de um registro CNAME .
Nosso método de autorizar o servidor a fornecer sessões seguras em docs.tenantcompany.com é por meio de um certificado SSL assinado por uma autoridade para quem a confiança anterior foi estabelecida no armazenamento de certificados raiz do navegador. Essa nem sempre é a forma mais strong de autenticação de servidor para cliente - muitos podem dar errado no modelo de CA centralizado - mas é o melhor que temos no momento.
Existem duas outras advertências aqui:
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 locatária pode ficar desconfortável em compartilhar isso fora de sua organização, já que qualquer pessoa que possua a chave privada pode, obviamente, comprometer a comunicação com outros sistemas seguros da empresa do locatário.
Alguns fornecedores assinarão 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.
Se a empresa de locatários fornecer uma cópia do certificado curinga (compartilhando a chave privada ou assinando seu próprio CSR), você poderá se passar por <anydomain>.tenantcompany.com , desmembrando uma proteção importante que garante a integridade dos servidores identificado no namespace tenantcompany.com DNS. Essa pode ser uma má posição para você e para a empresa locatária, do ponto de vista legal / de responsabilidade.