This bug was initially created as a copy of Bug #1992432

I am copying this bug because: to track fix for RHEL8



Description of problem:

Cockpit has initial support for client certificate (aka smart card) logins. This is currently only supported for machines joined to IdM (FreeIPA or AD) where you import and compare against the full client certificate with org.freedesktop.sssd.infopipe.Users.FindByCertificate(). There is no further validation of the certificate right now.

We'd like to make this both more robust and also allow this with certmap matchrules. For the latter it's absolutely crucial to ensure that the certificate is signed by an admin-specified CA, plus the usual extra checks (CRL file or OCSP, as configured). It's not strictly necessary for full certificate imports, but it'd be a desirable hardening step anyway.

For that we would like to have a D-Bus API that exposes sssd's cert validation. Right now that's done internally by pam_sss and the like, they apparently do cert validation and cert mapping as two distinct steps. There are reasons why they are separate (@sumit-bose mentioned on the meeting that mapping is done more often and is much cheaper than validation), so it should have a separate API as well. Something like org.freedesktop.sssd.infopipe.Users.ValidateCertificate s → void which gets the certificate PEM and throws a DbusError on failures, or alternatively returns a success/error code.

cockpit could then attempt to use that new API, and if the method does not exist, fall back to the current behaviour or do something more heuristic (like, erroring out when the mapped user is local, as then it's most likely a certmap one), and eventually require the new API.

The most important aspect of this is that this keeps the configuration like pam_cert_db_path, crl_file, ocsp_* etc. in sssd.conf and conf.d. cockpit-tls neither should (too complex) nor could (files are readable for root only) inspect these. It also avoids code duplication, as sssd already has all that validation logic.

As a kind of bonus it would be nice to expose the CA as a property on the InfoPipe object (or a GetCA() method), if it was set in the config. This would allow the server to send the expected CAs (or at least its properties) with the TLS handshake, using gnutls-x509-trust-list-add-cas() or a similar function. This may allow the web browser a more intelligent pre-selection of available certificates. But that's not crucial, and I'm also happy to split that out into a separate issue.


Version-Release number of selected component (if applicable):


sssd-2.5.2-2.el8.x86_64