[Freeipa-users] [solved] TLS error on master server / CA issue?

KodaK sakodak at gmail.com
Fri Feb 28 20:17:37 UTC 2014


On Fri, Feb 28, 2014 at 1:05 PM, Rob Crittenden <rcritten at redhat.com> wrote:

> KodaK wrote:
>
>>
>>
>>
>> On Fri, Feb 28, 2014 at 11:14 AM, Rob Crittenden <rcritten at redhat.com
>> <mailto:rcritten at redhat.com>> wrote:
>>
>>     KodaK wrote:
>>
>>         Hey everyone,
>>
>>         A couple of days ago I started getting the following message:
>>
>>         [jebalicki at slpidml01 ~]$ ipa cert-show 1
>>         ipa: INFO: trying https://slpidml01.unix.xxx.__com/ipa/xml
>>
>>         <https://slpidml01.unix.xxx.com/ipa/xml>
>>         ipa: INFO: Forwarding 'cert_show' to server
>>         u'https://slpidml01.unix.xxx.__com/ipa/xml
>>
>>         <https://slpidml01.unix.xxx.com/ipa/xml>'
>>         ipa: ERROR: Certificate operation cannot be completed: Unable to
>>         communicate with CMS (Not Found)
>>
>>         I get a similar error in the GUI when looking at hosts.
>>
>>         slpidml01 is my "master" -- the one I initially built.  The other
>>         replicas also replicated the CA.
>>
>>         After some digging (and prompting from Red Hat support) I've
>>         found the
>>         following:
>>
>>         [root at slpidml01 ~]# ldapsearch -ZZ -H
>>         ldap://slpidml01.unix.xxx.com <http://slpidml01.unix.xxx.com>
>>         <http://slpidml01.unix.xxx.com__> -D "cn=Directory Manager" -W -b
>>
>>
>>         "dc=unix,dc=xxx,dc=com" -x
>>         ldap_start_tls: Connect error (-11)
>>                   additional info: TLS error -8172:Peer's certificate
>>         issuer has
>>         been marked as not trusted by the user.
>>
>>         But, interestingly, from another replica:
>>
>>         [jebalicki at slpidml02 ~]$ ldapsearch -ZZ -H
>>         ldap://slpidml01.unix.xxx.com <http://slpidml01.unix.xxx.com>
>>         <http://slpidml01.unix.xxx.com__> -D "cn=Directory Manager" -W -b
>>
>>
>>         "dc=unix,dc=xxx,dc=com" -x
>>         Enter LDAP Password:
>>         # extended LDIF
>>         #
>>         # LDAPv3
>>         # base <dc=unix,dc=xxx,dc=com> with scope subtree
>>         # filter: (objectclass=*)
>>         # requesting: ALL
>>         ...
>>
>>         So, obviously some certificate got hosed up somewhere.  I've been
>>         digging but I haven't found it yet.
>>
>>         Anyone have any ideas?
>>
>>         I have a ticket open with RH support, but I think I somehow got
>>         put with
>>         someone with a completely different sleep schedule -- I get
>>         replies at 3
>>         in the morning.  So, I'm asking here because I'm impatient. :)
>>
>>
>>     Check certificate expiration. Run getcert list to see what the
>>     status is.
>>
>>     rob
>>
>>
>> None are expired, but there are some coming up soon:
>>
>> [root at slpidml01 ~]# getcert list | grep expires
>>          expires: 2014-03-29 19:03:31 UTC
>>          expires: 2014-03-29 19:04:04 UTC
>>          expires: 2014-03-29 19:04:30 UTC
>>          expires: 2016-02-09 06:26:34 UTC
>>          expires: 2016-02-09 06:25:34 UTC
>>          expires: 2016-02-09 06:25:34 UTC
>>          expires: 2016-02-09 06:25:34 UTC
>>          expires: 2016-02-09 06:25:34 UTC
>>
>
> Ok. CA requests are proxied through Apache so a Not Found means that the
> CA isn't running. Check the trust on the audit cert:
>
> # certutil -L -d /var/lib/pki-ca/alias
>
> The trust for the audit signing cert should be u,u,Pu
>
> If it doesn't have it, fix it with:
>
> # certutil -M -d /var/lib/pki-ca/alias -n 'auditSigningCert cert-pki-ca'
> -t u,u,Pu
>
> Then restart the CA (or all of IPA if you wish).
>
> For the LDAP searches you may want to try the commands again, preceding
> them with LDAPTLS_CACERT=/etc/ipa/ca.crt
> rob
>
>
Thanks a bunch, that worked!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140228/5b3160b7/attachment.htm>


More information about the Freeipa-users mailing list