Yea I replaced both certs, however, in my troubleshooting I've found more I'll 
say symptoms or potential problems, which may stem from this or be independent 
from it.  

1. Showing this error message on restarting the service: 
    EXAMPLE-COM...[29/May/2013:05:30:58 +0000] - SSL alert: 
CERT_VerifyCertificateNow: verify certificate failed for cert MyIPA of family 
cn=RSA,cn=encryption,cn=config (Netscape Portable Runtime error -8172 - Peer's 
certificate issuer has been marked as not trusted by the user.)

2. This is on an AWS machine, and when I rebooted the internal IP of the 
machine changed.  I'm not sure if there are values in the Directory Server that 
would have that internal IP in there which would cause a problem.  The external 
IP and DNS have stayed the same and I've tried to have all install values match 
the external IP or external name for this exact reason. 

3. The named service will no longer start, here are the errors getting put in 
the /var/log/messages
May 29 05:31:01 ip-10-1-3-5 named[5592]: sizing zone task pool based on 6 zones
May 29 05:31:01 ip-10-1-3-5 named[5592]: /etc/named.conf:12: no forwarders 
seen; disabling forwarding 
May 29 05:31:01 ip-10-1-3-5 named[5592]: set up managed keys zone for view 
_default, file 'dynamic/managed-keys.bind' 
 May 29 05:31:19 ip-10-1-3-5 named[5592]: Failed to init credentials (Cannot 
contact any KDC for realm 'EXAMPLE.COM') 
 May 29 05:31:19 ip-10-1-3-5 named[5592]: loading configuration: failure May 29 
05:31:19 ip-10-1-3-5 named[5592]: exiting (due to fatal error)

Any help in a right direction or theory to a right direction would be much 
appreciated! 

Thanks, 
_____________________________________________________
John Moyer
Director, IT Operations


On May 24, 2013, at 4:17 PM, Rob Crittenden <rcrit...@redhat.com> wrote:

> John Moyer wrote:
>> So I did that, and it executed perfectly (went back and checked that it did 
>> indeed replace the value as expected).  I got on the machine I was trying to 
>> add and got this:
>> 
>> root@ ~]# ipa-client-install --domain=example.com 
>> --server=server.example.com --realm=EXAMPLE.COM -p builduser -w "BLAH" -U
>> Hostname: blah.example.com
>> Realm: EXAMPLE.COM
>> DNS Domain: example.com
>> IPA Server: server.example.com
>> BaseDN: dc=example,dc=com
>> 
>> Synchronizing time with KDC...
>> The CA cert available from the IPA server does not match the
>> local certificate available at /etc/ipa/ca.crt
>> Existing CA cert:
>>     Subject:     CN=Certificate Authority,O=EXAMPLE.COM
>>     Issuer:      CN=Certificate Authority,O=EXAMPLE.COM
>>     Valid From:  Wed Mar 02 18:52:05 2013 UTC
>>     Valid Until: Sun Mar 02 18:52:05 2033 UTC
>> 
>> Retrieved CA cert:
>>     Subject:     CN=*.example.com,OU=Domain Control Validated,O=*.example.com
>>     Issuer:      serialNumber=07969287,CN=Go Daddy Secure Certification 
>> Authority,OU=http://certificates.godaddy.com/repository,O="GoDaddy.com, 
>> Inc.",L=Scottsdale,ST=Arizona,C=US
>>     Valid From:  Thu Dec 01 14:57:49 2011 UTC
>>     Valid Until: Sun Dec 01 14:57:49 2013 UTC
>> 
>> Cannot obtain CA certificate
>> 'ldap://server.example.com' doesn't have a certificate.
>> Installation failed. Rolling back changes.
>> IPA client is not configured on this system.
>> 
>> 
>> Then I tried to change the local machine's /etc/ipa/ca.crt to match the 
>> server.  I then got this:
> 
> Next time you can just remove /etc/ipa/ca.crt. The client will fetch an 
> updated one. This is fixed upstream.
> 
>> [root@]# ipa-client-install --domain=example.com --server=server.example.com 
>> --realm=EXAMPLE.COM -p builduser -w "BLAH" -U
>> Hostname: blah.example.com
>> Realm: EXAMPLE.COM
>> DNS Domain: example.com
>> IPA Server: server.example.com
>> BaseDN: dc=example,dc=com
>> 
>> Synchronizing time with KDC...
>> Joining realm failed: libcurl failed to execute the HTTP POST transaction.  
>> Peer certificate cannot be authenticated with known CA certificates
>> 
>> Installation failed. Rolling back changes.
>> IPA client is not configured on this system.
> 
> You replace the web server cert as well, right? And restarted Apache?
> 
> rob
> 
>> 
>> 
>> Thanks,
>> _____________________________________________________
>> John Moyer
>> Director, IT Operations
>> 
>> 
>> On May 24, 2013, at 3:11 PM, Rob Crittenden <rcrit...@redhat.com> wrote:
>> 
>>> John Moyer wrote:
>>>> So unfortunately a rebuild would be less than optimal for me, lots of 
>>>> servers and users.  So I've tried Dmitri's idea of ldapi and I got the 
>>>> access to LDAP now, however I may be going about this entire thing wrong.  
>>>>  I created an LDIF file that looks like this:
>>>> 
>>>> dn: cn=cacert,cn=ipa,cn=etc,dc=example,dc=com
>>>>    changetype: modify
>>>>    replace: cacert
>>>>    cacert:  NEWKEY_ksljdfkljadfkljalksdjfaBLAHBLAH
>>>> 
>>>> Then I ran the following:
>>>> 
>>>> ldapmodify -x -H ldapi://%2fvar%2frun%2fslapd-EXAMPLE-COM.socket -D 
>>>> "cn=Directory Manager" -W -f /root/change-settings.ldif
>>>> 
>>>> and I get the following error:
>>>> 
>>>> Enter LDAP Password:
>>>> modifying entry "cn=cacert,cn=ipa,cn=etc,dc=digitalreasoning,dc=com"
>>>> ldap_modify: Object class violation (65)
>>>>    additional info: attribute "cacert" not allowed
>>>> 
>>> 
>>> The attribute you want is caCertificate. What you need to do is convert 
>>> your CA cert from PEM format to DER:
>>> 
>>> openssl x509 -in /etc/ipa/ca.crt -out /tmp/ca.der -outform DER
>>> 
>>> Then use this ldif:
>>> 
>>> dn: cn=cacert,cn=ipa,cn=etc,dc=example,dc=com
>>> changetype: modify
>>> replace: cacertificate;binary
>>> cacertificate;binary:< file:///tmp/ca.der
>>> 
>>> That should do it.
>>> 
>>> rob
>> 
> 


_______________________________________________
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Reply via email to