That's what it was! thanks. Unfortunately going across subdomains was a no go : -12276 (Unable to communicate securely with peer: requested domain name does not match the server's certificate. I tried to generate a self signed wildcard (cn=*.mycompany.com) but no luck there. Thanks anyways! On Thu, Sep 9, 2010 at 9:02 AM, Rob Crittenden <rcritten@xxxxxxxxxx> wrote: > John Mancuso wrote: >> >> I followed the exact procedure below numerous times with the same >> frustrating error: >> >> >> http://www.redhat.com/docs/manuals/dir-server/ag/8.0/Managing_SSL-Using_certutil.html#certutil-procedure >> >> !481 $ openssl verify cacert_core.asc >> cacert_core.asc: /DC=tv/DC=freewheel/CN=CA cert >> error 18 at 0 depth lookup:self signed certificate >> OK >> >> !482 $ openssl verify cacert_PEKdev020.asc >> cacert_PEKdev020.asc: /DC=tv/DC=freewheel/CN=CA cert >> error 18 at 0 depth lookup:self signed certificate >> OK >> >> !474 $ certutil -V -u V -d . -n "Core CA certificate" >> certutil: certificate is valid >> >> !476 $ certutil -V -u V -d . -n "Core Server-Cert" >> certutil: certificate is valid >> >> I also imported the consumers CA cert into the supplier ... this is >> correct? I tried only importing the suppliers CA cert before with the >> same issue (trying everything here!) >> >> This looks strange though (why the duplicate cert): >> >> !478 $ certutil -d . -L >> >> Certificate Nickname Trust >> Attributes >> >> SSL,S/MIME,JAR/XPI >> Core Server-Cert u,u,u >> Core CA certificate CTu,u,u >> Core CA certificate CT,, >> > > Ok, I think I know what you're seeing. Did you do the same procedure on both > the master and the replica? > > If you did then you created two separate CAs that know nothing about each > other and don't trust one another. > > You probably just want one CA in this case so I'd just pick either the > master or replica and issue another server certificate from it: > > certutil -S -n "Replica-Cert" -s "cn=FQDN" -c "CA certificate" -t "u,u,u" -m > 1001 -v 120 -d . -k rsa -g 1024 -f /tmp/pwdfile > > Then use pk12util to create a PKCS#12 file containing the cert and private > key: > > pk12util -o replica.p12 -d . -n Replica-Cert > > Ship this over to the replica and import it with: > > pk12util -i replica.p12 -d . > > The CA cert should be included in the PKCS#12 file but if it isn't you'll > need to grab it from the master and install it on the replica. > > rob > >> >> >> On Wed, Sep 8, 2010 at 10:49 PM, Rob Crittenden<rcritten@xxxxxxxxxx> >> wrote: >>> >>> John Mancuso wrote: >>>> >>>> Two questions: >>>> >>>> 1. I have generated self-signed ssl/ca certs trying both the >>>> "certutil" method from the redhat doc and also the standard "openssl >>>> x509 req -new" method. After installing the certs and enabling secure >>>> ldaps replication both result in >>>> >>>> slapi_ldap_bind - Error: could not send bind request for id >>>> [cn=replication manager,cn=config] mech [SIMPLE]: error 81 (Can't >>>> contact LDAP server) -8172 (Peer's certificate issuer has been marked >>>> as not trusted by the user.) 11 (Resource temporarily unavailable) >>>> >>>> Is there a known issue with self-signed certs? >>> >>> No, they work fine. Did you add the CA certificate that signed the server >>> certificate as well? >>> >>> You can verify that the certificate is ok on the server with: >>> >>> certutil -V -u V -d /etc/dirsrv/slapd-<YOUR_INSTANCE> >>> >>> You are probably just missing the CA certificate. If you have it in PEM >>> format you can add it via the command-line with: >>> >>> certutil -A -d /etc/dirsrv/slapd-<YOUR_INSTANCE> -n 'Your CA' -t CT,, >>> -a< >>> /path/to/ca.pem >>> >>> The 'Your CA' here is the nickname of the CA certificate. It is how it >>> will >>> appear in the DS console and using certutil -L. Pick something meaningful >>> to >>> you. >>> >>>> 2. If there is an issue with the above, we may end up purchasing a >>>> wildcard cert for replicating across subdomains. I know in the HTML >>>> world some web browsers complain about ssl wildcard certs across >>>> subdomains. Any possible issues with this approach? >>>> >>>> ldaps://supplier_ldap.mycompany.com----> >>>> ldaps://consumer_ldap.dev.mycompany.com >>> >>> A wildcard cert will work but its probably overkill to buy one just for >>> this >>> purpose. self-signed certificates will work fine. >>> >>> rob >>> >> -- >> 389 users mailing list >> 389-users@xxxxxxxxxxxxxxxxxxxxxxx >> https://admin.fedoraproject.org/mailman/listinfo/389-users > > -- 389 users mailing list 389-users@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/389-users
