SSL on KnightLi Blog

How to Fix SSL Certificate Verification Failed When llama-cli Downloads from Hugging Face on Windows

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

If you run this command on Windows:

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

and see an error like this:

1
2

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

the problem is usually not CUDA or llama.cpp itself. More often, the program cannot correctly access the system certificate chain in the current environment, so HTTPS verification fails.

From the log, ggml-rpc.dll and ggml-cpu-alderlake.dll were loaded successfully, which means the runtime environment is mostly fine. The issue is mainly in the model download step.

The easiest workaround: download the model manually

If you just want to get it running quickly, downloading the model manually is usually the most stable option.

Open the matching Hugging Face repository page.
Download the required .gguf file from Files and versions.
After the download finishes, run it with the local file path:

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

This bypasses SSL verification during the -hf download step and is useful when you only want to verify that the model can run locally.

If you still want to use `-hf` automatic download

You can manually specify a certificate file path so the program can find a usable CA bundle in the current session.

cacert.pem can be obtained from the CA Extract page maintained by the curl project:

Page: https://curl.se/docs/caextract.html
Direct download: https://curl.se/ca/cacert.pem

If you download it in a browser, open the direct download link and save it as cacert.pem. You can also download it to a fixed directory with PowerShell:

1
2

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

After the download finishes, set these variables in the command line:

1
2

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

Then run the original command again:

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

If the issue really comes from the certificate chain, this usually fixes it directly.

Automatically Renew Let's Encrypt Certificates on Ubuntu (Certbot + Nginx)

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

Let’s Encrypt certificates are valid for only 90 days, so production sites should always enable automatic renewal to avoid HTTPS downtime.

If you already issued the certificate with Certbot, there are usually two things left:

Configure a scheduled renewal task
Verify the renewal workflow actually works

First, Check Whether Certbot Already Created a Scheduler

Depending on your distro, Certbot may already install a scheduler (for example, a systemd timer or /etc/cron.d/certbot).

You can check with:

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

If a valid timer already exists, you usually do not need an extra crontab entry.

Add a Crontab Job Manually (Recommended Example)

If you prefer managing renewal explicitly, edit root crontab:

`1`	`sudo crontab -e`

Add this line (runs daily at 03:00):

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

What it means:

0 3 * * *: run at 03:00 every day
certbot renew: renew certificates that are close to expiration
--pre-hook: stop Nginx before renewal (common for standalone mode)
--post-hook: start Nginx after renewal
>> /tmp/certbot-renew.log 2>&1: append logs for troubleshooting

Run a Dry Test Before Relying on Cron

After adding the task, validate the full flow manually:

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

If dry-run succeeds, you can safely rely on the scheduled job.

Common Notes

If you use the webroot or nginx plugin, you often do not need to stop Nginx. In many setups, reloading Nginx after renewal is enough:

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

certbot renew only performs actual renewal near expiration, so running it daily is normal.
For long-term maintenance, consider writing logs to a persistent path such as /var/log/letsencrypt/.

Summary

Reliable certificate auto-renewal is not just about writing a command. The key is confirming the workflow can run end to end.

A stable setup is usually just these three steps:

Check whether system-level scheduling already exists
Add cron if needed and keep logs
Validate once with --dry-run