Issues enabling SSL/TLS for config DS

I am having difficulty getting the config DS connection working over TLS.  When I enable
this and attempt to log into the console, I receive an "Authentication Failed"
error.

The admin server log shows:
[Tue Jun 13 21:34:16.649391 2017] [:error] [pid 2246:tid 140216580957952] Could not bind
as [cn=Directory Manager]: ldap error -1: Can't contact LDAP server
[Tue Jun 13 21:34:16.650706 2017] [:error] [pid 2246:tid 140216580957952] Could not bind
as [cn=Directory Manager]: ldap error -1: Can't contact LDAP server
[Tue Jun 13 21:34:16.653671 2017] [:crit] [pid 2246:tid 140216580957952] buildUGInfo():
unable to initialize TLS connection to LDAP host ldap.example.com port 636: 4
[Tue Jun 13 21:34:16.653758 2017] [auth_basic:error] [pid 2246:tid 140216580957952]
[client 127.0.0.1:36728] AH01618: user cn=Directory Manager not found:
/admin-serv/authenticate

DS access log shows:
[13/Jun/2017:21:34:16.648487859 +1000] conn=12 fd=64 slot=64 SSL connection from 127.0.0.1
to 127.0.1.1
[13/Jun/2017:21:34:16.649537136 +1000] conn=12 op=-1 fd=64 closed - Encountered end of
file.
[13/Jun/2017:21:34:16.649934634 +1000] conn=13 fd=64 slot=64 SSL connection from 127.0.0.1
to 127.0.1.1
[13/Jun/2017:21:34:16.650851904 +1000] conn=13 op=-1 fd=64 closed - Encountered end of
file.
[13/Jun/2017:21:34:16.651700770 +1000] conn=14 fd=64 slot=64 SSL connection from 127.0.0.1
to 127.0.1.1
[13/Jun/2017:21:34:16.653398027 +1000] conn=14 op=-1 fd=64 closed - Encountered end of
file.

Editing /etc/dirsrv/admin-serv/adm.conf to replace the ldapurl with the insecure version
allows the console login to proceed again.  Tick the box for secure config DS, restart and
the issue appears.  From the DS access log it seems the SSL/TLS connection may be aborting
unexpectedly.

ldapsearch over LDAPS or using STARTTLS both seem to work fine.

Is there any way of confirming where the issue lies?



Versions installed (running on Fedora25)

# yum list installed | grep 389
Redirecting to '/usr/bin/dnf list installed' (see 'man yum2dnf')

389-admin.x86_64                       1.1.46-1.fc25                   @updates
389-admin-console.noarch               1.1.12-1.fc25                   @fedora
389-admin-console-doc.noarch           1.1.12-1.fc25                   @fedora
389-adminutil.x86_64                   1.1.23-1.fc25                   @fedora
389-console.noarch                     1.1.18-1.fc25                   @fedora
389-ds.noarch                          1.2.2-8.fc24                    @fedora
389-ds-base.x86_64                     1.3.5.17-3.fc25                 @updates
389-ds-base-libs.x86_64                1.3.5.17-3.fc25                 @updates
389-ds-console.noarch                  1.2.16-1.fc25                   @fedora
389-ds-console-doc.noarch              1.2.16-1.fc25                   @fedora
389-dsgw.x86_64                        1.1.11-10.fc25                  @fedora

[Mark Reynolds]

