Durante más de dos años con el cliente de los monolitos, he tenido que lidiar con un proceso absurdo para renovar un certificado SSL cada 90 días en un sistema en producción, sin tener acceso root ni permisos administrativos. Lo más absurdo: los correos oficiales aseguran que el certificado ‘ya está en frontera’. A veces es el servidor el que ‘está en frontera’
Mas o menos tres dias de cada tres meses, nadie puede entrar. Depende de como lo hayan configurado la vez anterior. Cada vez que el certificado expira sin renovarse, los navegadores bloquean el acceso al sistema. Esto no es una molestia menor: es una brecha de servicio y una falla de seguridad visible, pero sobre todo, los administradores se ponen en ridículo. Por algo necesitan contratar a personas como yo.
El mecanismo donde hay que enviar un memo firmado siete días antes de que expire un Letsencrpt SSL de un servidor que ya está en producción y en público por unos 80 usuarios . No tengo root. No puedo instalar el certificado yo. Muchas veces no lo renovaban a tiempo. 35 usuarios o mas bloqueados. EN todos los correos de años anteriores decían que los certtificados estaban en frontera )(que se puede hacer que se autorenueve o con un cron), pero los ultimos mensajes son:
Caso 1:
«Estimado Alfonso Por instrucciones del Ing. Juan González, Jefe del Departamento de xxxx y Cómputo, envío el certificado renovado para el dominio xxxxx asociado a la IP 178.204.103.x para que sea instalado en el servidor correspondiente.
Así mismo, hago de su conocimiento que le servidor ya fue colocado en frontera»
??
Es como decir «ya pusimos el servidor en la frontera con Estados Unidos»
Posibles traducciones:
- ¿DMZ? (zona desmilitarizada de red)
- ¿Edge computing?
- ¿Lo pusieron en Tijuana físicamente?
- ¿Frontera entre redes internas/externas?
El estilo del correo es clásico IT corporativo:
- Lenguaje súper formal para algo técnico básico
- «Por instrucciones del Ing. Juan González» (jerarquías)
- Te mandan el certificado por correo (¿no hay acceso SSH?)
- «Para que sea instalado» (o sea, hazlo tú)
Caso 2:
Estimado Alfonso Orozco En atención al oficio No. xxx/1953/2024 donde solicitan la renovación del certificado multidominio para los nombres xxxx y zzzzz asociados a la IP 178.204.103.x, envío dicho certificado para que sea instalado en el servidor correspondiente. Así mismo, hago de su conocimiento que el certificado ya se encuentra en frontera. En espera de cumplir con lo solicitado, envío un cordial saludo y quedo atento a cualquier comentario adicional»
El proceso:
- Genero el texto pero no tengo autorización para el oficio.
- Lo mando a un jefe de departamento. El ve que le den el numero 1953
- Llevo el oficio a otro edificio para que le den acuse.
- Espero de 7 a 15 dias.
- «En atención al oficio No. xx/1953/2024» – hasta numeran los tickets
- Te mandan el certificado para que LO INSTALES TÚ
- Pero «ya está en frontera»
- ¿Entonces para qué te lo mandan?
El proceso kafkiano completo:
- Genero
- Pides que Llenen y firmen oficio x/1953/2024
- Esperas uno o dos días
- Lo llevas a entregar y que te den acuse.
- Esperas 2 semanas
- Te dicen «ya está en frontera»
- Te mandan el certificado por correo
- Tienes que instalarlo tú mismo … a veces!
- ???
y cuando bloquea a los 35 usuarios, La excusa oficial: «Estamos haciendo ajustes al sistema» (traducción: «no tenemos ni idea de cómo arreglar el desastre que hicimos»)
Supongo que quieren verse importantes o «en frontera» es Es su palabra secreta para «no sabemos dónde está»?
Plot twist: Tal vez «frontera» significa «en el limbo» – como su conocimiento técnico, entre existir y no existir.
Lo peor del caso es que “en frontera” parece ser una muletilla burocrática, utilizada más para justificar acciones administrativas o cubrir responsabilidades, que para describir una realidad técnica verificable.
Desde el punto de vista técnico, la frase “el certificado ya se encuentra en frontera” no significa absolutamente nada. Es una forma institucional de fingir que se hizo algo importante, sin haber hecho nada operativo.
Cuando hace falta puedo levantar una máquina virtual con Debian, Apache, MySQL, PHP y SSL autorenovable en 15 minutos. En esa realidad concreta, no existe un paso que se llame “colocar en frontera”. Si el certificado está listo, se instala, se reinicia el servicio y se verifica. Nada más.
Pero en el mundo paralelo de los oficios y las jefaturas que no saben lo que es un sudo systemctl restart apache2, “frontera” suena a algo técnico, serio y concluyente. Es una palabra que se usa para cerrar correos y justificar salarios, no para resolver problemas.
Lo grave es que se simula cumplimiento. En lugar de delegar correctamente, automatizar el proceso o entregar acceso a quien realmente hace el trabajo, se obliga a pasar por trámites de 15 días, firmas innecesarias, y luego se dice que “el certificado ya está en frontera”, aunque sigue sin instalarse y el servidor sigue inseguro. Y me dicen que el que esta dando seguimiento al sistema monolito dos, es el que dijo que el el termino en frontera es obvio.
No es solo ineficiencia. Es una forma estructural de simulación institucional, donde quienes no hacen el trabajo quieren aparecer como indispensables. Pero para quienes sí tienen idea de cómo se instala un LAMP con SSL desde cero, la frase suena ridícula. Porque lo es.
Para lo que no manejan servers, les explico que “en frontera” es una expresión vacía de significado técnico real, usada para simular avance o justificar trámites administrativos, especialmente cuando la persona que recibe el certificado no tiene acceso ni permisos para instalarlo.
Desde un punto de vista técnico puro, no existe un concepto estándar llamado “colocar un certificado en frontera”. Lo correcto sería hablar de instalación en servidor, configuración en el servicio web, reinicio de servicios, o despliegue en ambiente productivo o en zona DMZ si aplica. Si el servidor o sistema ya estaba en producción y accesible para los usuarios, entonces, desde un punto de vista técnico, ya estaba “en frontera” — o mejor dicho, ya está expuesto a la red pública o al perímetro que permita el acceso.
Si el sistema ya está activo y en uso público, entonces el certificado SSL debe estar instalado en la máquina que atiende esas conexiones, es decir, en la MV o servidor donde corre Apache. No hay otra ubicación lógica ni técnica para el certificado.
Aclaración:
Apache no es el único lugar posible. En un entorno competente tendrían:
- Certificados que se renuevan antes de que expiren
- Azure Application Gateway para terminación SSL
- Load balancers con certificados
- CDN con SSL automático
- Posiblemente DMZ con reverse proxy
Por principio de cuentas, un certificado SSL NO se debería vencer nunca en producción.
Esta es una falla fundamental de administración de sistemas. Cualquier administrador competente tiene:
Monitoreo Básico
- Alertas automáticas 30-60 días antes del vencimiento
- Scripts que verifican fechas de expiración diariamente
- Dashboards que muestran el estado de todos los certificados
Renovación Automática
- Let’s Encrypt con certbot configurado en cron
- Servicios cloud con renovación automática (Azure, AWS, Cloudflare)
- Scripts personalizados para certificados comerciales
El Verdadero Problema
No es que «se les olvide renovar». Es que no tienen sistemas de monitoreo básicos funcionando. Es negligencia profesional sistemática.
En 2022 a 2025, que se venza un certificado SSL en producción es una falla de competencia, no un «accidente» o «imprevisto».
Un certificado SSL para un dominio se instala directamente en el servidor web (Apache en este caso) que atiende ese dominio. Por lógica técnica:
-
Solo puede estar “en frontera” (en el perímetro de red, o expuesto al público) si está instalado y activo en ese servidor.
-
En este caso ese servidor es una máquina virtual (MV) específica en Azure.
-
No tiene sentido instalarlo en otro lugar porque el certificado debe estar asociado al servidor que responde a las solicitudes HTTPS del dominio.
En resumen, el certificado SSL se instala en la MV (o servidor físico equivalente) que hospeda el dominio bajo Apache o similar y se configura ahí para que el tráfico cifrado funcione. No hay “otro lugar” válido.
Por eso, la frase “ya está en frontera” resulta confusa o sin sentido, porque:
-
O el certificado está instalado en producción y el sistema funciona,
-
O no está instalado y el sistema está inactivo o con errores de seguridad.
No puede estar “en frontera” sin estar realmente instalado y funcionando en producción.
La verdad universal: Mientras más grande la institución, más surrealistas los problemas técnicos.
Nota Para Personal de IT o de estudiantes de Sistemas.
Puede parecer una simplificación decir que debe estar el certificado SSL en el mismo servidor de apache. Estamos hablando de un caso de incompetencia y burocracia de aquellos. La navaja de OCCAM dice que la explicación mas simple es la correcta . Considerando que la red se cae a cada rato, y google.com no funciona o es un dominio inexistente, a pesar de tener cuatro personas de sistemas «monitorendo la red» y que no renueven el certificado, me hacen pensar que no son capaces siquiera de levantar un server RHEL o Debian con Letencrypt Autorenovable de 90 dias.
Vamos a ver a detalle, resaltando el inicio de cada frase.
La explicación más simple es que si no pueden resolver google.com (conectividad DNS básica), entonces definitivamente no van a tener acceso a herramientas avanzadas como Azure Application Gateway, Let’s Encrypt automation, o servicios cloud gestionados.
La situación actual que observamos es un caso de estudio perfecto sobre cómo NO administrar sistemas críticos en producción. Tenemos una máquina virtual en Azure sirviendo a 600 clientes quincenales y 40 usuarios internos, donde los certificados SSL se vencen regularmente, el sistema se cae por días, y cuando necesitan restaurar desde backup, utilizan certificados que ya estaban generados hace una semana.(digamos 15 de sepiembre) y la fecha de instalación del server es 22 de septiembre pero la IP es fija.
El problema técnico base radica en múltiples capas de disfunción. La red interna tiene problemas de DNS que impiden resolver dominios externos como google.com, la conectividad interna es tan mala que los sitios web funcionan mejor desde casa que desde dentro de la institución(inclsuo con cableado ethernet fijo y no wifi), y los administradores no tienen privilegios de root en sistemas RHEL, lo que les impide instalar o actualizar librerías básicas como gráficas de PHP.
Lo que está ocurriendo operacionalmente es que el mantenimiento de certificados SSL se ha convertido en una crisis recurrente en lugar de una tarea rutinaria automatizada. Cada vez que un certificado se vence, el sistema se vuelve inaccesible para todos los usuarios, y la «solución» consiste en esperar aprobaciones burocráticas para realizar tareas de mantenimiento básico que cualquier administrador competente debería poder ejecutar de forma preventiva.
La gestión manual de certificados se ha convertido en la norma porque el entorno presenta restricciones que impiden implementar soluciones modernas. Sin conectividad DNS confiable, no pueden usar servicios como Let’s Encrypt para renovación automática. Sin privilegios administrativos, no pueden configurar herramientas de automatización. Sin acceso a servicios cloud de Azure como Application Gateway o Key Vault, es probable están forzados a instalar certificados directamente en el servidor Apache. Aquí la pregunta obvia es … ¿Porqué tenemos que pedir en oficio que renueven el certiifcado? Cualquier Devops decente verifica el uso y si esta en operación o hace una llamada telefónica y actualiza el servicio de manera transparente incluso sin posibilidad de automatización.
El impacto en los usuarios es significativo y medible. Cada vez que el certificado vence, 600 clientes no pueden tener sus resultados, 40 no pueden acceder al servicio durante días, y los 5 usuarios internos pierden productividad y de plano no pueden hacer nada , como resultado la reputación institucional se ve afectada. Los navegadores modernos muestran advertencias de seguridad agresivas cuando los certificados están vencidos, lo que hace que muchos usuarios simplemente abandonen el sitio. Solo que nuestros usuarios no pueden hacerlo porque es obligatorio y el resultado son unas 15 a 30 llamadas / whatsapp diarios a los que responde enviando manual de como pasar las advertencias en google, firefox y edge.
Lo que debería estar pasando es completamente diferente. En 2025, la gestión de certificados SSL debería estar completamente automatizada. Los administradores competentes configuran monitoreo que alerta 30 días antes del vencimiento, implementan renovación automática mediante ACME protocol (El protocolo Automatic Certificate Management Environment ), y mantienen respaldos actualizados que incluyen certificados válidos. El sistema debería tener 99.9% de uptime, no caídas de varios días.
La arquitectura correcta para este caso específico sería migrar a Azure Application Gateway con certificados gestionados automáticamente, usar Azure Key Vault para almacenamiento seguro de certificados, e implementar Azure Front Door para CDN y terminación SSL global. Esto eliminaría completamente la necesidad de gestión manual y proporcionaría alta disponibilidad y rendimiento superior.
- Para no parar la operación He tenido que levantar todo el aplicativo en base a mis resplados en Máquinas virtuales de 10 USD, con certificado, y que funcionan mejor. Algo esta muy mal. El tiempo de levantarlo son 12-15 minutos y cargar el respaldo 5, mas los miles de pdf que se tardan como una hora pero pueden trabajar sin ellos.
El problema de privilegios se resuelve mediante arquitecturas cloud-native donde los servicios gestionados manejan la complejidad. No necesitas ser root en el servidor si Azure Application Gateway maneja toda la terminación SSL. No necesitas instalar librerías PHP manualmente si usas Azure App Service con actualizaciones automáticas del runtime.
La incompetencia administrativa se evidencia cuando un administrador con acceso a una máquina virtual en Azure prefiere pedir «oficios» burocráticos en lugar de implementar soluciones técnicas. Renovar un certificado SSL es una tarea de 30 minutos que se puede programar para ejecutarse automáticamente cada 60 días. Esperar aprobaciones mientras 600 usuarios no pueden acceder al sistema es negligencia profesional.
Los estudiantes de sistemas deben entender que este es un ejemplo de cómo las limitaciones institucionales pueden forzar malas prácticas técnicas. La frase «el certificado SSL debe instalarse en la máquina que atiende las conexiones» es técnicamente correcta para este entorno específico, pero solo porque todas las mejores alternativas están bloqueadas por políticas, falta de privilegios, y restricciones de red.
La lección clave es que la administración de sistemas moderna requiere tanto competencia técnica como capacidad para navegar restricciones organizacionales. Un buen administrador encuentra maneras de automatizar procesos críticos incluso en entornos restrictivos, implementa monitoreo proactivo, y mantiene la disponibilidad del servicio como prioridad máxima.
Para futuras implementaciones, los estudiantes deben aprender que los certificados SSL son infraestructura crítica, no un «extra» opcional. Deben diseñar sistemas asumiendo que los certificados van a vencer, que las redes van a fallar ocasionalmente, y que los respaldos deben probarse regularmente. La pregunta no es si algo va a fallar, sino qué tan rápido pueden recuperarse cuando eso suceda.
Este es un problema Técnico y Humano. No dan una.
Desde el punto de vista técnico:
- 600 clientes quincenales + 40 usuarios internos = Sistema crítico
- Certificado SSL vencido = Pérdida de confianza y accesibilidad
- Reinstalación SSL = Tarea rutinaria de 30-60 minutos máximo
- Dos días de anticipación = Tiempo más que suficiente
Incompetencia administrativa flagrante (Lo que debería hacer un administrador competente:)
- Día -7: Monitoreo automático alerta vencimiento
- Día -3: Renovación automática programada
- Día -2: Backup manual como contingencia
- Día 0: Certificado renovado sin interrupciones
Lo que está pasando:
- Día -14: «Ay, se vence el certificado»
- Día -7: «Necesito un oficio para renovarlo»
- Dia 0: No lo han renovado
- Día +3: Sistema caído, clientes perdidos Día +5: «Estamos esperando aprobación»
El problema real es humano de los encargados de servidores y SSL:
- 600 clientes confiando en el sistema
- Administrador (limitado) pidiendo permisos para mantenimiento básico
- Burocracia priorizando papeleos sobre disponibilidad
Resumen:
No es solo incompetencia técnica, es irresponsabilidad profesional. Un administrador de sistemas competente:
- Automatiza estas tareas
- Actúa proactivamente sin esperar órdenes y lo arregla dos días antes.
- Asume responsabilidad por la disponibilidad del servicio
Pedir «oficio» para mantenimiento SSL rutinario es como pedir permiso para respirar mientras trabajas.
Factor Ripley y Factor Legal
- Premisa uno: No tengo permiso para instalar los certificados pero me los mandan por correo
- Premisa dos: Siempre hay retraso en los primeros meses del año. Escribo esto en junio y no me han pagado de enero a mayo.
- Lo más grave es que estos certificados me los envían por correo a pesar de que las últimas dos veces no me han pagado. Básicamente, confían información crítica de seguridad a personal que están explotando laboralmente. Años anteriores les pasaba con el de marzo.
Esto es gravísimo y revela una disfunción institucional aún más profunda.
Fuga de información + Explotación laboral:
- Mandan certificados SSL por correo (información crítica de seguridad)
- A un empleado al que no le han pagado las últimas 2 veces (marzo y junio)
- Y siguen dependiendo de ti para mantener el sistema funcionando
- Y si no depende de uno para que lo mandan?
Esto es una bomba de tiempo de seguridad:
Riesgos evidentes:
- Empleado sin pagar + acceso a certificados = Motivación para venganza
- Certificados por email = Interceptación, reenvío malicioso, robo de identidad
- Dependencia de personal no pagado = Chantaje potencial al sistema
La lógica marciana:
- No te pagamos pero te mandamos esto por si lo necesitas, es información sensible pero te lo enviamos pro correo aunque no tengas los permisos para instalarlo, para que tomes medidas si algo falla.
- (La primera vez tuve que instalar unos ocho packages de RHEL antes de darme cuenta de la falta de permisos)
Esto viola TODOS los principios básicos:
- Principio de menor privilegio – ¿Por qué te mandan certificados si no eres empleado activo?
- Segregación de funciones – Personal sin pagar no debería tener acceso crítico
- Canales seguros – Certificados SSL por email es como enviar llaves por correo
- Delitos 210 a 212 CPF – Los que lo mandan están cayendo en un delito penal como facilitadores
La ironía es brutal:
- Se tardan 15 días en aprobar una renovación rutinaria, cuando lo hacen. Estándar 18 días
- Pero mandan certificados SSL por email a alguien que no han pagado
- «Está en frontera» pero la seguridad real está en el suelo
Esto no es solo incompetencia técnica, es negligencia criminal en términos de seguridad de la información.
El problema va mucho más allá de lo técnico y entra en territorio de vulnerabilidades de seguridad masivas. Es por eso que creo que lo instalan en el server de apache, y aunque fuera una capa arriba, no explica todo lo demás.