[Freeipa-users] Cannot obtain CA Certificate

Dmitri Pal dpal at redhat.com
Tue Feb 19 02:35:43 UTC 2013


On 02/18/2013 09:06 PM, John Moyer wrote:
> Peter, 
>
> The client is pointing to DNS for the server.   Here is the log info
> from the ipa-client-log (in /var/log/).  I haven't tried the other
> stuff yet, I'll respond back when I get a chance to check out the CA
> cert things. 
>
>
> 2013-02-19T02:01:37Z DEBUG args=kinit ipa-bind at EXAMPLE.COM
> <mailto:ipa-bind at EXAMPLE.COM>
> 2013-02-19T02:01:37Z DEBUG stdout=Password for ipa-bind at EXAMPLE.COM
> <mailto:ipa-bind at EXAMPLE.COM>: 
>
> 2013-02-19T02:01:37Z DEBUG stderr=
> 2013-02-19T02:01:37Z DEBUG trying to retrieve CA cert via LDAP from
> ldap://ipa1.example.com
> 2013-02-19T02:01:37Z DEBUG get_ca_cert_from_ldap() error: Local error
> SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure.
>  Minor code may provide more information (Server
> krbtgt/COM at EXAMPLE.COM <mailto:krbtgt/COM at EXAMPLE.COM> not found in
> Kerberos database)
> 2013-02-19T02:01:37Z DEBUG {'info': 'SASL(-1): generic failure: GSSAPI
> Error: Unspecified GSS failure.  Minor code may provide more
> information (Server krbtgt/COM at EXAMPLE.COM
> <mailto:krbtgt/COM at EXAMPLE.COM> not found in Kerberos database)',
> 'desc': 'Local error'}
> 2013-02-19T02:01:37Z ERROR Cannot obtain CA certificate
> 'ldap://ipa1.example.com' <ldap://ipa1.example.com%27> doesn't have a
> certificate.
> 2013-02-19T02:01:37Z DEBUG args=kdestroy
> 2013-02-19T02:01:37Z DEBUG stdout=
> 2013-02-19T02:01:37Z DEBUG stderr=


Can the server resolve the client in the same way as client resolves itself?
In AWS it might be an issue because it changes system names dynamically
and thus you client host when restarted might have a different name or
be not resolvable by the server.
The fact that AWS changes names under you makes IPA not usable in AWS
environment.
https://fedorahosted.org/freeipa/ticket/2715