On 06/13/2017 08:10 AM, dave_horton2001(a)hotmail.com wrote:
>  I am having difficulty getting the config DS connection working over
> TLS.  When I enable this and attempt to log into the console, I receive an
> "Authentication Failed" error.
>
>  The admin server log shows:
>  [Tue Jun 13 21:34:16.649391 2017] [:error] [pid 2246:tid 140216580957952] Could not bind
> as [cn=Directory Manager]: ldap error -1: Can't contact LDAP server
>  [Tue Jun 13 21:34:16.650706 2017] [:error] [pid 2246:tid 140216580957952] Could not bind
> as [cn=Directory Manager]: ldap error -1: Can't contact LDAP server
>  [Tue Jun 13 21:34:16.653671 2017] [:crit] [pid 2246:tid 140216580957952] buildUGInfo():
> unable to initialize TLS connection to LDAP host ldap.example.com port 636: 4
>  [Tue Jun 13 21:34:16.653758 2017] [auth_basic:error] [pid 2246:tid 140216580957952]
> [client 127.0.0.1:36728] AH01618: user cn=Directory Manager not found:
> /admin-serv/authenticate
>
>  DS access log shows:
>  [13/Jun/2017:21:34:16.648487859 +1000] conn=12 fd=64 slot=64 SSL connection from
> 127.0.0.1 to 127.0.1.1
>  [13/Jun/2017:21:34:16.649537136 +1000] conn=12 op=-1 fd=64 closed - Encountered end of
> file.
>  [13/Jun/2017:21:34:16.649934634 +1000] conn=13 fd=64 slot=64 SSL connection from
> 127.0.0.1 to 127.0.1.1
>  [13/Jun/2017:21:34:16.650851904 +1000] conn=13 op=-1 fd=64 closed - Encountered end of
> file.
>  [13/Jun/2017:21:34:16.651700770 +1000] conn=14 fd=64 slot=64 SSL connection from
> 127.0.0.1 to 127.0.1.1
>  [13/Jun/2017:21:34:16.653398027 +1000] conn=14 op=-1 fd=64 closed - Encountered end of
> file.
>
>  Editing /etc/dirsrv/admin-serv/adm.conf to replace the ldapurl with the insecure version
> allows the console login to proceed again.  Tick the box for secure config DS, restart and
> the issue appears.  From the DS access log it seems the SSL/TLS connection may be aborting
> unexpectedly. 
Try removing all the *.db files from ~/.389-console/ and trying again.
 
It's possible that the cert db for the console is not valid or outdated.
>  ldapsearch over LDAPS or using STARTTLS both seem to work fine.
>
>  Is there any way of confirming where the issue lies?
>
>
>
>  Versions installed (running on Fedora25)
>
>  # yum list installed | grep 389
>  Redirecting to '/usr/bin/dnf list installed' (see 'man yum2dnf')
>
>  389-admin.x86_64                       1.1.46-1.fc25                   @updates
>  389-admin-console.noarch               1.1.12-1.fc25                   @fedora
>  389-admin-console-doc.noarch           1.1.12-1.fc25                   @fedora
>  389-adminutil.x86_64                   1.1.23-1.fc25                   @fedora
>  389-console.noarch                     1.1.18-1.fc25                   @fedora
>  389-ds.noarch                          1.2.2-8.fc24                    @fedora
>  389-ds-base.x86_64                     1.3.5.17-3.fc25                 @updates
>  389-ds-base-libs.x86_64                1.3.5.17-3.fc25                 @updates
>  389-ds-console.noarch                  1.2.16-1.fc25                   @fedora
>  389-ds-console-doc.noarch              1.2.16-1.fc25                   @fedora
>  389-dsgw.x86_64                        1.1.11-10.fc25                  @fedora
>  _______________________________________________
>  389-users mailing list -- 389-users(a)lists.fedoraproject.org
>  To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org

Thanks for the reply.

Same end result in the console, although the access log of the DS seems to indicate a bind
was attempted.  This is post restart after enabling the secure option.

[13/Jun/2017:22:37:57.078824629 +1000] conn=1 fd=64 slot=64 SSL connection from 127.0.0.1
to 127.0.1.1
[13/Jun/2017:22:37:57.084958096 +1000] conn=1 TLS1.2 128-bit AES
[13/Jun/2017:22:37:58.086857551 +1000] conn=1 op=0 BIND dn="cn=Directory
Manager" method=128 version=3
[13/Jun/2017:22:37:58.089006286 +1000] conn=1 op=0 RESULT err=0 tag=97 nentries=0 etime=1
dn="cn=directory manager"
[13/Jun/2017:22:37:58.466346017 +1000] conn=2 fd=65 slot=65 SSL connection from 127.0.0.1
to 127.0.1.1
[13/Jun/2017:22:37:58.466882909 +1000] conn=2 op=-1 fd=65 closed - Encountered end of
file.
[13/Jun/2017:22:37:58.467173875 +1000] conn=3 fd=65 slot=65 SSL connection from 127.0.0.1
to 127.0.1.1
[13/Jun/2017:22:37:58.467647324 +1000] conn=3 op=-1 fd=65 closed - Encountered end of
file.
[13/Jun/2017:22:37:58.504891549 +1000] conn=4 fd=65 slot=65 SSL connection from 127.0.0.1
to 127.0.1.1
[13/Jun/2017:22:37:58.505622631 +1000] conn=4 op=-1 fd=65 closed - Encountered end of
file.
[13/Jun/2017:22:37:58.505920575 +1000] conn=5 fd=65 slot=65 SSL connection from 127.0.0.1
to 127.0.1.1
[13/Jun/2017:22:37:58.506534580 +1000] conn=5 op=-1 fd=65 closed - Encountered end of
file.

