AlmaLinux 10: cockpit ships with Server, here is how to verify it

Test scope

An AlmaLinux 10.2 Server VM (@^server-product-environment) with cockpit 356-1.el10.

The console was reached through an SSH tunnel and driven by a real browser, so the figures are actual renders:

login page: public/evidence/cockpit/alma-login.png
overview: public/evidence/cockpit/alma-overview.png

Server installs it for you

$ rpm -q cockpit cockpit-ws cockpit-bridge
cockpit-356-1.el10.x86_64
cockpit-ws-356-1.el10.x86_64
cockpit-bridge-356-1.el10.noarch

$ systemctl is-enabled cockpit.socket
enabled
$ ss -tlnp | grep 9090
LISTEN 0 4096 *:9090 *:*

It is socket activated:

$ systemctl cat cockpit.socket | grep -E "ListenStream|WantedBy"
ListenStream=9090
WantedBy=sockets.target

No daemon runs while idle; the first connection to 9090 starts cockpit-ws. The Server environment also opens the firewall service:

$ firewall-cmd --list-services
cockpit dhcpv6-client ssh

A minimal install (349 packages) has none of this: install cockpit and run systemctl enable --now cockpit.socket.

AlmaLinux 10.2 cockpit login page

Logging in as an ordinary account (here labuser, already in wheel) shows a yellow banner:

Web console is running in limited access mode. — Turn on administrative access

Even a wheel user starts unprivileged; a click (equivalent to sudo for the session) is required before changing configuration or restarting services. That is by design, not a misconfiguration.

AlmaLinux 10.2 cockpit overview

The overview already answers common questions: distribution and version, health warnings (failed services, update state, unclean shutdown), CPU and memory, machine model, machine-id, host time, performance profile and crypto policy.

The certificate appears at first start, not at install

/etc/cockpit/ws-certs.d/ is empty right after installation; the self-signed pair is created when the service first starts:

$ ls -l /etc/cockpit/ws-certs.d/
... 0-self-signed.cert
... 0-self-signed.key

$ openssl x509 -in /etc/cockpit/ws-certs.d/0-self-signed.cert -noout -subject -dates
subject=C=US, O=1162730b..., CN=localhost
notBefore=Oct 21 14:29:37 2026 GMT
notAfter=Nov 20 14:29:37 2027 GMT

Three consequences: browsers always warn, CN=localhost never matches an IP address, and the certificate expires after one year. Note also that /etc/cockpit/cockpit.conf does not exist by default — a missing config file does not mean nothing is configured.

Replacing the certificate

# cp server.crt /etc/cockpit/ws-certs.d/50-server.cert
# cp server.key /etc/cockpit/ws-certs.d/50-server.key
# chmod 600 /etc/cockpit/ws-certs.d/50-server.key
# systemctl restart cockpit.socket

cockpit sorts files in that directory and uses the last *.cert plus the matching .key, so a 50- prefix overrides 0-self-signed. The key must be mode 600 or it is ignored.

Triage order when the page will not open

1) systemctl is-enabled cockpit.socket   # not enabled -> enable --now
2) ss -tlnp | grep 9090                  # not listening -> check cockpit-ws
3) firewall-cmd --list-services | grep cockpit
4) curl -k https://<host>:9090/          # works locally, not remotely -> network/firewall
5) journalctl -u cockpit-ws -n 20        # certificate, port and auth errors land here

Step 4 separates “the service is broken” from “the path or certificate is broken”.

Common traps

“Loading available updates failed” on an offline host: the red text means dnf cannot reach repositories (our lab has no default route); cockpit is fine;
Treating limited access as a permissions bug: click the banner once;
cockpit-machines is not installed by Server: add it if you need VM management; cockpit-podman is included;
Replacing the certificate without restarting the socket: the old one stays in use.

Practice: verify from the CLI, not by guessing

systemctl is-enabled cockpit.socket
ss -tlnp | grep 9090
sudo firewall-cmd --list-services
curl -k -o /dev/null -w "%{http_code}\n" https://127.0.0.1:9090/
sudo ls -l /etc/cockpit/ws-certs.d/