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

O nome comum de um certificado SSL com wild card pode ser mais específico do 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-wan1etc. Não há problema em usar um CN de pix-*.domain para um único certificado?

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

Isso depende do protocolo. Para HTTPS RFC 2818 permite explicitamente que o caractere curinga esteja dentro do rótulo, ou seja, algo como f*.example.com. E eu não consigo encontrar nenhuma declaração no requisitos de linha de base 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 permitir 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.

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 eb z.example.net seria    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.