Cómo funciona NotifiCert
Qué certifica exactamente, cómo funciona la cadena de hash que hace que un certificado no se pueda alterar sin que se note, y qué respaldo legal tiene esto en Chile, Argentina y Colombia.
Qué certifica exactamente, cómo funciona la cadena de hash que hace que un certificado no se pueda alterar sin que se note, y qué respaldo legal tiene esto en Chile, Argentina y Colombia.
| Capacidad | Correo normal | NotifiCert | Carta certificada postal |
|---|---|---|---|
| Prueba de contenido exacto | hash SHA-256 | Depende del sobre/copia | |
| Prueba de envío | timbre de correos | ||
| Prueba de entrega | SMTP | firma de recepción | |
| Verificable por un tercero | /verify | Solo con el operador postal | |
| Costo y tiempo | Gratis, instantáneo | Bajo costo, instantáneo | Alto costo, días |
Piénsalo como una carta certificada, pero para correo electrónico: cuando envías una notificación, NotifiCert no se limita a "mandar el correo" — va dejando un registro paso a paso de lo que efectivamente ocurrió, y ese registro queda sellado de forma que no se pueda editar después sin que se note (más abajo se explica cómo). Son tres hechos concretos, ni uno más:
| 1. Contenido | Apenas se crea la notificación, se calcula el hash SHA-256 del asunto, el mensaje y cualquier adjunto — es decir, se saca su "huella digital" exacta en ese instante. Esa huella queda guardada junto con la notificación. Si alguien, en cualquier momento futuro, quisiera decir "el correo en realidad decía otra cosa", basta con recalcular el hash del texto que se está mostrando y compararlo con el guardado: si no coinciden exactamente, se sabe que algo se alteró. |
| 2. Envío | El sistema que efectivamente transmite el correo por internet confirma que lo recibió y lo aceptó para enviarlo, entregando un identificador único de ese envío (un Message-ID). Es la prueba de que el mensaje salió de verdad, no solo que quedó "guardado como borrador". |
| 3. Entrega | El servidor de correo del destinatario (Gmail, Outlook, el servidor de su empresa, etc.) confirma por el protocolo estándar de correo (SMTP) que recibió el mensaje y lo aceptó en la casilla — la respuesta técnica es un código "250 OK". Es el equivalente electrónico exacto a que una carta certificada llegue físicamente al buzón del destinatario. |
Un hash SHA-256 es como una huella digital única e irrepetible para cualquier tipo de dato o archivo (un texto, un documento, una imagen o todo un programa). La sigla viene de Secure Hash Algorithm (Algoritmo de Hashing Seguro), y el "256" se debe a que siempre genera un resultado de largo fijo: 256 bits, que en texto se ve como una cadena de 64 caracteres de números y letras — sin importar si la entrada es una palabra o un archivo de varios megabytes.
¿Cómo funciona en la práctica? Imagina que le metes a una licuadora matemática cualquier texto o archivo. La licuadora siempre te devuelve una cadena de texto del mismo largo:
Entrada: "Hola mundo" SHA-256: 6a28723f124439c3... (64 caracteres en total)
Si le cambias solo un punto o una letra a la entrada, el resultado cambia por completo:
Entrada: "hola mundo" (con 'h' minúscula) SHA-256: 734f5d2e742e9e62... (completamente diferente)
Las 4 propiedades clave del SHA-256:
| Es unidireccional | Es facilísimo calcular el hash a partir de los datos, pero es prácticamente imposible hacer el proceso inverso — obtener el archivo original a partir solo del hash. |
| Es determinista | Si le das la misma entrada exacta 1000 veces, siempre genera exactamente el mismo hash. |
| Efecto avalancha | Un cambio mínimo en los datos (una letra, un espacio, un bit) produce un cambio radical y total en la huella final. |
| Resistente a colisiones | No existen dos archivos o textos diferentes conocidos que produzcan exactamente el mismo hash SHA-256. |
¿Para qué se usa en la industria? No es una tecnología inventada para NotifiCert — es un estándar usado en todas partes:
| Verificar integridad de archivos | Cuando descargas un programa pesado o una actualización, el desarrollador publica el hash SHA-256 oficial. Tú calculas el hash del archivo que descargaste; si coincide, sabes que se descargó completo y sin alteraciones. |
| Criptomonedas y blockchain | Es el algoritmo central que usa Bitcoin tanto para encadenar bloques de transacciones como en el proceso de minería — la misma idea de "cadena de eslabones sellados" que usa NotifiCert para encadenar eventos. |
| Contraseñas | Los sistemas serios no guardan tu contraseña en texto plano, guardan su hash. Cuando inicias sesión, el sistema convierte lo que escribiste a hash y compara si coincide con el guardado — así nunca queda tu contraseña real almacenada en ningún lado. |
Cómo se aplica esto en NotifiCert. Cada notificación certificada genera una secuencia de eventos (creación, envío, entrega...). Cada evento se guarda con un hash SHA-256 que se calcula sobre sus propios datos + el hash del evento anterior — igual que un bloque en una blockchain enlaza con el bloque anterior.
Es como una cadena de eslabones: cada eslabón nuevo se fabrica agarrando el anterior y soldándolo. Si alguien intentara cambiar un evento en el medio de la cadena — la fecha, el resultado de una entrega, lo que sea — el efecto avalancha haría que su hash cambiara por completo, y como el siguiente evento fue calculado incluyendo el hash original (el de antes de la alteración), la cadena completa a partir de ese punto dejaría de calzar. No hay forma de "arreglar" solo un eslabón sin que se detecte — habría que recalcular toda la cadena hacia adelante, y eso es exactamente lo que la verificación pública detecta.
Esto no es solo una explicación — cuando escaneas el código QR del
certificado o entras a /verify/<id>, el sistema recalcula los hashes
desde cero a partir de los datos guardados y confirma que coinciden. No es una
comparación visual ni un ícono decorativo: es la verificación criptográfica ejecutándose en ese
momento.
¿Y si el certificado dice "cadena inválida"? Baja al FAQ para esa pregunta.
La cadena de hash de arriba prueba algo importante: que nadie alteró los datos después de guardados. Pero hay una pregunta que la cadena por sí sola no responde: ¿cómo sabes que confiar en el reloj y en los registros de NotifiCert es suficiente, sin depender solo de la palabra de NotifiCert? Para eso existe el sello de tiempo (TSA — Time-Stamp Authority): un tercero completamente independiente que certifica la fecha y hora, sin que NotifiCert esté involucrado en esa parte.
La analogía más simple: un notario y un sobre sellado. Imagina que le llevas un papel a un notario. El notario le pone un timbre con la fecha de hoy y te lo devuelve. El notario no se queda con una copia para que mañana vengas a preguntarle "¿qué fecha le pusiste a mi papel?" — el timbre que ya tienes en la mano es la prueba completa. Cualquiera puede mirar ese timbre después y confirmar, por su cuenta, que es un timbre auténtico de ese notario (no falsificado) y qué fecha dice — sin tener que ir a buscarlo.
Así funciona en NotifiCert:
| 1. Se arma el certificado | Al llegar la notificación a un estado final (entregada, fallida, etc.), NotifiCert genera el PDF del certificado, que incluye impresa toda la cadena de eventos y su hash final — la huella digital de todo lo que pasó hasta ese momento. |
| 2. Se manda a sellar el documento | Se envía la huella de ese PDF (no el contenido: la autoridad nunca ve el documento) a una autoridad de sellado de tiempo independiente y reconocida internacionalmente, una de las más conocidas del rubro. |
| 3. El sello queda dentro del PDF | La autoridad devuelve un sello firmado con la fecha y hora, que se incrusta en el propio PDF como una firma del documento (estándar PAdES) — como el timbre del notario, pero estampado en el papel mismo. Al abrir el archivo en un lector como Adobe Acrobat, el sello aparece solo, en el panel de firmas. |
| 4. Se puede verificar sin pedirle nada a nadie | Para comprobar el sello más adelante, no hay que consultarle nada a esa autoridad ni a NotifiCert: cualquier lector o validador de PDF con soporte PAdES abre el archivo y dice si la firma es auténtica, de qué fecha es, y si el documento fue modificado aunque sea en un byte después del sello — usando matemática pública que cualquiera puede consultar libremente, para siempre. |
| Un solo sello, no dos | Como la cadena de eventos y su hash final están impresos dentro del documento sellado, sellar el PDF ya prueba también que esa cadena existía tal cual a esa fecha. No hace falta un segundo sello sobre el hash por separado para probar lo mismo. |
¿Para qué sirve esto si ya existe la cadena de hash? La cadena prueba que los datos no cambiaron entre ellos; el sello de tiempo prueba la fecha ante alguien que no confía únicamente en el reloj de NotifiCert — un respaldo independiente adicional, no un reemplazo de la cadena.
Es importante aclarar de entrada qué problema legal resuelve NotifiCert, en cualquier país: probar que se notificó algo a alguien — el equivalente electrónico de una carta certificada. No es una herramienta de firma electrónica de contratos (ese es un marco legal distinto, con sus propias reglas, y no es lo que este producto hace).
El respaldo jurídico concreto depende de la jurisdicción. Elige un país para ver el detalle:
Validez general de las comunicaciones electrónicas. La Ley N° 19.799 (2002) establece que los actos y contratos otorgados por medios electrónicos son válidos de la misma forma y producen los mismos efectos que los otorgados por escrito en papel — el principio de equivalencia funcional. Esto respalda que una comunicación mandada por correo electrónico no es "menos válida" solo por ser electrónica.
Un ejemplo concreto y directamente aplicable: seguros. El Código de Comercio (Título VIII, sobre el contrato de seguro, modificado por la Ley N° 20.667) es la base de las pólizas estandarizadas que regula la CMF (Comisión para el Mercado Financiero). Bajo ese marco, las aseguradoras ya notifican habitualmente por correo electrónico — por ejemplo, un aviso de no pago o de término de vigencia de una póliza — cuando así se pacta en las condiciones de la póliza, exigiéndose carta certificada solo como respaldo si el correo falla, el asegurado no tiene uno registrado, o se opone expresamente a ese canal. Es exactamente el caso de uso que resuelve NotifiCert: si el canal de notificación ya está pactado (en la póliza, en el contrato, en los términos del servicio), lo que hace falta es poder probar que se envió y se entregó — que es justamente lo que certifica la cadena de eventos.
Valor de la evidencia en un eventual juicio. Sin una firma electrónica avanzada (que este producto no usa ni pretende reemplazar), el registro que genera NotifiCert funciona como un instrumento privado según las reglas generales (Código Civil, art. 1702): tiene valor probatorio, pero formalmente puede requerir ser reconocido por la contraparte o corroborarse con otros medios si se disputa. Ahí es donde aporta la cadena de hash verificable y los metadatos técnicos (registro MX, encabezados, respuesta SMTP del servidor destinatario): son corroboración técnica difícil de fabricar, que refuerza el valor de ese instrumento privado como evidencia — no reemplazan una firma avanzada, pero tampoco la necesitan para este propósito.
Excepción: notificaciones dirigidas al Estado. Todo lo anterior aplica a relaciones privadas (una empresa notificando a un cliente, por ejemplo). Las notificaciones dentro de un procedimiento administrativo del Estado se rigen por la Ley N° 19.880, que exige medios específicos (personal, carta certificada, u otros que la propia ley habilite) — la Contraloría ha señalado que la validez general de la Ley 19.799 no basta por sí sola para reemplazar esas reglas especiales. Si necesitas notificar algo a un organismo público (o que un organismo público te notifique) en el marco de un procedimiento administrativo, ese es un contexto distinto y más restrictivo.
Referencias legales oficiales (Biblioteca del Congreso Nacional):
En la práctica, lo primero que hay que revisar no es la ley general sino el propio contrato, póliza o términos de servicio: si ese documento ya acepta el correo electrónico como canal válido de notificación (como en el ejemplo de seguros), NotifiCert aporta la prueba de que ese canal efectivamente se usó y funcionó. Si el contrato no dice nada al respecto, conviene revisarlo con un abogado antes de depender solo de esto para una notificación legalmente sensible.
Validez general de las comunicaciones electrónicas. El Código Civil y Comercial de la Nación (arts. 286 y 288) reconoce que la expresión escrita puede constar en cualquier soporte, incluido el electrónico, siempre que su contenido sea representado con texto inteligible. Junto con la Ley N° 25.506 de Firma Digital (2001), que da a la firma digital el mismo valor que la firma manuscrita cuando la ley exige firma, esto respalda que una comunicación electrónica no es "menos válida" solo por serlo.
Un ejemplo concreto: seguros y relaciones de consumo. Es habitual que pólizas y contratos de consumo pacten el correo electrónico como canal de aviso (vencimiento, falta de pago, cambio de condiciones) cuando el asegurado o consumidor lo aceptó al contratar. La propia Superintendencia de Seguros de la Nación (SSN) ha ido incorporando canales electrónicos para sus propias notificaciones a través de la plataforma de Trámites a Distancia (TAD), lo que refuerza la tendencia regulatoria hacia el correo electrónico como canal de notificación válido. Igual que en Chile: si el canal ya está pactado en la póliza o en los términos del servicio, lo que hace falta es poder probar que efectivamente se envió y se entregó — que es justo lo que certifica la cadena de eventos.
Valor de la evidencia en un eventual juicio. Sin firma digital, el registro que genera NotifiCert funciona como un instrumento particular no firmado. El art. 319 del Código Civil y Comercial establece que su valor probatorio lo pondera el juez considerando, entre otras pautas, "la confiabilidad de los soportes utilizados y de los procedimientos técnicos que se apliquen" — ahí es exactamente donde aporta la cadena de hash verificable y los metadatos técnicos del envío (registro MX, encabezados, respuesta SMTP), como corroboración técnica difícil de fabricar.
Un dato a favor: la Justicia argentina ya notifica así. Desde la Ley N° 26.685 (2011), que autorizó el expediente y las notificaciones electrónicas en el Poder Judicial de la Nación con la misma eficacia jurídica y valor probatorio que sus equivalentes convencionales, el propio sistema judicial confía en el domicilio electrónico como canal fehaciente de notificación.
Excepción: notificaciones dirigidas al Estado. Todo lo anterior aplica a relaciones privadas. Las notificaciones dentro de un procedimiento administrativo se rigen por la Ley N° 19.549 de Procedimientos Administrativos y su reglamentación — un régimen con reglas propias, distinto del uso privado descrito arriba.
Referencias legales oficiales:
En la práctica, igual que en Chile: revisa primero el propio contrato, póliza o términos de servicio. Si ya aceptan el correo electrónico como canal de notificación, NotifiCert aporta la prueba de que ese canal se usó correctamente.
Validez general de las comunicaciones electrónicas. La Ley 527 de 1999 regula el comercio electrónico y los mensajes de datos — que incluyen expresamente al correo electrónico — y consagra el principio de equivalencia funcional: un mensaje de datos tiene la misma validez jurídica que un documento en papel, y el art. 10 le reconoce la misma fuerza probatoria. Esto respalda que una comunicación enviada por correo electrónico no es "menos válida" solo por serlo.
Un ejemplo concreto: pólizas y contratos. Es habitual que las pólizas de seguro y los contratos comerciales pacten el correo electrónico como canal de aviso (renovación, no pago, cambio de condiciones) cuando el tomador lo aceptó al contratar. Igual que en Chile y Argentina: si el canal ya está pactado en la póliza o en los términos del servicio, lo que hace falta es poder probar que efectivamente se envió y se entregó — que es justo lo que certifica la cadena de eventos de NotifiCert.
Valor de la evidencia en un eventual juicio. El Código General del Proceso (Ley 1564 de 2012, art. 243) incluye expresamente los mensajes de datos dentro de la definición de documento, y les aplica las reglas generales de valoración de la prueba documental. Ahí es donde aporta la cadena de hash verificable y los metadatos técnicos del envío (registro MX, encabezados, respuesta SMTP) como corroboración técnica difícil de fabricar.
Un dato a favor: la Justicia colombiana ya notifica así. Desde la Ley 2213 de 2022 (que adoptó como legislación permanente el Decreto Legislativo 806 de 2020), la notificación personal en los procesos judiciales se hace, como regla general, enviando la providencia como mensaje de datos a la dirección electrónica suministrada — el propio sistema judicial confía en el correo electrónico como canal de notificación fehaciente.
Excepción: notificaciones dirigidas al Estado. Todo lo anterior aplica a relaciones privadas. Las notificaciones dentro de un procedimiento administrativo se rigen por el Código de Procedimiento Administrativo y de lo Contencioso Administrativo (Ley 1437 de 2011, art. 56), que exige que el administrado haya aceptado previamente el medio electrónico — un requisito adicional que no aplica a las relaciones privadas descritas arriba.
Referencias legales oficiales:
En la práctica, igual que en Chile y Argentina: revisa primero el propio contrato, póliza o términos de servicio. Si ya aceptan el correo electrónico como canal de notificación, NotifiCert aporta la prueba de que ese canal se usó correctamente.
No afecta la certificación. NotifiCert certifica entrega (que el servidor de correo del destinatario aceptó el mensaje), no lectura. Es el mismo principio que una carta certificada: si no vas a buscarla al correo, igual quedó constancia de que fue entregada a tu domicilio/casilla.
El certificado seguirá diciendo "entregado", porque técnicamente eso es lo que pasó — el servidor del destinatario aceptó el mensaje. Que el filtro antispam lo mueva de carpeta después es una decisión que toma ese servidor y que nunca se le informa de vuelta al remitente (por diseño de todo el ecosistema de correo, para no ayudar a spammers a evadir filtros). Por eso el certificado incluye una nota aclarando que "entregado" no garantiza bandeja principal.
La causa más común de esto es enviar "desde" un dominio que no controlas (por ejemplo, configurar tu remitente como una dirección @gmail.com sin ser Gmail el que envía). La solución real es autenticar tu propio dominio en el proveedor de envío (SPF/DKIM).
Escanea el código QR del PDF, o entra directamente a /verify/<id>. Esa
página recalcula los hashes de toda la cadena de eventos a partir de los datos guardados
y confirma si coinciden — no es una comparación cosmética. Si alguna vez dice que no pudo
verificar la integridad, significa que los datos guardados no coinciden con lo esperado y
deberías contactar a quien emitió el certificado.
Puede aportarse como evidencia documental de que una comunicación se envió y se entregó. Legalmente funciona como un instrumento privado (Código Civil, art. 1702): tiene valor probatorio, pero formalmente puede requerir ser reconocido por la contraparte o corroborarse con otros medios si se disputa. Ahí es donde ayuda la cadena de hash verificable y los metadatos técnicos (MX, SMTP, encabezados) — son corroboración difícil de fabricar.
Lo más importante para tu caso concreto: revisa si el contrato, póliza o términos de servicio ya aceptan el correo electrónico como canal de notificación (como ocurre, por ejemplo, en pólizas de seguro reguladas por la CMF). Si es así, NotifiCert aporta la prueba de que ese canal se usó correctamente. Si no está contemplado, o es una notificación hacia un organismo público, consulta con un abogado antes de depender solo de esto.
Sí. Cada adjunto se guarda con su propio hash SHA-256, que queda registrado en el evento de creación de la cadena (así que participa de la misma verificación). Además, si es un PDF, se anexa completo al final del certificado — puedes ver exactamente qué archivo se mandó, no solo su nombre.
Sí — cada fila del envío masivo genera una notificación certificada completa e independiente, con su propio PDF personalizado (con las variables ya reemplazadas), su propia cadena de hash y su propio certificado. No es un envío "genérico": cada destinatario tiene evidencia propia y verificable.
El contenido, los eventos y los adjuntos se guardan en la base de datos del servidor que corre NotifiCert. En un despliegue sin volumen persistente (por ejemplo, el plan gratuito de algunos hosts), esos datos pueden perderse si el servidor se reinicia — es una limitación de infraestructura, no del diseño del producto, y se resuelve agregando persistencia real (Postgres + almacenamiento de adjuntos) antes de usarlo en producción.
Técnicamente sí en cualquier país (es solo un envío de correo), y el respaldo legal descrito en la sección de marco legal ya cubre Chile, Argentina y Colombia. Para el resto de los países no hemos evaluado ni adaptado el marco legal local — otros tienen sus propios regímenes (eIDAS en la UE, ESIGN/UETA en EE.UU., etc.) que conviene revisar antes de depender de esto para una notificación legalmente sensible fuera de esos tres países.