Ask Ubuntu Asked by Buffoonism on October 31, 2021
I have a handful of Ubuntu Bionic platforms running openldap with TLS, which have been working perfectly for years (and still are). However, I added a new server recently, using the same install script as all the others, and it appears that the olcTLS* settings are now all being rejected.
To double-check, I tried reapplying the same script to one of the running servers, and it worked without error. I then reinitialised the server’s ldap instance, and the server that was working then failed. So this appears to be something that has changed within the defaults that are applied by a fresh installation of openldap using apt-get at some point in the last year or so.
example script snippet:
cat << EOF >/etc/config.ldif
dn: cn=config
changetype: modify
replace: olcTLSProtocolMin
olcTLSProtocolMin: 3.3
EOF
ldapmodify -v -Y EXTERNAL -f /etc/config.ldif
Example output from existing service that works as expected:
ldap_initialize( <DEFAULT> )
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
replace olcTLSProtocolMin:
3.3
modifying entry "cn=config"
modify complete
Example output from fresh-build which doesn’t work:
ldap_initialize( <DEFAULT> )
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
replace olcTLSProtocolMin:
3.3
modifying entry "cn=config"
ldap_modify: Other (e.g., implementation specific) error (80)
I’ve scoured the support forums and cannot find any examples of anyone having similar issues (some are having certificate/key issues that produce the same error, but as I already mentioned, this configuration is working perfectly on existing servers), which is a bit perplexing.
Any thoughts?
Implementation specific error (80) seems to have many possible causes as permissions, ownership and the certificate files accordingly generated. But when I was giving up the order of added attributes really made my day. The one which finally worked for me:
root@ldap:~# cat add7.ldif
dn: cn=config
changetype: modify
add: olcTLSCertificateKeyFile
olcTLSCertificateKeyFile: /etc/certs/privkey1.pem
root@ldap:~# cat add8.ldif
dn: cn=config
changetype: modify
add: olcTLSCertificateFile
olcTLSCertificateFile: /etc/certs/cert1.pem
root@ldap:~# cat add6.ldif
dn: cn=config
changetype: modify
replace: olcTLSCRLCheck
olcTLSCRLCheck: none
root@ldap:~# cat add5.ldap
dn: cn=config
changetype: modify
add: olcTLSCipherSuite
olcTLSCipherSuite: NORMAL
add: olcTLSCACertificateFile
olcTLSCACertificateFile: /etc/certs/fullchain1.pem
root@ldap:~# cat add2.ldap
dn: cn=config
changetype: modify
add: olcTLSProtocolMin
olcTLSProtocolMin: 3.3
root@ldap:~# cat add1.ldap
dn: cn=config
changetype: modify
replace: olcTLSVerifyClient
olcTLSVerifyClient: never
root@ldap:~#
To read in:
ldapmodify -Y EXTERNAL -H ldapi:/// -f add1.ldap
To check:
ldapsearch -Y EXTERNAL -H ldapi:/// -b cn=config | grep olcTLS
Answered by Thiago Cargnelutti on October 31, 2021
Finally worked this out (I thought I had permuted all the setting combinations, but obviously not).
So what it is, is that some of the olcTLS* settings require others to be present first for them to be successfully set.
The various certificate settings need to be present first, before the protocol, ciphers etc can be set.
What was breaking my script was that at some point in the last few months, the cipher set string being used has stopped being accepted. Not sure why at this point (as I mentioned, it is working on other servers just fine).
Answered by Buffoonism on October 31, 2021
Get help from others!
Recent Answers
Recent Questions
© 2024 TransWikia.com. All rights reserved. Sites we Love: PCI Database, UKBizDB, Menu Kuliner, Sharing RPP