So that error usually indicates that something is wrong with the cert. Have you viewed the contents of the certificate to validate the CN, etc? 

openssl x509 -in $DOMAIN.crt.pem -noout -text
Also I've seen instances where certificate db gets corrupted, so if everything pans out with the certificate contents, I'd try deleted *.db and recreating your certificate database. I've seen this occur but have been able to reproduce it consistently. When this corruption happens the manage certificates tab will not work in the idm console so if that doesn't work, I'd try recreating it. 



On Jul 17, 2013, at 12:59 PM, Kyle Johnson <kjohnson@gnulnx.net> wrote:

Pointing -CAfile to the ca public cert returns this:

    Verify return code: 0 (ok)

I have just one CA, with no intermediates.

 
 

On 2013-07-17 12:45, Dan Lavu wrote:

Set it up and see what the output is, this should give you a clearer idea of what the problem is with the cert. 
 
Out of curiosity do you have just one CA or do you have intermediates as well?

On Jul 17, 2013, at 12:35 PM, Kyle Johnson <kjohnson@gnulnx.net> wrote:

On the other working machines, the openssl command produces the same output.

You're correct, I didn't not configure my CA cert to be used with openssl in openssl.cnf (on either box).

 
 

On 2013-07-17 12:23, Dan Lavu wrote:

Sounds like your certificates are not setup correctly for that system, what are the results on the other 'working' machines? 
 
I might have made a bad assumption, did you configure your CA cert to be used with openssl? (openssl.conf) That must be set otherwise you will have trust errors when using openssl s_client .
 
On Jul 17, 2013, at 12:18 PM, Kyle Johnson <kjohnson@gnulnx.net> wrote:

Hi Dan,

Yes, dirsrv does indeed start.  Here is what I receive from the openssl command (the important bits):

 

verify error:num=19:self signed certificate in certificate chain
verify return:0
...

Verify return code: 19 (self signed certificate in certificate chain)

 

    Kyle

 
 

On 2013-07-17 12:04, Dan Lavu wrote:

Sorry the command is something like 
 
$ openssl s_client -connect localhost:443
 
it's not verify… 
 

On Jul 17, 2013, at 12:03 PM, Dan Lavu <dan@lavu.net> wrote:

Kyle,

Does dirsrv start? If it does start, have you tried running 'openssl verify HOSTNAME:PORT' to validate the certificate?

Dan

On Jul 17, 2013, at 10:55 AM, Kyle Johnson <kjohnson@gnulnx.net> wrote:

Hello everyone,

I have been receiving help from richm in the #389 channel for the last few days, but haven't made much progress, so I'd like to move the conversation somewhere a little more persistent.

My issue is that after manually enabling SSL by following the instructions at               ry.fedoraproject.org/wiki/Howto:SSL#Starting_the_Server_with_SSL_enabled
(that is, not using the setupssl2.sh script) and installing my CA and public and private key bundle, I am receiving the following error when starting dirsrv.
I also receive this error if I run the setupssl2.sh script and then replace the certificates and keys generated by it with the ones below.


[root@ldap005 slapd-ldap005]# service dirsrv restart
Shutting down dirsrv:
  ldap005...                                             [  OK  ]
Starting dirsrv:
  ldap005...[17/Jul/2013:14:41:21 +0000] - SSL alert: CERT_VerifyCertificateNow: verify certificate failed for cert ldap005.infra.dfw of family cn=RSA,cn=encryption,cn=config (Netscape Portable Runtime error -8016 - unknown)
                                                         [  OK  ]
[root@ldap005 slapd-ldap005]#


Here is a list of the installed certs:
ca001.zhv.domain.com                                  CT,,
ldap005.infra.dfw                                            u,u,u


And the installed keys:
< 0> rsa      a25fae676b83cfeb52d1fdc671aa74a34ef4ee8c   ldap005.infra.dfw


My versions of 389 are as follows:
389-ds-console-1.2.6-1.el6.noarch
389-ds-1.2.2-1.el6.noarch
389-ds-base-1.2.11.15-14.el6_4.x86_64
389-admin-console-1.1.8-1.el6.noarch
389-ds-console-doc-1.2.6-1.el6.noarch
389-dsgw-1.1.9-1.el6.x86_64
389-adminutil-1.1.15-1.el6.x86_64
389-ds-base-libs-1.2.11.15-14.el6_4.x86_64
389-console-1.1.7-1.el6.noarch
389-admin-1.1.29-1.el6.x86_64
389-admin-console-doc-1.1.8-1.el6.noarch


I would like to note that I have this working on another of my 389 servers, the difference being that 389-ds-base is an earlier version:
389-console-1.1.7-1.el6.noarch
389-ds-base-1.2.10.2-20.el6_3.x86_64
389-admin-console-1.1.8-1.el6.noarch
389-ds-console-doc-1.2.6-1.el6.noarch
389-dsgw-1.1.9-1.el6.x86_64
389-adminutil-1.1.15-1.el6.x86_64
389-ds-base-libs-1.2.10.2-20.el6_3.x86_64
389-admin-1.1.29-1.el6.x86_64
389-ds-console-1.2.6-1.el6.noarch
389-admin-console-doc-1.1.8-1.el6.noarch
389-ds-1.2.2-1.el6.noarch



Please let me know what other information you would need to help me with troubleshooting this issue.

  Kyle Johnson

--
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

--
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
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users