SSSD / sssd

#3832 [Help] Does SSSD still work properly if the self signed certificate on server-side is expired?
Closed: wontfix by pbrezina. Opened by haolee.

Closed: wontfix
Reopen Issue

The server is OpenLDAP and the client is SSSD. The OpenLDAP uses a self signed certificate.
I find that if I change the system date to make the self signed certificate expired, the SSSD can still work properly. I want to know if this is a problem. Thanks.

The self signed certificate is generated by this command:

openssl req -new -x509 -nodes -out slapdcert.pem -keyout slapdkey.pem -days 365

The SSSD configuration is:

[domain/default]
enumerate= False
ldap_schema = rfc2307bis
autofs_provider = ldap
cache_credentials = False
ldap_search_base = dc=mytest,dc=com
id_provider = ldap
auth_provider = ldap
chpass_provider = ldap
ldap_uri = ldaps://9.82.217.75:636
ldap_id_use_start_tls = True
ldap_tls_reqcert = allow
ldap_tls_cert = /etc/openldap/ssl/slapdcert.pem
ldap_tls_key = /etc/openldap/ssl/slapdkey.pem
ldap_search_timeout = 90
ldap_network_timeout = 90
timeout = 30
debug_level=6
[sssd]
debug_level = 7
services = nss, pam, autofs, ssh
domains = default
[nss]
homedir_substring = /home

The OpenLDAP configuration is:

dn: cn=config
objectClass: olcGlobal
cn: config
olcArgsFile: /var/run/openldap/slapd.args
olcPidFile: /var/run/openldap/slapd.pid
olcTLSCertificateFile: /etc/openldap/ssl/slapdcert.pem
olcTLSCertificateKeyFile: /etc/openldap/ssl/slapdkey.pem
structuralObjectClass: olcGlobal
entryUUID: fa38e0c6-4615-1038-8357-13831733eb6a
creatorsName: cn=config
createTimestamp: 20180906114437Z
olcSizeLimit: 20000
entryCSN: 20180906114450.487921Z#000000#000#000000
modifiersName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
modifyTimestamp: 20180906114450Z

The SSSD configuration is:
[domain/default]
enumerate= False
ldap_schema = rfc2307bis
autofs_provider = ldap
cache_credentials = False
ldap_search_base = dc=mytest,dc=com
id_provider = ldap
auth_provider = ldap
chpass_provider = ldap
ldap_uri = ldaps://9.82.217.75:636
ldap_id_use_start_tls = True

ldap_tls_reqcert = allow

If you use 'allow' SSSD is quite flexible with server-side certificates. Please see the entry for the ldap_tls_reqcert option in man sssd-ldap for more strict setting.

ldap_tls_cert = /etc/openldap/ssl/slapdcert.pem
ldap_tls_key = /etc/openldap/ssl/slapdkey.pem
ldap_search_timeout = 90
ldap_network_timeout = 90
timeout = 30
debug_level=6

Thanks, but if I change ldap_tls_reqcert = allow to ldap_tls_reqcert = demand, SSSD will report some errors in sssd_default.log.

