#3832 [Help] Does SSSD still work properly if the self signed certificate on server-side is expired?
Opened a month ago by haolee. Modified a month ago

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

Login to comment on this ticket.

Metadata