[Mark Reynolds]

On 06/13/2017 08:45 AM, dave_horton2001(a)hotmail.com wrote:
>  Thanks for the reply.
>
>  Same end result in the console, although the access log of the DS seems to indicate a
> bind was attempted.  This is post restart after enabling the secure option. 
Did you
setup SSL for the Admin Server?  Admin Server (http server)
needs its own server/CA cert in its security database.  DS looks good
and you confirmed this with your ldapsearch, but you need to do the same
for the Admin Server.

>  [13/Jun/2017:22:37:57.078824629 +1000] conn=1 fd=64 slot=64 SSL connection from 127.0.0.1
> to 127.0.1.1
>  [13/Jun/2017:22:37:57.084958096 +1000] conn=1 TLS1.2 128-bit AES
>  [13/Jun/2017:22:37:58.086857551 +1000] conn=1 op=0 BIND dn="cn=Directory
> Manager" method=128 version=3
>  [13/Jun/2017:22:37:58.089006286 +1000] conn=1 op=0 RESULT err=0 tag=97 nentries=0 etime=1
> dn="cn=directory manager"
>  [13/Jun/2017:22:37:58.466346017 +1000] conn=2 fd=65 slot=65 SSL connection from 127.0.0.1
> to 127.0.1.1
>  [13/Jun/2017:22:37:58.466882909 +1000] conn=2 op=-1 fd=65 closed - Encountered end of
> file.
>  [13/Jun/2017:22:37:58.467173875 +1000] conn=3 fd=65 slot=65 SSL connection from 127.0.0.1
> to 127.0.1.1
>  [13/Jun/2017:22:37:58.467647324 +1000] conn=3 op=-1 fd=65 closed - Encountered end of
> file.
>  [13/Jun/2017:22:37:58.504891549 +1000] conn=4 fd=65 slot=65 SSL connection from 127.0.0.1
> to 127.0.1.1
>  [13/Jun/2017:22:37:58.505622631 +1000] conn=4 op=-1 fd=65 closed - Encountered end of
> file.
>  [13/Jun/2017:22:37:58.505920575 +1000] conn=5 fd=65 slot=65 SSL connection from 127.0.0.1
> to 127.0.1.1
>  [13/Jun/2017:22:37:58.506534580 +1000] conn=5 op=-1 fd=65 closed - Encountered end of
> file.
>  _______________________________________________
>  389-users mailing list -- 389-users(a)lists.fedoraproject.org
>  To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org

I believe that should all be ok.  It's using the same key/cert as the DS although
I've also tried different keys/certs.  There is an intermediate cert in the chain, but
in Manage Certs in both DS and admin server the trust chain seems to appear ok.

I can contact the admin server over https, it's just when I change the config DS to
secure, and it updates the ldapurl in adm.conf that it subsequently fails.

Some more info in case it helps shed some light...  If I attempt to update the User DS in
the console then the update fails to apply.  But if I use ldapmodify to manually update
the directoryURL, then that seems to work ok over SSL.  The issue seems to be limited to
the config DS only as far as I can tell.

Admin server key/certs below.

[root@ldap admin-serv]# certutil -d . -K
certutil: Checking token "NSS Certificate DB" in slot "NSS User Private Key
and Certificate Services"
Enter Password or Pin for "NSS Certificate DB":
< 0> rsa      629b29a5d48bb157af44d40edf6b7b27d9fe6c2a   ldap.example.com
[root@ldap admin-serv]#

