Resumen

  • MI.ACMEDelegationMethod permite a la CDN ascendente habilitar una solicitud delimitada, mientras la CDN descendente genera y conserva el par de claves.
  • El objeto de delegación, la validación de la CSR y la emisión de la CA acreditan pasos concretos; no acreditan que DNS apunte al parque previsto ni que todos los nodos sirvan el certificado y el objeto correctos.
  • La cancelación STAR y la revocación no-STAR tienen relojes distintos. La autorización, la emisión, el DNS, la instalación, TLS, HTTP y la terminación requieren recibos separados.

Una CDN puede tener un certificado impecable y seguir entregando mal el servicio. Un punto de presencia conserva la credencial anterior; otro almacenó la nueva, pero una regla SNI escoge la predeterminada; parte de Internet resuelve todavía el CNAME viejo; el nodo correcto termina TLS y devuelve un objeto ajeno por un fallo de caché. Ninguna de esas averías invalida por sí sola el certificado.

RFC 9538, estándar del IETF publicado en febrero de 2024, aborda un problema preciso. Cuando una CDN ascendente delega HTTPS mediante redirección DNS, la descendente necesita un certificado para el nombre del proveedor de contenido. Copiar una clave privada duradera ampliaría su exposición. El esquema enlaza CDNI con RFC 9115: la descendente crea la clave y el Identity Owner ascendente limita la solicitud.

Cuatro campos abren el camino

acme-delegation aporta la URL HTTPS del objeto asociado a la cuenta descendente; time-window, la ventana de validez. La presencia de lifetime selecciona certificados STAR breves y autorrenovados; su ausencia indica no-STAR. lifetime-adjust modifica la duración STAR. El tipo está en el registro CDNI de IANA, sobre los marcos de RFC 8006, RFC 8008 y RFC 7336.

No hay en esos campos inventario de extremos, confirmación de instalación, huella por región, observación DNS, prueba SNI ni verificación de contenido. Anunciar la delegación no equivale a tener la entrega lista.

La cuenta prueba permiso para pedir

RFC 9115 exige que el Name Delegation Consumer esté preregistrado. Con su clave de cuenta obtiene el objeto y una plantilla de CSR, genera su par de claves y presenta la petición. El Identity Owner verifica nombres y extensiones y usa su propia cuenta de CA para ejecutar ACME, RFC 8555.

La ventaja es que la clave duradera ascendente no entra en el parque descendente. La contrapartida es que la cuenta descendente se convierte en un control crítico: su autenticación y la política preconfigurada sustituyen el desafío ACME ordinario en ese tramo. Una CSR conforme prueba ajuste a la plantilla, no instalación ni servicio.

RFC 5280 cubre la ruta X.509, RFC 9525 la identidad del servicio, RFC 8446 TLS 1.3 y RFC 6066 SNI. Ayudan a aceptar la identidad presentada. No certifican la respuesta HTTP.

DNS conserva una palanca independiente

El objeto admite CNAME y RFC 9538 contempla que una actualización futura incorpore SVCB/HTTPS. El titular puede mantener el control exclusivo de la zona. CAA limita las CA y RFC 8557 puede restringir la cuenta y el método de validación. Son límites a la emisión, no pruebas de propagación o destino.

La operación necesita el cambio autoritativo, RRset y TTL exactos, observaciones desde varias redes y la correspondencia de cada dirección con el inventario. El certificado no contiene ese mapa.

STAR no termina como un certificado ordinario

RFC 8739 define STAR. La CDN ascendente cancela futuras renovaciones, pero el último certificado emitido conserva autoridad hasta caducar. Hay que registrar cancelación, última emisión, descarga, activación y expiración. En no-STAR se solicita revocación; la descendente, dueña de la clave, puede tener capacidad directa en una emergencia. La aceptación por la CA no elimina la configuración de cada nodo.

Certificate Transparency hace visible la emisión, no el despliegue o la retirada. Las recomendaciones TLS de RFC 9325 tampoco sustituyen una observación externa.

Siete pruebas útiles

El expediente debe separar: mandato del proveedor de contenido; cuenta y alcance; objeto de delegación y plantilla; CSR, clave y orden; certificado, SAN y cadena; DNS autoritativo y observado; inventario, huella activa y SNI; finalmente, sondas TLS y HTTP desde redes independientes. La renovación y la terminación recorren de nuevo la cadena.

“Emitido, no instalado”, “92 % de nodos convergentes” o “STAR cancelado; quedan 47 minutos de validez” orientan una decisión. Una luz verde llamada “seguro” borra información.

RFC 9538 no promete una prueba de extremo a extremo. El error aparece cuando el operador obliga a un artefacto de coordinación a representar la realidad en ejecución.

Fuentes y límites

El estado se consulta en la ficha del RFC Editor, el historial del IETF y los errata. Se usaron además los RFC 9538, 9115, 8739, 8555, 8006, 8008, 7336, 9460, 9325, 9525, 5280, 8659, 8557, 8446, 6066 y 9162. No se examinó una implantación o incidente de una CDN concreta.