Analizador de certificado VMC

¿Por qué analizar un certificado de marca?

Un certificado de marca cuesta de 1000 a 1500 dólares al año. Recibirlo no demuestra nada sobre su funcionamiento.

Entre el archivo que entrega la autoridad y el logo que aparece en una bandeja de entrada hay un registro DNS, una dirección https, una política DMARC y un dominio de envío que debe figurar en el certificado. Cuando el logo no aparece, la causa se esconde en esa cadena, y los decodificadores clásicos se limitan a mostrar un titular y dos fechas.

Este analizador decodifica el certificado y luego contrasta cada dato medido con el perfil VMC, con el RFC 3709 para el logotipo y con el RFC 5280 para el resto. Devuelve un veredicto de cuatro estados y la lista de hallazgos que lo fundamentan, con su fuente. El catálogo consta de 44 códigos; el número de hallazgos devueltos depende del certificado analizado.

Los momentos en que sirve:

• Al recibir el certificado, antes de publicar nada en el DNS.
• Cuando el logo sigue invisible pese a una configuración que parece correcta.
• Antes de una renovación, para comparar el archivo antiguo y el nuevo en cuanto a los dominios cubiertos.

Qué comprueba el analizador

Siete familias de comprobaciones, 44 códigos, tres severidades. La tabla indica la pregunta que zanja cada familia.

VMC o CMC, el informe nombra el perfil. El programa BIMI emite dos tipos de certificado de marca: el VMC, respaldado por una marca registrada, y el CMC, emitido con la prueba de un uso anterior del logo. Ningún identificador de política los separa, y está medido sobre 37 certificados reales: dos certificados de perfiles distintos, emitidos por la misma autoridad, declaran exactamente las mismas políticas. Por eso el analizador lee el atributo de titular markType, el que el programa define para este uso, y el informe te dice cuál de los dos tienes en la mano. Un CMC sigue siendo un perfil legítimo: el hallazgo se reporta como información, no degrada el veredicto y solo recuerda que el soporte de los proveedores de correo es más estrecho.

El calibrado de las severidades sigue una regla única: clasificar como bloqueante únicamente lo que sabemos con certeza que es un defecto del certificado. Una extensión mal codificada que nuestro decodificador no ha sabido leer se queda en aviso, porque la duda está de nuestro lado. Esta disciplina tiene un coste, y también una ventaja: cuando el veredicto cae en no conforme, la frase es rotunda y quien la lee puede creerla.

La verificación del logotipo incrustado

Es la comprobación que separa a esta herramienta de un decodificador. Responde a una pregunta que ninguna otra página plantea: ¿la imagen que lleva este certificado es la que validó la autoridad?

El mecanismo procede del RFC 3709 §4.1. La extensión de logotipo 1.3.6.1.5.5.7.1.12 transporta, para cada imagen, un par formado por algoritmo y huella. El RFC 6170 precisa el resto: la imagen es un SVG Tiny, comprimido en gzip, codificado dentro de una URI data:. El analizador extrae esa imagen, la descomprime, la vuelve a hashear con el algoritmo que el certificado declara y compara.

Tres desenlaces, tres mensajes. Huellas iguales, el caso esperado, informado como nota porque es la prueba que venías a buscar. Huellas en discrepancia, hallazgo bloqueante: el archivo se ha modificado después de la verificación de la autoridad, y ese certificado no debe publicarse. Ninguna imagen incrustada, aviso: el logo solo se referencia mediante URI, la integridad ya no se comprueba fuera de línea y la visualización depende de un servidor de terceros.

La decodificación rechaza varias trampas que hasta ahora producían falsas discrepancias. Solo se lee el subjectLogo, la rama directa: el logotipo de la autoridad y los de una comunidad llevan otras huellas y no pintan nada en la comparación. Solo se conserva la primera imagen de la secuencia, ya que de lo contrario la huella de la segunda acabaría comparándose con la primera.

Ante una discrepancia probada, la acción no se discute: recupera el SVG que entregaste a la autoridad al hacer el pedido, o pide una reemisión. Volver a publicar una imagen retocada tras la emisión rompe el vínculo, y la guía de creación del logo BIMI recuerda las restricciones de formato que hay que respetar.

Dos falsos defectos, medidos sobre certificados reales

Un analizador que pide corregir lo que emiten DigiCert y GlobalSign ya no analiza nada. Dos hallazgos se han recalibrado tras medirlos en seis certificados reales, en las tres autoridades del programa.

La huella del logotipo solo en SHA-1. Cuatro certificados de seis declaran únicamente ese algoritmo, todos emitidos por DigiCert. El papel de esa huella es emparejar una imagen con un certificado; el verificador ya posee la imagen y recalcula el valor por sí mismo, sin dejar una segunda opción a un adversario. Clasificar este caso como aviso produciría un falso positivo masivo en la principal autoridad del programa. El analizador lo informa como nota.

