Resumen

  • draft-ietf-acme-profiles-02 permite anunciar perfiles locales y asociar la selección a un Order; sigue siendo un Internet-Draft de estándares, no una RFC ni un catálogo global.
  • El nombre prueba que el servidor aceptó una selección. La elegibilidad de la cuenta, el control del identificador, los campos del certificado, la instalación y la confianza del cliente siguen siendo comprobaciones distintas.
  • La evidencia útil conserva la Directory y la descripción vigentes al crear el pedido, inspecciona el DER y observa qué certificado sirvió cada destino.

El panel muestra que el Order usó tlsserver. La petición ACME tenía una firma válida y el servidor devolvió el mismo nombre. Sin embargo, un balanceador conserva el certificado anterior, el nuevo incluye un EKU inesperado y una clase de clientes no puede construir la cadena.

No hay contradicción. El perfil pertenece al plano de política. Los demás hechos ocurren después.

draft-ietf-acme-profiles-02, fechado el 28 de agosto de 2026, es trabajo en curso del grupo ACME. Aborda un vacío de RFC 8555: las autoridades ofrecen varios tipos de certificado, pero el protocolo original no ofrece una superficie clara para descubrir y escoger esas políticas. La nota de implementación menciona dos servidores y siete clientes; Let’s Encrypt documenta uso en producción. Eso demuestra interés y código ejecutable, no una norma final ni un censo independiente.

Un selector con significado local

El servidor que permite seleccionar publica meta.profiles en su Directory. Cada nombre corto apunta a una explicación legible. El cliente puede enviar uno en el campo profile de newOrder; si se acepta, el Order lo repite.

El nombre vive en el espacio del servidor. classic, tlsserver, shortlived o profile1 no adquieren un significado universal. La URL tampoco está obligada a contener un esquema verificable de todas las extensiones; incluso puede ser una data URI. La cadena es una llave hacia la política local, no un sello portable.

Esta limitación hace posible un estándar pequeño. El cliente expresa intención sin convertir la CSR en catálogo de producto. El servidor anuncia opciones sin una API paralela. El Order conserva la decisión hasta la finalización. No hace falta que IETF gobierne los productos y contratos de todas las CA.

Pero la operación debe guardar el contexto: endpoint de Directory, hash, hora, par TLS, bytes de la descripción y condiciones de la cuenta. Un log que dice solamente tlsserver conserva el identificador y pierde la definición.

La política sale de la CSR; la clave pública no

RFC 8555 recibe identificadores y una preferencia temporal al crear el Order, y una CSR al finalizar. Las CSR pueden transportar muchos campos X.509. Copiarlos sin una política fuerte amplía los riesgos de análisis y de emisión indebida.

Profiles coloca la elección en el Order. Para esa decisión, el borrador vuelve irrelevante el contenido de la CSR más allá de Subject Alternative Names y Subject Public Key. La CA aplica su plantilla en vez de adoptar las extensiones propuestas por el cliente.

No significa que toda la CSR desaparezca. La clave pública es esencial y los SAN deben corresponder a identificadores autorizados. La CA sigue obligada a construir, firmar, escoger cadena, cumplir políticas y registrar donde corresponda.

El protocolo define un control mínimo. La prueba de que funcionó está en los octetos que realmente firmó la CA.

Elegir y recibir un valor por defecto son actos distintos

Cuando el cliente manda un perfil, la petición firmada demuestra que la clave de la cuenta autorizó ese payload. El servidor todavía decide si la combinación es válida.

Si el cliente lo omite, el borrador recomienda al servidor escoger un perfil y asociarlo al Order. En esa ruta, el valor refleja una decisión del servidor, no una preferencia expresa del suscriptor.

Debe registrarse el origen de la selección, la versión del cliente, su configuración, la cuenta, la petición, la respuesta, la versión de política y quién podía cambiar cada lado. Así se distingue una adopción anticipada de un cambio de default aplicado a software sin modificar.

Los planes de Let’s Encrypt muestran la diferencia. Un perfil optativo permite probar la ausencia de un EKU o una duración menor antes de que cambie classic. Ambas rutas pueden ser correctas; no reparten igual la responsabilidad.

La cuenta puede ser elegible sin controlar el nombre

El servidor debe rechazar un perfil incompatible con el resto del pedido. El borrador cita un tipo de identificador inadecuado y una cuenta que no pertenece a la allowlist. Propone invalidProfile.

Esa decisión no es la autorización del identificador. Una cuenta empresarial puede tener acceso a un perfil privado y no haber probado el dominio. Completar DNS-01 o HTTP-01 no concede automáticamente un perfil restringido.

Conserve tres recibos: el fundamento de elegibilidad; la validación de cada identificador; la aceptación de la política de emisión. External Account Binding, contrato, pago, aprobación de incidente o lista de acceso sirven al primero. Los challenges sirven al segundo. El expediente de la CA y el certificado sirven al tercero.

Un Order se ve como una transacción, pero enlaza autoridades diferentes. La firma de la cuenta no es título sobre todos los nombres ni sobre todas las capacidades del certificado.

Lo no anunciado puede ser válido, pero no inexplicable

