[389-users] Error when starting dirsrv after enabling SSL and installing keys and certificates

[Dan Lavu]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/389-users/attachments/20130717/6ce0e08b/attachment.html>