La prueba es la clave, no su hash: renovar una licencia firmada sin migración

sh0 vende suscripciones mensuales y, hasta hace poco, emitía licencias perpetuas. Un mes a 19 $ compraba el plan Pro para siempre. La solución que a todos se les ocurre primero es «poner una fecha de caducidad en la clave», y eso hicimos: la licencia es un documento firmado con Ed25519 que lleva paid_through y expires_at. Después dejamos la funcionalidad desactivada, porque una clave con fecha y sin camino de renovación es peor que la fuga. Corta a un cliente el día 38 mientras Stripe sigue cobrándole tan tranquilo.

Este artículo trata de la mitad que faltaba: cómo un servidor que solo llama a casa una vez al día obtiene su clave renovada sin que nadie pegue nada, y por qué el diseño que sugería el prompt de la sesión se habría roto justo en el momento en que se necesitaba.

Las tres piezas

La renovación necesita tres cosas que no existían:

1. Un endpoint en el sitio web donde un servidor pueda obtener la clave vigente de una licencia que
2. posee.
3. Un manejador del webhook de Stripe para invoice.paid que vuelva a firmar la licencia para el
4. nuevo periodo.
5. Código en el binario de sh0 que obtenga, verifique y sustituya la clave almacenada.

Las piezas 2 y 3 son fontanería. La pieza 1 es donde vive la decisión de diseño, porque el endpoint sirve material de clave. El GET /api/licences/:id/status existente es público a propósito: no devuelve más que un estado, y un identificador de licencia viaja en claro en cada llamada diaria, así que quien se entere de uno no debe poder convertirlo en una clave.

El diseño que sugería el prompt, y por qué falla

El prompt escrito para esta sesión proponía la prueba de posesión obvia: el servidor ya guarda un SHA-256 de su clave, así que basta con enviar ese hash en una cabecera y dejar que el sitio lo compare con el hash de la clave que tiene registrada.

Recorramos una renovación con ese diseño. Día 30: Stripe renueva, el webhook vuelve a firmar la licencia y el sitio guarda ahora la clave N+1. Día 31: el servidor se despierta para su comprobación diaria con la clave N. Envía hash(N). El sitio calcula hash(N+1). No coinciden. 401. El servidor se queda con la clave N, que caduca el día 37, y el día 38 un cliente que paga pierde su plan.

El hash deja de coincidir exactamente en el instante para el que existe el endpoint. Arreglarlo obliga al sitio a recordar cada hash que haya emitido para una licencia, lo que supone una migración de Prisma y una tabla de historial. Una única columna de «hash anterior» tampoco basta: un servidor que estuvo desconectado durante dos ciclos de facturación tiene la clave N cuando el sitio tiene la N+2, y se queda fuera para siempre.

Lo que lo decidió: la clave en bruto ya estaba ahí

Al contrastar las afirmaciones del prompt con el código, una línea del manejador de activación zanjó la cuestión:

rust// Store raw key for cloud registration
let _ = sh0_db::Setting::set(&pool, "license_key_raw", &raw_key);

Escrita hace meses para una funcionalidad que nunca la volvió a leer. Todos los servidores activados en producción tienen su clave en bruto en disco. Así que la prueba de posesión puede ser la propia clave: el servidor envía su documento firmado vigente como token bearer, y el sitio verifica su propia firma Ed25519 sobre él y comprueba que el licence_id que contiene coincide con la URL.

Esto no tiene estado. Ni migración, ni tabla de historial, y funciona con todos los servidores activados antes de que existiera el endpoint. Una clave emitida hace un año sigue siendo un documento que solo nosotros podríamos haber firmado, así que un servidor que se saltó doce renovaciones recibe exactamente el mismo trato que uno que pregunta cada día.

De ahí se derivan dos decisiones deliberadas. El sitio no comprueba la caducidad de la clave presentada, porque la clave se presenta precisamente porque está caducando. Y una licencia revocada recibe un 403 sin material de clave, porque el endpoint de estado ya se lo dijo al servidor y este endpoint no debe convertirse en una segunda opinión.

En la red, la clave viaja por TLS hacia el emisor que ya la tiene. El diseño basado en hash también habría enviado una credencial bearer, solo que más corta. No se sacrificó seguridad a cambio de simplicidad.

