Hey there,

I can appreciate this seems really annoying, but if the hostname you use isn't in the certificate, we can't do anything about that. Either you have to use one of the SAN's or CN's in the cert, or you should consider using the ldapi socket on the same machine as well.

Another aspect of this is that we are working toward our new python tools, so we probably don't want to invest time in fixing db2index.pl to do anything. I think that dsconf should be the tool you want to look at using instead.

So in summary, I think you need to just use a fully qualified name to the server (one of the SANS), because this is a fact of how TLS works. Alternately, if you are on the same machine, ldapi:// is a great option for security too.

Hope that helps, and thanks for reporting it. If you need more help, please email 389-users mailing list and I'd be happy to help more with this situation.

@mreynolds I'll let you comment too, but I think we should resolve this ticket as no changes to be made.

Hello,

1)
I am using FQDN for all my hostname and SSL certificates.

Think about web servers. Suppose I had six web servers serving a web site (e.g example.com. Do you expect we would submit the physical internal hostnames of the six servers into the SAN?

Also sometimes it is not feasible because we are using external hosting services. You will expose the physical host names to the internet. Besides, re-issuing the SSL cert with CA sometimes requires service charge.

Also what if the physical server needed to be changed?

2) Edited: LDAPI option need to be enabled with 'nsslapd-ldapilisten' config and ACI. Previously I only enabled ACI and it's not enough.

Hi there,

That's the point of the SAN - to allow extra names. Additionally, knowledge of the machines in the cluster does not weaken the security of the system. You also will absolutely will require the hostnames to match for replication to be secure as well ...

Perhaps using cnames like "ldap1.domain.name" through "ldap6.domain.name" instead of raw hostnames could work for you? An different option is load balancers with the external facing with the "ca provided" cert, and behind using a self signed CA that you configure. The use of the aliases helps with your changing of the physical machine (move the cname), but it's also bad practice to share key/cert material on all servers. They should each have their own certificates.

For point two, you don't need -Z for LDAPI. You also need to pass in a different URL, not a different protocol. Try -P LDAP and the url something like "ldapi:///var...". I believe there are some examples in the red hat directory server documentation.

Hi,

Basically 389ds is the first network service that requires the physical hostname added to the SSL cert. Apahce, NGINX, sendmail, stunne, Java SSL and etc. does require it.

I remembered Java based netscape ds (e.g OpenDS , Open DJ, Oracle OUD) do not have this problem. Because they provide an option to specify hostname to connect, having and option to trust all remote certificate and having and option to trust the remote certificate for this session.

For point two, I am referring to db2index.pl. You cannot pass URL.
Anyway I got it working by using LDAPI.

LDAPI is the best solution here, if you want to avoid hostnames in certs, and guarantee security (localhost only).

The difference is that apache, sendmail, java and others do not have an active replication protocol - a protocol that contains the password hashes or private data of members of your organisation. It's important that we make sure that the replication traffic is not targeted for attack. As a result, we do want to have hostnames in certificates for this reason. I am now thinking more about how we could architect this better with regard to our certificates of course.

Take a look on OpenLDAP replication, it does not require the physical hostname added into the SAN/common name. (The server name specified in the config file need to match against the SAN/common name in the SSL cert. The physical hostname is not related.)

Sorry for the long delay. We aren't the OpenLDAP project, and I do strongly believe the value in TLS is the validation of the hostname. I think it's not right to weaken security assertions for this. Second, db2index is soon to be removed in 1.4.x so I really don't want to develop any improvements on the perl utilites, when our python tools will be available. Sorry about this :(

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

This issue has been cloned to Github and is available here:
- https://github.com/389ds/389-ds-base/issues/2971

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.