[root@ldap admin-serv]# certutil -d . -L

Certificate Nickname                                         Trust Attributes
                                                             SSL,S/MIME,JAR/XPI

root-ca                                                      CT,,
ca-cert                                                      CT,,
ldap.example.com                                                CTu,u,u

Is there anything in particular about the config DS that would require some specific
certificate extensions or anything like that?  It seems peculiar that only that portion
seems to be failing, unless I'm mistaken in what I'm seeing.

Thanks again for your help.

[Mark Reynolds]

On 06/13/2017 09:06 AM, dave_horton2001(a)hotmail.com wrote:
>  I believe that should all be ok.  It's using the same key/cert as
> the DS although I've also tried different keys/certs.  There is an intermediate cert
> in the chain, but in Manage Certs in both DS and admin server the trust chain seems to
> appear ok.
>
>  I can contact the admin server over https, it's just when I change the config DS to
> secure, and it updates the ldapurl in adm.conf that it subsequently fails.
>
>  Some more info in case it helps shed some light...  If I attempt to update the User DS in
> the console then the update fails to apply.  But if I use ldapmodify to manually update
> the directoryURL, then that seems to work ok over SSL.  The issue seems to be limited to
> the config DS only as far as I can tell.
>
>  Admin server key/certs below.
>
>  [root@ldap admin-serv]# certutil -d . -K
>  certutil: Checking token "NSS Certificate DB" in slot "NSS User Private
> Key and Certificate Services"
>  Enter Password or Pin for "NSS Certificate DB":
>  < 0> rsa      629b29a5d48bb157af44d40edf6b7b27d9fe6c2a   ldap.example.com
>  [root@ldap admin-serv]#
>
>  [root@ldap admin-serv]# certutil -d . -L
>
>  Certificate Nickname                                         Trust Attributes
>                                                               SSL,S/MIME,JAR/XPI
>
>  root-ca                                                      CT,,
>  ca-cert                                                      CT,,
>  ldap.example.com                                                CTu,u,u
>
>  Is there anything in particular about the config DS that would require some specific
> certificate extensions or anything like that?  It seems peculiar that only that portion
> seems to be failing, unless I'm mistaken in what I'm seeing. 

This is from my setup that works:


DS
================================
[root@localhost slapd-localhost]# certutil -d . -L

Certificate Nickname                                         Trust
Attributes
                                                            
SSL,S/MIME,JAR/XPI

CA certificate                                               CTu,u,u
server-cert                                                  u,u,Pu
Server-Cert                                                  u,u,Pu


Admin
================================
[root@localhost admin-serv]# certutil -d . -L

Certificate Nickname                                         Trust
Attributes
                                                            
SSL,S/MIME,JAR/XPI

server-cert                                                  u,u,u
CA certificate                                               CT,,


There are some differences.  Perhaps you could try these extensions to
see if it helps?

Also what is in your cn=config/cn=encryption,cn=config entries for the
config DS (dse.ldif).  Here is mine:

dn: cn=config
...
...
nsslapd-ssl-check-hostname: off

dn: cn=encryption,cn=config
objectClass: top
objectClass: nsEncryptionConfig
cn: encryption
nsSSLSessionTimeout: 0
nsSSLClientAuth: allowed
sslVersionMin: TLS1.0
nsSSL3Ciphers: +all
numSubordinates: 1


This link below might also be useful.  While this doc talks about
disabling SSLv3, the part I want you to look at is configuring the
console preferences to use TLS 1.1/1.2

http://www.port389.org/docs/389ds/howto/howto-disable-sslv3.html
>  Thanks again for your help.
>  _______________________________________________
>  389-users mailing list -- 389-users(a)lists.fedoraproject.org
>  To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org

There were a couple of differences in the dse.ldif, hostname checking was on and the
cipher list was more restrictive.  I've updated via ldapmodify and restarted the DS
which caused the changes to be reflected in dse.ldif.  No change to behaviour though.

This is the working adm.conf:

userdn: uid=admin,ou=Administrators,ou=TopologyManagement,o=NetscapeRoot
sysuser: dirsrv
sysgroup: dirsrv
SuiteSpotUserID: dirsrv
SuiteSpotGroup: dirsrv
sie: cn=admin-serv-ldap,cn=389 Administration Server,cn=Server
Group,cn=ldap.example.com,ou=example.com,o=NetscapeRoot
securitydir: /etc/dirsrv/admin-serv
ldapurl: ldap://ldap.exmaple.com:389/o=NetscapeRoot
ldapStart: /usr/sbin/start-dirsrv ldap
isie: cn=389 Administration Server,cn=Server
Group,cn=ldap.example.com,ou=example.com,o=NetscapeRoot
AdminDomain: example.com

The only difference when it fails is that the ldapurl becomes:

ldapurl: ldaps://ldap.exmaple.com:636/o=NetscapeRoot

I figured out the issue here so updating for anyone else who may suffer this problem.

It appears that when things are locked down to prevent use of SSLv3, if you want to use
SSL with the Config DS from the admin server, you also need to specify the min/max SSL/TLS
version in adm.conf.

I added the following to adm.conf and it sprang to life.

sslVersionMin: TLS1.0
sslVersionMax: TLS1.2

I had added as much debug as I could but still couldn't find out what was going on, so
I got the source for 389, nss and openldap and pored through it.  I built a debug version
of the admin server and deployed that.  Trying the config DS with SSL then showed this in
the log.

util_ldap_init: Success: set up conn to [ldap.1ga.home:636] using TLS/SSL
util_ldap_bind: attempting SIMPLE bind with id [] creds []
util_ldap_bind: Error: could not send bind request for id [] mech [SIMPLE]: error -1
(Can't contact LDAP server) -12168 (SSL version range is not valid.) 2 (No such file
or directory)

Searching for "SSL version range is not valid" in the source I figured out that
the NSS was rejecting the admin server's attempt to bind over SSL/TLS due to a
mismatch in expected versions and that it was trying to pull a range from the adm.conf
file.

It's mentioned in http://www.port389.org/docs/389ds/howto/howto-disable-sslv3.html to
add the sslVersionMin/Max parameters to the console preferences file but it doesn't
mention anything about adding them to adm.conf.  Similarly, in
http://directory.fedoraproject.org/docs/389ds/administration/adminserver.... it
doesn't mention these parameters.  Could be worth an update to the documentation.

As a follow up question, I've read that ldap:389/STARTTLS is preferred over ldaps.  Is
it possible to configure the DS to listen on 389 but reject any requests that don't
perform a STARTTLS after the initial connect?  I've not seen anything anywhere that
indicates this is possible, only that you can disable port 389 entirely.

[Mark Reynolds]

On 06/17/2017 08:33 AM, dave_horton2001(a)hotmail.com wrote:
>  I figured out the issue here so updating for anyone else who may
> suffer this problem.
>
>  It appears that when things are locked down to prevent use of SSLv3, if you want to use
> SSL with the Config DS from the admin server, you also need to specify the min/max SSL/TLS
> version in adm.conf.
>
>  I added the following to adm.conf and it sprang to life.
>
>  sslVersionMin: TLS1.0
>  sslVersionMax: TLS1.2
>
>  I had added as much debug as I could but still couldn't find out what was going on,
> so I got the source for 389, nss and openldap and pored through it.  I built a debug
> version of the admin server and deployed that.  Trying the config DS with SSL then showed
> this in the log.
>
>  util_ldap_init: Success: set up conn to [ldap.1ga.home:636] using TLS/SSL
>  util_ldap_bind: attempting SIMPLE bind with id [] creds []
>  util_ldap_bind: Error: could not send bind request for id [] mech [SIMPLE]: error -1
> (Can't contact LDAP server) -12168 (SSL version range is not valid.) 2 (No such file
> or directory)
>
>  Searching for "SSL version range is not valid" in the source I figured out that
> the NSS was rejecting the admin server's attempt to bind over SSL/TLS due to a
> mismatch in expected versions and that it was trying to pull a range from the adm.conf
> file.
>
>  It's mentioned in http://www.port389.org/docs/389ds/howto/howto-disable-sslv3.html to
> add the sslVersionMin/Max parameters to the console preferences file but it doesn't
> mention anything about adding them to adm.conf.   
I'll get that fixed in both
docs.
>  Similarly, in
> http://directory.fedoraproject.org/docs/389ds/administration/adminserver.... it
> doesn't mention these parameters.  Could be worth an update to the documentation.
Will do.
>  As a follow up question, I've read that ldap:389/STARTTLS is preferred over ldaps. 
> Is it possible to configure the DS to listen on 389 but reject any requests that don't
> perform a STARTTLS after the initial connect?  I've not seen anything anywhere that
> indicates this is possible, only that you can disable port 389 entirely. 
You can
require secure connections (LDAPS or StartTLS) under cn=config:

nsslapd-require-secure-binds: on


This is discussed in the Admin the guide:

https://access.redhat.com/documentation/en-us/red_hat_directory_server/10...

And on the wiki:

http://www.port389.org/docs/389ds/howto/howto-require-secure-binds.html

Regards,
Mark


>  _______________________________________________
>  389-users mailing list -- 389-users(a)lists.fedoraproject.org
>  To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org

Great!  Thanks very much!

[Mark Reynolds]

On 06/17/2017 08:33 AM, dave_horton2001(a)hotmail.com wrote:
>  I figured out the issue here so updating for anyone else who may
> suffer this problem.
>
>  It appears that when things are locked down to prevent use of SSLv3, if you want to use
> SSL with the Config DS from the admin server, you also need to specify the min/max SSL/TLS
> version in adm.conf.
>
>  I added the following to adm.conf and it sprang to life.
>
>  sslVersionMin: TLS1.0
>  sslVersionMax: TLS1.2 
Actually this should not have worked.  Looking through the
admin source
we don't check for sslVersionMin/Max in the adm.conf.  Perhaps you also
made the change to console.conf, and just restarted the server?  If you
remove the sslVersionMin/Max from adm.conf, then restart the admin
server, does it still work?
>  I had added as much debug as I could but still couldn't find out what was going on,
> so I got the source for 389, nss and openldap and pored through it.  I built a debug
> version of the admin server and deployed that.  Trying the config DS with SSL then showed
> this in the log.
>
>  util_ldap_init: Success: set up conn to [ldap.1ga.home:636] using TLS/SSL
>  util_ldap_bind: attempting SIMPLE bind with id [] creds []
>  util_ldap_bind: Error: could not send bind request for id [] mech [SIMPLE]: error -1
> (Can't contact LDAP server) -12168 (SSL version range is not valid.) 2 (No such file
> or directory)
>
>  Searching for "SSL version range is not valid" in the source I figured out that
> the NSS was rejecting the admin server's attempt to bind over SSL/TLS due to a
> mismatch in expected versions and that it was trying to pull a range from the adm.conf
> file.
>
>  It's mentioned in http://www.port389.org/docs/389ds/howto/howto-disable-sslv3.html to
> add the sslVersionMin/Max parameters to the console preferences file but it doesn't
> mention anything about adding them to adm.conf.  Similarly, in
> http://directory.fedoraproject.org/docs/389ds/administration/adminserver.... it
> doesn't mention these parameters.  Could be worth an update to the documentation.
>
>  As a follow up question, I've read that ldap:389/STARTTLS is preferred over ldaps. 
> Is it possible to configure the DS to listen on 389 but reject any requests that don't
> perform a STARTTLS after the initial connect?  I've not seen anything anywhere that
> indicates this is possible, only that you can disable port 389 entirely.
>  _______________________________________________
>  389-users mailing list -- 389-users(a)lists.fedoraproject.org
>  To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org

Hi Mark,

I can confirm removing it from adm.conf prevents it working.  Adding it back, it works
again.

Possibly there's another means that normally ensures the correct range is set for the
config DS connection?

The function returning the error that shows up in the log with the debug build is this
'ssl3_CheckRangeValidAndConstrainByPolicy' in 'nss/lib/ssl/sslsock.c'.

Following the call stack, ADMSSL_Init calls initNSS which in turn calls
SSL_VersionRangeSetDefault (again in 'nss/lib/ssl/sslsock.c').  This takes an
initial range as input and checks and constrains it (calling
ssl3_CheckRangeValidAndConstrainByPolicy which generates the error).