La extensión keyUsage ausente. Cinco certificados de seis no la llevan, en dos autoridades de tres, y muestran su logo en producción. El RFC 5280 §4.2.1.3 impone keyUsage solo a los certificados cuya clave valida firmas de otros certificados, es decir, a las autoridades. En una hoja es opcional. El hallazgo se sigue mostrando, como nota, porque explica por qué no se han evaluado las comprobaciones de uso de clave.

Estas dos líneas sirven sobre todo como clave de lectura del informe. Un hallazgo informado como nota no exige ninguna acción: documenta. No pidas una reemisión de 1200 dólares por un hecho informado.

Los cuatro veredictos y lo que exigen

Cuatro veredictos posibles, uno por análisis, cada uno con la acción que exige.

El cuarto estado existe porque el caso es frecuente, y escribir «tu certificado de marca no es conforme» sobre un objeto que no lo es sería falso. Dos caminos llevan ahí. Ni política de marca ni extensión de logotipo: es el certificado TLS del sitio web, pegado por error, y la presencia del uso serverAuth lo confirma. O bien basicConstraints declara cA=TRUE, y el objeto es una autoridad de certificación, casi siempre el intermedio entregado en el mismo archivo PEM que la hoja.

Este segundo caso producía antes un informe enteramente falso. Al intermedio se le dirigían reproches pensados para una hoja, entre ellos un uso keyCertSign juzgado excesivo cuando una autoridad debe llevarlo, y una línea que afirmaba que se trataba de un Verified Mark Certificate. Ahora se reconoce y se nombra, sin más juicio.

El dominio esperado, un campo opcional

Este campo gobierna exactamente dos de los 44 hallazgos. Si lo dejas vacío, pierdes esos dos, y nada más.

Indica ahí el dominio que publica tu registro BIMI. El analizador busca entonces una entrada dNSName del certificado que lo cubra, y devuelve cubierto o una discrepancia bloqueante. La trampa habitual es el wildcard (comodín): en el sentido del RFC 9525 §6.3, baja un solo nivel. *.captaindns.com cubre mail.captaindns.com, pero ni captaindns.com ni a.b.captaindns.com.

Una discrepancia aquí no se arregla con una modificación en el DNS. El certificado no cubre ese dominio, hay que pedir una reemisión. Más vale pensarlo al hacer el pedido, subdominios transaccionales incluidos.

Lo que este analizador no dice

Tres límites, enunciados porque una herramienta que los calla hace creer en garantías que no aporta.

La revocación no se comprueba. Ninguna consulta OCSP, ninguna lista de revocación. Un certificado revocado por su autoridad saldrá conforme si su contenido lo es.

No se juzga a la organización emisora. No hay ninguna lista de autoridades acreditadas fijada en el código, y es deliberado: una lista así se volvería falsa el día en que el BIMI Group acredite a un nuevo emisor, y se volvería falsa en silencio. El juicio pasa por la política de certificación declarada y por el vínculo de la cadena, no por un nombre.

La cadena no remonta hasta una raíz de marca. Las raíces del programa, medidas sobre el corpus, están ausentes de los dos almacenes verificables en local: el almacén del sistema de Apple, 127 raíces, y el paquete de Mozilla que distribuye curl, 190 raíces. Forman un almacén propio del programa, que ni un sistema operativo ni una imagen de contenedor llevan. Consecuencia aplicada en la herramienta: un fallo de verificación nunca se convierte en un hallazgo bloqueante, ya que no demuestra nada. Una cadena que se verifica correctamente sigue siendo una buena noticia; una cadena que no se verifica no dice nada del certificado.

Publicar el certificado una vez validado

El veredicto no basta para que el logo aparezca. Cuatro cosas deben sostenerse a la vez.

DMARC primero: el dominio de envío debe estar en p=quarantine o p=reject, sin lo cual ningún proveedor de correo mirará el resto. Después el archivo PEM, servido por https en una dirección estable, la que lleva la etiqueta a= de tu registro _bimi. El logo SVG, servido de la misma manera, referenciado por la etiqueta l=. Y por último el dominio de envío, presente entre los dominios certificados.

Sirve siempre el archivo completo, la hoja seguida de los intermedios, tal como lo entregó la autoridad. Un certificado servido en solitario dispara un aviso de cadena incompleta, y algunos verificadores se detienen ahí.

En cuanto al calendario, un certificado de marca vive un año. El analizador pasa a aviso en los últimos 30 días y señala el vencimiento ya en los últimos 60, pero un informe puntual no sustituye a una monitorización. Apunta la fecha y lee nuestra guía sobre los certificados VMC y CMC para elegir entre los dos perfiles en el momento de la renovación. Si el logo sigue ausente después de publicar, cinco causas frecuentes cubren la mayoría de los casos.

Confidencialidad

Dos caminos, dos comportamientos, y la herramienta te dice cuál se aplica antes de que hagas clic.