El servidor debería rechazar nombres que no anuncia, aunque el borrador admite excepciones. Menciona un perfil privado acordado fuera de banda y una sustitución durante una revocación masiva cuando el perfil original ya no se ofrece.

La excepción protege continuidad. También rompe la equivalencia entre “aparece en Directory” y “puede aceptarse”. La ausencia pública no prueba invalidez.

Para esos Orders hacen falta más datos: acuerdo o incidente, cuentas y nombres cubiertos, plazo, restricciones, aprobador, objetivo de reemplazo, retirada y prueba de que el camino no estaba abierto a cuentas ordinarias. Privado no significa abusivo; sin una autoridad trazable significa no auditable.

La retirada corre con dos relojes

El perfil puede desaparecer mientras existen Orders vivos. Si la CA ya no quiere emitir al llegar finalize, debe devolver invalidProfile. El borrador recomienda esperar a que caduquen los Orders antes de cortar la emisión.

El reloj de Directory rige lo que un nuevo cliente descubre. El reloj del Order empieza al crearlo y conserva su expiración y autorizaciones. La migración debe registrar publicación, último Order, vencimiento máximo, última emisión, renovaciones pendientes, alternativa y excepciones.

Sin esa contabilidad, el cliente recibe una negativa tardía y la atribuye a red, CSR o validación.

También puede cambiar el significado sin cambiar el nombre: duración, EKU, reutilización de autorización o cadena. Por eso se congela la definición por Order y se vuelve a verificar en cada renovación.

El certificado emitido es el objeto verificable

El Order es un compromiso de política. El DER es el resultado.

Un comprobador debe comparar SAN, tipos de identificador, algoritmo y parámetros de clave, Key Usage, Extended Key Usage, Basic Constraints, Certificate Policies, criticidad, validez, issuer, firma, cadena, serial, codificación, CT y campos prohibidos con un predicado versionado.

También debe vincular el certificado con Order, autorizaciones y clave de la CSR. De lo contrario, demuestra que un certificado satisface una política sin demostrar que pertenece a la operación analizada.

La descripción humana sirve para elegir, pero es débil para automatizar. La CA podría publicar un manifiesto verificable. Es una propuesta operativa de este artículo, no un requisito del borrador. Haría comprobable su promesa sin imponer un diccionario central.

La renovación repite el análisis. El nombre estable no garantiza la misma versión, cadena, validez o conjunto de extensiones. Validar sólo la respuesta ACME deja sin inspeccionar la credencial.

CT y CAA aportan otras observaciones

Certificate Transparency puede mostrar que un certificado o precertificado llegó a un log. No demuestra qué perfil eligió el suscriptor, si el DER coincide con él ni si se desplegó.

CAA puede limitar emisores y expresar sus propios parámetros. No selecciona el perfil ACME ni certifica sus campos.

Su fuerza reside en la independencia. Lo mismo vale para la ruta de confianza: la CA ofrece una cadena, pero un cliente puede construir otra según su almacén. El perfil no obliga la aceptación local.

Emitir no equivale a instalar

El certificado y su clave deben llegar al endpoint correcto. Balanceadores, regiones, almacenes de secretos, sidecars y procesos sin reiniciar producen despliegues parciales. Un job verde puede coexistir con tráfico que recibe lo anterior.

Vincule hash DER y hash de clave a cada destino. Observe desde fuera lo que se presenta. Compruebe SNI o identidad, cadena, activación y retirada del certificado antiguo. Después pruebe clientes representativos.

La secuencia es descubrir -> preservar -> seleccionar -> habilitar -> autorizar identificadores -> fijar Order -> finalizar -> inspeccionar -> desplegar -> observar -> renovar.

Cada paso puede ser correcto y el siguiente fallar. La interfaz debe exponer recibos enlazados, no un único semáforo.

La producción demuestra el valor de una migración escalonada

Let’s Encrypt describe el perfil como características del proceso de validación y del certificado. La mayoría puede usar selección automática; quien tenga requisitos concretos puede optar.

Para el EKU, tlsserver permitió retirar antes Client Authentication, luego cambió classic, y un tlsclient temporal dio margen. Para las duraciones, perfiles de 45 y seis días preceden cambios del default.

Es evidencia real de que se pueden separar prueba temprana, cambio general y compatibilidad limitada. También prueba que el nombre requiere fecha: validez, EKU, reutilización y disponibilidad cambian en calendarios diferentes.

No demuestra que toda migración tuvo éxito ni que todo cliente implementa todas las opciones. Describe una CA que usa el selector como superficie operativa.

Un recibo enlaza intención y resultado

El recibo debe unir Directory y documentación, origen de selección, cuenta y autoridad de configuración, identificadores, clave, elegibilidad, autorizaciones, Order y vencimiento, CSR, DER, serial, issuer, cadena, CT, resultado de conformidad, destinos, observación, pruebas de clientes, renovación, excepción y rollback.

“El Order devolvió el nombre” es observación. “El DER cumple la versión X” es prueba. “El endpoint sirvió ese DER” es otra observación. “El servicio logró su objetivo” es una conclusión posterior.

El protocolo puede seguir siendo mínimo mientras cada actor conserva las pruebas de su decisión. Un nombre no necesita convertirse en autoridad para ser útil.