John Mancuso wrote: > 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! > Use SubjectAltName instead of wildcards - http://directory.fedoraproject.org/wiki/Howto:SSL#Using_Subject_Alt_Name > 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 > -- 389 users mailing list 389-users@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/389-users