Un certificado pegado en formato PEM se analiza fuera de línea: decodificación en memoria, ninguna conexión saliente, ningún archivo conservado. Una dirección https, en cambio, la descargarán nuestros servidores en una única petición acotada, tal como indica en tiempo real la nota bajo el botón. Un certificado no es en ningún caso un secreto: lleva una clave pública e identificadores destinados a ser publicados.

El campo dominio esperado solo se usa para la comprobación de cobertura. Más allá de diez bloques CERTIFICATE en un mismo envío, el excedente se ignora y el informe lo señala.

FAQ - Preguntas frecuentes

P: ¿Qué es un certificado VMC?

R: Un Verified Mark Certificate es un certificado X.509 que vincula un logo con una organización cuyos derechos de marca se han verificado. Lleva la imagen dentro de una extensión de logotipo (RFC 3709) y declara una política de certificación propia del programa. Gmail, Yahoo Mail y Apple Mail se sirven de él para mostrar tu logo, siempre que DMARC esté en p=quarantine o p=reject. Lo emiten DigiCert, Entrust y GlobalSign, entre otras autoridades acreditadas por el BIMI Group.

P: ¿Por qué no aparece mi logo si el certificado es válido?

R: El certificado es solo uno de los eslabones. Comprueba por orden: DMARC en p=quarantine o p=reject en el dominio de envío, el registro _bimi publicado, la etiqueta a= apuntando a una dirección https que sirva el PEM, y el dominio de envío presente entre los dominios certificados. Este último punto es el que zanja aquí el campo dominio esperado. Las cachés de los proveedores de correo añaden después un retraso de varias horas.

P: ¿El analizador comprueba que el logotipo incrustado es el que validó la autoridad?

R: Sí, y es la comprobación que distingue a esta herramienta. La imagen SVG se extrae de la extensión de logotipo, se descomprime y se vuelve a hashear con el algoritmo que el propio certificado declara. Si la huella recalculada difiere de la huella declarada, el hallazgo es bloqueante: el archivo ha cambiado después de la verificación de la autoridad. Esta comparación no funcionaba sobre ningún certificado real antes de la remodelación de la herramienta.

P: Mi certificado declara la huella del logotipo en SHA-1, ¿es un defecto?

R: No. Sobre seis certificados reales medidos en tres autoridades, cuatro declaran su huella de logotipo solo en SHA-1: es lo que emite DigiCert. El papel de esa huella es emparejar una imagen con un certificado, no levantar una barrera anticolisión, ya que el verificador tiene la imagen y recalcula el valor. El analizador lo señala como un hecho, sin degradar el veredicto.

P: Falta la extensión keyUsage en mi VMC, ¿hay que pedir una reemisión?

R: No. La extensión falta en cinco de los seis certificados medidos, en dos de las tres autoridades del programa, y esos certificados muestran su logo en producción. El RFC 5280 §4.2.1.3 solo impone keyUsage a los certificados de autoridad; en una hoja sigue siendo opcional. El hallazgo se informa como nota, para explicar por qué no se han evaluado las comprobaciones de uso de clave.

P: ¿Qué significa el veredicto «no es un certificado de marca»?

R: Que el objeto pegado no pertenece al perfil VMC, y hay dos caminos para llegar ahí. El primero: ni política de marca ni extensión de logotipo, es decir, el certificado TLS del sitio web pegado en lugar del VMC. El segundo: basicConstraints declara cA=TRUE, así que es una autoridad de certificación, a menudo el intermedio entregado en el mismo archivo PEM. En ese caso, la hoja es el primer bloque del archivo.

P: ¿Para qué sirve el campo dominio esperado?

R: Para comprobar que el dominio que publica tu registro BIMI figura entre los dominios que cubre el certificado. El campo es opcional y gobierna exactamente dos de los 44 hallazgos: cubierto, o en discrepancia. Cuidado con el wildcard, que baja un solo nivel según el RFC 9525 §6.3: *.captaindns.com cubre mail.captaindns.com, pero ni captaindns.com ni a.b.captaindns.com.

P: ¿Cuánto cuesta un certificado VMC y por cuánto tiempo vale?

R: Del orden de 1000 a 1500 dólares al año en DigiCert, Entrust o GlobalSign, un precio que cubre la verificación de la marca registrada ante una oficina reconocida. La validez habitual es de un año. Prevé la renovación con antelación: el analizador señala los últimos 30 días como aviso y los últimos 60 como nota, y un certificado caducado hace desaparecer el logo sin más preaviso.

Herramientas complementarias

Recursos útiles

• RFC 3709 - extensión de logotipo de los certificados (estructura logotypeHash, huella declarada del logotipo)
• RFC 6170 - imagen dentro de un certificado X.509 (SVG Tiny comprimido, transportado en una URI data:)
• RFC 5280 - perfil de los certificados X.509 (validez, basicConstraints, keyUsage, SAN)
• RFC 9525 - verificación de identidad de servicio (alcance del wildcard en un SAN)
• BIMI Group - certificados de marca verificada (perfil VMC, autoridades acreditadas)
• Especificación BIMI (etiquetas a= y l=, prerrequisitos DMARC)