Re: [389-users] Problems with replication over SSL

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Dan Weintraub wrote:
Hi all,

I've been looking into this and I first found out that your suspicions are correct. The trust attributes on my CA certificate are incorrect.

certutil -L shows them as "CT,,"

To fix this I tried the modify command,

certutil -M -n cacert -t CTu,u,u -d .

It gives no error, but unfortunately, does nothing and certutil -L still shows me "CT,,"

I thought this might have been because I used openssh tools instead of certutil, so I removed all my certificates and created a new CA with certutil, specifying "CTu,u,u" on the command line when I created the CA cert. I then added the CA with the Certificate Manager and did a certutil -L only to find that it was marked "CT,," I tried to modify this certificate with certutil -M, but it still doesn't work.

Do I have some permissions wrong somewhere? Am I using the tools incorrectly? Any suggestions?
CT and CTu are equivalent for a CA cert - that is, the "u" doesn't matter for a CA cert.

What is it that leads you to believe the trust settings are an issue?

Thanks in advance,
Dan



jean-Noël Chardron wrote:
hi,

Dan Weintraub a écrit :
Thanks, that's exactly what I was following. Now that I've got the port corrected I'm getting a certificate error despite having the correct certificates setup (or so I thought...) I'll read through that documentation you posted and see if I can sort it out.

Thanks,
Dan

PS
NSMMReplicationPlugin - agmt="cn=One" (fds:636): Simple bind failed, LDAP sdk error 81 (Can't contact LDAP server), Netscape Portable Runtime error -8172

(Peer's certificate issuer has been marked as not trusted by the user.)

Can you post the output of the command :
#certutil -L -d /path/of/directory/where/is/the/certificate/

The path of the directory where is the certificate has 2 files : key3.db and cert8.db

For example, on my server the output is :
# certutil -L -d /etc/dirsrv/slapd-aragon/
Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI

CNRS2-Standard                                               CT,C,C
aragon.dr15.cnrs.fr Cert                                     u,u,u
CNRS-Standard                                                CT,C,C
CNRS                                                         CT,C,C
CNRS2                                                        CT,C,C

I suppose (it's a hypothesis) that your certificate doesn't have the tag u,u,u or something like this or the CA can't trust the certificate

John A. Sullivan III wrote:

On Tue, 2009-06-09 at 16:20 -0400, Dan Weintraub wrote:
Hi all,

I'm trying to setup replication over ssl and am running into problems. I first tried it unencrypted and all worked fine. I then copied over the
consumer's CA certificate and set up replication with SSL and Simple
Authentication. It doesn't work and I now get the following errors:

When I set it up:
supplier error log:
[01/Jun/2009:01:00:00 -0000] NSMMReplicationPlugin - agmt="cn=One"
(fds:389): Simple bind failed, LDAP sdk error 81 (Can't contact LDAP
server), Netscape Portable Runtime error -5938 (Encountered end of file.)

these appear thereafter:
consumer access log:
[01/Jun/2009:01:01:01 -0000] conn=898 fd=64 slot=64 connection from
10.1.1.100 to 10.1.1.101
[01/Jun/2009:01:01:01 -0000] conn=898 op=-1 fd=64 closed error 71
(Protocol error) - B1

consumer error log:
[01/Jun/2009:01:01:01 -0000] - conn=898 received a non-LDAP message (tag
0x80, expected 0x30)

Versions:
Supplier:
fedora-ds-1.1.2-1.fc6
fedora-ds-dsgw-1.1.1-1.fc6
fedora-ds-base-1.1.3-2.fc6
fedora-ds-admin-1.1.6-1.fc6
fedora-ds-admin-console-1.1.2-1.fc6
fedora-ds-console-1.1.2-1.fc6

Consumer:
fedora-ds-admin-1.1.7-3.fc6
fedora-ds-admin-console-1.1.3-1.fc6
fedora-ds-base-1.2.0-2.fc6
fedora-ds-dsgw-1.1.2-1.fc6
fedora-ds-console-1.2.0-1.fc6
fedora-ds-1.1.3-1.fc6

I'm at a loss as to how to proceed with troubleshooting and would
appreciate any suggestions.

Thanks,
Dan Weintraub
<snip>
Hi, Dan. Here is a snippet from our internal documentation. I apologize that I don't have time to customize it or analyze your issue more deeply
but perhaps our findings will help you in your environment.  Given
Rich's comment, I wonder if you were stung by the same error in
documentation we noted below:

        Go back to the centos-idm-console on ldap1
        Go to the Configuration tab, select the userRoot under the
        Replication
        object in the left panel.  Left/right client and choose New
        Replication
        Agreement
The name is "mycompany.com ldap1->ldap2" and the Description is
        "Replicates mycompany.com from ldap1 to ldap2".  Click Next.
        Set the Consumer to ldap2.mycompany.com:389 from the drop down
box (389 is correct even though we are really using 636) - Oops!
        That is not true despite what the documentation says.  Click
        other and create a new entry for ldap2.mycompany.com on port
        636.
        Enable the SSL connection.
        Enter cn=repuser,cn=config for the Bind As and enter the
        password.
        Click Next and then Next again.
        We will always keep directories in sync so click Next again.
        Choose Initialize Consumer Now and click Next
        Click Done

If you need more details, e.g., about how we set up SSL, I posted most
of our internal procedure a day or two ago on this mailing list in
response to a post entitled "Developting a CentOS-DS setup".  You can
find much more detail there.

Good luck - John

--
389 users mailing list
389-users@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-directory-users



--
389 users mailing list
389-users@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-directory-users


<<attachment: smime.p7s>>

--
389 users mailing list
389-users@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-directory-users

[Index of Archives]     [Fedora Directory Users]     [Fedora Directory Devel]     [Fedora Announce]     [Fedora Legacy Announce]     [Kernel]     [Fedora Legacy]     [Share Photos]     [Fedora Desktop]     [PAM]     [Red Hat Watch]     [Red Hat Development]     [Big List of Linux Books]     [Gimp]     [Yosemite News]

  Powered by Linux