(Sun Nov 15 02:50:05 2020) [sssd[be[default]]] [set_server_common_status] (0x0100): Marking server '9.82.217.75' as 'resolving name'
(Sun Nov 15 02:50:05 2020) [sssd[be[default]]] [set_server_common_status] (0x0100): Marking server '9.82.217.75' as 'name resolved'
(Sun Nov 15 02:50:05 2020) [sssd[be[default]]] [be_resolve_server_process] (0x0200): Found address for server 9.82.217.75: [9.82.217.75] TTL 7200
(Sun Nov 15 02:50:05 2020) [sssd[be[default]]] [sdap_uri_callback] (0x0400): Constructed uri 'ldaps://9.82.217.75:636'
(Sun Nov 15 02:50:05 2020) [sssd[be[default]]] [sssd_async_socket_init_send] (0x0400): Setting 90 seconds timeout for connecting
(Sun Nov 15 02:50:05 2020) [sssd[be[default]]] [sss_ldap_init_sys_connect_done] (0x0020): ldap_install_tls failed: [Connect error] [error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed (self signed certificate)]
(Sun Nov 15 02:50:05 2020) [sssd[be[default]]] [sss_ldap_init_state_destructor] (0x0400): calling ldap_unbind_ext for ldap:[0x56234fcc8b00] sd:[23]
(Sun Nov 15 02:50:05 2020) [sssd[be[default]]] [sss_ldap_init_state_destructor] (0x0400): closing socket [23]
(Sun Nov 15 02:50:05 2020) [sssd[be[default]]] [sdap_sys_connect_done] (0x0020): sdap_async_connect_call request failed: [5]: Input/output error.
(Sun Nov 15 02:50:05 2020) [sssd[be[default]]] [fo_set_port_status] (0x0100): Marking port 636 of server '9.82.217.75' as 'not working'
(Sun Nov 15 02:50:05 2020) [sssd[be[default]]] [fo_set_port_status] (0x0400): Marking port 636 of duplicate server '9.82.217.75' as 'not working'
(Sun Nov 15 02:50:05 2020) [sssd[be[default]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'LDAP'
(Sun Nov 15 02:50:05 2020) [sssd[be[default]]] [get_port_status] (0x0080): SSSD is unable to complete the full connection request, this internal status does not necessarily indicate network port issues.
(Sun Nov 15 02:50:05 2020) [sssd[be[default]]] [fo_resolve_service_send] (0x0020): No available servers for service 'LDAP'
(Sun Nov 15 02:50:05 2020) [sssd[be[default]]] [sdap_id_op_connect_done] (0x0020): Failed to connect, going offline (5 [Input/output error])
(Sun Nov 15 02:50:05 2020) [sssd[be[default]]] [be_ptask_create] (0x0400): Periodic task [Check if online (periodic)] was created
(Sun Nov 15 02:50:05 2020) [sssd[be[default]]] [be_ptask_schedule] (0x0400): Task [Check if online (periodic)]: scheduling task 72 seconds from now [1605379877]
(Sun Nov 15 02:50:05 2020) [sssd[be[default]]] [be_run_offline_cb] (0x0080): Going offline. Running callbacks.
(Sun Nov 15 02:50:05 2020) [sssd[be[default]]] [sdap_sudo_refresh_connect_done] (0x0020): SUDO LDAP connection failed [11]: Resource temporarily unavailable
(Sun Nov 15 02:50:05 2020) [sssd[be[default]]] [be_ptask_done] (0x0040): Task [SUDO Full Refresh]: failed with [11]: Resource temporarily unavailable
(Sun Nov 15 02:50:05 2020) [sssd[be[default]]] [be_ptask_schedule] (0x0400): Task [SUDO Full Refresh]: scheduling task 21600 seconds from now [1605401405]
(Sun Nov 15 02:50:05 2020) [sssd[be[default]]] [be_ptask_offline_cb] (0x0400): Back end is offline
(Sun Nov 15 02:50:05 2020) [sssd[be[default]]] [be_ptask_disable] (0x0400): Task [SUDO Smart Refresh]: disabling task
(Sun Nov 15 02:50:05 2020) [sssd[be[default]]] [be_ptask_offline_cb] (0x0400): Back end is offline
(Sun Nov 15 02:50:05 2020) [sssd[be[default]]] [be_ptask_disable] (0x0400): Task [SUDO Full Refresh]: disabling task
Edited by haolee

Wouldn't you need ldap_tls_cacert set as well, to get proper server certification validation?

Metadata Update from @pbrezina:
- Issue tagged with: Canditate to close

Thank you for taking time to submit this request for SSSD. Unfortunately this issue was not given priority and the team lacks the capacity to work on it at this time.

Given that we are unable to fulfill this request I am closing the issue as wontfix.

If the issue still persist on recent SSSD you can request re-consideration of this decision by reopening this issue. Please provide additional technical details about its importance to you.

Thank you for understanding.

Metadata Update from @pbrezina:
- Issue close_status updated to: wontfix
- Issue status updated to: Closed (was: Open)

SSSD is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in SSSD's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/SSSD/sssd/issues/4826

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.
Metadata
None

Candidate to close

None
None
High
None
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.