El lado del servidor tiene su propia trampa

La pasada diaria de sh0 cargaba la licencia activa. Eso es correcto para aplicar restricciones e incorrecto para renovar: la licencia que más necesita una clave renovada es la que el barrido de caducidad ya retiró. Un servidor desconectado durante todo su periodo de gracia, que volviera con una suscripción al día, se habría quedado en Free para siempre porque la pasada nunca miraba una fila caducada.

Ahora la pasada lee la licencia más reciente sea cual sea su estado, la retira si ha caducado, intenta la renovación y solo entonces pregunta por la revocación. Las filas revocadas y reemplazadas son definitivas y nunca se tocan.

Aceptar una clave obtenida sigue la misma regla que la activación: primero la firma, antes de leer nada del contenido. Después el identificador debe coincidir, y el documento debe haberse emitido estrictamente después del que tenemos. Esta última comprobación rechaza una respuesta reenviada y un fallo del sitio que vuelva a servir un documento más antiguo. Cada rechazo conserva la clave que tenemos, igual que cada fallo de red conserva el plan.

Tres pruebas de extremo a extremo ejecutan la pasada completa contra un pool SQLite en memoria y un stub HTTP local que firma con un par de claves efímero: una licencia caducada vuelve a estar activa con la nueva clave almacenada; un documento de otra licencia la deja retirada; una clave en bruto obsoleta dejada por una licencia anterior nunca se presenta.

Lo que no se publicó, y luego lo que lo demostró

La sesión que escribió las tres piezas terminó con el flag todavía desactivado. El prompt decía que se activara «solo cuando las tres piezas estén demostradas juntas», y la regla del registro es que «corregido en el código» no es un estado: un elemento está demostrado o está abierto. Tres piezas y una docena de pruebas en verde, ninguna ejecutada sobre un objetivo real, es exactamente la situación para la que existe esa regla. Así que la incidencia siguió abierta, con una línea Preuve due: que nombraba la observación, el objetivo y lo que faltaba.

Lo que faltaba era una build. La sesión siguiente, el mismo día, ejecutó la campaña en el orden que importa. Primero la release candidate se instaló en el servidor testigo, dejando intacta la release pública latest. Solo entonces se activó el flag en el sitio, para que ningún servidor en producción pudiera recibir una clave con fecha antes de tener el código para renovarla. Después se suscribió el webhook invoice.paid y se comprobó leyéndolo de vuelta.

El plan había dado por hecho un reloj de prueba de Stripe. No sobrevivió al contacto con la realidad: el sitio funciona con claves live, y el modo de prueba nunca llega hasta él. La campaña usó en su lugar el checkout real, con una suscripción de cero dólares, y forzó el siguiente ciclo de facturación adelantando unos minutos el fin del periodo de prueba. Stripe emitió una factura subscription_cycle real, se pagó a cero y se disparó invoice.paid.

El sitio volvió a firmar la licencia por sí solo: una clave nueva, distinta byte a byte de la primera, con fecha hasta el final del nuevo periodo más la semana de gracia. El servidor se reinició en lugar de dejarlo esperar un día hasta su siguiente pasada, y unos minutos después su log decía:

INFO sh0_api::licence: Licence renewed -- new key stored, no action was needed from anyone

El servidor tiene ahora el nuevo documento, y la clave en bruto en disco es la nueva clave, byte a byte. El contracaso se jugó con una segunda licencia: se canceló la suscripción, el sitio revocó la licencia en cuestión de segundos y, en su siguiente pasada, el servidor registró Licence revoked upstream -- Pro features stop, running applications are untouched y volvió a Free.

Hubo una cosa que la campaña no pudo jugar en real: una tarjeta que falla. Las tarjetas de prueba necesitan el modo de prueba, que el sitio no usa. Ese camino lo cubren la prueba del barrido de caducidad en otra incidencia y las pruebas unitarias, y el registro lo dice en lugar de fingir lo contrario.

La incidencia se cerró el día en que se redactó, sobre una observación con marca de tiempo, no sobre el código. El servidor testigo conserva su suscripción de cero dólares y sigue activado, así que el ciclo se ejercita ahora cada mes por el camino real. Ese es el sentido de la regla: el artículo que acabas de leer podría haber terminado en «el código está escrito», y habría sido la mitad menos interesante.