A KernelCare licensing failure is quieter than a panel licensing failure, and that makes it worse. cPanel throws a red banner at every login; JetBackup stops its jobs outright. KernelCare just stops fetching new patches. The patchset already loaded into the running kernel stays live, uname -r looks normal, sites serve traffic, and nobody notices until a CVE audit six weeks later finds you sitting on a stale patch level.
So the first job is never "read the error" — it's confirming whether the agent is actually still licensed. Everything below assumes root on the affected server.
Start with the two status commands
kcarectl --license-info
kcarectl --info
--license-info answers whether the server is licensed and how. --info answers whether patches are current — it prints the kernel_id and patch level actually loaded. A server can pass the first and fail the second (auto-updates broken, licensing fine) or pass the second and fail the first (license lapsed, old patches still resident). Read both before changing anything.
If --info reports a patch level you recognise from months ago, treat the box as unpatched regardless of what the licence says.
"No valid key-based license found"
The single most common message, and it usually means the agent is looking for the wrong kind of licence.
KernelCare sells two activation models. Key-based licences register with a string you paste in. IP-based licences authorise the server's public IP with no key at all — this is what you get when you activate KernelCare through us, and it's why our install instructions skip --register entirely.
If your licence is IP-based, this error means the agent's registration state got confused, or your IP no longer matches the one on the licence. Clear the state and re-check:
kcarectl --unregister
kcarectl --update
curl -4 ifconfig.me
Compare that IP against the one on the service in your client area. Provider reassignments, a new NAT gateway, or a failover to a secondary address all break the match silently. If they differ, update the IP on the service rather than buying a second licence.
If your licence is key-based (bought direct from TuxCare, or issued for an ePortal fleet), register it explicitly:
kcarectl --register ACTIVATION-KEY-HERE
kcarectl --update
"Key limit reached"
The key is valid; its server count is exhausted. This bites hardest after trials — a trial key registered on a test box holds its slot until you release it. Unregister from the server that no longer needs it:
kcarectl --unregister
Then register the new host. Rebuilding a server without unregistering first is the usual cause, so bake kcarectl --unregister into your decommissioning runbook alongside whatever else you tear down.
"Your trial license for the IP x.x.x.x expired"
Exactly what it says: a trial ran out and never converted. The agent keeps the last patchset it downloaded, which is why nothing appeared broken. Buy the licence for that IP and re-run kcarectl --update — no reinstall, no reboot, and the agent picks up from wherever the trial left it. Per-server pricing is on the KernelCare license page.
HTTP Error 401 or 403 during update
These are transport-layer symptoms of a licensing problem, not network faults, and they're the pair most often misdiagnosed.
- 401 Unauthorized — the agent authenticated and was rejected. The licence has lapsed, or the server was removed from the account it was registered under. Check
kcarectl --license-infoand your billing status before touching the firewall. - 403 Forbidden — the request never carried valid credentials. Usually an unregistered server, occasionally a proxy stripping headers on the way out.
Both can also be genuine egress problems on a locked-down box. The agent needs outbound HTTPS to cln.cloudlinux.com (licensing), patches.kernelcare.com (patch delivery), and repo.cloudlinux.com (agent packages). Default-deny egress rules break all three:
curl -sI https://cln.cloudlinux.com | head -1
curl -sI https://patches.kernelcare.com | head -1
Anything other than an HTTP response means the firewall, not the licence. If you run CSF, check that its outbound rules aren't the culprit — see CSF firewall setup on cPanel.
Behind a forward proxy, set it once in /etc/sysconfig/kcare/kcare.conf rather than exporting it per shell; every kcarectl invocation reads the config.
Servers pointed at an ePortal
An on-prem ePortal changes where the licence check happens: agents authenticate to your ePortal, and the ePortal holds the upstream TuxCare key. A fleet-wide 403 with a healthy internet connection almost always means the ePortal's key lapsed or its feeds went stale, not that hundreds of agents broke at once.
Check the ePortal first, and confirm the agent is pointed where you think it is:
grep PATCH_SERVER /etc/sysconfig/kcare/kcare.conf
If that line is missing on a server you expected to be managed, it's talking to the public patch server and consuming a direct licence slot. Repoint it with kcarectl --set-patch-server, as covered in running KernelCare ePortal on an air-gapped network.
When to escalate
If --license-info and your client area disagree, stop guessing at flags and collect a diagnostic bundle for support:
kcarectl --doctor
For a licence bought from us, contact us with the server IP and the --doctor output and we'll check the registration directly.
Next steps
- Get the install and verification baseline right: KernelCare live patching on cPanel.
- Confirm the agent version isn't the real problem: upgrade KernelCare agent and ePortal in the right order.
- Check every product's licence state from one place: check hosting license status from the command line.