>
>
> Thanks, 
> _____________________________________________________
> John Moyer
> Director, IT Operations
> *Digital Reasoning Systems, Inc.*
> John.Moyer at digitalreasoning.com <mailto:john.moyer at digitalreasoning.com>
> Office:703.678.2311
> Mobile:240.460.0023
> Fax:703.678.2312
> www.digitalreasoning.com <http://www.digitalreasoning.com/>
>
> On Feb 18, 2013, at 8:42 PM, Peter Brown <rendhalver at gmail.com
> <mailto:rendhalver at gmail.com>> wrote:
>
>> On 19 February 2013 11:03, John Moyer
>> <john.moyer at digitalreasoning.com
>> <mailto:john.moyer at digitalreasoning.com>> wrote:
>>
>>     Peter, 
>>
>>     Thanks for the response, I just checked out my security group
>>     settings, I did have some ports blocked, however, allowing them
>>     did not help.   I installed mmap on the client and did a port
>>     scan of the server and got the follow: 
>>
>>     PORT    STATE SERVICE
>>     22/tcp  open  ssh
>>     53/tcp  open  domain
>>     80/tcp  open  http
>>     88/tcp  open  kerberos-sec
>>     389/tcp open  ldap
>>     443/tcp open  https
>>     464/tcp open  kpasswd5
>>     636/tcp open  ldapssl
>>     749/tcp open  kerberos-adm
>>
>>
>> There is a couple of UDP ports that need to be open as well
>> 464 and 88 from memory.
>>
>> They shouldn't affect your ability to download the ca cert.
>>
>> Have you checked the ipa-client log file?
>> I can't remember where that gets saved right now but it should
>> mention the location when you run the ipa-client command.
>>
>>
>>
>>     I tried to enroll again and got the same error as seen here: 
>>
>>
>>     Synchronizing time with KDC...
>>
>>     ipa         : ERROR    Cannot obtain CA certificate
>>
>>
>>
>>     Thanks, 
>>     _____________________________________________________
>>     John Moyer
>>
>>
>>     On Feb 18, 2013, at 7:24 PM, Peter Brown <rendhalver at gmail.com
>>     <mailto:rendhalver at gmail.com>> wrote:
>>
>>>     Hi John,
>>>
>>>     I ran into a similar issue with setting up a 2.2 client with a
>>>     3.1 server.
>>>     It turned out to be that port 80 wasn't open on the freeipa server.
>>>     I would check your ports and see if the right ones are open.
>>>     I also find that setting up the SRV and TXT records in your dns
>>>     zone makes setting up clients a lot simpler.
>>>
>>>
>>>
>>>     On 19 February 2013 00:58, John Moyer
>>>     <john.moyer at digitalreasoning.com
>>>     <mailto:john.moyer at digitalreasoning.com>> wrote:
>>>
>>>         Hello all, 
>>>
>>>         I am having an issue using IPA 2.2.0.   I am trying to put
>>>         together a proof of concept set of systems.  I've stood up 2
>>>         servers on AWS.   One is the server one is the client.   I
>>>         am using CentOS 6 to do all this testing on, with the
>>>         default IPA packages provided from CentOS.   I had a fully
>>>         operational proof of concept finished fully scripted to be
>>>         built without issues.   I shutdown and started these as
>>>         needed to show to people to get approval for the project.  
>>>         The other day the client stopped enrolling to the IPA
>>>         server, I have no idea why I assume a patch pushed out broke
>>>         something since it is a fully scripted install. It does get
>>>         the most recent patches each time I stand it up so it
>>>         definitely would pull any new patches that came out. 
>>>
>>>         After investigating I am getting this error when I try to
>>>         manually enroll the client.  I haven't been able to find any
>>>         reference to this error anywhere on the net.  Any help would
>>>         be greatly appreciated!  Let me know if any additional
>>>         details are needed. 
>>>
>>>
>>>         PLEASE NOTE:  Everything below has been sanitized 
>>>
>>>
>>>         [root at client ~]# ipa-client-install --domain=example.com
>>>         <http://example.com/> --server=ipa1.example.com
>>>         <http://ipa1.example.com/> --realm=EXAMPLE.COM
>>>         <http://example.com/> --configure-ssh --configure-sshd -p
>>>         ipa-bind -w "blah" -U
>>>         DNS domain 'example.com <http://example.com/>' is not
>>>         configured for automatic KDC address lookup.
>>>         KDC address will be set to fixed value.
>>>
>>>         Discovery was successful!
>>>         Hostname: client.ec2.internal
>>>         Realm: EXAMPLE.COM <http://example.com/>
>>>         DNS Domain: digitalreasoning.com <http://digitalreasoning.com/>
>>>         IPA Server: ipa1.example.com <http://ipa1.example.com/>
>>>         BaseDN: dc=example,dc=com
>>>
>>>
>>>         Synchronizing time with KDC...
>>>
>>>         ipa         : ERROR    Cannot obtain CA certificate
>>>         'ldap://ipa1.example.com' doesn't have a certificate.
>>>         Installation failed. Rolling back changes.
>>>         IPA client is not configured on this system.
>>>
>>>          
>>>         Thanks, 
>>>         _____________________________________________________
>>>         John Moyer
>>>
>>>
>>>
>>>         _______________________________________________
>>>         Freeipa-users mailing list
>>>         Freeipa-users at redhat.com <mailto:Freeipa-users at redhat.com>
>>>         https://www.redhat.com/mailman/listinfo/freeipa-users
>>>
>>>
>>
>>
>
>
>
> _______________________________________________
> Freeipa-users mailing list
> Freeipa-users at redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-users


-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager for IdM portfolio
Red Hat Inc.


-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20130218/a48831bb/attachment.htm>


More information about the Freeipa-users mailing list