[Freeipa-users] Cannot obtain CA Certificate

Tue Feb 19 02:44:17 UTC 2013

On 19 February 2013 12:06, John Moyer <john.moyer at digitalreasoning.com>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
> 2013-02-19T02:01:37Z DEBUG stdout=Password for 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 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 not found in Kerberos database)', 'desc':
> 'Local error'}
> 2013-02-19T02:01:37Z ERROR Cannot obtain CA certificate
> 'ldap://ipa1.example.com' 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=
>

 I would hazard a guess you need those udp ports open on the firewall for
your freeipa server.
the two I mentioned are kerberos ports.
you will likely need udp port 389 open as well for talking to the directory
server where it is attempting to get the cert from.

>
> Thanks,
> _____________________________________________________
> John Moyer
> Director, IT Operations
> *Digital Reasoning Systems, Inc.*
> John.Moyer at digitalreasoning.com <john.moyer at digitalreasoning.com>
> Office: 703.678.2311
> Mobile: 240.460.0023
> Fax: 703.678.2312
> www.digitalreasoning.com
>
> On Feb 18, 2013, at 8:42 PM, Peter Brown <rendhalver at gmail.com> wrote:
>
> On 19 February 2013 11:03, John Moyer <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> 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>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 --server=
>>> ipa1.example.com --realm=EXAMPLE.COM <http://example.com/>--configure-ssh --configure-sshd -p ipa-bind -w "blah" -U
>>> DNS domain '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
>>>  IPA Server: 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
>>> https://www.redhat.com/mailman/listinfo/freeipa-users
>>>
>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20130219/160cc33f/attachment.htm>