Hi Ralf,

Where do you see the error from the bugzilla title? I mean "PAM unable to dlopen(/usr/lib64/security/pam_console.so)". Do you mind sharing those logs too?

pam_console was removed in fedora 39 (https://fedoraproject.org/wiki/Changes/RemovePamConsole), so this problem should have become evident from that version onwards.

(In reply to Iker Pedrosa from comment #1)
> Hi Ralf,
> 
> Where do you see the error from the bugzilla title? I mean "PAM unable to
> dlopen(/usr/lib64/security/pam_console.so)". Do you mind sharing those logs
> too?
> 
> pam_console was removed in fedora 39
> (https://fedoraproject.org/wiki/Changes/RemovePamConsole), so this problem
> should have become evident from that version onwards.

Hi Iker,

since the gdm-login via smartcard was not possible I took a look into journalctl at first. There gdm-smartcard reports:

Nov 18 08:43:12 gdm-smartcard][3677]: PAM unable to dlopen(/usr/lib64/security/pam_console.so): /usr/lib64/security/pam_console.so: Kann die Shared-Object-Datei nicht öffnen: Datei oder Verzeichnis nicht gefunden
Nov 18 08:43:12 gdm-smartcard][3677]: PAM adding faulty module: /usr/lib64/security/pam_console.so
Nov 18 08:43:22 gdm-smartcard][3677]: pam_sss(gdm-smartcard:auth): User info message: Please (re)insert (different) Smartcard

So while filing the bug I took this as a header since I was expecting this to be the problem. 

When looking into journalctl when executing pamtester as specified above I do not see any complaints about pam_console.

Curious. That line was removed a year and a half ago upstream (https://gitlab.gnome.org/GNOME/gdm/-/commit/cb060ca0b0feaf9f2e4679482d64107f11b411d3) and it should have been ported automatically when rebasing to gdm v47. Can you share the content of /etc/pam.d/gdm-smartcard? Try removing pam_console from that file and see if you can authenticate successfully.

mmm if you have some modification in that file then it isn't replaced, so you'll probably have a /etc/pam.d/gdm-smartcard.rpmnew file with the new content but you are still using the old one.

(In reply to Iker Pedrosa from comment #3)
> Curious. That line was removed a year and a half ago upstream
> (https://gitlab.gnome.org/GNOME/gdm/-/commit/
> cb060ca0b0feaf9f2e4679482d64107f11b411d3) and it should have been ported
> automatically when rebasing to gdm v47. Can you share the content of
> /etc/pam.d/gdm-smartcard? Try removing pam_console from that file and see if
> you can authenticate successfully.

Content of /etc/pam.d/gdm-smartcard is:

auth        substack      smartcard-auth
# -- From https://bugzilla.redhat.com/show_bug.cgi?id=1676385
auth	    optional      pam_gnome_keyring.so
# --
auth        include       postlogin

account     required      pam_nologin.so
account     include       smartcard-auth

password    include       smartcard-auth

session     required      pam_selinux.so close
session     required      pam_loginuid.so
# -- From https://bugzilla.redhat.com/show_bug.cgi?id=1676385
session     optional      pam_console.so
# --
session     required      pam_selinux.so open
session     optional      pam_keyinit.so force revoke
session     required      pam_namespace.so
session     include       smartcard-auth
# -- From https://bugzilla.redhat.com/show_bug.cgi?id=1676385
session     optional      pam_gnome_keyring.so auto_start
# --
session     include       postlogin

I have now commented out
session     optional      pam_console.so
=>
#session     optional      pam_console.so

This made the "PAM unable to dlopen(/usr/lib64/security/pam_console.so)" message disapear from journalctl while the "[pam] [parse_p11_child_response] (0x1000): [CID#16] No certificate found" persists and smartcard login or sudo authentication is not possible.

(In reply to Iker Pedrosa from comment #4)
> mmm if you have some modification in that file then it isn't replaced, so
> you'll probably have a /etc/pam.d/gdm-smartcard.rpmnew file with the new
> content but you are still using the old one.

Actually I can not remember modifying this file.
I checked and there is no /etc/pam.d/gdm-smartcard.rpmnew
Last modification of the original file was Dec 7th 2023 which is when the system was installed I think.

So pam_console was not the problem, I thought it wasn't, but I wanted to make sure.

Sumit can I get your eyes on this issue? It seems like the certificate disappeared from the smartcard.

(In reply to Ralf Schneider from comment #0)
> 
> (2024-11-18  9:35:29): [pam] [child_sig_handler] (0x0100): [CID#16] child [13272] finished successfully.
> (2024-11-18  9:35:29): [pam] [_read_pipe_handler] (0x0400): [CID#16] EOF received, client finished
> (2024-11-18  9:35:29): [pam] [parse_p11_child_response] (0x1000): [CID#16] No certificate found.

Could you please attach corresponding part of '/var/log/sss/p11_child.log'?

And could you please also check if `/usr/share/polkit-1/rules.d/sssd-pcsc.rules` file is present on your system?

(In reply to Alexey Tikhonov from comment #9)
> And could you please also check if
> `/usr/share/polkit-1/rules.d/sssd-pcsc.rules` file is present on your system?

(In reply to Alexey Tikhonov from comment #8)
> (In reply to Ralf Schneider from comment #0)
> > 
> > (2024-11-18  9:35:29): [pam] [child_sig_handler] (0x0100): [CID#16] child [13272] finished successfully.
> > (2024-11-18  9:35:29): [pam] [_read_pipe_handler] (0x0400): [CID#16] EOF received, client finished
> > (2024-11-18  9:35:29): [pam] [parse_p11_child_response] (0x1000): [CID#16] No certificate found.
> 
> Could you please attach corresponding part of '/var/log/sss/p11_child.log'?

Hi all thanks a lot for the quick responses and sorry about digging through the wrong logs.

/var/log/sssd/p11_child.log tells

(2024-11-18 17:17:13): [p11_child[11266]] [do_verification] (0x0040): [CID#20] X509_verify_cert failed [0].
(2024-11-18 17:17:13): [p11_child[11266]] [do_verification] (0x0040): [CID#20] X509_verify_cert failed [10][certificate has expired].

So doing an

openssl ca -config ca.cnf -batch -notext -keyfile rootCA.key -in user.csr -days <no_days> -extensions usr_cert -out new_cert.crt
pkcs15-init --update-certificate new_cert.crt --auth-id $AUTH_ID --id $ID --format pem

did the trick. Now everything works again as expected. Updating to Fedora 41 at the same time as my user certificate expired was really another prime example of Murphy's Law.
 
What was indeed confusing was the fact that unlocking LUKS2 with X509 certificate on Nitrokey Storage, which I implemented as per https://vtimofeenko.com/posts/unlocking-luks2-with-x509-certificate-on-nitrokey-storage/, still worked and is still working even though I have not enrolled the new certificate on the luks device.

Sorry again for all the confusion & thanks a lot for the quick help.

Hi,

about your confusion with LUKS2, it looks like LUKS2 is only using the private key stored on the Nitrokey and is initially only referring to the certificate to locate the matching private key. As long as you have regenerated the certificate with the same public and private key than the old certificate the private key stored on the Nitrokey didn't change and as a result you do not have to re-enroll it.

HTH

bye,
Sumit