[Freeipa-users] ACIerrors is httpd log

Fri Dec 2 15:46:44 UTC 2016

Hmm ya. So before I rebuilt anything I thought maybe it was my DNS records but it looks like that’s not it.

More background, I used to have sso-109 and sso-110, both CA’s. I rebuilt sso-110 without CA.

My DNS is external, BIND on another host.

Using the following (at the end of the message) host/key issue as an example. On this host, in sssd.conf, ipa_server and krb5_server values are both _srv_ so that means they’ll discover from DNS right?

But in my krb5.conf I have:

[realms]
  PLACEIQ.NET = {
    kdc = sso-110.nym1.placeiq.net:88
    master_kdc = sso-110.nym1.placeiq.net:88
    admin_server = sso-110.nym1.placeiq.net:749
    default_domain = placeiq.net
    pkinit_anchors = FILE:/etc/ipa/ca.crt
  }

Is there any other IPA related config file that might reference a host name?

I’ll include my DNS records at the end here, do they look correct for a two server setup, one with a CA (sso-109) and the other no CA (sso-110)?

I never have been sure about the “kerberos-master” entries, what makes an IPA host a “kerberos master” and is this related to the CA in any way?

; ldap servers
_ldap._tcp      IN SRV 0 100 389    sso-109.nym1.placeiq.net.
_ldap._tcp      IN SRV 0 100 389    sso-110.nym1.placeiq.net.

;kerberos realm
_kerberos               IN TXT PLACEIQ.NET

; kerberos servers
_kerberos._tcp          IN SRV 0 100 88         sso-109.nym1.placeiq.net.
_kerberos._tcp          IN SRV 0 100 88         sso-110.nym1.placeiq.net.

_kerberos._udp          IN SRV 0 100 88         sso-109.nym1.placeiq.net.
_kerberos._udp          IN SRV 0 100 88         sso-110.nym1.placeiq.net.

_kerberos-master._tcp   IN SRV 0 100 88         sso-109.nym1.placeiq.net.
_kerberos-master._udp   IN SRV 0 100 88         sso-109.nym1.placeiq.net.
_kerberos-adm._tcp      IN SRV 0 100 749        sso-109.nym1.placeiq.net.
_kerberos-adm._udp      IN SRV 0 100 749        sso-109.nym1.placeiq.net.

_kpasswd._tcp           IN SRV 0 100 464        sso-109.nym1.placeiq.net.
_kpasswd._tcp           IN SRV 0 100 464        sso-110.nym1.placeiq.net.

_kpasswd._udp           IN SRV 0 100 464        sso-109.nym1.placeiq.net.
_kpasswd._udp           IN SRV 0 100 464        sso-110.nym1.placeiq.net.

; CNAME for IPA CA replicas (used for CRL, OCSP)
ipa-ca                  IN A                    10.1.41.109

Number of certificates and requests being tracked: 1.
Request ID '20141110221330':
        status: MONITORING
        ca-error: Server at https://sso-110.nym1.placeiq.net/ipa/xml denied our request, giving up: 2100 (RPC failed at server.  Insufficient access: not allowed to perform this command).
        stuck: no
        key pair storage: type=NSSDB,location='/etc/pki/nssdb',nickname='IPA Machine Certificate - phoenix-142.nym1.placeiq.net',token='NSS Certificate DB'
        certificate: type=NSSDB,location='/etc/pki/nssdb',nickname='IPA Machine Certificate - phoenix-142.nym1.placeiq.net',token='NSS Certificate DB'
        CA: IPA
        issuer: CN=Certificate Authority,O=PLACEIQ.NET
        subject: CN=phoenix-142.nym1.placeiq.net,O=PLACEIQ.NET
        expires: 2016-11-10 22:13:31 UTC
        key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
        eku: id-kp-serverAuth,id-kp-clientAuth
        pre-save command:
        post-save command:
        track: yes
        auto-renew: yes

We are moving to latest version on RHEL so we’ll have paid support but before than, gaining this understanding is massively valuable :)

 <http://www.placeiq.com/> <http://www.placeiq.com/> <http://www.placeiq.com/>	Jim Richard	 <https://twitter.com/placeiq> <https://twitter.com/placeiq> <https://twitter.com/placeiq>	 <https://www.facebook.com/PlaceIQ> <https://www.facebook.com/PlaceIQ>	 <https://www.linkedin.com/company/placeiq> <https://www.linkedin.com/company/placeiq>
SYSTEM ADMINISTRATOR III
(646) 338-8905  

 <http://placeiq.com/2016/10/26/the-making-of-a-location-data-industry-milestone/>

> On Dec 1, 2016, at 10:56 PM, Rob Crittenden <rcritten at redhat.com> wrote:
> 
> Jim Richard wrote:
>> I think I know what the issue is.
>> 
>> I had 2 IPA servers, both with CA’s
>> 
>> I dropped one and rebuilt without the CA but a bunch of clients are
>> still pointing at this one server that now is without a CA.
>> 
>> Will rebuild that one with a CA and almost sure that will fix.
> 
> I'm rather skeptical of that. Not having a CA should not result in an
> ACI error. It should internally forward any cert requests to an IPA
> server that does have a CA and relay the result back to the requester.
> 
> rob
> 
>> 
>> <http://www.placeiq.com/><http://www.placeiq.com/><http://www.placeiq.com/>
>> Jim Richard
>> <https://twitter.com/placeiq><https://twitter.com/placeiq><https://twitter.com/placeiq>
>> <https://www.facebook.com/PlaceIQ><https://www.facebook.com/PlaceIQ>
>> <https://www.linkedin.com/company/placeiq><https://www.linkedin.com/company/placeiq>
>> SYSTEM ADMINISTRATOR III
>> /(646) 338-8905 / 
>> 
>> 
>> PlaceIQ:Alibaba
>> <http://placeiq.com/2016/10/26/the-making-of-a-location-data-industry-milestone/>
>> 
>> 
>> 
>> 
>>> On Nov 28, 2016, at 2:39 PM, Rob Crittenden <rcritten at redhat.com
>>> <mailto:rcritten at redhat.com>> wrote:
>>> 
>>> Jim Richard wrote:
>>>> Honestly I’m not even sure if something is not working correctly :)
>>>> 
>>>> All I know is that my httpd, access and krb5 logs are filling up all my
>>>> disk space extremely quickly and I have no idea why.
>>>> 
>>>> Centos 6.8 + IPA 3.0
>>>> 
>>>> One master and one replica.
>>>> 
>>>> Are these things related?
>>>> 
>>>> How do I fix, where do I even start?
>>>> 
>>>> Thanks !
>>>> 
>>>> On the replica the httpd log is constantly getting spammed with:
>>>> 
>>>> [Thu Nov 24 05:55:18 2016] [error] ipa: INFO:
>>>> host/phoenix-153.nym1.placeiq.net at PLACEIQ.NET
>>>> <mailto:host/phoenix-153.nym1.placeiq.net at placeiq.net>:
>>>> cert_request(u’actual cert removed
>>> .. , add=True): ACIError
>>>> 
>>>> and on the master the access log is filling up quickly with:
>>>> 
>>>> 10.1.41.110 - - [24/Nov/2016:06:09:54 +0000] "POST
>>>> /ca/agent/ca/displayBySerial HTTP/1.1" 200 10106
>>> 
>>> Looks like certmonger trying to renew the per-client SSL certificate.
>>> You can confirm by pulling out the CSR and poking at it with openssl req.
>>> 
>>> On the client you can try running: ipa-getcert list
>>> 
>>> This may show more details on why the request was rejected.
>>> 
>>> rob
>> 
> 

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