SSL on KnightLi Blog

Cómo reparar el error de verificación del certificado SSL cuando llama-cli se descarga desde Hugging Face en Windows

Fri, 17 Apr 2026 14:20:29 +0800

Si ejecuta este comando en Windows:

`1`	`llama-cli -hf unsloth/gemma-4-E4B-it-GGUF`

y veo un error como este:

1
2

get_repo_commit: error: HTTPLIB failed: SSL server verification failed
error: failed to download model from Hugging Face

Por lo general, el problema no es CUDA ni llama.cpp. Más a menudo, el programa no puede acceder correctamente a la cadena de certificados del sistema en el entorno actual, por lo que falla la verificación HTTPS.

Desde el registro, ggml-rpc.dll y ggml-cpu-alderlake.dll se cargaron correctamente, lo que significa que el entorno de ejecución está prácticamente bien. El problema está principalmente en el paso de descarga del modelo.

La solución más sencilla: descargar el modelo manualmente

Si sólo desea que funcione rápidamente, descargar el modelo manualmente suele ser la opción más estable.

Abra la página del repositorio de Hugging Face correspondiente.
Descargue el archivo .gguf requerido desde Archivos y versiones.
Una vez finalizada la descarga, ejecútela con la ruta del archivo local:

`1`	`llama-cli -m C:\Users\knightli\Downloads\gemma-4-e4b-it.gguf`

Esto omite la verificación SSL durante el paso de descarga -hf y es útil cuando solo desea verificar que el modelo se puede ejecutar localmente.

Si aún deseas utilizar la descarga automática `-hf`

Puede especificar manualmente una ruta de archivo de certificado para que el programa pueda encontrar un paquete de CA utilizable en la sesión actual.

cacert.pem se puede obtener de la página de extracto de CA mantenida por el proyecto curl:

Página: https://curl.se/docs/caextract.html
Descarga directa: https://curl.se/ca/cacert.pem

Si lo descarga en un navegador, abra el enlace de descarga directa y guárdelo como cacert.pem. También puedes descargarlo a un directorio fijo con PowerShell:

1
2

New-Item -ItemType Directory -Force C:\certs
Invoke-WebRequest -Uri https://curl.se/ca/cacert.pem -OutFile C:\certs\cacert.pem

Una vez finalizada la descarga, configure estas variables en la línea de comando:

1
2

set SSL_CERT_FILE=C:\certs\cacert.pem
set CURL_CA_BUNDLE=C:\certs\cacert.pem

Luego ejecute el comando original nuevamente:

`1`	`llama-cli -hf unsloth/gemma-4-E4B-it-GGUF`

Si el problema realmente proviene de la cadena de certificados, esto generalmente lo soluciona directamente.

Renovar automáticamente los certificados Let's Encrypt en Ubuntu (Certbot + Nginx)

Fri, 03 Apr 2026 00:00:00 +0000

Los certificados Let’s Encrypt son válidos solo por 90 días, por lo que los sitios de producción siempre deben habilitar la renovación automática para evitar el tiempo de inactividad de HTTPS.

Si ya emitiste el certificado con Certbot, generalmente quedan dos cosas:

Configurar una tarea de renovación programada
Verifique que el flujo de trabajo de renovación realmente funcione

Primero, verifique si Certbot ya creó un programador

Dependiendo de su distribución, es posible que Certbot ya haya instalado un programador (por ejemplo, un systemd timer o /etc/cron.d/certbot).

Puedes consultar con:

`1`	`systemctl list-timers \| grep certbot`

Si ya existe un temporizador válido, normalmente no necesitará una entrada adicional en el crontab.

Agregar un trabajo de Crontab manualmente (ejemplo recomendado)

Si prefiere administrar la renovación explícitamente, edite el crontab raíz:

`1`	`sudo crontab -e`

Agregue esta línea (se publica todos los días a las 03:00):

`1`	`0 3 * * * certbot renew --pre-hook "systemctl stop nginx" --post-hook "systemctl start nginx" >> /tmp/certbot-renew.log 2>&1`

Lo que significa:

0 3 * * *: se ejecuta a las 03:00 todos los días
certbot renew: renueva los certificados que están próximos a caducar
--pre-hook: detiene Nginx antes de la renovación (común para el modo independiente)
--post-hook: inicia Nginx después de la renovación
>> /tmp/certbot-renew.log 2>&1: agregar registros para solucionar problemas

Ejecute una prueba en seco antes de confiar en Cron

Después de agregar la tarea, valide el flujo completo manualmente:

`1`	`sudo certbot renew --dry-run`

Si el ensayo tiene éxito, podrá confiar con seguridad en el trabajo programado.

Notas comunes

Si utiliza el complemento webroot o nginx, a menudo no necesita detener Nginx. En muchas configuraciones, recargar Nginx después de la renovación es suficiente:

`1`	`certbot renew --deploy-hook "systemctl reload nginx"`

certbot renew solo realiza una renovación real cerca del vencimiento, por lo que ejecutarla diariamente es normal.
Para el mantenimiento a largo plazo, considere escribir registros en una ruta persistente como /var/log/letsencrypt/.

Resumen

La renovación automática de certificados confiable no consiste solo en escribir un comando. La clave es confirmar que el flujo de trabajo puede ejecutarse de un extremo a otro.

Una configuración estable suele consistir sólo en estos tres pasos:

Verifique si la programación a nivel del sistema ya existe
Agregue cron si es necesario y mantenga registros
Valide una vez con --dry-run