Certbot informa de una renovación correcta, los archivos del disco llevan fechas nuevas y los clientes siguen encontrando la identidad antigua. SoftEther guarda su certificado SSL de servidor en su propia configuración a nivel de servidor, así que un archivo nuevo en el disco no cambia nada hasta que se importan el certificado hoja y su clave. La secuencia siguiente cubre una importación manual, un envoltorio que se ejecuta tras cada renovación y una comprobación que lee lo que el listener presenta realmente. Cada paso deja pruebas que puede comparar tras la siguiente renovación.

Un archivo renovado no cambia la identidad del servidor

La emisión y el despliegue son sucesos separados con formas de fallar separadas. El cliente ACME escribe archivos en un directorio de linaje y registra el éxito; SoftEther sigue usando el certificado que se cargó por última vez en su configuración. Por tanto, un estado de salida cero describe los archivos, no el servicio, y ambos pueden discrepar mientras nadie mire. Trate la importación como el paso de despliegue y la renovación como su entrada.

Esa distinción también explica el confuso medio fallo: el certificado antiguo sigue funcionando hasta su vencimiento, así que al principio nada parece roto. Cuando vence, todos los clientes fallan a la vez, lo que parece una caída y no un paso de despliegue omitido. Comprobar la identidad presentada tras cada renovación convierte esa sorpresa en una observación rutinaria.

Elija el desafío que encaje con el listener

El certificado debe nombrar el host que verifican los clientes, así que use el nombre DNS público en lugar de una etiqueta interna o una dirección. HTTP-01 necesita que el desafío se responda en el puerto 80 durante un momento, lo que es un listener temporal y nunca un motivo para mover el puerto propio de SoftEther. DNS-01 demuestra el control mediante un registro y no necesita ningún HTTP entrante.

La renovación desatendida significa una integración DNS automatizada con credenciales limitadas a una sola zona, no un registro TXT escrito a mano cada dos meses. Un comodín cambia el tipo de desafío, no la necesidad de esa automatización. Decídalo antes de que exista el primer certificado, porque cambiar el tipo de desafío después implica tocar la configuración del cliente y el cortafuegos a la vez.

Mantenga los artefactos en orden mientras está aquí. El certificado hoja y los intermedios llegan como archivos separados y como un archivo de cadena combinado, la clave privada vuelve a ser aparte, y la importación necesita la cadena con su clave correspondiente, no un certificado público por sí solo.

Importe la cadena a nivel de servidor

Haga una copia de seguridad de la configuración del servidor y confirme que aún puede llegar a la interfaz de administración antes de tocar el certificado. Conéctese como administrador del servidor y no como administrador del Virtual Hub, porque el certificado pertenece al objeto del servidor. Después cargue la cadena y la clave por ruta absoluta, desde archivos que la cuenta que ejecuta la orden pueda leer. Note que las rutas son absolutas porque la orden las resuelve desde el directorio de trabajo del proceso que ejecutó vpncmd:

ServerCertSet /LOADCERT:/etc/letsencrypt/live/vpn.example.com/fullchain.pem /LOADKEY:/etc/letsencrypt/live/vpn.example.com/privkey.pem

Lea la salida de la orden en lugar de suponer el éxito, y después vuelva a leer la cadena en lugar de confiar en el archivo que pasó. La frontera entre las compilaciones que importan un paquete PEM completo y las que solo toman el primer certificado no está documentada en un solo lugar, así que la comprobación es lo que lo resuelve para la compilación que tiene delante. Cuente los certificados que presenta el listener; un certificado hoja sin intermedios es la firma de un importador que solo consumió el primer bloque.

Mantenga la clave importada legible solo por la cuenta que ejecuta el servidor, y mantenga la contraseña de administración fuera del historial del intérprete. Para esta primera importación, escriba la contraseña en el aviso en lugar de pasarla como argumento de la orden. Esos dos hábitos no cuestan nada y eliminan la forma más común de que un despliegue de certificados filtre algo que debía proteger. Hágalo antes de la primera importación, no después.

Enganche el despliegue, no la renovación

Cuando la importación manual funcione, ponga exactamente esos pasos en un envoltorio pequeño y llámelo desde el cliente ACME tras una renovación correcta. Certbot establece RENEWED_LINEAGE y RENEWED_DOMAINS para el hook, así que el envoltorio puede actuar sobre un certificado en una máquina que gestiona varios. Filtre por el linaje en lugar de reaccionar a cada renovación del host. El envoltorio es código de despliegue que se ejecuta con los privilegios del servidor, así que revíselo como cualquier otro script en esa posición.

certbot renew --deploy-hook /usr/local/sbin/softether-deploy.sh

Un hook que se ejecuta desatendido necesita su propio almacén protegido de credenciales y una señal de fallo que llegue a una persona. Si la emisión tiene éxito y la importación falla, reintente la importación en lugar de pedir otro certificado, porque una segunda solicitud esconde el defecto de despliegue tras un archivo nuevo. La documentación de renovación de Certbot deja claro que una ejecución que no actualiza nada es un resultado normal, así que el hook es lo que distingue ambas cosas.

Compare la cadena presentada con el archivo

Lea el listener, no el disco. Conéctese al puerto orientado a los clientes con el nombre de servidor que usan los clientes y después compare la huella y la cadena entregada con el linaje que instaló el hook. Dos órdenes lo cubren, y la primera también muestra si llegan intermediarios:

openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts </dev/null 2>/dev/null | grep -c 'BEGIN CERTIFICATE'
openssl s_client -connect vpn.example.com:443 -servername vpn.example.com </dev/null 2>/dev/null | openssl x509 -noout -subject -dates -fingerprint -sha256

Luego haga una conexión de cliente nueva, porque las sesiones establecidas antes de la importación se autenticaron contra la identidad anterior y no prueban nada sobre la nueva. Si los clientes fijan el certificado hoja antiguo, necesitan una actualización coordinada incluso cuando la cadena pública es válida, y esa tarea pertenece al mismo runbook que la renovación. Un proxy inverso delante del servicio puede presentar un certificado bueno mientras el listener VPN aún conserva el viejo, y por eso la comprobación debe nombrar el puerto al que los clientes llegan de verdad. Anote la huella junto a la fecha de renovación, para que la siguiente comparación sea una comprobación y no un acto de memoria.

Artículos relacionados