On 12/14/2010 01:51 AM, remy d1 wrote: > Hi list, > > I have followed the instructions of the SSL Howto, but I am still > stick at the SSL activation. > > From a clean installation, I try to launch the setupssl.sh script, but > at the end, I have > > ldapmodify: invalid format (line 11) entry: "cn=encryption,cn=config" > > > There is not specific configuration except that I use the port 9831 > for my DS instead of 389 (I already use the standard LDAP port for > OpenLDAP and I do not want to migrate (it is for testing)). I have > modified the setupssl script to execute on this port. What version of 389-ds-base? What platform? > > If I just try the end of the script, you can see the error : > > ldapmodify -x -h localhost -p 9831 -D "cn=Directory Manager" -W <<EOF > dn: cn=encryption,cn=config > changetype: modify > replace: nsSSL3 > nsSSL3: on > - > replace: nsSSLClientAuth > nsSSLClientAuth: allowed > - > add: nsSSL3Ciphers > nsSSL3Ciphers: > -rsa_null_md5,+rsa_rc4_128_md5,+rsa_rc4_40_md5,+rsa_rc2_40_md5, > +rsa_des_sha,+rsa_fips_des_sha,+rsa_3des_sha,+rsa_fips_3des_sha,+fortezza, > +fortezza_rc4_128_sha,+fortezza_null,+tls_rsa_export1024_with_rc4_56_sha, > +tls_rsa_export1024_with_des_cbc_qsha > Did you modify the script in any other way, other than changing the port number? Because the Ciphers attribute LDIF does not look correct. Each of the continuation lines should begin with a single space character - these continuation lines look left justified. > > > dn: cn=config > changetype: modify > add: nsslapd-security > nsslapd-security: on > - > replace: nsslapd-ssl-check-hostname > nsslapd-ssl-check-hostname: off > - > replace: nsslapd-secureport > nsslapd-secureport: 636 > > dn: cn=RSA,cn=encryption,cn=config > changetype: add > objectclass: top > objectclass: nsEncryptionModule > cn: RSA > nsSSLPersonalitySSL: Server-Cert > nsSSLToken: internal (software) > nsSSLActivation: on > > EOF > > Enter LDAP Password: > ldapmodify: invalid format (line 11) entry: "cn=encryption,cn=config" > > > I have checked every part of these ldif data. The error is here : > > nsSSL3Ciphers: > -rsa_null_md5,+rsa_rc4_128_md5,+rsa_rc4_40_md5,+rsa_rc2_40_md5, > +rsa_des_sha,+rsa_fips_des_sha,+rsa_3des_sha,+rsa_fips_3des_sha,+fortezza, > +fortezza_rc4_128_sha,+fortezza_null,+tls_rsa_export1024_with_rc4_56_sha, > +tls_rsa_export1024_with_des_cbc_qsha > > > But if I do the modifications except this piece of code, ldaps can be > started on the port 636, but the cert files could not be loaded from > dirsrv, so I can not do any request in SSL... If you do not successfully complete TLS/SSL configuration, you will almost always find that TLS/SSL is not working correctly. What errors do you get? Error codes? > I also try to : > - edit dse.ldif file in the dirsrv DS configuration directory and > delete the line corresponding to the cert files as Red Hat > documentation tells (after stoping dirsrv service). Since you did not successfully complete TLS/SSL configuration, you will find that TLS/SSL is not working correctly. Can you provide a link to the Red Hat docs? > We can see that dirsrv reload the cert files in the dse.ldif file, but > it changed nothing. > - delete every *.db and *.txt files and cacert.csa. Then, if I > reexecute setupssl.sh, it generates the cert files, but (again), there > is no changes... > > Obviously, if I open 389-console, I could see this string in the > properties of "cn=encryption,cn=config". Including all of the ciphers in the Ciphers attribute? > > I have checked my real hostname and other stuffs specified in the > documentation... I know that I do not use the standard LDAP port but I > do not see why this section could not work... Other ldap request on > this port work. > > Sorry for my bad english... > > Any help would be gracefull ! > > Regards; > > R?my > > > -- > 389 users mailing list > 389-users at lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/389-users -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.fedoraproject.org/pipermail/389-users/attachments/20101214/4420a7c4/attachment-0001.html
