Um CN coringa em um certificado SSL pode ser mais específico

Question

O nome comum de um certificado SSL com coringa pode ser mais específico que simplesmente "*"?

por exemplo: no caso de um firewall com várias interfaces e nomes semelhantes atribuídos a essas interfaces: pix-lan1 , pix-lan2 , pix-wan1 , etc. Está tudo bem em usar um CN de pix-*.domain para um único certificado?

Claramente, *.domain funcionaria; mas descobrimos que o uso de um único certificado de wild-card com toda a empresa requer a substituição simultânea de certificados em muitas máquinas.

    

Answer 1

Isso depende do protocolo. Para HTTPS, o RFC 2818 permite explicitamente que o caractere curinga esteja dentro do rótulo, ou seja, algo como f*.example.com . E não consigo encontrar nenhuma declaração nos requisitos básicos do fórum do navegador da CA que restringem o curinga apenas ao rótulo completo.

Para outros protocolos, como LDAP ou SMTP, a situação é diferente. A maioria permite apenas os curingas de rótulo completo padrão, como *.example.com , e não permite f*.example.com . Mas não tenho certeza de quanto essas diferenças são realmente aplicadas na prática, porque muitas vezes há um código compartilhado para a validação do assunto.

    

Answer 2

RFC 6125, parágrafo 6.4.3 diz:

3. O cliente pode corresponder a um identificador apresentado no qual o curinga    caractere não é o único caractere do rótulo (por exemplo,    baz * .example.net e baz.example.net e b z.exemplo.net    ser levado para coincidir com baz1.example.net e foobaz.example.net e    buzz.example.net, respectivamente).

No entanto, o parágrafo 7.2 do mesmo documento levanta preocupações de segurança. O Apêndice B lista alguns aplicativos e seu uso de curingas. Por exemplo, o caractere curinga, como o seu exemplo, funciona em HTTP, mas não em LDAP ou SMTP / POP3 / IMAP.