Protocolo de Verificación de Dominio
Define el mecanismo mediante el cual una entidad digital demuestra control técnico real sobre el dominio que desea certificar. Sin verificación de dominio, cualquier entidad podría reclamar control sobre cualquier dominio sin evidencia.
1. Propósito y Alcance
Base técnica del protocolo
El mecanismo de verificación mediante archivo en la ruta /.well-known/ está definido por el RFC 8615 (Well-Known Uniform Resource Identifiers) de la IETF. Es el mismo mecanismo que utilizan sistemas como Let's Encrypt, Google Search Console y Apple para la verificación de propiedad de dominio. El Estándar LM adopta este mecanismo y lo extiende con elementos criptográficos propios del ecosistema.
El protocolo aplica a: todo proceso de certificación iniciado en un portal territorial, la fase de investigación (LM-PI-001) en su etapa A4, la fase de operación (LM-PO-001) en su etapa A6, y cualquier sistema de terceros que implemente o valide certificados del Estándar LM.
2. Definiciones del Protocolo
| Término | Definición en el contexto de este protocolo |
|---|---|
| Challenge | Cadena de texto única e irrepetible generada por el portal para un proceso de certificación específico. Sirve para vincular el archivo de verificación publicado en el dominio con el proceso de certificación activo en el portal. |
| Hash de verificación | Resultado de aplicar SHA-256 sobre el challenge exacto. Permite que cualquier sistema externo verifique matemáticamente la integridad del archivo sin acceso al portal. |
| Archivo de verificación | Archivo de texto plano publicado por la entidad solicitante en la ruta /.well-known/luvameta.txt de su dominio. Su existencia y contenido correcto demuestran control técnico del dominio. |
| Verificación cruzada | Proceso en que tres elementos se validan mutuamente: el certificado JSON del portal, el archivo de verificación del dominio y el registro público del portal. La coherencia entre los tres es la prueba de que el sistema no ha sido manipulado. |
| Vigencia del archivo | Periodo durante el cual el archivo de verificación es considerado activo. El Estándar LM v1.0 establece una vigencia máxima de 180 días desde la última verificación exitosa registrada. |
| PASS | Resultado de verificación exitosa. El elemento verificado cumple todos los criterios del protocolo. |
| FAIL | Resultado de verificación fallida. Un FAIL en cualquier punto del protocolo detiene el proceso. |
3. Estructura del Challenge Criptográfico
3.1 Formato del challenge
LM-[PAIS]-[ID_CERT]-[FECHA]-[HEX8]
Donde:
LM = Prefijo fijo del Estándar LM
[PAIS] = Código ISO 3166-1 alpha-2 (2 letras mayúsculas)
[ID_CERT] = Número secuencial del certificado (mínimo 4 dígitos)
[FECHA] = Fecha de generación sin separadores: AAAAMMDD
[HEX8] = 8 caracteres hexadecimales aleatorios en minúsculas
Ejemplo conforme:
LM-CL-0001-20260412-a3f7b2c9
Ejemplos NO conformes:
lm-CL-0001-20260412-a3f7b2c9 (prefijo en minúsculas)
LM-cl-0001-20260412-a3f7b2c9 (país en minúsculas)
LM-CL-1-20260412-a3f7b2c9 (ID sin 4 dígitos mínimos)
LM-CL-0001-2026-04-12-a3f7b2c9 (fecha con separadores)
LM-CL-0001-20260412-A3F7B2C9 (hex en mayúsculas)
LM-CL-0001-20260412-a3f7b2c (hex con menos de 8 chars)
La parte aleatoria de 8 caracteres hexadecimales DEBE generarse mediante un generador criptográficamente seguro. NO DEBE usarse un generador pseudoaleatorio basado en tiempo o secuencias predecibles.
3.2 Cálculo del hash de verificación
hash = SHA-256( challenge_string )
Donde challenge_string es el challenge exacto como texto UTF-8,
sin espacios iniciales, finales ni saltos de línea.
Ejemplo:
challenge = "LM-CL-0001-20260412-a3f7b2c9"
hash = SHA-256("LM-CL-0001-20260412-a3f7b2c9")
= [resultado de 64 chars hexadecimales en minúsculas]
Node.js:
const crypto = require("crypto");
const hash = crypto
.createHash("sha256")
.update("LM-CL-0001-20260412-a3f7b2c9", "utf8")
.digest("hex");
Python:
import hashlib
hash = hashlib.sha256(
"LM-CL-0001-20260412-a3f7b2c9".encode("utf-8")
).hexdigest()
Regla crítica de cálculo
El hash DEBE calcularse sobre el challenge exacto tal como aparece en el campo "challenge" del JSON y en el campo luvameta-challenge del archivo. Cualquier diferencia —un espacio, una letra en distinta mayúscula, un carácter adicional— produce un hash completamente distinto y la verificación FALLA con resultado FAIL irrecuperable. No existe tolerancia de diferencia.
4. Especificación del Archivo de Verificación
4.1 Ubicación del archivo
El archivo DEBE publicarse en la siguiente ruta exacta, accesible mediante HTTPS:
https://[dominio-certificado]/.well-known/luvameta.txt
Ejemplos:
https://ejemplo-empresa.com/.well-known/luvameta.txt
https://miproyecto.cl/.well-known/luvameta.txt
https://plataforma.ar/.well-known/luvameta.txt
El archivo NO PUEDE publicarse en ninguna ruta alternativa. El Estándar LM no acepta rutas de verificación distintas a /.well-known/luvameta.txt en la versión 1.0.
4.2 Estructura del archivo
El archivo es texto plano (Content-Type: text/plain) con codificación UTF-8. Cada campo ocupa una línea con formato clave: valor.
luvameta-cert-id: CL-0001
luvameta-issued-by: https://cl.luvameta.com
luvameta-challenge: LM-CL-0001-20260412-a3f7b2c9
luvameta-hash: e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
luvameta-record: https://cl.luvameta.com/certificados/CL-0001.json
4.3 Especificación de cada campo del archivo
| Campo | Nivel | Criterio de contenido |
|---|---|---|
luvameta-cert-id | DEBE | DEBE coincidir exactamente con el campo "cert_id" del JSON del certificado. Formato: [CC]-[NNNN]. Sensible a mayúsculas. |
luvameta-issued-by | DEBE | DEBE coincidir exactamente con el campo "issued_by" del JSON del certificado. DEBE ser la URL HTTPS del portal territorial emisor. |
luvameta-challenge | DEBE | DEBE coincidir exactamente con el challenge generado por el portal para este proceso. Cualquier diferencia produce FAIL en la verificación del hash. |
luvameta-hash | DEBE | DEBE ser el resultado de SHA-256(challenge) en hexadecimal minúsculas. 64 caracteres exactos. El auditor DEBE recalcular y comparar. |
luvameta-record | DEBE | DEBE ser la URL pública del JSON del certificado en el portal. DEBE usar HTTPS. DEBE resolver y devolver el JSON del certificado. |
4.4 Restricciones de formato del archivo
- El archivo DEBE usar codificación UTF-8.
- El separador entre clave y valor DEBE ser
": "(dos puntos seguido de un espacio). - NO DEBE haber líneas en blanco entre los campos.
- NO DEBE haber espacios adicionales antes de las claves ni después de los valores.
- El archivo NO DEBE contener más campos que los cinco definidos.
- El archivo DEBE terminar con un salto de línea después del último campo.
- NO DEBE incluir comentarios, encabezados ni metadatos adicionales.
5. Flujo del Protocolo de Verificación
El protocolo se ejecuta en tres fases con responsabilidades diferenciadas:
| Fase | Responsable | Resultado |
|---|---|---|
| 1. Generación | Portal territorial | Challenge + hash generados y comunicados al solicitante. |
| 2. Publicación | Entidad solicitante | Archivo publicado en /.well-known/ del dominio. |
| 3. Verificación | Portal territorial (auditor) | PASS o FAIL por cada punto de verificación. |
5.1 Secuencia de verificación — Puntos obligatorios
| # | Punto de verificación | Criterio exacto | Si cumple | Si falla |
|---|---|---|---|---|
| V1 | Accesibilidad HTTPS del archivo | GET https://[dominio]/.well-known/luvameta.txt devuelve HTTP 200 sin redirección. Content-Type debe incluir text/plain. | PASS | FAIL — detener |
| V2 | Presencia de todos los campos | El archivo contiene exactamente los cinco campos requeridos. | PASS | FAIL — detener |
| V3 | Coincidencia del cert-id | luvameta-cert-id coincide exactamente con el cert_id del certificado en proceso. Sensible a mayúsculas. | PASS | FAIL — detener |
| V4 | Coincidencia del issued-by | luvameta-issued-by coincide exactamente con issued_by del certificado. Debe incluir protocolo https://. | PASS | FAIL — detener |
| V5 | Coincidencia del challenge | luvameta-challenge coincide exactamente con el challenge generado por el portal. Sin tolerancia de diferencia. | PASS | FAIL — detener |
| V6 | Validez del hash SHA-256 | El auditor recalcula SHA-256(challenge) y compara con luvameta-hash. Los 64 caracteres deben ser idénticos. | PASS | FAIL mayor |
| V7 | Coherencia del record | luvameta-record es la URL del JSON del certificado. La URL debe resolver con HTTP 200 y devolver el JSON correcto. | PASS | FAIL |
| V8 | Codificación y formato del archivo | El archivo usa UTF-8. El separador es ": ". No hay campos adicionales ni líneas en blanco entre campos. | PASS | WARN |
El protocolo DEBE ejecutar los puntos V1 a V7 en el orden definido. Si cualquier punto de V1 a V6 resulta FAIL, la verificación se detiene en ese punto. El punto V8 genera advertencia pero no detiene el proceso.
6. Vigencia del Archivo y Protocolo de Renovación
| Parámetro | Valor en Estándar LM v1.0 |
|---|---|
| Vigencia máxima | 180 días calendario desde la última verificación exitosa registrada por el portal. |
| Inicio de vigencia | La fecha en que el portal registra el resultado PASS de la verificación completa (V1 a V7). |
| Efecto del vencimiento | Un archivo vencido genera una Observación en la auditoría periódica aleatoria. Si en la próxima auditoría sigue vencido, genera No Conformidad Menor. El titular tiene 30 días para que el portal ejecute una reverificación exitosa. |
El archivo no necesita cambiar
La renovación de vigencia no requiere que la entidad modifique ni vuelva a publicar el archivo de verificación, siempre que el archivo existente siga siendo correcto. La vigencia se renueva con cada verificación exitosa que el portal registra, independientemente de si el archivo cambió o no.
7. Casos de Error y Protocolo de Respuesta
| Error | Punto afectado | Clasificación | Causa probable | Respuesta del portal |
|---|---|---|---|---|
| ERR-01 | V1 — Accesibilidad | FAIL MAYOR | El archivo no existe, el servidor devuelve 404, el dominio no resuelve o no hay HTTPS. | Notificar al solicitante. Otorgar 5 días hábiles. Si persiste: No Conformidad Mayor. |
| ERR-02 | V1 — Redirección | FAIL | El servidor redirige /.well-known/luvameta.txt a otra URL. | El archivo DEBE servirse directamente sin redirección. Notificar para corregir la configuración del servidor. |
| ERR-03 | V2 — Campos faltantes | FAIL MAYOR | Uno o más de los cinco campos requeridos no están presentes. | Notificar listando los campos ausentes. Otorgar 5 días hábiles. |
| ERR-04 | V3 — cert-id incorrecto | FAIL | El valor de luvameta-cert-id no coincide con el cert_id del certificado. | Verificar si la entidad tiene múltiples certificados. Notificar para corregir. |
| ERR-05 | V5 — Challenge incorrecto | FAIL MAYOR | El challenge en el archivo difiere del generado por el portal. | No se puede continuar. Regenerar el challenge si el anterior expiró. Notificar para republicar. |
| ERR-06 | V6 — Hash inválido | FAIL CRÍTICO | El hash en el archivo no coincide con SHA-256(challenge). Indica posible modificación. | FAIL irrecuperable sin republicación. El proceso debe reiniciarse desde la generación del challenge. |
| ERR-07 | V7 — Record inválido | FAIL | La URL de luvameta-record no resuelve o no devuelve el JSON del certificado correcto. | Verificar que el JSON esté publicado en la URL correcta. |
| ERR-08 | Vigencia — Archivo vencido | ADVERTENCIA | Han transcurrido más de 180 días desde la última verificación exitosa. | Ejecutar reverificación. Si resulta PASS: vigencia renovada. |
| ERR-09 | Plazo vencido sin corrección | ESCALADA | La entidad no corrigió el error dentro del plazo. | En fase de operación: el certificado pasa a SUSPENDED. En fase de investigación: el expediente pasa a SUSPENDIDO. |
8. Verificación por Sistemas Externos
El protocolo está diseñado para ser ejecutable por sistemas externos —motores de búsqueda, agentes de IA, herramientas de análisis— sin acceso interno al portal territorial.
| Qué puede verificar | Cómo lo verifica |
|---|---|
| Existencia del certificado | Accediendo a la URL del registro JSON del portal: https://[portal]/certificados/[cert-id].json |
| Control del dominio | Accediendo a https://[dominio]/.well-known/luvameta.txt y verificando que luvameta-cert-id coincide con el cert_id del JSON. |
| Integridad del challenge | Recalculando SHA-256(luvameta-challenge) y comparando con luvameta-hash. No requiere conocer el challenge previo — está todo en el archivo. |
| Identidad del emisor | Verificando que luvameta-issued-by coincide con issued_by del JSON y que esa URL pertenece al ecosistema luvameta.com. |
| Coherencia cruzada | Comparando el cert_id, issued_by y el hash entre el archivo /.well-known/ y el JSON del certificado. Si coinciden y el hash es válido: el sistema es coherente. |
Algoritmo de verificación para sistemas externos
ALGORITMO: Verificación externa de certificado LM
ENTRADA: URL del dominio a verificar (ej: "https://ejemplo.com")
PASO 1: Obtener el archivo de verificación
GET {dominio}/.well-known/luvameta.txt
Si HTTP != 200 → RESULTADO: NO VERIFICABLE
PASO 2: Parsear el archivo
Extraer: cert_id, issued_by, challenge, hash, record
Si algún campo falta → RESULTADO: ARCHIVO INCOMPLETO
PASO 3: Verificar integridad criptográfica
hash_calculado = SHA-256(challenge)
Si hash_calculado != hash → RESULTADO: HASH INVÁLIDO
PASO 4: Obtener el JSON del certificado
GET {record}
Si HTTP != 200 → RESULTADO: REGISTRO NO ACCESIBLE
PASO 5: Verificar coherencia cruzada
Si json.cert_id != cert_id → RESULTADO: INCONSISTENCIA
Si json.issued_by != issued_by → RESULTADO: INCONSISTENCIA
Si json.status != "ACTIVE" → RESULTADO: CERTIFICADO NO ACTIVO
PASO 6: Verificar autoridad raíz
Si json.root_authority != "https://luvameta.com"
→ RESULTADO: AUTORIDAD INVÁLIDA
RESULTADO FINAL: CERTIFICADO VÁLIDO Y VERIFICADO
El dominio está certificado por el Estándar LM.
La entidad que lo opera tiene identidad verificada.
El control técnico del dominio está demostrado.
9. Relación con Otros Estándares y Protocolos
| Estándar / Protocolo | Relación | Cómo interactúan |
|---|---|---|
| RFC 8615 — Well-Known URIs | Base técnica | El Estándar LM usa la ruta /.well-known/ definida por el RFC 8615. El archivo luvameta.txt es un Well-Known URI registrado dentro de ese estándar. |
| HTTPS / TLS | Prerequisito | El protocolo de verificación DEBE ejecutarse sobre HTTPS. HTTP no es aceptado. El certificado TLS del dominio debe ser válido al momento de la verificación. |
| SHA-256 | Algoritmo de hash | El mismo algoritmo usado por TLS, Let's Encrypt y la mayoría de los sistemas de verificación modernos. |
| Let's Encrypt / ACME | Mecanismo análogo | El mecanismo ACME http-01 challenge usa el mismo principio: publicar un archivo en una ruta específica para demostrar control del dominio. |
| Google Search Console | Mecanismo análogo | La verificación de propiedad de dominio usa el mismo principio. El protocolo LM puede coexistir en el mismo servidor sin conflicto. |
10. Control del Documento
| Versión | Fecha | Descripción | Autorizado por |
|---|---|---|---|
| 1.0 | 2026 | Versión inicial. Define el protocolo completo: estructura del challenge, algoritmo de hash, especificación del archivo .well-known/, flujo de verificación con 8 puntos, 9 casos de error documentados, algoritmo de verificación para sistemas externos y relación con estándares existentes. | Nodo Raíz |