Certificado curinga - Wildcard certificate
Em redes de computadores, um certificado curinga é um certificado de chave pública que pode ser usado com vários subdomínios de um domínio. O principal uso é para proteger sites da Web com HTTPS , mas também existem aplicativos em muitos outros campos. Em comparação com os certificados convencionais, um certificado curinga pode ser mais barato e mais conveniente do que um certificado para cada subdomínio. Os certificados curinga de vários domínios simplificam ainda mais a complexidade e reduzem os custos ao proteger vários domínios e seus subdomínios.
Exemplo
Um único certificado curinga para https://*.example.com
protegerá todos esses subdomínios no https://*.example.com
domínio:
payment.example.com
contact.example.com
login-secure.example.com
www.example.com
Em vez de obter certificados separados para subdomínios, você pode usar um único certificado para todos os domínios e subdomínios principais e reduzir custos.
Como o curinga cobre apenas um nível de subdomínios (o asterisco não corresponde a pontos finais), esses domínios não seriam válidos para o certificado:
test.login.example.com
O domínio "simples" é válido quando adicionado separadamente como um Nome alternativo do assunto ( SubjectAltName
):
example.com
Observe as possíveis exceções das CAs, por exemplo, o certificado wildcard-plus da DigiCert contém uma propriedade automática "Plus" para o domínio sem www example.com
.
Tipo de certificados curinga
Os certificados curinga são categorizados com base no nível de validação, número de domínio e número de servidores com os quais podem ser usados. Da mesma forma, eles são nomeados como certificado curinga de validação de domínio, certificado curinga de validação de organização e certificado curinga de validação estendida quando os categorizamos de acordo com o nível de validação. O nome Certificados curinga de vários domínios e Certificados curinga de vários servidores são fornecidos de acordo com o número do domínio e o número do servidor. Todos os tipos de certificados curinga assinados por CAs populares são categorizados e listados na Internet. Portanto, existem tipos de curinga que podem proteger vários domínios, vários servidores e fornecer diferentes níveis de validação.
Limitações
Apenas um único nível de correspondência de subdomínio é suportado de acordo com RFC 2818 .
Não é possível obter um caractere curinga para um certificado de validação estendida . Uma solução alternativa poderia ser adicionar cada nome de host virtual na extensão Nome Alternativo do Assunto (SAN), sendo que o principal problema é que o certificado precisa ser reemitido sempre que um novo servidor virtual é adicionado. (Consulte Segurança da camada de transporte § Suporte para servidores virtuais baseados em nomes para obter mais informações.)
Os curingas podem ser adicionados como domínios em certificados de vários domínios ou Certificados de Comunicações Unificadas (UCC). Além disso, os próprios curingas podem ter subjectAltName
extensões, incluindo outros curingas. Por exemplo, o certificado curinga *.wikipedia.org
tem *.m.wikimedia.org
um nome alternativo de assunto. Assim, ele protege www.wikipedia.org
, bem como o nome do site completamente diferente meta.m.wikimedia.org
.
RFC 6125 argumenta contra certificados curinga por motivos de segurança.
Exemplos
O curinga se aplica apenas a um nível do nome de domínio.
label.label.label.TLD
-
*.domain.com
está bem. Vai combinar,www.domain.com
mas nãodomain.com
e nãozzz.www.domain.com
O curinga pode aparecer em qualquer lugar dentro de um rótulo como um "curinga parcial" de acordo com as especificações anteriores
-
f*.domain.com
está bem. Vai combinar,frog.domain.com
mas nãofrog.super.domain.com
-
baz*.example.net
está OK e correspondebaz1.example.net
-
*baz.example.net
está OK e correspondefoobaz.example.net
-
b*z.example.net
está OK e correspondebuzz.example.net
No entanto, o uso de certificados "curinga parcial" não é recomendado. A partir de 2011, o suporte a curinga parcial é opcional e explicitamente proibido nos cabeçalhos SubjectAltName que são necessários para certificados de vários nomes. Todos os principais navegadores removeram deliberadamente o suporte a certificados curinga parcial; eles resultarão em um erro "SSL_ERROR_BAD_CERT_DOMAIN". Da mesma forma, é comum que bibliotecas padrão em linguagens de programação não suportem certificados "curinga parcial". Por exemplo, qualquer certificado "curinga parcial" não funcionará com as versões mais recentes de Python e Go. Assim,
Não permitir um rótulo que consiste inteiramente em apenas um caractere curinga, a menos que seja o rótulo mais à esquerda
-
sub1.*.domain.com
não é permitido.
Um certificado com vários curingas em um nome não é permitido.
*.*.domain.com
Um certificado com *
mais um domínio de nível superior não é permitido.
*.com
Muito geral e não deve ser permitido.
*
Nomes de domínio internacionais codificados em ASCII (A-label) são rótulos que são codificados em ASCII e começam com xn--
.
Não permita curingas em um rótulo internacional.
-
xn--caf-dma.com
écafé.com
-
xn--caf-dma*.com
não é permitido -
Lw*.xn--caf-dma.com
é permitido
Referências
RFCs relevantes
- "RFC 2595 - Usando TLS com IMAP, POP3 e ACAP" . Força-Tarefa de Engenharia da Internet . Junho de 1999. p. 3
- "RFC 2818 - HTTP sobre TLS" . Força-Tarefa de Engenharia da Internet . Maio de 2000. p. 5
- "RFC 6125 - Representação e verificação de identidade de serviço de aplicativo baseada em domínio na infraestrutura de chave pública da Internet usando certificados X.509 (PKIX) no contexto de segurança da camada de transporte (TLS)" . Força-Tarefa de Engenharia da Internet . Março de 2011.