[SSSD-users] Re: SSSD and PKI: capability of checking trust/validation/revocation
Hello, Okay. That concludes al of the test cases as successful. Thank you for your support once again! BR, Hristina ___ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
[SSSD-users] Re: SSSD and PKI: capability of checking trust/validation/revocation
On Mon, Mar 30, 2020 at 02:22:44PM -, Hristina Marosevic wrote:
> Hello,
>
> I successfuly added the CRL list into nssdb. CRL list is in DER format.
> So, I tested the last scenario, which was vaidation of the revoked user
> certificate used for authenticatiion using offline CRL list instead of using
> OCSP. So, just giving info about this:
> In the [sssd] section of the sssd.conf file, option certificate_validation
> has value "no_ocsp" and in the log file recorded using strace, this lines
> were generated:
> write(2, "(Mon Mar 30 16:12:12 2020) [[sssd[p11_child[25761
> [do_verification] (0x0040): Certificate [(null)][CN=test_sssd_revoked.]
> not valid [-8102][Certificate key usage inadequate for attempted
> operation.].\n", 228) = 228
> stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=1931, ...}) = 0
> stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=1931, ...}) = 0
> write(2, "(Mon Mar 30 16:12:12 2020) [[sssd[p11_child[25761 [do_work]
> (0x0400): Certificate is NOT valid.\n", 100) = 100
> stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=1931, ...}) = 0
> stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=1931, ...}) = 0
> write(2, "(Mon Mar 30 16:12:12 2020) [[sssd[p11_child[25761 [main]
> (0x0040): do_work failed.\n", 87) = 87
> stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=1931, ...}) = 0
> stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=1931, ...}) = 0
> write(2, "(Mon Mar 30 16:12:12 2020) [[sssd[p11_child[25761 [main]
> (0x0020): p11_child failed!\n", 89) = 89
> close(1)= 0
> exit_group(1) = ?
> +++ exited with 1 +++
>
>
> So, the authentication did not pass, which was excpected.
> Please confirm that this is the answer that the p11_child should give in case
> of revoked user certificate.
Hi,
yes, in the way SSSD is using NSS '[-8102][Certificate key usage
inadequate for attempted operation.]' is often returned instead of a
more specific error message when certificate validation fails.
bye,
Sumit
> If it is like that, by this step I can confirm that SSSD PKI authentication
> works properly i.e successfuly verifies trust/time validity/revocation status
> of the user certificate.
>
> BR,
> Hristina
> ___
> sssd-users mailing list -- sssd-users@lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
[SSSD-users] Re: SSSD and PKI: capability of checking trust/validation/revocation
Hello,
I successfuly added the CRL list into nssdb. CRL list is in DER format.
So, I tested the last scenario, which was vaidation of the revoked user
certificate used for authenticatiion using offline CRL list instead of using
OCSP. So, just giving info about this:
In the [sssd] section of the sssd.conf file, option certificate_validation has
value "no_ocsp" and in the log file recorded using strace, this lines were
generated:
write(2, "(Mon Mar 30 16:12:12 2020) [[sssd[p11_child[25761
[do_verification] (0x0040): Certificate [(null)][CN=test_sssd_revoked.] not
valid [-8102][Certificate key usage inadequate for attempted operation.].\n",
228) = 228
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=1931, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=1931, ...}) = 0
write(2, "(Mon Mar 30 16:12:12 2020) [[sssd[p11_child[25761 [do_work]
(0x0400): Certificate is NOT valid.\n", 100) = 100
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=1931, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=1931, ...}) = 0
write(2, "(Mon Mar 30 16:12:12 2020) [[sssd[p11_child[25761 [main]
(0x0040): do_work failed.\n", 87) = 87
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=1931, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=1931, ...}) = 0
write(2, "(Mon Mar 30 16:12:12 2020) [[sssd[p11_child[25761 [main]
(0x0020): p11_child failed!\n", 89) = 89
close(1)= 0
exit_group(1) = ?
+++ exited with 1 +++
So, the authentication did not pass, which was excpected.
Please confirm that this is the answer that the p11_child should give in case
of revoked user certificate.
If it is like that, by this step I can confirm that SSSD PKI authentication
works properly i.e successfuly verifies trust/time validity/revocation status
of the user certificate.
BR,
Hristina
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
[SSSD-users] Re: SSSD and PKI: capability of checking trust/validation/revocation
On Thu, Mar 26, 2020 at 08:16:31AM -, Hristina Marosevic wrote: > > On Wed, Mar 25, 2020 at 10:49:55AM -, Hristina Marosevic wrote: > > > > Hi, > > > > glad to hear it is working now. Thanks for your patience. > > > > bye, > > Sumit > > > Hello, > > As I was planning, I tried to login with an expired certificate and the > authentication failed with error: > write(2, "(Wed Mar 25 16:28:59 2020) [[sssd[p11_child[10489 > [do_verification] (0x0040): Certificate [(null)][CN=test_sssd,.] not > valid [-8181][Peer's Certificate has expired.].\n", 194) = 194 > I also, in some way tested authentication using certificate signed by > untrusted authorities i.e. when the root and intermediate CA certificates > were not imported correctly I got the error: " Certificate not valid. > .Peer's Certificate is not recognized" > This seems to be working properly. > > The last scenario which I would like to test is CRL status, but if possiible > using offline CRL list instead of OCSP responder. > I guess certificate_verification=no_ocsp stays in the sssd section of the > sssd configuration, but what else should I do to make sssd chek the > revocation status of a user certificate using an offline CRL list, stored > somewhere on the machine? > This is like that because our lab environment is not connected to internet, > and I can not use the OCSP URL given in the user's certificate. Is this > workaround possible? Hi, please use crlutil to import a CRL into the NSS database, see man crlutil for details. HTH bye, Sumit > > BR, > Hristina > > ___ > sssd-users mailing list -- sssd-users@lists.fedorahosted.org > To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org ___ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
[SSSD-users] Re: SSSD and PKI: capability of checking trust/validation/revocation
> On Wed, Mar 25, 2020 at 10:49:55AM -, Hristina Marosevic wrote: > > Hi, > > glad to hear it is working now. Thanks for your patience. > > bye, > Sumit Hello, As I was planning, I tried to login with an expired certificate and the authentication failed with error: write(2, "(Wed Mar 25 16:28:59 2020) [[sssd[p11_child[10489 [do_verification] (0x0040): Certificate [(null)][CN=test_sssd,.] not valid [-8181][Peer's Certificate has expired.].\n", 194) = 194 I also, in some way tested authentication using certificate signed by untrusted authorities i.e. when the root and intermediate CA certificates were not imported correctly I got the error: " Certificate not valid. .Peer's Certificate is not recognized" This seems to be working properly. The last scenario which I would like to test is CRL status, but if possiible using offline CRL list instead of OCSP responder. I guess certificate_verification=no_ocsp stays in the sssd section of the sssd configuration, but what else should I do to make sssd chek the revocation status of a user certificate using an offline CRL list, stored somewhere on the machine? This is like that because our lab environment is not connected to internet, and I can not use the OCSP URL given in the user's certificate. Is this workaround possible? BR, Hristina ___ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
[SSSD-users] Re: SSSD and PKI: capability of checking trust/validation/revocation
On Wed, Mar 25, 2020 at 10:49:55AM -, Hristina Marosevic wrote:
> > On Tue, Mar 24, 2020 at 02:20:17PM -, Hristina Marosevic wrote:
> >
> > Hi,
> >
> > did you change the 'ca_db' option in sssd.conf? If looks like a wrong
> > path '/home/oracle' is used for the NSS database.
> >
> > bye,
> > Sumit
>
>
> Hello,
>
> It was anold configuration - thank you for noticing!
> After deleting the ca_db option value from the sssd configuration i.e. now,
> when it has the default value - /etc/pki/nssdb user authentication passed
> successfully.
>
> /var/log/sssd/sssd_ssh.log
> ...
> (Wed Mar 25 11:34:44 2020) [sssd[ssh]] [child_sig_handler] (0x1000): Waiting
> for child [20372].
> (Wed Mar 25 11:34:44 2020) [sssd[ssh]] [child_sig_handler] (0x0100): child
> [20372] finished successfully.
> (Wed Mar 25 11:34:44 2020) [sssd[ssh]] [cert_to_ssh_key_done] (0x1000):
> Certificate
> [MIIGMTCCBBmgAwIBAgIUfYWZ212wMteK0jjnnXd6dqlqkIkwDQYJKoZIhvcNAQELBQAwLTELMAkGA1UEBhMCS1oxHjAcBgNVBAMMFdKw0JrQniAzLjAgKFJTQSBURVNUKTAeFw0xOTA0MDQwODU0NTRaFw0yMTA0MDMwODU0NTRaMIGvMSIwIAYDVQQDDBnQotCV0KHQotCi0J7QkiDQotCV0KHQotCiMRcwFQYDVQQEDA7QotCV0KHQotCi0J7QkjEYMBYGA1UEBRMPSUlOMTIzNDU2Nzg5MDEyMQswCQYDVQQGEwJLWjEVMBMGA1UEBwwM0JDQodCi0JDQndCQMRUwEwYDVQQIDAzQkNCh0KLQkNCd0JAxGzAZBgNVBCoMEtCi0JXQodCi0KLQntCS0JjQpzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAI9kXtq5MjdOP+6uelfthsbeOFCrjPQdypbwkDgIoas054FJvKHgfX9apVHvbMrNK7/atFMbfrv1gxbLqFkHPs5/u2dDo4GWZmYDHIWSRRTVlVEoVHJVYHOZPxio6N611pgSvh/1yM5XbYRK08kKF5mbLIxEw62VMDfZ1DutYEtyOmQsVBmEiducfklQQS6JVMpdnnENHOksJU3H9UXIvEeA+N+/SZY4ane1UIFFieZb/zak5y9gZC1Iluwv0vIiy4lZU3MlZBra/iCs1/c4K5Y7rAiI9olydg229G00cK17E+JwnuJoKaCPGBaxQoLJpUgU2f5JOBHzXOXn2WuZ8MMCAwEAAaOCAcQwggHAMA4GA1UdDwEB/wQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKoMOAwMEAQEwHwYDVR0jBBgwFoAUpowWM3y46DVnBj5eQVdVo
>
> q80UGgwHQYDVR0OBBYEFLoJ735qnU1Q4y8AEtPdJI2lqQVfMF4GA1UdIARXMFUwUwYHKoMOAwMCBDBIMCEGCCsGAQUFBwIBFhVodHRwOi8vcGtpLmdvdi5rei9jcHMwIwYIKwYBBQUHAgIwFwwVaHR0cDovL3BraS5nb3Yua3ovY3BzMDwGA1UdHwQ1MDMwMaAvoC2GK2h0dHA6Ly90ZXN0LnBraS5nb3Yua3ovY3JsL25jYV9yc2FfdGVzdC5jcmwwPgYDVR0uBDcwNTAzoDGgL4YtaHR0cDovL3Rlc3QucGtpLmdvdi5rei9jcmwvbmNhX2RfcnNhX3Rlc3QuY3JsMHEGCCsGAQUFBwEBBGUwYzA4BggrBgEFBQcwAoYsaHR0cDovL3Rlc3QucGtpLmdvdi5rei9jZXJ0L25jYV9yc2FfdGVzdC5jZXIwJwYIKwYBBQUHMAGGG2h0dHA6Ly90ZXN0LnBraS5nb3Yua3ovb2NzcDANBgkqhkiG9w0BAQsFAAOCAgEACnYpytjbyuV3sRojnlyxEC7HG7BgcDDy6rS/kfOtK6X5+MGCT/zvwksZOumN5Jg5TPdJuKt3ebKJGIBVr474mHFk7Nq0F8WxuAWNffjoL0Lvcuon4Zwq/W8h4t6PYutD4NEauIPEa8X8BGPgMn+YqOc3sfEruXh8rmcSJ/zuT7uw1wD6ZQlNsniioengKIgapDVDHuzoV/r//rEANwIpntAyjXFh+fjx+CDCx2sLxYjlVgyxNzT53mD6ZqsMlg6NrajJe/GvS0A38jKNyxW/DPX06NToWP/hu7M4P2/WiskjKVgOxqQcc4yzTfKV41DmEmGGC7sT1r3YeZ4dH/KQRpjowBOSKmUZq4/XR0yXXhpTDtiiRwXkQgM1p4SKE19bBqGuc76lDgmffPPPj4B+3HZqaprIIDG3YA3/W4rwUoWBQPGGCXpOBvGEQptEHItx4YiEZTQuvdCtlW585kUyol39sK
>
> v2uIo/FgycBd8NufOInGCLUgpZec4zVLZN9Shj+M20BMUh+SiGoL/kJAi2XdM922U3po9a2FbULvJfOlsFY2Z6n+TUZZVXBCUIEE6Ek4tTIGjHWj7uQVGLjw0PcHf11CtrMZO7Y+OTBb/Y0oyUY9JOyzSqhj4rt4nNkzR1vMGVYMNISoXbDgYBaAKuv2oSpG6yQdlufS8M/YWxAWw=]
> is valid.
> (Wed Mar 25 11:34:44 2020) [sssd[ssh]] [ssh_protocol_done] (0x4000): Sending
> reply: success
> (Wed Mar 25 11:34:44 2020) [sssd[ssh]] [client_recv] (0x0200): Client
> disconnected!
> (Wed Mar 25 11:34:44 2020) [sssd[ssh]] [client_close_fn] (0x2000): Terminated
> client [0x561dbac3a190][18]
>
>
> p11_child-log
> # log file 2...
> write(2, "(Wed Mar 25 11:34:44 2020) [[sssd[p11_child[20372 [do_work]
> (0x0400): Certificate is valid.\n", 96) = 96
> # log file 1...
> write(7, "(Wed Mar 25 11:34:44 2020) [sssd[ssh]] [child_sig_handler]
> (0x1000): Waiting for child [20372].\n", 96) = 96
> wait4(20372, [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], WNOHANG, NULL) = 20372
> stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=1931, ...}) = 0
> stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=1931, ...}) = 0
> write(7, "(Wed Mar 25 11:34:44 2020) [sssd[ssh]] [child_sig_handler]
> (0x0100): child [20372] finished successfully.\n", 106) = 106
> close(19) = 0
> close(22) = 0
> stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=1931, ...}) = 0
> stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=1931, ...}) = 0
> write(7, "(Wed Mar 25 11:34:44 2020) [sssd[ssh]] [cert_to_ssh_key_done]
> (0x1000): Certificate
>
[SSSD-users] Re: SSSD and PKI: capability of checking trust/validation/revocation
> On Tue, Mar 24, 2020 at 02:20:17PM -, Hristina Marosevic wrote:
>
> Hi,
>
> did you change the 'ca_db' option in sssd.conf? If looks like a wrong
> path '/home/oracle' is used for the NSS database.
>
> bye,
> Sumit
Hello,
It was anold configuration - thank you for noticing!
After deleting the ca_db option value from the sssd configuration i.e. now,
when it has the default value - /etc/pki/nssdb user authentication passed
successfully.
/var/log/sssd/sssd_ssh.log
...
(Wed Mar 25 11:34:44 2020) [sssd[ssh]] [child_sig_handler] (0x1000): Waiting
for child [20372].
(Wed Mar 25 11:34:44 2020) [sssd[ssh]] [child_sig_handler] (0x0100): child
[20372] finished successfully.
(Wed Mar 25 11:34:44 2020) [sssd[ssh]] [cert_to_ssh_key_done] (0x1000):
Certificate
[MIIGMTCCBBmgAwIBAgIUfYWZ212wMteK0jjnnXd6dqlqkIkwDQYJKoZIhvcNAQELBQAwLTELMAkGA1UEBhMCS1oxHjAcBgNVBAMMFdKw0JrQniAzLjAgKFJTQSBURVNUKTAeFw0xOTA0MDQwODU0NTRaFw0yMTA0MDMwODU0NTRaMIGvMSIwIAYDVQQDDBnQotCV0KHQotCi0J7QkiDQotCV0KHQotCiMRcwFQYDVQQEDA7QotCV0KHQotCi0J7QkjEYMBYGA1UEBRMPSUlOMTIzNDU2Nzg5MDEyMQswCQYDVQQGEwJLWjEVMBMGA1UEBwwM0JDQodCi0JDQndCQMRUwEwYDVQQIDAzQkNCh0KLQkNCd0JAxGzAZBgNVBCoMEtCi0JXQodCi0KLQntCS0JjQpzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAI9kXtq5MjdOP+6uelfthsbeOFCrjPQdypbwkDgIoas054FJvKHgfX9apVHvbMrNK7/atFMbfrv1gxbLqFkHPs5/u2dDo4GWZmYDHIWSRRTVlVEoVHJVYHOZPxio6N611pgSvh/1yM5XbYRK08kKF5mbLIxEw62VMDfZ1DutYEtyOmQsVBmEiducfklQQS6JVMpdnnENHOksJU3H9UXIvEeA+N+/SZY4ane1UIFFieZb/zak5y9gZC1Iluwv0vIiy4lZU3MlZBra/iCs1/c4K5Y7rAiI9olydg229G00cK17E+JwnuJoKaCPGBaxQoLJpUgU2f5JOBHzXOXn2WuZ8MMCAwEAAaOCAcQwggHAMA4GA1UdDwEB/wQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKoMOAwMEAQEwHwYDVR0jBBgwFoAUpowWM3y46DVnBj5eQVdVo
q80UGgwHQYDVR0OBBYEFLoJ735qnU1Q4y8AEtPdJI2lqQVfMF4GA1UdIARXMFUwUwYHKoMOAwMCBDBIMCEGCCsGAQUFBwIBFhVodHRwOi8vcGtpLmdvdi5rei9jcHMwIwYIKwYBBQUHAgIwFwwVaHR0cDovL3BraS5nb3Yua3ovY3BzMDwGA1UdHwQ1MDMwMaAvoC2GK2h0dHA6Ly90ZXN0LnBraS5nb3Yua3ovY3JsL25jYV9yc2FfdGVzdC5jcmwwPgYDVR0uBDcwNTAzoDGgL4YtaHR0cDovL3Rlc3QucGtpLmdvdi5rei9jcmwvbmNhX2RfcnNhX3Rlc3QuY3JsMHEGCCsGAQUFBwEBBGUwYzA4BggrBgEFBQcwAoYsaHR0cDovL3Rlc3QucGtpLmdvdi5rei9jZXJ0L25jYV9yc2FfdGVzdC5jZXIwJwYIKwYBBQUHMAGGG2h0dHA6Ly90ZXN0LnBraS5nb3Yua3ovb2NzcDANBgkqhkiG9w0BAQsFAAOCAgEACnYpytjbyuV3sRojnlyxEC7HG7BgcDDy6rS/kfOtK6X5+MGCT/zvwksZOumN5Jg5TPdJuKt3ebKJGIBVr474mHFk7Nq0F8WxuAWNffjoL0Lvcuon4Zwq/W8h4t6PYutD4NEauIPEa8X8BGPgMn+YqOc3sfEruXh8rmcSJ/zuT7uw1wD6ZQlNsniioengKIgapDVDHuzoV/r//rEANwIpntAyjXFh+fjx+CDCx2sLxYjlVgyxNzT53mD6ZqsMlg6NrajJe/GvS0A38jKNyxW/DPX06NToWP/hu7M4P2/WiskjKVgOxqQcc4yzTfKV41DmEmGGC7sT1r3YeZ4dH/KQRpjowBOSKmUZq4/XR0yXXhpTDtiiRwXkQgM1p4SKE19bBqGuc76lDgmffPPPj4B+3HZqaprIIDG3YA3/W4rwUoWBQPGGCXpOBvGEQptEHItx4YiEZTQuvdCtlW585kUyol39sK
v2uIo/FgycBd8NufOInGCLUgpZec4zVLZN9Shj+M20BMUh+SiGoL/kJAi2XdM922U3po9a2FbULvJfOlsFY2Z6n+TUZZVXBCUIEE6Ek4tTIGjHWj7uQVGLjw0PcHf11CtrMZO7Y+OTBb/Y0oyUY9JOyzSqhj4rt4nNkzR1vMGVYMNISoXbDgYBaAKuv2oSpG6yQdlufS8M/YWxAWw=]
is valid.
(Wed Mar 25 11:34:44 2020) [sssd[ssh]] [ssh_protocol_done] (0x4000): Sending
reply: success
(Wed Mar 25 11:34:44 2020) [sssd[ssh]] [client_recv] (0x0200): Client
disconnected!
(Wed Mar 25 11:34:44 2020) [sssd[ssh]] [client_close_fn] (0x2000): Terminated
client [0x561dbac3a190][18]
p11_child-log
# log file 2...
write(2, "(Wed Mar 25 11:34:44 2020) [[sssd[p11_child[20372 [do_work]
(0x0400): Certificate is valid.\n", 96) = 96
# log file 1...
write(7, "(Wed Mar 25 11:34:44 2020) [sssd[ssh]] [child_sig_handler] (0x1000):
Waiting for child [20372].\n", 96) = 96
wait4(20372, [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], WNOHANG, NULL) = 20372
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=1931, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=1931, ...}) = 0
write(7, "(Wed Mar 25 11:34:44 2020) [sssd[ssh]] [child_sig_handler] (0x0100):
child [20372] finished successfully.\n", 106) = 106
close(19) = 0
close(22) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=1931, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=1931, ...}) = 0
write(7, "(Wed Mar 25 11:34:44 2020) [sssd[ssh]] [cert_to_ssh_key_done]
(0x1000): Certificate
[SSSD-users] Re: SSSD and PKI: capability of checking trust/validation/revocation
On Tue, Mar 24, 2020 at 02:20:17PM -, Hristina Marosevic wrote:
> > On Wed, Mar 18, 2020 at 10:42:52AM -, Hristina Marosevic wrote:
> >
> > Hi,
> >
> > can you send the output of
> >
> > ls -al /etc/pki/nssdb
> >
> > and
> >
> > certutil -L -d /etc/pki/nssdb -h all
> >
> > bye,
> > Sumit
>
>
> Hello Sumit,
>
> Somehow, today I didn't get any error when executing certutil command. In
> meanwhile I didn't do anything different, except for the sssd and sshd
> restart.
> Few days ago, I couldn't add nor list the existing certificates in the nssdb
> using certutil.
> Now, when this is working, I added the two CA certs in the chain of the
> user's public certificate. One is intermediate, and one is root CA.
> Too add the intermediate and root CA certs in the nssdb, I used der fomrats
> of the certificates and the following command for each one of them:
> certutil -A -n "CA cert nickname" -t C,C,C -i /path/to/CA_cert_file -d
> /etc/pki/nssdb
>
> You asked me to list the nssdb directory. Here is the result:
> $ ls -al /etc/pki/nssdb
> total 132
> drwxr-xr-x. 2 root root 4096 Mar 6 10:34 .
> drwxr-xr-x. 10 root root 4096 Jan 24 2019 ..
> -rw-r--r-- 1 root root 65536 Aug 7 2019 cert8.db
> -rw-r--r--. 1 root root 9216 Jan 24 2019 cert9.db
> -rw-r--r-- 1 root root 0 Mar 6 10:34 i#uiap
> -rw-r--r-- 1 root root 16384 Aug 7 2019 key3.db
> -rw-r--r--. 1 root root 11264 Jan 24 2019 key4.db
> -rw-r--r-- 1 root root 451 Aug 7 2019 pkcs11.txt
> -rw-r--r-- 1 root root 16384 Aug 7 2019 secmod.db
>
> After adding the certificates from the chain of the user's public
> certificate, following command:
> certutil -L -d /etc/pki/nssdb -h all
> resulted with:
>
> Certificate Nickname Trust Attributes
>
> SSL,S/MIME,JAR/XPI
>
> root_KZ C,C,C
> intermediate_KZ C,C,C
>
>
> In the sssd section of the sssd.conf file the value for
> certificate_verification is no_ocsp. Using strace, recorded log of the
> p11_child about the pki authentication attempt is:
>
> .
> stat("/home/oracle/secmod.db", 0x7ffcf6ee2350) = -1 ENOENT (No such file or
> directory)
> open("/home/oracle/secmod.db", O_RDONLY) = -1 ENOENT (No such file or
> directory)
> open("/proc/sys/crypto/fips_enabled", O_RDONLY) = 4
> fstat(4, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
> mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
> 0x7f2379ad3000
> read(4, "0\n", 1024)= 2
> close(4)= 0
> munmap(0x7f2379ad3000, 4096)= 0
> stat("/home/oracle/cert8.db", 0x7ffcf6ee1f30) = -1 ENOENT (No such file or
> directory)
> open("/home/oracle/cert8.db", O_RDONLY) = -1 ENOENT (No such file or
> directory)
> stat("/home/oracle/cert7.db", 0x7ffcf6ee1f50) = -1 ENOENT (No such file or
> directory)
> open("/home/oracle/cert7.db", O_RDONLY) = -1 ENOENT (No such file or
> directory)
Hi,
did you change the 'ca_db' option in sssd.conf? If looks like a wrong
path '/home/oracle' is used for the NSS database.
bye,
Sumit
> access("/etc/pki/nss-legacy/nss-rhel7.config", R_OK) = 0
> open("/proc/sys/crypto/fips_enabled", O_RDONLY) = 4
> fstat(4, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
> mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
> 0x7f2379ad3000
> read(4, "0\n", 1024)= 2
> close(4)= 0
> munmap(0x7f2379ad3000, 4096)= 0
> open("/etc/pki/nss-legacy/nss-rhel7.config", O_RDONLY) = 4
> fstat(4, {st_mode=S_IFREG|0644, st_size=257, ...}) = 0
> mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
> 0x7f2379ad3000
> read(4, "# To re-enable legacy algorithms, edit this file\n# Note that the
> last empty line in this file must be
> preserved\nlibrary=\nname=Policy\nNSS=flags=policyOnly,moduleDB\nconfig=\"disallow=MD5:RC4
> allow=DH-MIN=1023:DSA-MIN=1023:RSA-MIN=1023:TLS-VERSION-MIN=tls1.0\"\n\n",
> 4096) = 257
> stat("/etc/sysconfig/64bit_strstr_via_64bit_strstr_sse2_unaligned",
> {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
> read(4, "", 4096) = 0
> close(4)= 0
> munmap(0x7f2379ad3000, 4096)= 0
> open("/proc/sys/crypto/fips_enabled", O_RDONLY) = 4
> fstat(4, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
> mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
> 0x7f2379ad3000
> read(4, "0\n", 1024)= 2
> close(4)= 0
> munmap(0x7f2379ad3000, 4096)= 0
> stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=1931, ...}) = 0
> stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=1931, ...}) = 0
> write(2, "(Tue Mar 24 13:36:19 2020) [[sssd[p11_child[5538
>
[SSSD-users] Re: SSSD and PKI: capability of checking trust/validation/revocation
> On Tue, Mar 24, 2020 at 02:20:17PM -, Hristina Marosevic wrote:
>
> Hi,
>
> please try to add them with
>
> certutil -A -n "CA cert nickname" -t CT,C,C -i /path/to/CA_cert_file -d
> /etc/pki/nssdb
>
> (please note the additional 'T' for 'trusted CA for client
> authentication') and check if this makes a difference.
>
> bye,
> Sumit
Hello,
I got the same error:
write(2, "(Tue Mar 24 15:56:24 2020) [[sssd[p11_child[28171
[do_verification] (0x0040): Certificate
[(null)][givenName=\320\242\320\225\320\241\320\242\320\242\320\236\320\222\320\230\320\247,ST=\320\220\320\241\320\242\320\220\320\235\320\220,L=\320\220\320\241\320\242\320\220\320\235\320\220,C=KZ,serialNumber=IIN123456789012,SN=\320\242\320\225\320\241\320\242\320\242\320\236\320\222,CN=\320\242\320\225\320\241\320\242\320\242\320\236\320\222
\320\242\320\225\320\241\320\242\320\242] not valid [-8179][Peer's Certificate
issuer is not recognized.].\n", 310) = 310
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=1931, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=1931, ...}) = 0
write(2, "(Tue Mar 24 15:56:24 2020) [[sssd[p11_child[28171 [do_work]
(0x0400): Certificate is NOT valid.\n", 100) = 100
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=1931, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=1931, ...}) = 0
write(2, "(Tue Mar 24 15:56:24 2020) [[sssd[p11_child[28171 [main]
(0x0040): do_work failed.\n", 87) = 87
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=1931, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=1931, ...}) = 0
write(2, "(Tue Mar 24 15:56:24 2020) [[sssd[p11_child[28171 [main]
(0x0020): p11_child failed!\n", 89) = 89
close(1)= 0
exit_group(1) = ?
+++ exited with 1 +++
What I did is:
added the CA certs once again, as trusted:
certutil -L -d /etc/pki/nssdb -h all
Certificate Nickname Trust Attributes
SSL,S/MIME,JAR/XPI
root_KZ CT,C,C
intermediate_KZ CT,C,C
and stoppped sssd, emptyed its cache, started sssd, restarted sshd, afterwards.
BR,
Hristina M.
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
[SSSD-users] Re: SSSD and PKI: capability of checking trust/validation/revocation
On Tue, Mar 24, 2020 at 02:20:17PM -, Hristina Marosevic wrote:
> > On Wed, Mar 18, 2020 at 10:42:52AM -, Hristina Marosevic wrote:
> >
> > Hi,
> >
> > can you send the output of
> >
> > ls -al /etc/pki/nssdb
> >
> > and
> >
> > certutil -L -d /etc/pki/nssdb -h all
> >
> > bye,
> > Sumit
>
>
> Hello Sumit,
>
> Somehow, today I didn't get any error when executing certutil command. In
> meanwhile I didn't do anything different, except for the sssd and sshd
> restart.
> Few days ago, I couldn't add nor list the existing certificates in the nssdb
> using certutil.
> Now, when this is working, I added the two CA certs in the chain of the
> user's public certificate. One is intermediate, and one is root CA.
> Too add the intermediate and root CA certs in the nssdb, I used der fomrats
> of the certificates and the following command for each one of them:
> certutil -A -n "CA cert nickname" -t C,C,C -i /path/to/CA_cert_file -d
> /etc/pki/nssdb
Hi,
please try to add them with
certutil -A -n "CA cert nickname" -t CT,C,C -i /path/to/CA_cert_file -d
/etc/pki/nssdb
(please note the additional 'T' for 'trusted CA for client
authentication') and check if this makes a difference.
bye,
Sumit
>
> You asked me to list the nssdb directory. Here is the result:
> $ ls -al /etc/pki/nssdb
> total 132
> drwxr-xr-x. 2 root root 4096 Mar 6 10:34 .
> drwxr-xr-x. 10 root root 4096 Jan 24 2019 ..
> -rw-r--r-- 1 root root 65536 Aug 7 2019 cert8.db
> -rw-r--r--. 1 root root 9216 Jan 24 2019 cert9.db
> -rw-r--r-- 1 root root 0 Mar 6 10:34 i#uiap
> -rw-r--r-- 1 root root 16384 Aug 7 2019 key3.db
> -rw-r--r--. 1 root root 11264 Jan 24 2019 key4.db
> -rw-r--r-- 1 root root 451 Aug 7 2019 pkcs11.txt
> -rw-r--r-- 1 root root 16384 Aug 7 2019 secmod.db
>
> After adding the certificates from the chain of the user's public
> certificate, following command:
> certutil -L -d /etc/pki/nssdb -h all
> resulted with:
>
> Certificate Nickname Trust Attributes
>
> SSL,S/MIME,JAR/XPI
>
> root_KZ C,C,C
> intermediate_KZ C,C,C
>
>
> In the sssd section of the sssd.conf file the value for
> certificate_verification is no_ocsp. Using strace, recorded log of the
> p11_child about the pki authentication attempt is:
>
> .
> stat("/home/oracle/secmod.db", 0x7ffcf6ee2350) = -1 ENOENT (No such file or
> directory)
> open("/home/oracle/secmod.db", O_RDONLY) = -1 ENOENT (No such file or
> directory)
> open("/proc/sys/crypto/fips_enabled", O_RDONLY) = 4
> fstat(4, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
> mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
> 0x7f2379ad3000
> read(4, "0\n", 1024)= 2
> close(4)= 0
> munmap(0x7f2379ad3000, 4096)= 0
> stat("/home/oracle/cert8.db", 0x7ffcf6ee1f30) = -1 ENOENT (No such file or
> directory)
> open("/home/oracle/cert8.db", O_RDONLY) = -1 ENOENT (No such file or
> directory)
> stat("/home/oracle/cert7.db", 0x7ffcf6ee1f50) = -1 ENOENT (No such file or
> directory)
> open("/home/oracle/cert7.db", O_RDONLY) = -1 ENOENT (No such file or
> directory)
> access("/etc/pki/nss-legacy/nss-rhel7.config", R_OK) = 0
> open("/proc/sys/crypto/fips_enabled", O_RDONLY) = 4
> fstat(4, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
> mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
> 0x7f2379ad3000
> read(4, "0\n", 1024)= 2
> close(4)= 0
> munmap(0x7f2379ad3000, 4096)= 0
> open("/etc/pki/nss-legacy/nss-rhel7.config", O_RDONLY) = 4
> fstat(4, {st_mode=S_IFREG|0644, st_size=257, ...}) = 0
> mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
> 0x7f2379ad3000
> read(4, "# To re-enable legacy algorithms, edit this file\n# Note that the
> last empty line in this file must be
> preserved\nlibrary=\nname=Policy\nNSS=flags=policyOnly,moduleDB\nconfig=\"disallow=MD5:RC4
> allow=DH-MIN=1023:DSA-MIN=1023:RSA-MIN=1023:TLS-VERSION-MIN=tls1.0\"\n\n",
> 4096) = 257
> stat("/etc/sysconfig/64bit_strstr_via_64bit_strstr_sse2_unaligned",
> {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
> read(4, "", 4096) = 0
> close(4)= 0
> munmap(0x7f2379ad3000, 4096)= 0
> open("/proc/sys/crypto/fips_enabled", O_RDONLY) = 4
> fstat(4, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
> mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
> 0x7f2379ad3000
> read(4, "0\n", 1024)= 2
> close(4)= 0
> munmap(0x7f2379ad3000, 4096)= 0
> stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=1931, ...}) = 0
> stat("/etc/localtime",
[SSSD-users] Re: SSSD and PKI: capability of checking trust/validation/revocation
> On Wed, Mar 18, 2020 at 10:42:52AM -, Hristina Marosevic wrote:
>
> Hi,
>
> can you send the output of
>
> ls -al /etc/pki/nssdb
>
> and
>
> certutil -L -d /etc/pki/nssdb -h all
>
> bye,
> Sumit
Hello Sumit,
Somehow, today I didn't get any error when executing certutil command. In
meanwhile I didn't do anything different, except for the sssd and sshd restart.
Few days ago, I couldn't add nor list the existing certificates in the nssdb
using certutil.
Now, when this is working, I added the two CA certs in the chain of the user's
public certificate. One is intermediate, and one is root CA.
Too add the intermediate and root CA certs in the nssdb, I used der fomrats of
the certificates and the following command for each one of them:
certutil -A -n "CA cert nickname" -t C,C,C -i /path/to/CA_cert_file -d
/etc/pki/nssdb
You asked me to list the nssdb directory. Here is the result:
$ ls -al /etc/pki/nssdb
total 132
drwxr-xr-x. 2 root root 4096 Mar 6 10:34 .
drwxr-xr-x. 10 root root 4096 Jan 24 2019 ..
-rw-r--r-- 1 root root 65536 Aug 7 2019 cert8.db
-rw-r--r--. 1 root root 9216 Jan 24 2019 cert9.db
-rw-r--r-- 1 root root 0 Mar 6 10:34 i#uiap
-rw-r--r-- 1 root root 16384 Aug 7 2019 key3.db
-rw-r--r--. 1 root root 11264 Jan 24 2019 key4.db
-rw-r--r-- 1 root root 451 Aug 7 2019 pkcs11.txt
-rw-r--r-- 1 root root 16384 Aug 7 2019 secmod.db
After adding the certificates from the chain of the user's public certificate,
following command:
certutil -L -d /etc/pki/nssdb -h all
resulted with:
Certificate Nickname Trust Attributes
SSL,S/MIME,JAR/XPI
root_KZ C,C,C
intermediate_KZ C,C,C
In the sssd section of the sssd.conf file the value for
certificate_verification is no_ocsp. Using strace, recorded log of the
p11_child about the pki authentication attempt is:
.
stat("/home/oracle/secmod.db", 0x7ffcf6ee2350) = -1 ENOENT (No such file or
directory)
open("/home/oracle/secmod.db", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/proc/sys/crypto/fips_enabled", O_RDONLY) = 4
fstat(4, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x7f2379ad3000
read(4, "0\n", 1024)= 2
close(4)= 0
munmap(0x7f2379ad3000, 4096)= 0
stat("/home/oracle/cert8.db", 0x7ffcf6ee1f30) = -1 ENOENT (No such file or
directory)
open("/home/oracle/cert8.db", O_RDONLY) = -1 ENOENT (No such file or directory)
stat("/home/oracle/cert7.db", 0x7ffcf6ee1f50) = -1 ENOENT (No such file or
directory)
open("/home/oracle/cert7.db", O_RDONLY) = -1 ENOENT (No such file or directory)
access("/etc/pki/nss-legacy/nss-rhel7.config", R_OK) = 0
open("/proc/sys/crypto/fips_enabled", O_RDONLY) = 4
fstat(4, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x7f2379ad3000
read(4, "0\n", 1024)= 2
close(4)= 0
munmap(0x7f2379ad3000, 4096)= 0
open("/etc/pki/nss-legacy/nss-rhel7.config", O_RDONLY) = 4
fstat(4, {st_mode=S_IFREG|0644, st_size=257, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x7f2379ad3000
read(4, "# To re-enable legacy algorithms, edit this file\n# Note that the last
empty line in this file must be
preserved\nlibrary=\nname=Policy\nNSS=flags=policyOnly,moduleDB\nconfig=\"disallow=MD5:RC4
allow=DH-MIN=1023:DSA-MIN=1023:RSA-MIN=1023:TLS-VERSION-MIN=tls1.0\"\n\n",
4096) = 257
stat("/etc/sysconfig/64bit_strstr_via_64bit_strstr_sse2_unaligned",
{st_mode=S_IFREG|0644, st_size=0, ...}) = 0
read(4, "", 4096) = 0
close(4)= 0
munmap(0x7f2379ad3000, 4096)= 0
open("/proc/sys/crypto/fips_enabled", O_RDONLY) = 4
fstat(4, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x7f2379ad3000
read(4, "0\n", 1024)= 2
close(4)= 0
munmap(0x7f2379ad3000, 4096)= 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=1931, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=1931, ...}) = 0
write(2, "(Tue Mar 24 13:36:19 2020) [[sssd[p11_child[5538
[do_verification] (0x0040): Certificate
[(null)][givenName=\320\242\320\225\320\241\320\242\320\242\320\236\320\222\320\230\320\247,ST=\320\220\320\241\320\242\320\220\320\235\320\220,L=\320\220\320\241\320\242\320\220\320\235\320\220,C=KZ,serialNumber=IIN123456789012,SN=\320\242\320\225\320\241\320\242\320\242\320\236\320\222,CN=\320\242\320\225\320\241\320\242\320\242\320\236\320\222
\320\242\320\225\320\241\320\242\320\242] not valid
[SSSD-users] Re: SSSD and PKI: capability of checking trust/validation/revocation
On Wed, Mar 18, 2020 at 10:42:52AM -, Hristina Marosevic wrote: > > On Tue, Mar 17, 2020 at 02:17:06PM -, Hristina Marosevic wrote: > > > > Hi, > > > > about 'certificate_verification = no_verification', there is an issue > > which was fixed by > > https://pagure.io/SSSD/sssd/c/31ebf912d6426aea446b2bdae919d4e33b0c95be > > but the fix is not in the build you are using. So better continue with > > 'certificate_verification = no_ocsp'. > > > > > > Please add all CA certificates to the NSS database /etc/pki/nssdb with > > the help of the certutil command: > > > > certutil -A -n "CA cert nickname" -t C,C,C -i /path/to/CA_cert_file -d > > /etc/pki/nssdb > > > > each CA certificate should get an individual nickname. If your > > CA_cert_file is in PEM format (with BEGIN CERTIFICATE and END > > CERTIFICATE lines) you might need to add a '-a' option as well. > > > > If there are still issues please send the strace output. > > > > HTH > > > > bye, > > Sumit > > > Hello, > > I just tried to add the certificates (intermediate and root CA) to the > database and I got the error: "certutil: function failed: > SEC_ERROR_LEGACY_DATABASE: The certificate/key database is in an old, > unsupported format." for each one. Hi, can you send the output of ls -al /etc/pki/nssdb and certutil -L -d /etc/pki/nssdb -h all bye, Sumit > > The confirugation in sssd is still not changed and no other step is executed > due to this error. I think it is important to solve this problem first, and > that this one is not related to the sssd configuration and option > certificate_verification in the config file. > Can you propose me a solution for this? > > > BR, > Hristina > ___ > sssd-users mailing list -- sssd-users@lists.fedorahosted.org > To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org ___ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
[SSSD-users] Re: SSSD and PKI: capability of checking trust/validation/revocation
> On Tue, Mar 17, 2020 at 02:17:06PM -, Hristina Marosevic wrote: > > Hi, > > about 'certificate_verification = no_verification', there is an issue > which was fixed by > https://pagure.io/SSSD/sssd/c/31ebf912d6426aea446b2bdae919d4e33b0c95be > but the fix is not in the build you are using. So better continue with > 'certificate_verification = no_ocsp'. > > > Please add all CA certificates to the NSS database /etc/pki/nssdb with > the help of the certutil command: > > certutil -A -n "CA cert nickname" -t C,C,C -i /path/to/CA_cert_file -d > /etc/pki/nssdb > > each CA certificate should get an individual nickname. If your > CA_cert_file is in PEM format (with BEGIN CERTIFICATE and END > CERTIFICATE lines) you might need to add a '-a' option as well. > > If there are still issues please send the strace output. > > HTH > > bye, > Sumit Hello, I just tried to add the certificates (intermediate and root CA) to the database and I got the error: "certutil: function failed: SEC_ERROR_LEGACY_DATABASE: The certificate/key database is in an old, unsupported format." for each one. The confirugation in sssd is still not changed and no other step is executed due to this error. I think it is important to solve this problem first, and that this one is not related to the sssd configuration and option certificate_verification in the config file. Can you propose me a solution for this? BR, Hristina ___ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
[SSSD-users] Re: SSSD and PKI: capability of checking trust/validation/revocation
On Tue, Mar 17, 2020 at 02:17:06PM -, Hristina Marosevic wrote: > > On Tue, Mar 17, 2020 at 11:17:34AM -, Hristina Marosevic wrote: > > > > > > Hi, > > > > I'm sorry, I haven't read one of your earlier emails carefully enough, > > please do not use "certificate_verification = no_ocsp, no_verification" > > but only > > > > certificate_verification = no_verification > > > > 'no_ocsp' implies verification but without OCSP so using both options is > > an inconsistency. > > > > bye, > > Sumit Hi, about 'certificate_verification = no_verification', there is an issue which was fixed by https://pagure.io/SSSD/sssd/c/31ebf912d6426aea446b2bdae919d4e33b0c95be but the fix is not in the build you are using. So better continue with 'certificate_verification = no_ocsp'. > > > Besides this, I thought of another scenario which may help me validate the > certificate. I can add certificate_verification=no_ocsp instead of > certificate_verification=no_verification in [sssd] section of sssd.conf file, > and store the trust on the server - in that case, where should I store the > trust and is it enought just to provide the root CA certificate, or it is > needed to store the intermediate CAs certificates? Also, in which format? Please add all CA certificates to the NSS database /etc/pki/nssdb with the help of the certutil command: certutil -A -n "CA cert nickname" -t C,C,C -i /path/to/CA_cert_file -d /etc/pki/nssdb each CA certificate should get an individual nickname. If your CA_cert_file is in PEM format (with BEGIN CERTIFICATE and END CERTIFICATE lines) you might need to add a '-a' option as well. If there are still issues please send the strace output. HTH bye, Sumit > > If this won't work, I really have no idea of any other options for testing > the PKI based authentication, so if you have any other ideas, I will > appreciate if you share it. > > > Thank you for your help! > ___ > sssd-users mailing list -- sssd-users@lists.fedorahosted.org > To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org ___ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
[SSSD-users] Re: SSSD and PKI: capability of checking trust/validation/revocation
> On Tue, Mar 17, 2020 at 11:17:34AM -, Hristina Marosevic wrote: > > > Hi, > > I'm sorry, I haven't read one of your earlier emails carefully enough, > please do not use "certificate_verification = no_ocsp, no_verification" > but only > > certificate_verification = no_verification > > 'no_ocsp' implies verification but without OCSP so using both options is > an inconsistency. > > bye, > Sumit Besides this, I thought of another scenario which may help me validate the certificate. I can add certificate_verification=no_ocsp instead of certificate_verification=no_verification in [sssd] section of sssd.conf file, and store the trust on the server - in that case, where should I store the trust and is it enought just to provide the root CA certificate, or it is needed to store the intermediate CAs certificates? Also, in which format? If this won't work, I really have no idea of any other options for testing the PKI based authentication, so if you have any other ideas, I will appreciate if you share it. Thank you for your help! ___ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
[SSSD-users] Re: SSSD and PKI: capability of checking trust/validation/revocation
On Tue, Mar 17, 2020 at 11:17:34AM -, Hristina Marosevic wrote:
> > On Tue, Mar 17, 2020 at 09:41:16AM -, Hristina Marosevic wrote:
> >
> >
> > Hi,
> >
> > so p11_child is really called but as you said earlier there are no logs.
> >
> > This might e.g. be a permission issue, please check the permissions on
> > /var/log/sssd if you see anything odd. For me it looks like:
> >
> > drwxr-x---. 2 root root system_u:object_r:sssd_var_log_t:s04096
> > Mar 17 09:09 .
> > drwxr-xr-x. 12 root root system_u:object_r:var_log_t:s0 4096
> > Mar 15 03:27 ..
> > -rw---. 1 root root system_u:object_r:sssd_var_log_t:s0 221452
> > Mar 17 09:19
> > krb5_child.log
> > -rw---. 1 root root system_u:object_r:sssd_var_log_t:s0 1069023
> > Mar 17 11:16
> > ldap_child.log
> > -rw---. 1 root root system_u:object_r:sssd_var_log_t:s0 0
> > Mar 16 10:31
> > p11_child.log
> > -rw---. 1 root root system_u:object_r:sssd_var_log_t:s0 14816
> > Mar 17 09:19
> > selinux_child.log
> > -rw---. 1 root root system_u:object_r:sssd_var_log_t:s0 623
> > Mar 16 10:31
> > sssd.log
> > -rw---. 1 root root system_u:object_r:sssd_var_log_t:s0 0
> > Mar 16 10:31
> > sssd_nss.log
> > -rw---. 1 root root system_u:object_r:sssd_var_log_t:s0 0
> > Mar 16 10:31
> > sssd_pac.log
> > -rw---. 1 root root system_u:object_r:sssd_var_log_t:s0 490679
> > Mar 17 11:18
> > sssd_pam.log
> > -rw---. 1 root root system_u:object_r:sssd_var_log_t:s0 6723166
> > Mar 17 11:18
> > sssd_ipa.devel.log
> > -rw---. 1 root root system_u:object_r:sssd_var_log_t:s0 0
> > Mar 16 10:31
> > sssd_ssh.log
> > -rw---. 1 root root system_u:object_r:sssd_var_log_t:s0 0
> > Mar 16 10:31
> > sssd_sudo.log
> >
> >
> > The next step would be to check what failed with strace. For this call
> >
> > mkdir /tmp/strace_data
> > strace -ff -s 1024 -o /tmp/strace_data/strace_ -p $(pidof
> > /usr/libexec/sssd/sssd_ssh)
> >
> > in one terminal can call 'sss_ssh_authorizedkeys IIN321' in a
> > different
> > terminal. After calling sss_ssh_authorizedkeys you can stop the strace
> > command
> > with CTRL-C. In /tmp/strace_data there should be at least 2 files, one of
> > the
> > main sssd_ssh process and the other for p11_child, please send both (if
> > there
> > are more than 2 please send all).
> >
> > bye,
> > Sumit
>
>
> There are two files:
>
> after executing strace -ff -s 1024 -o /tmp/strace_data/strace_ -p $(pidof
> /usr/libexec/sssd/sssd_ssh) strace_.24180 was generated.
> write(2, "(Tue Mar 17 12:09:26 2020) [[sssd[p11_child[5539
> [parse_cert_verify_opts] (0x4000): Found 'no_ocsp' option, disabling
> OCSP.\n", 128) = 128
> stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=1931, ...}) = 0
> stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=1931, ...}) = 0
> write(2, "(Tue Mar 17 12:09:26 2020) [[sssd[p11_child[5539
> [parse_cert_verify_opts] (0x0020): Found 'no_verification' option, disabling
> verification completely. This should not be used in production.\n", 194) = 194
> write(2, "Cannot run verification with option 'no_verification'.\n", 55) = 55
Hi,
I'm sorry, I haven't read one of your earlier emails carefully enough,
please do not use "certificate_verification = no_ocsp, no_verification"
but only
certificate_verification = no_verification
'no_ocsp' implies verification but without OCSP so using both options is
an inconsistency.
bye,
Sumit
> stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=1931, ...}) = 0
> stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=1931, ...}) = 0
> write(2, "(Tue Mar 17 12:09:26 2020) [[sssd[p11_child[5539 [main]
> (0x0020): p11_child failed!\n", 88) = 88
> close(1)= 0
> exit_group(1) = ?
> +++ exited with 1 +++
> ___
> sssd-users mailing list -- sssd-users@lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
[SSSD-users] Re: SSSD and PKI: capability of checking trust/validation/revocation
On Tue, Mar 17, 2020 at 09:41:16AM -, Hristina Marosevic wrote: > > On Thu, Mar 12, 2020 at 03:13:57PM -, Hristina Marosevic wrote: > > > > Hi, > > > > the file should be in the SSSD log directory, so typically > > /var/log/sssd/p11_child.log. > > > > Since it does not exists, p11_child was not called to validate the > > certificates. In this case sssd_ssh.log is the only source of > > information. Feel free to send the file or the part of the log file > > which covers the time where sss_ssh_authorized_keys was called. > > > > bye, > > Sumit > > > > Hello, > > command: /usr/bin/sss_ssh_authorizedkeys IIN321 > > output: > (Tue Mar 17 10:39:34 2020) [sssd[ssh]] [get_client_cred] (0x4000): Client > creds: euid[0] egid[0] pid[24441]. > (Tue Mar 17 10:39:34 2020) [sssd[ssh]] [get_client_cred] (0x0080): The > following failure is expected to happen in case SELinux is disabled: > SELINUX_getpeercon failed [92][Protocol not available]. > Please, consider enabling SELinux in your system. > (Tue Mar 17 10:39:34 2020) [sssd[ssh]] [setup_client_idle_timer] (0x4000): > Idle timer re-set for client [0x55e6a3217350][18] > (Tue Mar 17 10:39:34 2020) [sssd[ssh]] [accept_fd_handler] (0x0400): Client > connected! > (Tue Mar 17 10:39:34 2020) [sssd[ssh]] [sss_cmd_get_version] (0x0200): > Received client version [0]. > (Tue Mar 17 10:39:34 2020) [sssd[ssh]] [sss_cmd_get_version] (0x0200): > Offered version [0]. > (Tue Mar 17 10:39:34 2020) [sssd[ssh]] [ssh_protocol_parse_request] (0x0400): > Requested domain [] > (Tue Mar 17 10:39:34 2020) [sssd[ssh]] [ssh_cmd_get_user_pubkeys] (0x0400): > Requesting SSH user public keys for [IIN321] from [] > > (Tue Mar 17 10:39:34 2020) [sssd[ssh]] [child_handler_setup] (0x2000): > Setting up signal handler up for pid [24442] > (Tue Mar 17 10:39:34 2020) [sssd[ssh]] [child_handler_setup] (0x2000): Signal > handler set up for pid [24442] > (Tue Mar 17 10:39:34 2020) [sssd[ssh]] [child_sig_handler] (0x1000): Waiting > for child [24442]. > (Tue Mar 17 10:39:34 2020) [sssd[ssh]] [child_sig_handler] (0x0020): child > [24442] failed with status [1]. > (Tue Mar 17 10:39:34 2020) [sssd[ssh]] [cert_to_ssh_key_done] (0x0040): > /usr/libexec/sssd/p11_child failed with status [256] Hi, so p11_child is really called but as you said earlier there are no logs. This might e.g. be a permission issue, please check the permissions on /var/log/sssd if you see anything odd. For me it looks like: drwxr-x---. 2 root root system_u:object_r:sssd_var_log_t:s04096 Mar 17 09:09 . drwxr-xr-x. 12 root root system_u:object_r:var_log_t:s0 4096 Mar 15 03:27 .. -rw---. 1 root root system_u:object_r:sssd_var_log_t:s0 221452 Mar 17 09:19 krb5_child.log -rw---. 1 root root system_u:object_r:sssd_var_log_t:s0 1069023 Mar 17 11:16 ldap_child.log -rw---. 1 root root system_u:object_r:sssd_var_log_t:s0 0 Mar 16 10:31 p11_child.log -rw---. 1 root root system_u:object_r:sssd_var_log_t:s0 14816 Mar 17 09:19 selinux_child.log -rw---. 1 root root system_u:object_r:sssd_var_log_t:s0 623 Mar 16 10:31 sssd.log -rw---. 1 root root system_u:object_r:sssd_var_log_t:s0 0 Mar 16 10:31 sssd_nss.log -rw---. 1 root root system_u:object_r:sssd_var_log_t:s0 0 Mar 16 10:31 sssd_pac.log -rw---. 1 root root system_u:object_r:sssd_var_log_t:s0 490679 Mar 17 11:18 sssd_pam.log -rw---. 1 root root system_u:object_r:sssd_var_log_t:s0 6723166 Mar 17 11:18 sssd_ipa.devel.log -rw---. 1 root root system_u:object_r:sssd_var_log_t:s0 0 Mar 16 10:31 sssd_ssh.log -rw---. 1 root root system_u:object_r:sssd_var_log_t:s0 0 Mar 16 10:31 sssd_sudo.log The next step would be to check what failed with strace. For this call mkdir /tmp/strace_data strace -ff -s 1024 -o /tmp/strace_data/strace_ -p $(pidof /usr/libexec/sssd/sssd_ssh) in one terminal can call 'sss_ssh_authorizedkeys IIN321' in a different terminal. After calling sss_ssh_authorizedkeys you can stop the strace command with CTRL-C. In /tmp/strace_data there should be at least 2 files, one of the main sssd_ssh process and the other for p11_child, please send both (if there are more than 2 please send all). bye, Sumit > (Tue Mar 17 10:39:34 2020) [sssd[ssh]] [cert_to_ssh_key_done] (0x0080): > Certificate >
[SSSD-users] Re: SSSD and PKI: capability of checking trust/validation/revocation
> On Thu, Mar 12, 2020 at 4:52 PM Sumit Bose > log file > and the records > were actually stored in parent process log. > > Fixed in commit 30d0ccd49 Hello Tomas, Can you please send me link of the commit? About the paret p11 log file - I am not sure, which log process is the parent process? Where should I look for p11 child logs? BR, Hristina ___ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
[SSSD-users] Re: SSSD and PKI: capability of checking trust/validation/revocation
> On Thu, Mar 12, 2020 at 03:13:57PM -, Hristina Marosevic wrote: > > Hi, > > the file should be in the SSSD log directory, so typically > /var/log/sssd/p11_child.log. > > Since it does not exists, p11_child was not called to validate the > certificates. In this case sssd_ssh.log is the only source of > information. Feel free to send the file or the part of the log file > which covers the time where sss_ssh_authorized_keys was called. > > bye, > Sumit Hello, command: /usr/bin/sss_ssh_authorizedkeys IIN321 output: (Tue Mar 17 10:39:34 2020) [sssd[ssh]] [get_client_cred] (0x4000): Client creds: euid[0] egid[0] pid[24441]. (Tue Mar 17 10:39:34 2020) [sssd[ssh]] [get_client_cred] (0x0080): The following failure is expected to happen in case SELinux is disabled: SELINUX_getpeercon failed [92][Protocol not available]. Please, consider enabling SELinux in your system. (Tue Mar 17 10:39:34 2020) [sssd[ssh]] [setup_client_idle_timer] (0x4000): Idle timer re-set for client [0x55e6a3217350][18] (Tue Mar 17 10:39:34 2020) [sssd[ssh]] [accept_fd_handler] (0x0400): Client connected! (Tue Mar 17 10:39:34 2020) [sssd[ssh]] [sss_cmd_get_version] (0x0200): Received client version [0]. (Tue Mar 17 10:39:34 2020) [sssd[ssh]] [sss_cmd_get_version] (0x0200): Offered version [0]. (Tue Mar 17 10:39:34 2020) [sssd[ssh]] [ssh_protocol_parse_request] (0x0400): Requested domain [] (Tue Mar 17 10:39:34 2020) [sssd[ssh]] [ssh_cmd_get_user_pubkeys] (0x0400): Requesting SSH user public keys for [IIN321] from [] (Tue Mar 17 10:39:34 2020) [sssd[ssh]] [cache_req_set_plugin] (0x2000): CR #0: Setting "User by name" plugin (Tue Mar 17 10:39:34 2020) [sssd[ssh]] [cache_req_send] (0x0400): CR #0: New request 'User by name' (Tue Mar 17 10:39:34 2020) [sssd[ssh]] [cache_req_process_input] (0x0400): CR #0: Parsing input name [IIN321] (Tue Mar 17 10:39:34 2020) [sssd[ssh]] [sss_parse_name_for_domains] (0x0200): name 'IIN321' matched without domain, user is IIN321 (Tue Mar 17 10:39:34 2020) [sssd[ssh]] [cache_req_set_name] (0x0400): CR #0: Setting name [IIN321] (Tue Mar 17 10:39:34 2020) [sssd[ssh]] [cache_req_select_domains] (0x0400): CR #0: Performing a multi-domain search (Tue Mar 17 10:39:34 2020) [sssd[ssh]] [cache_req_search_domains] (0x0400): CR #0: Search will check the cache and check the data provider (Tue Mar 17 10:39:34 2020) [sssd[ssh]] [cache_req_validate_domain_type] (0x2000): Request type POSIX-only for domain LDAP type POSIX is valid (Tue Mar 17 10:39:34 2020) [sssd[ssh]] [cache_req_set_domain] (0x0400): CR #0: Using domain [LDAP] (Tue Mar 17 10:39:34 2020) [sssd[ssh]] [cache_req_prepare_domain_data] (0x0400): CR #0: Preparing input data for domain [LDAP] rules (Tue Mar 17 10:39:34 2020) [sssd[ssh]] [cache_req_search_send] (0x0400): CR #0: Looking up IIN321@ldap (Tue Mar 17 10:39:34 2020) [sssd[ssh]] [cache_req_search_ncache] (0x0400): CR #0: Checking negative cache for [IIN321@ldap] (Tue Mar 17 10:39:34 2020) [sssd[ssh]] [sss_ncache_check_str] (0x2000): Checking negative cache for [NCE/USER/LDAP/IIN321@ldap] (Tue Mar 17 10:39:34 2020) [sssd[ssh]] [cache_req_search_ncache] (0x0400): CR #0: [IIN321@ldap] is not present in negative cache (Tue Mar 17 10:39:34 2020) [sssd[ssh]] [cache_req_search_cache] (0x0400): CR #0: Looking up [IIN321@ldap] in cache (Tue Mar 17 10:39:34 2020) [sssd[ssh]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x55e6a321fcd0 (Tue Mar 17 10:39:34 2020) [sssd[ssh]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x55e6a321fda0 (Tue Mar 17 10:39:34 2020) [sssd[ssh]] [ldb] (0x4000): Running timer event 0x55e6a321fcd0 "ltdb_callback" (Tue Mar 17 10:39:34 2020) [sssd[ssh]] [ldb] (0x4000): Destroying timer event 0x55e6a321fda0 "ltdb_timeout" (Tue Mar 17 10:39:34 2020) [sssd[ssh]] [ldb] (0x4000): Destroying timer event 0x55e6a321fcd0 "ltdb_callback" (Tue Mar 17 10:39:34 2020) [sssd[ssh]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x55e6a321fc00 (Tue Mar 17 10:39:34 2020) [sssd[ssh]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x55e6a321fcd0 (Tue Mar 17 10:39:34 2020) [sssd[ssh]] [ldb] (0x4000): Running timer event 0x55e6a321fc00 "ltdb_callback" (Tue Mar 17 10:39:34 2020) [sssd[ssh]] [ldb] (0x4000): Destroying timer event 0x55e6a321fcd0 "ltdb_timeout" (Tue Mar 17 10:39:34 2020) [sssd[ssh]] [ldb] (0x4000): Destroying timer event 0x55e6a321fc00 "ltdb_callback" (Tue Mar 17 10:39:34 2020) [sssd[ssh]] [cache_req_search_send] (0x0400): CR #0: Returning [IIN321@ldap] from cache (Tue Mar 17 10:39:34 2020) [sssd[ssh]] [cache_req_search_ncache_filter] (0x0400): CR #0: This request type does not support filtering result by negative cache (Tue Mar 17 10:39:34 2020) [sssd[ssh]] [cache_req_create_and_add_result] (0x0400): CR #0: Found 1 entries in domain LDAP (Tue Mar 17 10:39:34 2020) [sssd[ssh]] [cache_req_done] (0x0400): CR #0: Finished: Success (Tue Mar
[SSSD-users] Re: SSSD and PKI: capability of checking trust/validation/revocation
On Thu, Mar 12, 2020 at 4:52 PM Sumit Bose wrote: > Hi, > > the file should be in the SSSD log directory, so typically > /var/log/sssd/p11_child.log. > > Since it does not exists, p11_child was not called to validate the > certificates. In this case sssd_ssh.log is the only source of > information. Feel free to send the file or the part of the log file > which covers the time where sss_ssh_authorized_keys was called. > > bye, > Sumit > > Just for the record, there was a bug that caused not creating p11_child log file and the records were actually stored in parent process log. Fixed in commit 30d0ccd49 -- Tomas Halman ___ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
[SSSD-users] Re: SSSD and PKI: capability of checking trust/validation/revocation
On Thu, Mar 12, 2020 at 03:13:57PM -, Hristina Marosevic wrote: > > On Fri, Mar 06, 2020 at 12:44:35PM -, Hristina Marosevic wrote: > > > > Hi, > > > > no [pam] is not needed for your use case, access via ssh. > > > > > > This command looks for certificates from a Smartcard connected to the > > local system. However p11_child is used to validate the certificates for > > the ssh key generation as well. You should add debug_level = 9 to the > > [ssh] section of sssd.conf and then check sssd_ssh.log and p11_child.log > > after calling sss_ssh_authorized_keys. > > > > HTH > > > > bye, > > Sumit > > > I can not find a file named p11_child.log (i searched everything from the > root directory) > The only thing related to p11_child is executable /usr/libexec/sssd/p11_child > - should I use it to generate log? > Can you please help me with this? Hi, the file should be in the SSSD log directory, so typically /var/log/sssd/p11_child.log. Since it does not exists, p11_child was not called to validate the certificates. In this case sssd_ssh.log is the only source of information. Feel free to send the file or the part of the log file which covers the time where sss_ssh_authorized_keys was called. bye, Sumit > > BR, > Hristina > ___ > sssd-users mailing list -- sssd-users@lists.fedorahosted.org > To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org ___ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
[SSSD-users] Re: SSSD and PKI: capability of checking trust/validation/revocation
> On Fri, Mar 06, 2020 at 12:44:35PM -, Hristina Marosevic wrote: > > Hi, > > no [pam] is not needed for your use case, access via ssh. > > > This command looks for certificates from a Smartcard connected to the > local system. However p11_child is used to validate the certificates for > the ssh key generation as well. You should add debug_level = 9 to the > [ssh] section of sssd.conf and then check sssd_ssh.log and p11_child.log > after calling sss_ssh_authorized_keys. > > HTH > > bye, > Sumit I can not find a file named p11_child.log (i searched everything from the root directory) The only thing related to p11_child is executable /usr/libexec/sssd/p11_child - should I use it to generate log? Can you please help me with this? BR, Hristina ___ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
[SSSD-users] Re: SSSD and PKI: capability of checking trust/validation/revocation
On Fri, Mar 06, 2020 at 12:44:35PM -, Hristina Marosevic wrote: > Hello, > > I added: "certificate_verification = no_ocsp, no_verification" in [sssd] part > of the sssd configuration and I didn't add the CA certs because the > certification validation is disabled, but I am getting the same error > "certificate is not valid" in the sssd_ssh.log > SSSD version that I am using is (yum package version): > 1.16.4-21.0.1.el7_7.1 > Somewhere on the internet, I saw this in the [pam] part of the sssd > configuration: "pam_cert_auth = True" - should I add this line in my config > file? Hi, no [pam] is not needed for your use case, access via ssh. > and I found the following command for the p11_child log (by you): > /usr/libexec/sssd/p11_child -d 10 --debug-fd=1 --pre --nssdb=/etc/pki/nssdb This command looks for certificates from a Smartcard connected to the local system. However p11_child is used to validate the certificates for the ssh key generation as well. You should add debug_level = 9 to the [ssh] section of sssd.conf and then check sssd_ssh.log and p11_child.log after calling sss_ssh_authorized_keys. HTH bye, Sumit > > The output on my machine was: > $ /usr/libexec/sssd/p11_child -d 10 --debug-fd=1 --pre --nssdb=/etc/pki/nssdb > (Fri Mar 6 13:33:30:652007 2020) [[sssd[p11_child[8855 [main] (0x0400): > p11_child started. > (Fri Mar 6 13:33:30:652310 2020) [[sssd[p11_child[8855 [main] (0x2000): > Running in [pre-auth] mode. > (Fri Mar 6 13:33:30:652517 2020) [[sssd[p11_child[8855 [main] (0x2000): > Running with effective IDs: [0][0]. > (Fri Mar 6 13:33:30:652758 2020) [[sssd[p11_child[8855 [main] (0x2000): > Running with real IDs [0][0]. > (Fri Mar 6 13:33:30:710650 2020) [[sssd[p11_child[8855 [do_card] > (0x4000): Default Module List: > (Fri Mar 6 13:33:30:710904 2020) [[sssd[p11_child[8855 [do_card] > (0x4000): common name: [NSS Internal PKCS #11 Module]. > (Fri Mar 6 13:33:30:711013 2020) [[sssd[p11_child[8855 [do_card] > (0x4000): dll name: [(null)]. > (Fri Mar 6 13:33:30:76 2020) [[sssd[p11_child[8855 [do_card] > (0x4000): Dead Module List: > (Fri Mar 6 13:33:30:711218 2020) [[sssd[p11_child[8855 [do_card] > (0x4000): DB Module List: > (Fri Mar 6 13:33:30:711320 2020) [[sssd[p11_child[8855 [do_card] > (0x4000): common name: [NSS Internal Module]. > (Fri Mar 6 13:33:30:711434 2020) [[sssd[p11_child[8855 [do_card] > (0x4000): dll name: [(null)]. > (Fri Mar 6 13:33:30:711564 2020) [[sssd[p11_child[8855 [do_card] > (0x4000): common name: [Policy File]. > (Fri Mar 6 13:33:30:711768 2020) [[sssd[p11_child[8855 [do_card] > (0x4000): dll name: [(null)]. > (Fri Mar 6 13:33:30:711890 2020) [[sssd[p11_child[8855 [do_card] > (0x4000): Description [NSS User Private Key and Certificate Services > Mozilla Foundation ] Manufacturer [Mozilla Foundation >] flags [1]. > (Fri Mar 6 13:33:30:712016 2020) [[sssd[p11_child[8855 [do_card] > (0x4000): Description [NSS Internal Cryptographic Services > Mozilla Foundation ] Manufacturer [Mozilla > Foundation ] flags [9]. > (Fri Mar 6 13:33:30:712335 2020) [[sssd[p11_child[8855 [do_card] > (0x0040): No removable slots found. > (Fri Mar 6 13:33:30:712448 2020) [[sssd[p11_child[8855 [main] (0x0040): > do_work failed. > (Fri Mar 6 13:33:30:712595 2020) [[sssd[p11_child[8855 [main] (0x0020): > p11_child failed! > > > BR, > Hristina > ___ > sssd-users mailing list -- sssd-users@lists.fedorahosted.org > To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org ___ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
[SSSD-users] Re: SSSD and PKI: capability of checking trust/validation/revocation
> On Fri, Mar 06, 2020 at 08:09:59AM -, Hristina Marosevic wrote: > > Hi, > > this looks like some progress. Please check p11_child.log which might > contain detail why SSSD thinks the certificate is not valid. By default > SSSD will check the certificate with the help of the CA certificates and > does OCSP if the certificate contains the needed OCSP data. > > To disable OCSP, since your system cannot reach the OCSP responder, > please add > > certificate_verification = no_ocsp > > to the [sssd] section of sssd.conf and restart SSSD. For testing you can > even use 'no_verification' but this is should not be used in production > (see man sssd.conf for details). > > Which version of SSSD are you using? Depending on the version you might > have to add the CA certificates to different locations, please check the > 'ca_db' option described in man sssd.conf for details as well. > > bye, > Sumit Can you please check the comment bellow? (I didn't quote your text there, so I am not sure if you got a notification for my comment) BR, Hristina ___ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
[SSSD-users] Re: SSSD and PKI: capability of checking trust/validation/revocation
Hello, I added: "certificate_verification = no_ocsp, no_verification" in [sssd] part of the sssd configuration and I didn't add the CA certs because the certification validation is disabled, but I am getting the same error "certificate is not valid" in the sssd_ssh.log SSSD version that I am using is (yum package version): 1.16.4-21.0.1.el7_7.1 Somewhere on the internet, I saw this in the [pam] part of the sssd configuration: "pam_cert_auth = True" - should I add this line in my config file? and I found the following command for the p11_child log (by you): /usr/libexec/sssd/p11_child -d 10 --debug-fd=1 --pre --nssdb=/etc/pki/nssdb The output on my machine was: $ /usr/libexec/sssd/p11_child -d 10 --debug-fd=1 --pre --nssdb=/etc/pki/nssdb (Fri Mar 6 13:33:30:652007 2020) [[sssd[p11_child[8855 [main] (0x0400): p11_child started. (Fri Mar 6 13:33:30:652310 2020) [[sssd[p11_child[8855 [main] (0x2000): Running in [pre-auth] mode. (Fri Mar 6 13:33:30:652517 2020) [[sssd[p11_child[8855 [main] (0x2000): Running with effective IDs: [0][0]. (Fri Mar 6 13:33:30:652758 2020) [[sssd[p11_child[8855 [main] (0x2000): Running with real IDs [0][0]. (Fri Mar 6 13:33:30:710650 2020) [[sssd[p11_child[8855 [do_card] (0x4000): Default Module List: (Fri Mar 6 13:33:30:710904 2020) [[sssd[p11_child[8855 [do_card] (0x4000): common name: [NSS Internal PKCS #11 Module]. (Fri Mar 6 13:33:30:711013 2020) [[sssd[p11_child[8855 [do_card] (0x4000): dll name: [(null)]. (Fri Mar 6 13:33:30:76 2020) [[sssd[p11_child[8855 [do_card] (0x4000): Dead Module List: (Fri Mar 6 13:33:30:711218 2020) [[sssd[p11_child[8855 [do_card] (0x4000): DB Module List: (Fri Mar 6 13:33:30:711320 2020) [[sssd[p11_child[8855 [do_card] (0x4000): common name: [NSS Internal Module]. (Fri Mar 6 13:33:30:711434 2020) [[sssd[p11_child[8855 [do_card] (0x4000): dll name: [(null)]. (Fri Mar 6 13:33:30:711564 2020) [[sssd[p11_child[8855 [do_card] (0x4000): common name: [Policy File]. (Fri Mar 6 13:33:30:711768 2020) [[sssd[p11_child[8855 [do_card] (0x4000): dll name: [(null)]. (Fri Mar 6 13:33:30:711890 2020) [[sssd[p11_child[8855 [do_card] (0x4000): Description [NSS User Private Key and Certificate Services Mozilla Foundation ] Manufacturer [Mozilla Foundation ] flags [1]. (Fri Mar 6 13:33:30:712016 2020) [[sssd[p11_child[8855 [do_card] (0x4000): Description [NSS Internal Cryptographic Services Mozilla Foundation ] Manufacturer [Mozilla Foundation ] flags [9]. (Fri Mar 6 13:33:30:712335 2020) [[sssd[p11_child[8855 [do_card] (0x0040): No removable slots found. (Fri Mar 6 13:33:30:712448 2020) [[sssd[p11_child[8855 [main] (0x0040): do_work failed. (Fri Mar 6 13:33:30:712595 2020) [[sssd[p11_child[8855 [main] (0x0020): p11_child failed! BR, Hristina ___ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
[SSSD-users] Re: SSSD and PKI: capability of checking trust/validation/revocation
On Fri, Mar 06, 2020 at 08:09:59AM -, Hristina Marosevic wrote: > Hello, > > I got an error message: "Certificate is not valid" > > So, I am not sure what should this mean? Is it because the trust (path to CA > cert) isn't stored in the sssd configuration? Here I have a root CA and an > intermediate CA. > This can be the only option I can think of, so far because it is still valid > considering expiration time, and it is not revoked (there is also no change > in sssd configuration regarding OCSP (should I do something about this or > sssd will by default check the provided CRL list given by URL in the > certificate?), but there is a link of the CRL in the certificate provided by > LDAP to sssd which - maybe can not be reached because this machine is not > connected to Internet - in this case is it possible to use offlice copy of > the CRL list on the local machine? ) > > sssd_ssh.log: > > (Fri Mar 6 08:50:11 2020) [sssd[ssh]] [cert_to_ssh_key_done] (0x0080): > Certificate > [MIIGMTCCBBmgAwIBAgIUfYWZ212wMteK0jjnnXd6dqlqkIkwDQYJKoZIhvcNAQELBQAwLTELMAkGA1UEBhMCS1oxHjAcBgNVBAMMFdKw0JrQniAzLjAgKFJTQSBURVNUKTAeFw0xOTA0MDQwODU0NTRaFw0yMTA0MDMwODU0NTRaMIGvMSIwIAYDVQQDDBnQotCV0KHQotCi0J7QkiDQotCV0KHQotCiMRcwFQYDVQQEDA7QotCV0KHQotCi0J7QkjEYMBYGA1UEBRMPSUlOMTIzNDU2Nzg5MDEyMQswCQYDVQQGEwJLWjEVMBMGA1UEBwwM0JDQodCi0JDQndCQMRUwEwYDVQQIDAzQkNCh0KLQkNCd0JAxGzAZBgNVBCoMEtCi0JXQodCi0KLQntCS0JjQpzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAI9kXtq5MjdOP+6uelfthsbeOFCrjPQdypbwkDgIoas054FJvKHgfX9apVHvbMrNK7/atFMbfrv1gxbLqFkHPs5/u2dDo4GWZmYDHIWSRRTVlVEoVHJVYHOZPxio6N611pgSvh/1yM5XbYRK08kKF5mbLIxEw62VMDfZ1DutYEtyOmQsVBmEiducfklQQS6JVMpdnnENHOksJU3H9UXIvEeA+N+/SZY4ane1UIFFieZb/zak5y9gZC1Iluwv0vIiy4lZU3MlZBra/iCs1/c4K5Y7rAiI9olydg229G00cK17E+JwnuJoKaCPGBaxQoLJpUgU2f5JOBHzXOXn2WuZ8MMCAwEAAaOCAcQwggHAMA4GA1UdDwEB/wQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKoMOAwMEAQEwHwYDVR0jBBgwFoAUpowWM3y46DVnBj5eQVdVo > > q80UGgwHQYDVR0OBBYEFLoJ735qnU1Q4y8AEtPdJI2lqQVfMF4GA1UdIARXMFUwUwYHKoMOAwMCBDBIMCEGCCsGAQUFBwIBFhVodHRwOi8vcGtpLmdvdi5rei9jcHMwIwYIKwYBBQUHAgIwFwwVaHR0cDovL3BraS5nb3Yua3ovY3BzMDwGA1UdHwQ1MDMwMaAvoC2GK2h0dHA6Ly90ZXN0LnBraS5nb3Yua3ovY3JsL25jYV9yc2FfdGVzdC5jcmwwPgYDVR0uBDcwNTAzoDGgL4YtaHR0cDovL3Rlc3QucGtpLmdvdi5rei9jcmwvbmNhX2RfcnNhX3Rlc3QuY3JsMHEGCCsGAQUFBwEBBGUwYzA4BggrBgEFBQcwAoYsaHR0cDovL3Rlc3QucGtpLmdvdi5rei9jZXJ0L25jYV9yc2FfdGVzdC5jZXIwJwYIKwYBBQUHMAGGG2h0dHA6Ly90ZXN0LnBraS5nb3Yua3ovb2NzcDANBgkqhkiG9w0BAQsFAAOCAgEACnYpytjbyuV3sRojnlyxEC7HG7BgcDDy6rS/kfOtK6X5+MGCT/zvwksZOumN5Jg5TPdJuKt3ebKJGIBVr474mHFk7Nq0F8WxuAWNffjoL0Lvcuon4Zwq/W8h4t6PYutD4NEauIPEa8X8BGPgMn+YqOc3sfEruXh8rmcSJ/zuT7uw1wD6ZQlNsniioengKIgapDVDHuzoV/r//rEANwIpntAyjXFh+fjx+CDCx2sLxYjlVgyxNzT53mD6ZqsMlg6NrajJe/GvS0A38jKNyxW/DPX06NToWP/hu7M4P2/WiskjKVgOxqQcc4yzTfKV41DmEmGGC7sT1r3YeZ4dH/KQRpjowBOSKmUZq4/XR0yXXhpTDtiiRwXkQgM1p4SKE19bBqGuc76lDgmffPPPj4B+3HZqaprIIDG3YA3/W4rwUoWBQPGGCXpOBvGEQptEHItx4YiEZTQuvdCtlW585kUyol39sK > > v2uIo/FgycBd8NufOInGCLUgpZec4zVLZN9Shj+M20BMUh+SiGoL/kJAi2XdM922U3po9a2FbULvJfOlsFY2Z6n+TUZZVXBCUIEE6Ek4tTIGjHWj7uQVGLjw0PcHf11CtrMZO7Y+OTBb/Y0oyUY9JOyzSqhj4rt4nNkzR1vMGVYMNISoXbDgYBaAKuv2oSpG6yQdlufS8M/YWxAWw=] > is not valid. > Hi, this looks like some progress. Please check p11_child.log which might contain detail why SSSD thinks the certificate is not valid. By default SSSD will check the certificate with the help of the CA certificates and does OCSP if the certificate contains the needed OCSP data. To disable OCSP, since your system cannot reach the OCSP responder, please add certificate_verification = no_ocsp to the [sssd] section of sssd.conf and restart SSSD. For testing you can even use 'no_verification' but this is should not be used in production (see man sssd.conf for details). Which version of SSSD are you using? Depending on the version you might have to add the CA certificates to different locations, please check the 'ca_db' option described in man sssd.conf for details as well. bye, Sumit > > > > Once again, the certificate is stored in LDAP like: > .. > userCertificate;binary:: > MIIGMTCCBBmgAwIBAgIUfYWZ212wMteK0jjnnXd6dqlqkIkwDQYJKoZ > > IhvcNAQELBQAwLTELMAkGA1UEBhMCS1oxHjAcBgNVBAMMFdKw0JrQniAzLjAgKFJTQSBURVNUKTAeFw > > 0xOTA0MDQwODU0NTRaFw0yMTA0MDMwODU0NTRaMIGvMSIwIAYDVQQDDBnQotCV0KHQotCi0J7QkiDQo > > tCV0KHQotCiMRcwFQYDVQQEDA7QotCV0KHQotCi0J7QkjEYMBYGA1UEBRMPSUlOMTIzNDU2Nzg5MDEy > > MQswCQYDVQQGEwJLWjEVMBMGA1UEBwwM0JDQodCi0JDQndCQMRUwEwYDVQQIDAzQkNCh0KLQkNCd0JA > > xGzAZBgNVBCoMEtCi0JXQodCi0KLQntCS0JjQpzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCgg > > EBAI9kXtq5MjdOP+6uelfthsbeOFCrjPQdypbwkDgIoas054FJvKHgfX9apVHvbMrNK7/atFMbfrv1g > > xbLqFkHPs5/u2dDo4GWZmYDHIWSRRTVlVEoVHJVYHOZPxio6N611pgSvh/1yM5XbYRK08kKF5mbLIxE > > w62VMDfZ1DutYEtyOmQsVBmEiducfklQQS6JVMpdnnENHOksJU3H9UXIvEeA+N+/SZY4ane1UIFFieZ > > b/zak5y9gZC1Iluwv0vIiy4lZU3MlZBra/iCs1/c4K5Y7rAiI9olydg229G00cK17E+JwnuJoKaCPGB > > axQoLJpUgU2f5JOBHzXOXn2WuZ8MMCAwEAAaOCAcQwggHAMA4GA1UdDwEB/wQEAwIFoDAdBgNVHSUEF > >
[SSSD-users] Re: SSSD and PKI: capability of checking trust/validation/revocation
I added the certificate using the ldapmodify option "read from file" and the content for the user certificate retrieved by the ldapsearch on the LDAP server, also the content mapped by SSSD on the sssd client proved that the format of the user certificate was okay. What I get in the sssd_ssh.log is the same errror as before, i.e. "certificate is not valid" So, now I need to find out only why is this certificate not valid. Is it because of the trust or revocation status that can not be retrieved from the CRL list which can not be downloaded due to the lack of connection to Internet or both.. What is your opinion on this? BR, Hristina ___ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
[SSSD-users] Re: SSSD and PKI: capability of checking trust/validation/revocation
I will try this proposal to check if I get the same error when using the binary format. I will let you know. Thank you for your help! BR, Hristina ___ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
[SSSD-users] Re: SSSD and PKI: capability of checking trust/validation/revocation
Hello, I got an error message: "Certificate is not valid" So, I am not sure what should this mean? Is it because the trust (path to CA cert) isn't stored in the sssd configuration? Here I have a root CA and an intermediate CA. This can be the only option I can think of, so far because it is still valid considering expiration time, and it is not revoked (there is also no change in sssd configuration regarding OCSP (should I do something about this or sssd will by default check the provided CRL list given by URL in the certificate?), but there is a link of the CRL in the certificate provided by LDAP to sssd which - maybe can not be reached because this machine is not connected to Internet - in this case is it possible to use offlice copy of the CRL list on the local machine? ) sssd_ssh.log: (Fri Mar 6 08:50:11 2020) [sssd[ssh]] [cert_to_ssh_key_done] (0x0080): Certificate [MIIGMTCCBBmgAwIBAgIUfYWZ212wMteK0jjnnXd6dqlqkIkwDQYJKoZIhvcNAQELBQAwLTELMAkGA1UEBhMCS1oxHjAcBgNVBAMMFdKw0JrQniAzLjAgKFJTQSBURVNUKTAeFw0xOTA0MDQwODU0NTRaFw0yMTA0MDMwODU0NTRaMIGvMSIwIAYDVQQDDBnQotCV0KHQotCi0J7QkiDQotCV0KHQotCiMRcwFQYDVQQEDA7QotCV0KHQotCi0J7QkjEYMBYGA1UEBRMPSUlOMTIzNDU2Nzg5MDEyMQswCQYDVQQGEwJLWjEVMBMGA1UEBwwM0JDQodCi0JDQndCQMRUwEwYDVQQIDAzQkNCh0KLQkNCd0JAxGzAZBgNVBCoMEtCi0JXQodCi0KLQntCS0JjQpzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAI9kXtq5MjdOP+6uelfthsbeOFCrjPQdypbwkDgIoas054FJvKHgfX9apVHvbMrNK7/atFMbfrv1gxbLqFkHPs5/u2dDo4GWZmYDHIWSRRTVlVEoVHJVYHOZPxio6N611pgSvh/1yM5XbYRK08kKF5mbLIxEw62VMDfZ1DutYEtyOmQsVBmEiducfklQQS6JVMpdnnENHOksJU3H9UXIvEeA+N+/SZY4ane1UIFFieZb/zak5y9gZC1Iluwv0vIiy4lZU3MlZBra/iCs1/c4K5Y7rAiI9olydg229G00cK17E+JwnuJoKaCPGBaxQoLJpUgU2f5JOBHzXOXn2WuZ8MMCAwEAAaOCAcQwggHAMA4GA1UdDwEB/wQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKoMOAwMEAQEwHwYDVR0jBBgwFoAUpowWM3y46DVnBj5eQVdVo q80UGgwHQYDVR0OBBYEFLoJ735qnU1Q4y8AEtPdJI2lqQVfMF4GA1UdIARXMFUwUwYHKoMOAwMCBDBIMCEGCCsGAQUFBwIBFhVodHRwOi8vcGtpLmdvdi5rei9jcHMwIwYIKwYBBQUHAgIwFwwVaHR0cDovL3BraS5nb3Yua3ovY3BzMDwGA1UdHwQ1MDMwMaAvoC2GK2h0dHA6Ly90ZXN0LnBraS5nb3Yua3ovY3JsL25jYV9yc2FfdGVzdC5jcmwwPgYDVR0uBDcwNTAzoDGgL4YtaHR0cDovL3Rlc3QucGtpLmdvdi5rei9jcmwvbmNhX2RfcnNhX3Rlc3QuY3JsMHEGCCsGAQUFBwEBBGUwYzA4BggrBgEFBQcwAoYsaHR0cDovL3Rlc3QucGtpLmdvdi5rei9jZXJ0L25jYV9yc2FfdGVzdC5jZXIwJwYIKwYBBQUHMAGGG2h0dHA6Ly90ZXN0LnBraS5nb3Yua3ovb2NzcDANBgkqhkiG9w0BAQsFAAOCAgEACnYpytjbyuV3sRojnlyxEC7HG7BgcDDy6rS/kfOtK6X5+MGCT/zvwksZOumN5Jg5TPdJuKt3ebKJGIBVr474mHFk7Nq0F8WxuAWNffjoL0Lvcuon4Zwq/W8h4t6PYutD4NEauIPEa8X8BGPgMn+YqOc3sfEruXh8rmcSJ/zuT7uw1wD6ZQlNsniioengKIgapDVDHuzoV/r//rEANwIpntAyjXFh+fjx+CDCx2sLxYjlVgyxNzT53mD6ZqsMlg6NrajJe/GvS0A38jKNyxW/DPX06NToWP/hu7M4P2/WiskjKVgOxqQcc4yzTfKV41DmEmGGC7sT1r3YeZ4dH/KQRpjowBOSKmUZq4/XR0yXXhpTDtiiRwXkQgM1p4SKE19bBqGuc76lDgmffPPPj4B+3HZqaprIIDG3YA3/W4rwUoWBQPGGCXpOBvGEQptEHItx4YiEZTQuvdCtlW585kUyol39sK v2uIo/FgycBd8NufOInGCLUgpZec4zVLZN9Shj+M20BMUh+SiGoL/kJAi2XdM922U3po9a2FbULvJfOlsFY2Z6n+TUZZVXBCUIEE6Ek4tTIGjHWj7uQVGLjw0PcHf11CtrMZO7Y+OTBb/Y0oyUY9JOyzSqhj4rt4nNkzR1vMGVYMNISoXbDgYBaAKuv2oSpG6yQdlufS8M/YWxAWw=] is not valid. Once again, the certificate is stored in LDAP like: .. userCertificate;binary:: MIIGMTCCBBmgAwIBAgIUfYWZ212wMteK0jjnnXd6dqlqkIkwDQYJKoZ IhvcNAQELBQAwLTELMAkGA1UEBhMCS1oxHjAcBgNVBAMMFdKw0JrQniAzLjAgKFJTQSBURVNUKTAeFw 0xOTA0MDQwODU0NTRaFw0yMTA0MDMwODU0NTRaMIGvMSIwIAYDVQQDDBnQotCV0KHQotCi0J7QkiDQo tCV0KHQotCiMRcwFQYDVQQEDA7QotCV0KHQotCi0J7QkjEYMBYGA1UEBRMPSUlOMTIzNDU2Nzg5MDEy MQswCQYDVQQGEwJLWjEVMBMGA1UEBwwM0JDQodCi0JDQndCQMRUwEwYDVQQIDAzQkNCh0KLQkNCd0JA xGzAZBgNVBCoMEtCi0JXQodCi0KLQntCS0JjQpzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCgg EBAI9kXtq5MjdOP+6uelfthsbeOFCrjPQdypbwkDgIoas054FJvKHgfX9apVHvbMrNK7/atFMbfrv1g xbLqFkHPs5/u2dDo4GWZmYDHIWSRRTVlVEoVHJVYHOZPxio6N611pgSvh/1yM5XbYRK08kKF5mbLIxE w62VMDfZ1DutYEtyOmQsVBmEiducfklQQS6JVMpdnnENHOksJU3H9UXIvEeA+N+/SZY4ane1UIFFieZ b/zak5y9gZC1Iluwv0vIiy4lZU3MlZBra/iCs1/c4K5Y7rAiI9olydg229G00cK17E+JwnuJoKaCPGB axQoLJpUgU2f5JOBHzXOXn2WuZ8MMCAwEAAaOCAcQwggHAMA4GA1UdDwEB/wQEAwIFoDAdBgNVHSUEF jAUBggrBgEFBQcDAgYIKoMOAwMEAQEwHwYDVR0jBBgwFoAUpowWM3y46DVnBj5eQVdVoq80UGgwHQYD VR0OBBYEFLoJ735qnU1Q4y8AEtPdJI2lqQVfMF4GA1UdIARXMFUwUwYHKoMOAwMCBDBIMCEGCCsGAQU FBwIBFhVodHRwOi8vcGtpLmdvdi5rei9jcHMwIwYIKwYBBQUHAgIwFwwVaHR0cDovL3BraS5nb3Yua3 ovY3BzMDwGA1UdHwQ1MDMwMaAvoC2GK2h0dHA6Ly90ZXN0LnBraS5nb3Yua3ovY3JsL25jYV9yc2Ffd GVzdC5jcmwwPgYDVR0uBDcwNTAzoDGgL4YtaHR0cDovL3Rlc3QucGtpLmdvdi5rei9jcmwvbmNhX2Rf cnNhX3Rlc3QuY3JsMHEGCCsGAQUFBwEBBGUwYzA4BggrBgEFBQcwAoYsaHR0cDovL3Rlc3QucGtpLmd vdi5rei9jZXJ0L25jYV9yc2FfdGVzdC5jZXIwJwYIKwYBBQUHMAGGG2h0dHA6Ly90ZXN0LnBraS5nb3 Yua3ovb2NzcDANBgkqhkiG9w0BAQsFAAOCAgEACnYpytjbyuV3sRojnlyxEC7HG7BgcDDy6rS/kfOtK 6X5+MGCT/zvwksZOumN5Jg5TPdJuKt3ebKJGIBVr474mHFk7Nq0F8WxuAWNffjoL0Lvcuon4Zwq/W8h 4t6PYutD4NEauIPEa8X8BGPgMn+YqOc3sfEruXh8rmcSJ/zuT7uw1wD6ZQlNsniioengKIgapDVDHuz oV/r//rEANwIpntAyjXFh+fjx+CDCx2sLxYjlVgyxNzT53mD6ZqsMlg6NrajJe/GvS0A38jKNyxW/DP X06NToWP/hu7M4P2/WiskjKVgOxqQcc4yzTfKV41DmEmGGC7sT1r3YeZ4dH/KQRpjowBOSKmUZq4/XR
[SSSD-users] Re: SSSD and PKI: capability of checking trust/validation/revocation
On Thu, Mar 05, 2020 at 02:34:42PM -, Hristina Marosevic wrote: > Some more info (another prove that sssd does not derive the public key from > the user certificate): > /usr/bin/sss_ssh_authorizedkeys IIN321 when I am using only > userCertificate;binary attribute (with the binary value of the certificate) > is not giving any output, while when I am using the userCertificate attribute > associated with the value of the public key (when the PKI authentication > works fine) /usr/bin/sss_ssh_authorizedkeys IIN321 outputs the public > key of the user which proves the oposite situation when using public key > (wether used along with certificate or not; in cases when user certificate is > used along with public key it gets mapped in sssd but it is not validated or > compared to the public key - I already mentioned this, and the authentication > using the private/public key pair work fine which is not fine :) ) > > I am just trying to give as much information in order to solve this problem. > Sorry for the spam. Hi, the best information would be the SSSD logs files with 'debug_level = 9'. bye, Sumit > > > BR, > Hristina > ___ > sssd-users mailing list -- sssd-users@lists.fedorahosted.org > To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org ___ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
[SSSD-users] Re: SSSD and PKI: capability of checking trust/validation/revocation
On Thu, Mar 05, 2020 at 02:24:25PM -, Hristina Marosevic wrote:
> I added the content between -BEGIN CERTIFICATE- and -END
> CERTIFICATE- from the base64 user certificate and during authentication
> in the logs I saw that the user certificate was stored in the user
> certificate SSSD option but there was no public key derived.
> This time I deleted the public key and during authentication I was using only
> userCertificate;binary attrbiute wit hthe default SSSD configuration for
> mapping the certificate.
>
>
> This is from the SSSD_LDAP.log
>
> (Thu Mar 5 15:16:19 2020) [sssd[be[LDAP]]] [sdap_attrs_add_ldap_attr]
> (0x2000): Adding userCertificate
> [0\82\0610\82\04\19\A0\03\02\01\02\02\14}\85\99\DB]\B02\D7\8A\D28\E7\9Dwzv\A9j\90\890\0D\06\09\2A\86H\86\F7\0D\01\01\0B\05\000-1\0B0\09\06\03U\04\06\13\02KZ1\1E0\1C\06\03U\04\03\0C\15\D2\B0\D0\9A\D0\9E\203.0\20\28RSA\20TEST\290\1E\17\0D190404085454Z\17\0D210403085454Z0\81\AF1\220\20\06\03U\04\03\0C\19\D0\A2\D0\95\D0\A1\D0\A2\D0\A2\D0\9E\D0\92\20\D0\A2\D0\95\D0\A1\D0\A2\D0\A21\170\15\06\03U\04\04\0C\0E\D0\A2\D0\95\D0\A1\D0\A2\D0\A2\D0\9E\D0\921\180\16\06\03U\04\05\13\0FIIN1234567890121\0B0\09\06\03U\04\06\13\02KZ1\150\13\06\03U\04\07\0C\0C\D0\90\D0\A1\D0\A2\D0\90\D0\9D\D0\901\150\13\06\03U\04\08\0C\0C\D0\90\D0\A1\D0\A2\D0\90\D0\9D\D0\901\1B0\19\06\03U\04\2A\0C\12\D0\A2\D0\95\D0\A1\D0\A2\D0\A2\D0\9E\D0\92\D0\98\D0\A70\82\01\220\0D\06\09\2A\86H\86\F7\0D\01\01\01\05\00\03\82\01\0F\000\82\01\0A\02\82\01\01\00\8Fd^\DA\B927N?\EE\AEzW\ED\86\C6\DE8P\AB\8C\F4\1D\CA\96\F0\908\08\A1\AB4\E7\81I
>
> \BC\A1\E0}\7FZ\A5Q\EFl\CA\CD+\BF\DA\B4S\1B~\BB\F5\83\16\CB\A8Y\07>\CE\7F\BBgC\A3\81\96ff\03\1C\85\92E\14\D5\95Q\28TrU`s\99?\18\A8\E8\DE\B5\D6\98\12\BE\1F\F5\C8\CEWm\84J\D3\C9\0A\17\99\9B,\8CD\C3\AD\9507\D9\D4;\AD`Kr:d,T\19\84\89\DB\9C~IPA.\89T\CA]\9Eq\0D\1C\E9,%M\C7\F5E\C8\BCG\80\F8\DF\BFI\968jw\B5P\81E\89\E6[\FF6\A4\E7/`d-H\96\EC/\D2\F2\22\CB\89YSs%d\1A\DA\FE\20\AC\D7\F78+\96;\AC\08\88\F6\89rv\0D\B6\F4m4p\AD{\13\E2p\9E\E2h\29\A0\8F\18\16\B1B\82\C9\A5H\14\D9\FEI8\11\F3\5C\E5\E7\D9k\99\F0\C3\02\03\01\00\01\A3\82\01\C40\82\01\C00\0E\06\03U\1D\0F\01\01\FF\04\04\03\02\05\A00\1D\06\03U\1D%\04\160\14\06\08+\06\01\05\05\07\03\02\06\08\2A\83\0E\03\03\04\01\010\1F\06\03U\1D#\04\180\16\80\14\A6\8C\163\7C\B8\E85g\06>^AWU\A2\AF4Ph0\1D\06\03U\1D\0E\04\16\04\14\BA\09\EF~j\9DMP\E3/\00\12\D3\DD$\8D\A5\A9\05_0^\06\03U\1D\20\04W0U0S\06\07\2A\83\0E\03\03\02\040H0\21\06\08+\06\01\05\05\07\02\01\16\15http://pki.gov.kz/cps0#\06\08+\06\01\05\05\07\02\020\17\0C\15http://pki.gov.kz/cps0<\06\03U\1D\1F\045030
>
> 1\A0/\A0-\86+http://test.pki.gov.kz/crl/nca_rsa_test.crl0>\06\03U\1D.\0470503\A01\A0/\86-http://test.pki.gov.kz/crl/nca_d_rsa_test.crl0q\06\08+\06\01\05\05\07\01\01\04e0c08\06\08+\06\01\05\05\070\02\86,http://test.pki.gov.kz/cert/nca_rsa_test.cer0'\06\08+\06\01\05\05\070\01\86\1Bhttp://test.pki.gov.kz/ocsp0\0D\06\09\2A\86H\86\F7\0D\01\01\0B\05\00\03\82\02\01\00\0Av\29\CA\D8\DB\CA\E5w\B1\1A#\9E\5C\B1\10.\C7\1B\B0`p0\F2\EA\B4\BF\91\F3\AD+\A5\F9\F8\C1\82O\FC\EF\C2K\19:\E9\8D\E4\989L\F7I\B8\ABwy\B2\89\18\80U\AF\8E\F8\98qd\EC\DA\B4\17\C5\B1\B8\05\8D}\F8\E8/B\EFr\EA'\E1\9C\2A\FDo\21\E2\DE\8Fb\EBC\E0\D1\1A\B8\83\C4k\C5\FC\04c\E02\7F\98\A8\E77\B1\F1+\B9x\7C\AEg\12'\FC\EEO\BB\B0\D7\00\FAe\09M\B2x\A2\A1\E9\E0\28\88\1A\A45C\1E\EC\E8W\FA\FF\FE\B1\007\02\29\9E\D02\8Dqa\F9\F8\F1\F8\20\C2\C7k\0B\C5\88\E5V\0C\B174\F9\DE`\FAf\AB\0C\96\0E\8D\AD\A8\C9{\F1\AFK@7\F22\8D\CB\15\BF\0C\F5\F4\E8\D4\E8X\FF\E1\BB\B38?o\D6\8A\C9#\29X\0E\C6\A4\1Cs\8C\B3M\F2\95\E3P\E6\12a\86\0B\BB\13\D6\BD\D8y\9E\1D\1F\F2\90F\98\
>
> E8\C0\13\92\2Ae\19\AB\8F\D7GL\97^\1AS\0E\D8\A2G\05\E4B\035\A7\84\8A\13_[\06\A1\AEs\BE\A5\0E\09\9F\7C\F3\CF\8F\80~\DCvjj\9A\C8\201\B7`\0D\FF[\8A\F0R\85\81@\F1\86\09zN\06\F1\84B\9BD\1C\8Bq\E1\88\84e4.\BD\D0\AD\95n\7C\E6E2\A2]\FD\B0\AB\F6\B8\8A?\16\0C\9C\05\DF\0D\B9\F3\88\9C`\8BR\0AYy\CE3T\B6M\F5\28c\F8\CD\B4\04\C5\21\F9\28\86\A0\BF\E4$\08\B6]\D3=\DBe7\A6\8FZ\D8V\D4.\F2_:[\05cfz\9F\E4\D4e\95W\04%\08\10N\84\93\8BS\20h\C7Z>\EEAQ\8B\8F\0D\0Fpw\F5\D4+k1\93\BBc\E3\93\05\BF\D8\D2\8C\94c\D2N\CB4\AA\86>+\B7\89\CD\934u\BC\C1\95`\C3HJ\85\DB\0E\06\01h\02\AE\BFj\12\A4n\B2A\D9n}/\0C\FD\85\B1\01l]
> to attributes of [IIN321@ldap].
Hi,
yes, this looks better, please add 'debug_level = 9' to the [ssh]
section of sssd.conf, restart sssd and call sss_ssh_authorizedkeys for
the user and check sssd_ssh.log.
HTH
bye,
Sumit
>
> before, the content of the certificate was not like this, but:
>
> (Tue Mar 3 17:08:15 2020) [sssd[be[LDAP]]] [sdap_attrs_add_ldap_attr]
> (0x2000): Adding userCertificate
>
[SSSD-users] Re: SSSD and PKI: capability of checking trust/validation/revocation
Some more info (another prove that sssd does not derive the public key from the user certificate): /usr/bin/sss_ssh_authorizedkeys IIN321 when I am using only userCertificate;binary attribute (with the binary value of the certificate) is not giving any output, while when I am using the userCertificate attribute associated with the value of the public key (when the PKI authentication works fine) /usr/bin/sss_ssh_authorizedkeys IIN321 outputs the public key of the user which proves the oposite situation when using public key (wether used along with certificate or not; in cases when user certificate is used along with public key it gets mapped in sssd but it is not validated or compared to the public key - I already mentioned this, and the authentication using the private/public key pair work fine which is not fine :) ) I am just trying to give as much information in order to solve this problem. Sorry for the spam. BR, Hristina ___ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
[SSSD-users] Re: SSSD and PKI: capability of checking trust/validation/revocation
On Thu, Mar 05, 2020 at 07:16:45AM -, Hristina Marosevic wrote: > Hello, > > By using ldapmodify command and ldif file as input. > > # ldif file: > dn: uid=321, > changetype: modify > add: userCertificate;binary > userCertificate;binary: > MIIGMTCCBBmgAwIBAgIUfYWZ212wMteK0jjnnXd6dqlqkIkwDQYJKoZIhvcNAQELBQAwLTELMAkGA1UEBhMCS1oxHjAcBgNVBAMMFdKw0JrQniAzLjAgKFJTQSBURVNUKTAeFw0xOTA0MDQwODU0NTRaFw0yMTA0MDMwODU0NTRaMIGvMSIwIAYDVQQDDBnQotCV0KHQotCi0J7QkiDQotCV0KHQotCiMRcwFQYDVQQEDA7QotCV0KHQotCi0J7QkjEYMBYGA1UEBRMPSUlOMTIzNDU2Nzg5MDEyMQswCQYDVQQGEwJLWjEVMBMGA1UEBwwM0JDQodCi0JDQndCQMRUwEwYDVQQIDAzQkNCh0KLQkNCd0JAxGzAZBgNVBCoMEtCi0JXQodCi0KLQntCS0JjQpzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAI9kXtq5MjdOP+6uelfthsbeOFCrjPQdypbwkDgIoas054FJvKHgfX9apVHvbMrNK7/atFMbfrv1gxbLqFkHPs5/u2dDo4GWZmYDHIWSRRTVlVEoVHJVYHOZPxio6N611pgSvh/1yM5XbYRK08kKF5mbLIxEw62VMDfZ1DutYEtyOmQsVBmEiducfklQQS6JVMpdnnENHOksJU3H9UXIvEeA+N+/SZY4ane1UIFFieZb/zak5y9gZC1Iluwv0vIiy4lZU3MlZBra/iCs1/c4K5Y7rAiI9olydg229G00cK17E+JwnuJoKaCPGBaxQoLJpUgU2f5JOBHzXOXn2WuZ8MMCAwEAAaOCAcQwggHAMA4GA1UdDwEB/wQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKoMOAwMEAQEwHwYDVR0jBBgwFoAUpowWM3y46DVnBj5eQVdVoq80UGgwHQYDVR0OBBYEFLoJ735qnU1Q4y8AEtPdJI2lqQVfMF4GA1UdIARXMF > > UwUwYHKoMOAwMCBDBIMCEGCCsGAQUFBwIBFhVodHRwOi8vcGtpLmdvdi5rei9jcHMwIwYIKwYBBQUHAgIwFwwVaHR0cDovL3BraS5nb3Yua3ovY3BzMDwGA1UdHwQ1MDMwMaAvoC2GK2h0dHA6Ly90ZXN0LnBraS5nb3Yua3ovY3JsL25jYV9yc2FfdGVzdC5jcmwwPgYDVR0uBDcwNTAzoDGgL4YtaHR0cDovL3Rlc3QucGtpLmdvdi5rei9jcmwvbmNhX2RfcnNhX3Rlc3QuY3JsMHEGCCsGAQUFBwEBBGUwYzA4BggrBgEFBQcwAoYsaHR0cDovL3Rlc3QucGtpLmdvdi5rei9jZXJ0L25jYV9yc2FfdGVzdC5jZXIwJwYIKwYBBQUHMAGGG2h0dHA6Ly90ZXN0LnBraS5nb3Yua3ovb2NzcDANBgkqhkiG9w0BAQsFAAOCAgEACnYpytjbyuV3sRojnlyxEC7HG7BgcDDy6rS/kfOtK6X5+MGCT/zvwksZOumN5Jg5TPdJuKt3ebKJGIBVr474mHFk7Nq0F8WxuAWNffjoL0Lvcuon4Zwq/W8h4t6PYutD4NEauIPEa8X8BGPgMn+YqOc3sfEruXh8rmcSJ/zuT7uw1wD6ZQlNsniioengKIgapDVDHuzoV/r//rEANwIpntAyjXFh+fjx+CDCx2sLxYjlVgyxNzT53mD6ZqsMlg6NrajJe/GvS0A38jKNyxW/DPX06NToWP/hu7M4P2/WiskjKVgOxqQcc4yzTfKV41DmEmGGC7sT1r3YeZ4dH/KQRpjowBOSKmUZq4/XR0yXXhpTDtiiRwXkQgM1p4SKE19bBqGuc76lDgmffPPPj4B+3HZqaprIIDG3YA3/W4rwUoWBQPGGCXpOBvGEQptEHItx4YiEZTQuvdCtlW585kUyol39sKv2uIo/FgycBd8NufOInGCLUgpZec4zVLZN9Shj+M20BMUh+SiGoL/kJAi2XdM > > 922U3po9a2FbULvJfOlsFY2Z6n+TUZZVXBCUIEE6Ek4tTIGjHWj7uQVGLjw0PcHf11CtrMZO7Y+OTBb/Y0oyUY9JOyzSqhj4rt4nNkzR1vMGVYMNISoXbDgYBaAKuv2oSpG6yQdlufS8M/YWxAWw= Hi, you have to load it as a binary. For this frist convert your certificate into DER format with openssl x509 -in my_cert.cer -outform der -out my_cert.der and then the ldif should look like # ldif file: dn: uid=321, changetype: modify add: userCertificate;binary userCertificate;binary:< file:///path/to/my_cert.der (see man ldapmodify for details about the file syntax). bye, Sumit > > > > BR, > Hristina > ___ > sssd-users mailing list -- sssd-users@lists.fedorahosted.org > To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org ___ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
[SSSD-users] Re: SSSD and PKI: capability of checking trust/validation/revocation
I added the content between -BEGIN CERTIFICATE- and -END
CERTIFICATE- from the base64 user certificate and during authentication in
the logs I saw that the user certificate was stored in the user certificate
SSSD option but there was no public key derived.
This time I deleted the public key and during authentication I was using only
userCertificate;binary attrbiute wit hthe default SSSD configuration for
mapping the certificate.
This is from the SSSD_LDAP.log
(Thu Mar 5 15:16:19 2020) [sssd[be[LDAP]]] [sdap_attrs_add_ldap_attr]
(0x2000): Adding userCertificate
[0\82\0610\82\04\19\A0\03\02\01\02\02\14}\85\99\DB]\B02\D7\8A\D28\E7\9Dwzv\A9j\90\890\0D\06\09\2A\86H\86\F7\0D\01\01\0B\05\000-1\0B0\09\06\03U\04\06\13\02KZ1\1E0\1C\06\03U\04\03\0C\15\D2\B0\D0\9A\D0\9E\203.0\20\28RSA\20TEST\290\1E\17\0D190404085454Z\17\0D210403085454Z0\81\AF1\220\20\06\03U\04\03\0C\19\D0\A2\D0\95\D0\A1\D0\A2\D0\A2\D0\9E\D0\92\20\D0\A2\D0\95\D0\A1\D0\A2\D0\A21\170\15\06\03U\04\04\0C\0E\D0\A2\D0\95\D0\A1\D0\A2\D0\A2\D0\9E\D0\921\180\16\06\03U\04\05\13\0FIIN1234567890121\0B0\09\06\03U\04\06\13\02KZ1\150\13\06\03U\04\07\0C\0C\D0\90\D0\A1\D0\A2\D0\90\D0\9D\D0\901\150\13\06\03U\04\08\0C\0C\D0\90\D0\A1\D0\A2\D0\90\D0\9D\D0\901\1B0\19\06\03U\04\2A\0C\12\D0\A2\D0\95\D0\A1\D0\A2\D0\A2\D0\9E\D0\92\D0\98\D0\A70\82\01\220\0D\06\09\2A\86H\86\F7\0D\01\01\01\05\00\03\82\01\0F\000\82\01\0A\02\82\01\01\00\8Fd^\DA\B927N?\EE\AEzW\ED\86\C6\DE8P\AB\8C\F4\1D\CA\96\F0\908\08\A1\AB4\E7\81I
\BC\A1\E0}\7FZ\A5Q\EFl\CA\CD+\BF\DA\B4S\1B~\BB\F5\83\16\CB\A8Y\07>\CE\7F\BBgC\A3\81\96ff\03\1C\85\92E\14\D5\95Q\28TrU`s\99?\18\A8\E8\DE\B5\D6\98\12\BE\1F\F5\C8\CEWm\84J\D3\C9\0A\17\99\9B,\8CD\C3\AD\9507\D9\D4;\AD`Kr:d,T\19\84\89\DB\9C~IPA.\89T\CA]\9Eq\0D\1C\E9,%M\C7\F5E\C8\BCG\80\F8\DF\BFI\968jw\B5P\81E\89\E6[\FF6\A4\E7/`d-H\96\EC/\D2\F2\22\CB\89YSs%d\1A\DA\FE\20\AC\D7\F78+\96;\AC\08\88\F6\89rv\0D\B6\F4m4p\AD{\13\E2p\9E\E2h\29\A0\8F\18\16\B1B\82\C9\A5H\14\D9\FEI8\11\F3\5C\E5\E7\D9k\99\F0\C3\02\03\01\00\01\A3\82\01\C40\82\01\C00\0E\06\03U\1D\0F\01\01\FF\04\04\03\02\05\A00\1D\06\03U\1D%\04\160\14\06\08+\06\01\05\05\07\03\02\06\08\2A\83\0E\03\03\04\01\010\1F\06\03U\1D#\04\180\16\80\14\A6\8C\163\7C\B8\E85g\06>^AWU\A2\AF4Ph0\1D\06\03U\1D\0E\04\16\04\14\BA\09\EF~j\9DMP\E3/\00\12\D3\DD$\8D\A5\A9\05_0^\06\03U\1D\20\04W0U0S\06\07\2A\83\0E\03\03\02\040H0\21\06\08+\06\01\05\05\07\02\01\16\15http://pki.gov.kz/cps0#\06\08+\06\01\05\05\07\02\020\17\0C\15http://pki.gov.kz/cps0<\06\03U\1D\1F\045030
1\A0/\A0-\86+http://test.pki.gov.kz/crl/nca_rsa_test.crl0>\06\03U\1D.\0470503\A01\A0/\86-http://test.pki.gov.kz/crl/nca_d_rsa_test.crl0q\06\08+\06\01\05\05\07\01\01\04e0c08\06\08+\06\01\05\05\070\02\86,http://test.pki.gov.kz/cert/nca_rsa_test.cer0'\06\08+\06\01\05\05\070\01\86\1Bhttp://test.pki.gov.kz/ocsp0\0D\06\09\2A\86H\86\F7\0D\01\01\0B\05\00\03\82\02\01\00\0Av\29\CA\D8\DB\CA\E5w\B1\1A#\9E\5C\B1\10.\C7\1B\B0`p0\F2\EA\B4\BF\91\F3\AD+\A5\F9\F8\C1\82O\FC\EF\C2K\19:\E9\8D\E4\989L\F7I\B8\ABwy\B2\89\18\80U\AF\8E\F8\98qd\EC\DA\B4\17\C5\B1\B8\05\8D}\F8\E8/B\EFr\EA'\E1\9C\2A\FDo\21\E2\DE\8Fb\EBC\E0\D1\1A\B8\83\C4k\C5\FC\04c\E02\7F\98\A8\E77\B1\F1+\B9x\7C\AEg\12'\FC\EEO\BB\B0\D7\00\FAe\09M\B2x\A2\A1\E9\E0\28\88\1A\A45C\1E\EC\E8W\FA\FF\FE\B1\007\02\29\9E\D02\8Dqa\F9\F8\F1\F8\20\C2\C7k\0B\C5\88\E5V\0C\B174\F9\DE`\FAf\AB\0C\96\0E\8D\AD\A8\C9{\F1\AFK@7\F22\8D\CB\15\BF\0C\F5\F4\E8\D4\E8X\FF\E1\BB\B38?o\D6\8A\C9#\29X\0E\C6\A4\1Cs\8C\B3M\F2\95\E3P\E6\12a\86\0B\BB\13\D6\BD\D8y\9E\1D\1F\F2\90F\98\
E8\C0\13\92\2Ae\19\AB\8F\D7GL\97^\1AS\0E\D8\A2G\05\E4B\035\A7\84\8A\13_[\06\A1\AEs\BE\A5\0E\09\9F\7C\F3\CF\8F\80~\DCvjj\9A\C8\201\B7`\0D\FF[\8A\F0R\85\81@\F1\86\09zN\06\F1\84B\9BD\1C\8Bq\E1\88\84e4.\BD\D0\AD\95n\7C\E6E2\A2]\FD\B0\AB\F6\B8\8A?\16\0C\9C\05\DF\0D\B9\F3\88\9C`\8BR\0AYy\CE3T\B6M\F5\28c\F8\CD\B4\04\C5\21\F9\28\86\A0\BF\E4$\08\B6]\D3=\DBe7\A6\8FZ\D8V\D4.\F2_:[\05cfz\9F\E4\D4e\95W\04%\08\10N\84\93\8BS\20h\C7Z>\EEAQ\8B\8F\0D\0Fpw\F5\D4+k1\93\BBc\E3\93\05\BF\D8\D2\8C\94c\D2N\CB4\AA\86>+\B7\89\CD\934u\BC\C1\95`\C3HJ\85\DB\0E\06\01h\02\AE\BFj\12\A4n\B2A\D9n}/\0C\FD\85\B1\01l]
to attributes of [IIN321@ldap].
before, the content of the certificate was not like this, but:
(Tue Mar 3 17:08:15 2020) [sssd[be[LDAP]]] [sdap_attrs_add_ldap_attr]
(0x2000): Adding userCertificate
[SSSD-users] Re: SSSD and PKI: capability of checking trust/validation/revocation
So, I am not sure if I should use userCertificate;binary:: MIIGMT.. in the ldif file. Also, should I add the -BEGIN CERTIFICATE-/-END CERTIFICATE- (now I am adding only the content between these lines as a value of the userCertificate;binary attribute) ? and if yes, should they be base64 encoded, too? ___ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
[SSSD-users] Re: SSSD and PKI: capability of checking trust/validation/revocation
Thank you for the explanation! BR, Hristina ___ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
[SSSD-users] Re: SSSD and PKI: capability of checking trust/validation/revocation
Hello, By using ldapmodify command and ldif file as input. # ldif file: dn: uid=321, changetype: modify add: userCertificate;binary userCertificate;binary: MIIGMTCCBBmgAwIBAgIUfYWZ212wMteK0jjnnXd6dqlqkIkwDQYJKoZIhvcNAQELBQAwLTELMAkGA1UEBhMCS1oxHjAcBgNVBAMMFdKw0JrQniAzLjAgKFJTQSBURVNUKTAeFw0xOTA0MDQwODU0NTRaFw0yMTA0MDMwODU0NTRaMIGvMSIwIAYDVQQDDBnQotCV0KHQotCi0J7QkiDQotCV0KHQotCiMRcwFQYDVQQEDA7QotCV0KHQotCi0J7QkjEYMBYGA1UEBRMPSUlOMTIzNDU2Nzg5MDEyMQswCQYDVQQGEwJLWjEVMBMGA1UEBwwM0JDQodCi0JDQndCQMRUwEwYDVQQIDAzQkNCh0KLQkNCd0JAxGzAZBgNVBCoMEtCi0JXQodCi0KLQntCS0JjQpzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAI9kXtq5MjdOP+6uelfthsbeOFCrjPQdypbwkDgIoas054FJvKHgfX9apVHvbMrNK7/atFMbfrv1gxbLqFkHPs5/u2dDo4GWZmYDHIWSRRTVlVEoVHJVYHOZPxio6N611pgSvh/1yM5XbYRK08kKF5mbLIxEw62VMDfZ1DutYEtyOmQsVBmEiducfklQQS6JVMpdnnENHOksJU3H9UXIvEeA+N+/SZY4ane1UIFFieZb/zak5y9gZC1Iluwv0vIiy4lZU3MlZBra/iCs1/c4K5Y7rAiI9olydg229G00cK17E+JwnuJoKaCPGBaxQoLJpUgU2f5JOBHzXOXn2WuZ8MMCAwEAAaOCAcQwggHAMA4GA1UdDwEB/wQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKoMOAwMEAQEwHwYDVR0jBBgwFoAUpowWM3y46DVnBj5eQVdVoq80UGgwHQYDVR0OBBYEFLoJ735qnU1Q4y8AEtPdJI2lqQVfMF4GA1UdIARXMF UwUwYHKoMOAwMCBDBIMCEGCCsGAQUFBwIBFhVodHRwOi8vcGtpLmdvdi5rei9jcHMwIwYIKwYBBQUHAgIwFwwVaHR0cDovL3BraS5nb3Yua3ovY3BzMDwGA1UdHwQ1MDMwMaAvoC2GK2h0dHA6Ly90ZXN0LnBraS5nb3Yua3ovY3JsL25jYV9yc2FfdGVzdC5jcmwwPgYDVR0uBDcwNTAzoDGgL4YtaHR0cDovL3Rlc3QucGtpLmdvdi5rei9jcmwvbmNhX2RfcnNhX3Rlc3QuY3JsMHEGCCsGAQUFBwEBBGUwYzA4BggrBgEFBQcwAoYsaHR0cDovL3Rlc3QucGtpLmdvdi5rei9jZXJ0L25jYV9yc2FfdGVzdC5jZXIwJwYIKwYBBQUHMAGGG2h0dHA6Ly90ZXN0LnBraS5nb3Yua3ovb2NzcDANBgkqhkiG9w0BAQsFAAOCAgEACnYpytjbyuV3sRojnlyxEC7HG7BgcDDy6rS/kfOtK6X5+MGCT/zvwksZOumN5Jg5TPdJuKt3ebKJGIBVr474mHFk7Nq0F8WxuAWNffjoL0Lvcuon4Zwq/W8h4t6PYutD4NEauIPEa8X8BGPgMn+YqOc3sfEruXh8rmcSJ/zuT7uw1wD6ZQlNsniioengKIgapDVDHuzoV/r//rEANwIpntAyjXFh+fjx+CDCx2sLxYjlVgyxNzT53mD6ZqsMlg6NrajJe/GvS0A38jKNyxW/DPX06NToWP/hu7M4P2/WiskjKVgOxqQcc4yzTfKV41DmEmGGC7sT1r3YeZ4dH/KQRpjowBOSKmUZq4/XR0yXXhpTDtiiRwXkQgM1p4SKE19bBqGuc76lDgmffPPPj4B+3HZqaprIIDG3YA3/W4rwUoWBQPGGCXpOBvGEQptEHItx4YiEZTQuvdCtlW585kUyol39sKv2uIo/FgycBd8NufOInGCLUgpZec4zVLZN9Shj+M20BMUh+SiGoL/kJAi2XdM 922U3po9a2FbULvJfOlsFY2Z6n+TUZZVXBCUIEE6Ek4tTIGjHWj7uQVGLjw0PcHf11CtrMZO7Y+OTBb/Y0oyUY9JOyzSqhj4rt4nNkzR1vMGVYMNISoXbDgYBaAKuv2oSpG6yQdlufS8M/YWxAWw= BR, Hristina ___ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
[SSSD-users] Re: SSSD and PKI: capability of checking trust/validation/revocation
On Wed, Mar 04, 2020 at 02:12:30PM -, Hristina Marosevic wrote: > > On Wed, Mar 04, 2020 at 07:29:14AM -, Hristina Marosevic wrote: > > > > Hi, > > > > with 'ldap_user_ssh_public_key = userCertificate' this should work, i.e. > > calling 'sss_ssh_authorizedkeys testUser7' should return the ssh key > > from above. If there is no output I need the SSSD ssh and domain logs to > > understand why this fails. > > Yes, this is working, but this is only an exported private key and no > certificate is sither stored in the LDAP's entry or used by SSSD. > > > Are the line break added by you or is this the real output? For > > certificates you have to user 'userCertificate;binary' and store the > > certificates as binaries in LDAP. When you use the ldapsearch command > > the output should be: > > > > userCertificate;binary:: MIIGMTCC > > > > Please note the '::' which indicates that the attribute value is a > > binary and that it is encoded in base64 to be able to print the output. > > > > The lines don't exist in the LDAP entry. > Is the .cer x509 compatible format for storing into LDAP's attribute > userCertificate;binary? As I know, so far this is Base64 encoded format (pls > correct me if I am wrong) > And should I manually add "::" or the LDAP should do that after modifying the > entry by adding the binary format of the user certificate? (when user > certificate is added without "::" ldapsearch retrieves the user certificate > only with "userCertificate;binary: MIIGMTCC" Hi, how do you add the certificate to the LDAP entry? bye, Sumit > > BR, > Hristina > ___ > sssd-users mailing list -- sssd-users@lists.fedorahosted.org > To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org ___ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
[SSSD-users] Re: SSSD and PKI: capability of checking trust/validation/revocation
> On Wed, Mar 04, 2020 at 07:29:14AM -, Hristina Marosevic wrote: > > Hi, > > with 'ldap_user_ssh_public_key = userCertificate' this should work, i.e. > calling 'sss_ssh_authorizedkeys testUser7' should return the ssh key > from above. If there is no output I need the SSSD ssh and domain logs to > understand why this fails. Yes, this is working, but this is only an exported private key and no certificate is sither stored in the LDAP's entry or used by SSSD. > Are the line break added by you or is this the real output? For > certificates you have to user 'userCertificate;binary' and store the > certificates as binaries in LDAP. When you use the ldapsearch command > the output should be: > > userCertificate;binary:: MIIGMTCC > > Please note the '::' which indicates that the attribute value is a > binary and that it is encoded in base64 to be able to print the output. > The lines don't exist in the LDAP entry. Is the .cer x509 compatible format for storing into LDAP's attribute userCertificate;binary? As I know, so far this is Base64 encoded format (pls correct me if I am wrong) And should I manually add "::" or the LDAP should do that after modifying the entry by adding the binary format of the user certificate? (when user certificate is added without "::" ldapsearch retrieves the user certificate only with "userCertificate;binary: MIIGMTCC" BR, Hristina ___ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
[SSSD-users] Re: SSSD and PKI: capability of checking trust/validation/revocation
On Wed, Mar 04, 2020 at 07:29:14AM -, Hristina Marosevic wrote:
> Hello,
>
> I forgot to mention the LDAP implementation I am using - it is OUD (Oracle
> Unified Directory). Object class "strongAuthenticationUser" was added to the
> users for PKI based authentication. The mandatory attribute od this object
> class is "userCertificate" or "userCertificate;binary" in which I would store
> the value of the public key or the certificate.
> Case 1. I stored the certificate in the userCertificate;binary LDAP attribute
> as this was the default configuration
> Case 2. I also tried to store the certificate as a value of the LDAP
> attribute userCertificate and changed "ldap_user_certificate" to
> "userCertificate" in SSSD configuration (commented in the SSSD configuration
> bellow)
> Both of the cases resulted in password based authentication, instead of PKI
> based authentication.
> Also in the log I saw that SSSD mapped userCertificate(;binary) value to
> userCertificate parameter of the entry but I didn't see a derived public key
> in the logs.
> I am using x509 base64 encoded value od the certificate (also I tried with
> pkcs#7 but the result was the same)
>
> # SSSD configuration at this moment: I am using only public key stored as a
> value of the attribute "userCertificate" for authentication of the user which
> works fine - but this way, there is no certificate shown to SSSD client,
> hence - no certificate validation/verification mechanisms can be used
> (correct me if I am wrong)
> [sssd]
> config_file_version = 2
> domains = LDAP
> services = nss, pam, autofs, ssh
> reconnection_retries = 3
>
> [nss]
> reconnection_retries = 3
> debug_level = 2
> filter_users = root, oracle
> filter_groups = root
>
> [pam]
> reconnection_retries = 3
> debug_level = 2
>
> [domain/LDAP]
> id_provider = ldap
> access_provider = ldap
> chpass_provider = ldap
> ldap_schema = rfc2307
> ldap_uri = ldaps://:
> ldap_default_bind_dn =
> ldap_default_authtok =
> ldap_default_authtok_type = password
> ldap_search_base =
> ldap_user_search_base =
> ldap_group_search_base =
> ldap_access_filter = isMemberOf=
> cache_credentials = true
> enumerate = false
> debug_level = 9
> ldap_id_use_start_tls = false
> ldap_tls_reqcert = demand
> ldap_tls_cacert = /etc/sssd/cacerts/
> ldap_tls_cacertdir = /etc/sssd/cacerts
> ldap_user_name = employeeNumber
> ldap_user_ssh_public_key = userCertificate
> #ldap_user_certificate = userCertificate
>
> # LDAP entry at this moment (only with public key value stored in
> "userCertificate" attribute)
> dn: uid=321,
> givenName: testUser7
> objectClass: strongAuthenticationUser
> objectClass: person
> objectClass: inetOrgPerson
> objectClass: organizationalPerson
> objectClass: posixAccount
> objectClass: top
> uid: 321
> cn: 321
> sn: test
> loginShell: /bin/bash
> userPassword:
> {SSHA512}0QAWd8NQNpN5bVS/sS0CDjHzctpy54X/JflWRSzIk/zpgSEgm5IE003RX
> v35iEyt2LfqaXd5HGAwYrCaRbM7ylrg0syFXrLU
> homeDirectory: /ssh_users/321
> ou:
> uidNumber: 1234567890
> userCertificate: ssh-rsa
> B3NzaC1yc2EDAQABAAABAQCPZF7auTI3Tj/urnpX7YbG3jh
>
> Qq4z0HcqW8JA4CKGrNOeBSbyh4H1/WqVR72zKzSu/2rRTG3679YMWy6hZBz7Of7tnQ6OBlmZmAxyFkk
>
> UU1ZVRKFRyVWBzmT8YqOjetdaYEr4f9cjOV22EStPJCheZmyyMRMOtlTA32dQ7rWBLcjpkLFQZhInbn
>
> H5JUEEuiVTKXZ5xDRzpLCVNx/VFyLxHgPjfv0mWOGp3tVCBRYnmW/82pOcvYGQtSJbsL9LyIsuJWVNz
>
> JWQa2v4grNf3OCuWO6wIiPaJcnYNtvRtNHCtexPicJ7iaCmgjxgWsUKCyaVIFNn+STgR81zl59lrmfD
> D
> gidNumber:
> employeeNumber:
Hi,
with 'ldap_user_ssh_public_key = userCertificate' this should work, i.e.
calling 'sss_ssh_authorizedkeys testUser7' should return the ssh key
from above. If there is no output I need the SSSD ssh and domain logs to
understand why this fails.
>
>
> When using certificate only or certificate and public key stored in the LDAP
> entry, the value of the certificate stored in the userCertificate;binary
> attribute is:
> MIIGMTCCBBmgAwIBAgIUfYWZ212wMteK0jjnnXd6dqlqkIkwDQYJKoZIhvcNAQELBQAwLTELMAkGA1UEBhMCS1oxHjAcBgNVBAMMFdKw0JrQniAzLjAgKFJTQSBURVNUKTAeFw0xOTA0MDQwODU0NTRaFw0yMTA0MDMwODU0NTRaMIGvMSIwIAYDVQQDDBnQotCV0KHQotCi0J7QkiDQotCV0KHQotCiMRcwFQYDVQQEDA7QotCV0KHQotCi0J7QkjEYMBYGA1UEBRMPSUlOMTIzNDU2Nzg5MDEyMQswCQYDVQQGEwJLWjEVMBMGA1UEBwwM0JDQodCi0JDQndCQMRUwEwYDVQQIDAzQkNCh0KLQkNCd0JAxGzAZBgNVBCoMEtCi0JXQodCi0KLQntCS0JjQpzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAI9kXtq5MjdOP+6uelfthsbeOFCrjPQdypbwkDgIoas054FJvKHgfX9apVHvbMrNK7/atFMbfrv1gxbLqFkHPs5/u2dDo4GWZmYDHIWSRRTVlVEoVHJVYHOZPxio6N611pgSvh/1yM5XbYRK08kKF5mbLIxEw62VMDfZ1DutYEtyOmQsVBmEiducfklQQS6JVMpdnnENHOksJU3H9UXIvEeA+N+/SZY4ane1UIFFieZb/zak5y9gZC1Iluwv0vIiy4lZU3MlZBra/iCs1/c4K5Y7rAiI9olydg229G00cK17E+JwnuJoKaCPGBaxQoLJpUgU2f5JOBHzXOXn2WuZ8MMCAwEAAaOCAcQwggHAMA4GA1UdDwEB/wQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKoMOAwMEAQEwHwYDVR0jBBgwFoAUpowWM3y46DVnBj5eQVdVoq80UGgwHQYDVR0OBBYEFLoJ735qnU1Q4y8AEtPdJI2lqQVfMF4GA1UdIARXMFUwUwYHKoMOAwMCBDBIMCEGCC
>
>
[SSSD-users] Re: SSSD and PKI: capability of checking trust/validation/revocation
Hello,
I forgot to mention the LDAP implementation I am using - it is OUD (Oracle
Unified Directory). Object class "strongAuthenticationUser" was added to the
users for PKI based authentication. The mandatory attribute od this object
class is "userCertificate" or "userCertificate;binary" in which I would store
the value of the public key or the certificate.
Case 1. I stored the certificate in the userCertificate;binary LDAP attribute
as this was the default configuration
Case 2. I also tried to store the certificate as a value of the LDAP attribute
userCertificate and changed "ldap_user_certificate" to "userCertificate" in
SSSD configuration (commented in the SSSD configuration bellow)
Both of the cases resulted in password based authentication, instead of PKI
based authentication.
Also in the log I saw that SSSD mapped userCertificate(;binary) value to
userCertificate parameter of the entry but I didn't see a derived public key in
the logs.
I am using x509 base64 encoded value od the certificate (also I tried with
pkcs#7 but the result was the same)
# SSSD configuration at this moment: I am using only public key stored as a
value of the attribute "userCertificate" for authentication of the user which
works fine - but this way, there is no certificate shown to SSSD client, hence
- no certificate validation/verification mechanisms can be used (correct me if
I am wrong)
[sssd]
config_file_version = 2
domains = LDAP
services = nss, pam, autofs, ssh
reconnection_retries = 3
[nss]
reconnection_retries = 3
debug_level = 2
filter_users = root, oracle
filter_groups = root
[pam]
reconnection_retries = 3
debug_level = 2
[domain/LDAP]
id_provider = ldap
access_provider = ldap
chpass_provider = ldap
ldap_schema = rfc2307
ldap_uri = ldaps://:
ldap_default_bind_dn =
ldap_default_authtok =
ldap_default_authtok_type = password
ldap_search_base =
ldap_user_search_base =
ldap_group_search_base =
ldap_access_filter = isMemberOf=
cache_credentials = true
enumerate = false
debug_level = 9
ldap_id_use_start_tls = false
ldap_tls_reqcert = demand
ldap_tls_cacert = /etc/sssd/cacerts/
ldap_tls_cacertdir = /etc/sssd/cacerts
ldap_user_name = employeeNumber
ldap_user_ssh_public_key = userCertificate
#ldap_user_certificate = userCertificate
# LDAP entry at this moment (only with public key value stored in
"userCertificate" attribute)
dn: uid=321,
givenName: testUser7
objectClass: strongAuthenticationUser
objectClass: person
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: posixAccount
objectClass: top
uid: 321
cn: 321
sn: test
loginShell: /bin/bash
userPassword: {SSHA512}0QAWd8NQNpN5bVS/sS0CDjHzctpy54X/JflWRSzIk/zpgSEgm5IE003RX
v35iEyt2LfqaXd5HGAwYrCaRbM7ylrg0syFXrLU
homeDirectory: /ssh_users/321
ou:
uidNumber: 1234567890
userCertificate: ssh-rsa B3NzaC1yc2EDAQABAAABAQCPZF7auTI3Tj/urnpX7YbG3jh
Qq4z0HcqW8JA4CKGrNOeBSbyh4H1/WqVR72zKzSu/2rRTG3679YMWy6hZBz7Of7tnQ6OBlmZmAxyFkk
UU1ZVRKFRyVWBzmT8YqOjetdaYEr4f9cjOV22EStPJCheZmyyMRMOtlTA32dQ7rWBLcjpkLFQZhInbn
H5JUEEuiVTKXZ5xDRzpLCVNx/VFyLxHgPjfv0mWOGp3tVCBRYnmW/82pOcvYGQtSJbsL9LyIsuJWVNz
JWQa2v4grNf3OCuWO6wIiPaJcnYNtvRtNHCtexPicJ7iaCmgjxgWsUKCyaVIFNn+STgR81zl59lrmfD
D
gidNumber:
employeeNumber:
When using certificate only or certificate and public key stored in the LDAP
entry, the value of the certificate stored in the userCertificate;binary
attribute is:
MIIGMTCCBBmgAwIBAgIUfYWZ212wMteK0jjnnXd6dqlqkIkwDQYJKoZIhvcNAQELBQAwLTELMAkGA1UEBhMCS1oxHjAcBgNVBAMMFdKw0JrQniAzLjAgKFJTQSBURVNUKTAeFw0xOTA0MDQwODU0NTRaFw0yMTA0MDMwODU0NTRaMIGvMSIwIAYDVQQDDBnQotCV0KHQotCi0J7QkiDQotCV0KHQotCiMRcwFQYDVQQEDA7QotCV0KHQotCi0J7QkjEYMBYGA1UEBRMPSUlOMTIzNDU2Nzg5MDEyMQswCQYDVQQGEwJLWjEVMBMGA1UEBwwM0JDQodCi0JDQndCQMRUwEwYDVQQIDAzQkNCh0KLQkNCd0JAxGzAZBgNVBCoMEtCi0JXQodCi0KLQntCS0JjQpzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAI9kXtq5MjdOP+6uelfthsbeOFCrjPQdypbwkDgIoas054FJvKHgfX9apVHvbMrNK7/atFMbfrv1gxbLqFkHPs5/u2dDo4GWZmYDHIWSRRTVlVEoVHJVYHOZPxio6N611pgSvh/1yM5XbYRK08kKF5mbLIxEw62VMDfZ1DutYEtyOmQsVBmEiducfklQQS6JVMpdnnENHOksJU3H9UXIvEeA+N+/SZY4ane1UIFFieZb/zak5y9gZC1Iluwv0vIiy4lZU3MlZBra/iCs1/c4K5Y7rAiI9olydg229G00cK17E+JwnuJoKaCPGBaxQoLJpUgU2f5JOBHzXOXn2WuZ8MMCAwEAAaOCAcQwggHAMA4GA1UdDwEB/wQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKoMOAwMEAQEwHwYDVR0jBBgwFoAUpowWM3y46DVnBj5eQVdVoq80UGgwHQYDVR0OBBYEFLoJ735qnU1Q4y8AEtPdJI2lqQVfMF4GA1UdIARXMFUwUwYHKoMOAwMCBDBIMCEGCC
[SSSD-users] Re: SSSD and PKI: capability of checking trust/validation/revocation
On Tue, Mar 03, 2020 at 04:38:16PM -, Hristina Marosevic wrote: > Hello, > > Thank you for information. I can use this options (OCSP URL, trust cert > location) once I make SSSD derive public keys from user certificate which is > a problem that I can not solve, so far. > The default mapping of the user certificate is from userCertificate;binary > LDAP attribute to SSSD option ldap_user_certificate, but when I have only the > certificate in the LDAP entry (and not the public key, also - as a value of > another attribute of the entry - later configured in sssd), the key is not > derived. Another combination that I have tried is storing the user > certificate in the userCertificate;binary attribute and storing the exported > public key as a value of another LDAP attribute but it didn't prove to be a > solution - this is like that because I experimented cases with different > public key and user certificate for one user and the user was accepted > without problem - which means that SSSD did not validated the public key > against the user certificate provided by LDAP > > Can you please give me instructions on how to configure SSSD to derive the > publiy key from a user certificate (I would like to store only the user > certificate in LDAP, not the user certificate and the exported public key - > if possible)? Hi, just using the certificate is the expected way how to do it. In which LDAP attribute is you certificate stored and in which format? Can you send an example of an LDAP user object with all attributes? The attribute value can be sanitized if needed but it would be helpful to see the real attribute names. Can you send your current sssd.conf as well since this would help tp see what might be missing. bye, Sumit > > > BR, > Hristina > ___ > sssd-users mailing list -- sssd-users@lists.fedorahosted.org > To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org ___ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
[SSSD-users] Re: SSSD and PKI: capability of checking trust/validation/revocation
Hello, Thank you for information. I can use this options (OCSP URL, trust cert location) once I make SSSD derive public keys from user certificate which is a problem that I can not solve, so far. The default mapping of the user certificate is from userCertificate;binary LDAP attribute to SSSD option ldap_user_certificate, but when I have only the certificate in the LDAP entry (and not the public key, also - as a value of another attribute of the entry - later configured in sssd), the key is not derived. Another combination that I have tried is storing the user certificate in the userCertificate;binary attribute and storing the exported public key as a value of another LDAP attribute but it didn't prove to be a solution - this is like that because I experimented cases with different public key and user certificate for one user and the user was accepted without problem - which means that SSSD did not validated the public key against the user certificate provided by LDAP Can you please give me instructions on how to configure SSSD to derive the publiy key from a user certificate (I would like to store only the user certificate in LDAP, not the user certificate and the exported public key - if possible)? BR, Hristina ___ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
[SSSD-users]Re: SSSD and PKI: capability of checking trust/validation/revocation
On Wed, Feb 26, 2020, at 4:38 AM, Hristina Marosevic wrote: > Hello, > > I am using SSSD with LDAP directory which provides public keys for each > user entry to SSSD. > I am not sure if it is possible to configure SSSD not just to accept > the private key (provided by the user during the login) and > authenticate the user from LDAP (where his public ke is stored), but > also to check the: > - trust (validation of the CA used for signing the user's certificate > i.e. public key) > - validity of a user certificate with its public key (its "from" - "to" > dates) > - revocation status (configuration of SSSD with CRL lists or OCSP) SSSD manages all of these. What it does not manage for SSH is whether the certificate from LDAP actually matches the user, which allows users to grant SSH access "as himself" to anyone else in the organization. (If, as in the case of AD, users can modify their own userCertificate attribute. > or should I manage this on the LDAP side or on application level or > somewhere else? > I would be grateful if you share your ideas about the possible > solutions of this situation! > > V/r, James Cassell ___ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
[SSSD-users] Re: SSSD and PKI: capability of checking trust/validation/revocation
On Wed, Feb 26, 2020 at 09:38:21AM -, Hristina Marosevic wrote: > Hello, > > I am using SSSD with LDAP directory which provides public keys for each user > entry to SSSD. > I am not sure if it is possible to configure SSSD not just to accept the > private key (provided by the user during the login) and authenticate the user > from LDAP (where his public ke is stored), but also to check the: > - trust (validation of the CA used for signing the user's certificate i.e. > public key) > - validity of a user certificate with its public key (its "from" - "to" dates) > - revocation status (configuration of SSSD with CRL lists or OCSP) > or should I manage this on the LDAP side or on application level or somewhere > else? > I would be grateful if you share your ideas about the possible solutions of > this situation! Hi, if you are thinking of using ssh to log in then SSSD can already handle this. SSSD can read the certificate for the user form the LDAP entry, validate it and if valid make the derived ssh-key available to sshd with the help of the sss_ssh_authorizedkeys utility. Please check the option 'certificate_verification' and it's sub-options in the sssd.conf man page for details. Also check the 'SSH configuration options' section about how to configure SSSD's ssh responder. The sss_ssh_authorizedkeys man page explains how to make sshd use the utility. HTH bye, Sumit > > > BR, > Hristina > ___ > sssd-users mailing list -- sssd-users@lists.fedorahosted.org > To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org ___ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
