![]() |
![]() |
![]() |
Cockpit Guide | ![]() |
---|
Cockpit can use TLS client certificates for authenticating users. Commonly these are provided by a smart card, but it's equally possible to import certificates directly into the web browser.
This requires the host to be in an Identity Management domain like FreeIPA or Active Directory, which can associate certificates to users.
To authenticate users from a Identity Management domain, the server that Cockpit is running on must be joined to that domain. See the SSO server requirements for details.
The domain's users also need to get associated to certificates, usually with
the ipa user-add-cert command. See the
FreeIPA User Certificates documentation
for details. As a simple example, these commands will generate a new certificate/key
pair and associate it to the user alice
:
# create self-signed certificate and key # some browsers insist on specifying key usage, so it needs a config file printf '[req]\ndistinguished_name=dn\nextensions=v3_req\n[dn]\n [v3_req]\nkeyUsage=digitalSignature,keyEncipherment,keyAgreement\n' > /tmp/openssl.cnf openssl req -x509 -newkey rsa:2048 -days 365 -nodes -keyout alice.key \ -out alice.pem -subj "/CN=alice" -config /tmp/openssl.cnf -extensions v3_req # FreeIPA only accepts DER format, convert it openssl x509 -outform der -in alice.pem -out alice.der # browsers and smart cart utilities accept PKCS#12 format, convert it # this needs to set a transfer/import password openssl pkcs12 -export -password pass:somepassword \ -in alice.pem -inkey alice.key -out alice.p12 # assign it to the IdM user alice ipa user-add-cert alice --certificate="$(base64 alice.der)"
You can now import alice.p12
directly into your browser,
with giving the transfer password set above. Or
put the certificate onto a smart card:
pkcs15-init --store-private-key alice.p12 --format pkcs12 --auth-id 01
Certificate authentication needs to be enabled in cockpit.conf explicitly:
[WebService] ClientCertAuthentication = yes
When enabling this mode, other authentication types commonly get disabled, so that *only* client certificate authentication will be accepted. By default, after a failed certificate authentication attempt, Cockpit's normal login page will appear and permit other login types such as `basic` (passwords) or `gssapi` (Kerberos). For example, password authentication gets disabled with:
[Basic] action = none
When using certificate authentication, all requests with a particular certificate will be handled by a separate and isolated instance of the cockpit-ws web server. This protects against possible vulnerabilities in the web server and prevents an attacker from impersonating another user. However, this introduces a potential Denial of Service: Some remote attacker could create a large number of certificates and send a large number of http requests to Cockpit with these.
To mitigate that, all cockpit-ws
instances run
in a system-cockpithttps.slice
systemd slice unit
which limits
the collective resources of these web server instances: by default,
this slice sets a limit of 200 threads (roughly 100 instances of cockpit-ws
-- in other
words, a maximum of 100 parallel user sessions with different certificates) and
a 75% (soft)/90% (hard) memory limit.
You are welcome to adjust these limits to your need through a drop-in. For example:
# systemctl edit system-cockpithttps.slice [Slice] # change existing value TasksMax=100 # add new restriction CPUQuota=30%