That initial range passed to SSL_VersionRangeSetDefault comes from the following in
initNSS:

  range.min = admldapGetSSLMin(info);
  range.max = admldapGetSSLMax(info);

Tracing back, that info was the AdmldapInfo constructed for the config connection which
came from adm.conf.  So that was what led me to attempt adding the entries to adm.conf
which seemed to do the trick.

Hope that helps.
David

[Mark Reynolds]

On 06/17/2017 10:46 PM, dave_horton2001(a)hotmail.com wrote:
>  Hi Mark,
>
>  I can confirm removing it from adm.conf prevents it working.  Adding it back, it works
> again.
>
>  Possibly there's another means that normally ensures the correct range is set for the
> config DS connection?
>
>  The function returning the error that shows up in the log with the debug build is this
> 'ssl3_CheckRangeValidAndConstrainByPolicy' in 'nss/lib/ssl/sslsock.c'.
>
>  Following the call stack, ADMSSL_Init calls initNSS which in turn calls
> SSL_VersionRangeSetDefault (again in 'nss/lib/ssl/sslsock.c').  This takes an
> initial range as input and checks and constrains it (calling
> ssl3_CheckRangeValidAndConstrainByPolicy which generates the error).
>
>  That initial range passed to SSL_VersionRangeSetDefault comes from the following in
> initNSS:
>
>    range.min = admldapGetSSLMin(info);
>    range.max = admldapGetSSLMax(info); 
My bad, yeah it's in the 389-adminutil
package source code.  I was
previously looking in the 389-admin source. 

Updating the wiki...

Thanks,
Mark
>  Tracing back, that info was the AdmldapInfo constructed for the config connection which
> came from adm.conf.  So that was what led me to attempt adding the entries to adm.conf
> which seemed to do the trick.
>
>  Hope that helps.
>  David
>  _______________________________________________
>  389-users mailing list -- 389-users(a)lists.fedoraproject.org
>  To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org

[Mark Reynolds]

On 06/18/2017 07:41 AM, Mark Reynolds wrote:
>  On 06/17/2017 10:46 PM, dave_horton2001(a)hotmail.com wrote:
> > Hi Mark,
> >
> > I can confirm removing it from adm.conf prevents it working.  Adding it back, it
> works again.
> >
> > Possibly there's another means that normally ensures the correct range is set for
> the config DS connection?
> >
> > The function returning the error that shows up in the log with the debug build is
> this 'ssl3_CheckRangeValidAndConstrainByPolicy' in
> 'nss/lib/ssl/sslsock.c'.
> >
> > Following the call stack, ADMSSL_Init calls initNSS which in turn calls
> SSL_VersionRangeSetDefault (again in 'nss/lib/ssl/sslsock.c').  This takes an
> initial range as input and checks and constrains it (calling
> ssl3_CheckRangeValidAndConstrainByPolicy which generates the error).
> >
> > That initial range passed to SSL_VersionRangeSetDefault comes from the following in
> initNSS:
> >
> >   range.min = admldapGetSSLMin(info);
> >   range.max = admldapGetSSLMax(info);
>  My bad, yeah it's in the 389-adminutil package source code.  I was
>  previously looking in the 389-admin source. 
>
>  Updating the wiki... 
The following wiki pages now contain the complete SSL version
range
information:

http://www.port389.org/docs/389ds/howto/howto-ssl.html

http://www.port389.org/docs/389ds/howto/howto-disable-sslv3.html

http://www.port389.org/docs/389ds/administration/adminserver.html


Thanks Dave,

Mark

>  Thanks,
>  Mark
> > Tracing back, that info was the AdmldapInfo constructed for the config connection
> which came from adm.conf.  So that was what led me to attempt adding the entries to
> adm.conf which seemed to do the trick.
> >
> > Hope that helps.
> > David
> > _______________________________________________
> > 389-users mailing list -- 389-users(a)lists.fedoraproject.org
> > To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org
>  _______________________________________________
>  389-users mailing list -- 389-users(a)lists.fedoraproject.org
>  To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org

Nice one!  Happy to be of help and thanks for being so responsive to the initial query.

Dave