Retainer de soporte: paquete renovación certificado SSL/TLS (con IA)

En un retainer de soporte, al cliente le da igual que Let's Encrypt “renueve solo”—hasta el martes a las nueve, cuando Chrome muestra NET::ERR_CERT_DATE_INVALID y comercial está en una demo. La caducidad del certificado es predecible, pero se come horas del retainer si nadie tiene el calendario, desapareció el TXT de validación DNS o el balanceador sigue sirviendo la cadena del año pasado.

Este pack es para autónomos y agencias pequeñas que ya hacen la revisión mensual del retainer y saben montar una ventana de mantenimiento programado. No es el pack de incidente urgente P1 (aunque una renovación fallida puede derivar en uno) ni una escalación a proveedor salvo que el certificado lo gestione un SaaS al que no tienes acceso. Es la vía proactiva: caducidad cerca o renovación en curso, con comunicación escrita al cliente y plan de rollback si la nueva cadena no valida.

Cuándo usar este pack

Úsalo cuando todas estas condiciones se cumplan:

• El retainer está activo e incluye soporte de infraestructura o aplicación con acceso (panel, CDN, proxy inverso, pipeline).
• El certificado está dentro de la ventana de renovación (habitual: 30 días en CAs públicas; antes si el cliente exige control de cambios).
• Necesitas trazabilidad visible: qué cambia, cuándo, quién aprueba y cómo verificarás el éxito.
• La renovación afecta hostnames de producción (web, app, API, webhooks).

Si el certificado ya expiró y paró el negocio, triage como incidente urgente y vuelve aquí para evitar recurrencia. Si piden migración de dominio nueva, trátalo como solicitud de cambio con alcance aparte.

Qué vas a entregar

1. Brief de renovación TLS en Google Docs (una página): hostnames, emisor, fecha de caducidad, método de validación, ventana, trigger de rollback.
2. Memo de triage con ChatGPT separando HECHO vs SUPOSICIÓN sobre cadena, SANs y auto-renovación.
3. Secuencia de tres emails en Gmail: aviso, recordatorio de ventana, resumen post-renovación.
4. Fila en la revisión mensual con fechas de caducidad para alimentar renovaciones de contrato.

Paso 1 — Inventario de hechos antes de tocar producción

Pega un snapshot estructurado en ChatGPT (sin secretos—redacta claves privadas e IDs):

Eres mi asistente de ops en retainer. Separa HECHO vs SUPOSICIÓN.

HECHOS:
- Hostnames: …
- Caducidad (UTC): …
- Emisor / CA: …
- Terminación: (CDN / LB / origen / ingress K8s)
- Último método: (HTTP-01 / DNS-01 / subida manual)

SUPOSICIONES a cuestionar:
- Sigue corriendo auto-renovación
- Todos los SAN cubiertos
- Cadena intermedia en cada salto

Salida: riesgos ordenados, preguntas al cliente, plan de 5 líneas.

Guarda la salida en el Brief bajo Triage. Si hay muchas SUPOSICIONES, la siguiente hora facturable es descubrimiento, no pulsar Renovar.

Paso 2 — Brief de una página (Google Docs)

Sección	Contenido
Alcance	Hostnames + entornos (prod vs staging)
Estado actual	Caducidad, emisor, huella (opcional)
Ventana	Zona horaria local + duración
Validación	Registros DNS, ruta HTTP o portal
Rollback	¿Cert anterior disponible? ¿Backup LB?
Verificación	Checkers externos + smoke tests
Comms	Quién recibe Gmail #1–3

Enlaza el doc en el ticket para no reabrir tickets crónicos duplicados cada trimestre.

Paso 3 — Cadencia Gmail (plantillas)

Email 1 — Aviso (7–14 días antes)

Asunto: [Cliente] Renovación certificado TLS planificada — [ventana]

Cuerpo: hostnames, por qué es rutinario, enlace al Brief, confirmación DNS/contacto si es DNS-01.

Email 2 — Recordatorio (24 h antes)

Asunto: [Cliente] Recordatorio: renovación cert mañana [hora TZ]

Cuerpo: hora exacta, impacto esperado (normalmente ninguno), contacto para abortar.

Email 3 — Todo claro (tras verificación)

Asunto: [Cliente] Renovación TLS completada — verificación adjunta

Cuerpo: nueva caducidad, resumen de checkers, dónde queda el Brief para auditoría.

Envía siempre un humano—la IA redacta, tú revisas nombres de host.

Paso 4 — Ejecutar con trigger de rollback

Durante la ventana:

1. Snapshot del cert + cadena actual.
2. Renovar o reemitir en la CA; completar validación DNS/HTTP.
3. Instalar cadena completa en cada punto de terminación.
4. Checkers externos y prueba en navegador por hostname.
5. Observar logs 60 minutos—webhooks y apps móviles cachean más que el navegador.

Rollback: checker en rojo, hostname incorrecto o pico 5xx/TLS → revertir cert, email corto de incidente, ticket de seguimiento.

Paso 5 — Fila en la revisión mensual

Mes	Hostname	Nueva caducidad	Incidentes	Notas
…	app.cliente.com	…	0	¿Auto-renovación? S/N

Esa fila alimenta conversaciones de renovación del retainer con prueba de que reduces riesgo predecible.

Trampas habituales

• Staging olvidado: prod renovado, staging caduca y bloquea QA.
• DNS movido: cambiaron de proveedor y el TXT ACME no se actualizó.
• Varios saltos: origen renovado pero el CDN sirve cert viejo.
• Scope creep: piden subdominio nuevo—derivar a solicitud de cambio.

Checklist rápido

• Caducidades en monitor o calendario ≥30 días antes
• Brief firmado o ack por escrito
• Triage HECHO/SUPOSICIÓN guardado
• Cadena completa en todos los saltos
• Tres emails enviados por humano
• Log de revisión mensual actualizado

La caducidad TLS es aburrida hasta que cuesta dinero. En retainer, lo aburrido es el producto: renovación documentada mejor que héroes a medianoche cada trimestre.