Re: [389-users] SSL Cert Issue
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,, On Wed, Sep 8, 2010 at 10:49 PM, Rob Crittenden 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- > > 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- -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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
Re: [389-users] SSL Cert Issue
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- 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- -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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
Re: [389-users] SSL Cert Issue
On 09/08/2010 08:45 PM, 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? > > 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 > You need to create your own CA Cert, sign your cert with that CA Cert, and import the CA cert into the certutil store. You also want to put the CA public cert into /etc/openldap/certs so the openldap tools will use it. There are a few guides on the internet for creating your own CA. I know Fedora 13 comes with its own CA tool. I personally use tinyca. -B -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
[389-users] SSL Cert Issue
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? 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 -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
Re: [389-users] Segfault & Core Dumps
Dael Maselli wrote: > > It worked! > > I wrote fs.suid_dumpable=1 in /etc/sysctl.conf, `sysctl -p` and > restarted dirsrv. Now it dumps. > > Thank you! > > I will report here the backtrace when it occurs. Great! Be sure to install the 389-ds-base-debuginfo package to get the symbols when generating the backtrace. > > Regards, > Dael Maselli. > > > > On 07/09/10 19.44, Ulf Weltman wrote: >> On 9/7/2010 8:25 AM, Dael Maselli wrote: >>> Hi Rich, >>> >>> On 07/09/10 16.56, Rich Megginson wrote: Do you see seg fault messages in /var/log/messages? >>> Sure: ns-slapd[13737]: segfault at 00bc rip >>> 003abb420375 >>> rsp 580d85d0 error 4 >>> >>> The directory server dumps core in the log file directory, which by default is /var/log/dirsrv/slapd-INSTANCE >>> Yes, it is the same as working directory: >>> # ls -l /proc/`pidof ns-slapd`/cwd >>> lrwxrwxrwx 1 root root 0 Sep 7 17:12 /proc/18721/cwd -> >>> /var/log/dirsrv/slapd-ds1 >>> >>> Is the crash easily reproducible? >>> No, it isn't. It seems random, but I can simulate a crash with kill >>> -QUIT. >>> >>> I tried killing a simple `sleep 10`: >>> >>> # ulimit -c unlimited >>> >>> # sleep 10& >>> [1] 19726 >>> >>> # kill -QUIT 19726 >>> [1]+ Quit (core dumped) sleep 10 >>> >>> # ls -l core.* >>> -rw--- 1 root root 290816 Aug 31 08:52 core.1008 >>> >>> But if I kill -QUIT ns-slapd no file is created. >> ns-slapd typically runs as setuid to a non-root user. Check what >> fs.suid_dumpable or kernel.suid_dumpable are set to. >>> Thanks, >>> Dael Maselli. >>> >>> >> >> >> >> -- >> 389 users mailing list >> 389-users@lists.fedoraproject.org >> https://admin.fedoraproject.org/mailman/listinfo/389-users > > > > -- > 389 users mailing list > 389-users@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/389-users -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
Re: [389-users] Segfault & Core Dumps
It worked! I wrote fs.suid_dumpable=1 in /etc/sysctl.conf, `sysctl -p` and restarted dirsrv. Now it dumps. Thank you! I will report here the backtrace when it occurs. Regards, Dael Maselli. On 07/09/10 19.44, Ulf Weltman wrote: On 9/7/2010 8:25 AM, Dael Maselli wrote: Hi Rich, On 07/09/10 16.56, Rich Megginson wrote: Do you see seg fault messages in /var/log/messages? Sure: ns-slapd[13737]: segfault at 00bc rip 003abb420375 rsp 580d85d0 error 4 The directory server dumps core in the log file directory, which by default is /var/log/dirsrv/slapd-INSTANCE Yes, it is the same as working directory: # ls -l /proc/`pidof ns-slapd`/cwd lrwxrwxrwx 1 root root 0 Sep 7 17:12 /proc/18721/cwd -> /var/log/dirsrv/slapd-ds1 Is the crash easily reproducible? No, it isn't. It seems random, but I can simulate a crash with kill -QUIT. I tried killing a simple `sleep 10`: # ulimit -c unlimited # sleep 10& [1] 19726 # kill -QUIT 19726 [1]+ Quit (core dumped) sleep 10 # ls -l core.* -rw--- 1 root root 290816 Aug 31 08:52 core.1008 But if I kill -QUIT ns-slapd no file is created. ns-slapd typically runs as setuid to a non-root user. Check what fs.suid_dumpable or kernel.suid_dumpable are set to. Thanks, Dael Maselli. -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users -- ___ Dael Maselli --- INFN-LNF Computing Service -- +39.06.9403.2214 ___ * Il Buco Nero * http://www.buconero.eu * ___ Democracy is two wolves and a lamb voting on what to have for lunch ___ smime.p7s Description: S/MIME Cryptographic Signature -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
