[Freeipa-users] With freeipa 4.4.0-14 on CentOS 7 cert-show fails

Tue Dec 13 15:41:18 UTC 2016

Maybe this will help more, I noticed this error in the Apache logs

[Tue Dec 13 09:33:37.774921 2016] [:error] [pid 2309] ipa: INFO:
[jsonserver_kerb] admin at IPA.US-WEST-2.COMPUTE.INTERNAL: cert_show/1(u'1',
version=u'2.213'): CertificateOperationError
[Tue Dec 13 09:35:29.141847 2016] [proxy:error] [pid 2316] (111)Connection
refused: AH00957: AJP: attempt to connect to 127.0.0.1:8009 (localhost)
failed
[Tue Dec 13 09:35:29.141881 2016] [proxy:error] [pid 2316] AH00959:
ap_proxy_connect_backend disabling worker for (localhost) for 60s
[Tue Dec 13 09:35:29.141900 2016] [proxy_ajp:error] [pid 2316] [client
172.31.0.254:39646] AH00896: failed to make connection to backend: localhost
[Tue Dec 13 09:35:29.142412 2016] [:error] [pid 2310] ipa: ERROR:
ra.get_certificate(): Unable to communicate with CMS (503)

So whatever is running on port 8009 isn't responding or setup properly.

Jay

On Tue, Dec 13, 2016 at 8:46 AM, jay <titleistfour at gmail.com> wrote:

> Thank you for the response Flo.  So I do see Apache running and listening
> on port 443.  However, running that command I get a 503
>
> *   Trying 172.31.0.254...
> * Connected to ip-172-31-0-254.us-west-2.compute.internal (172.31.0.254)
> port 443 (#0)
> * Initializing NSS with certpath: sql:/etc/httpd/alias
> *   CAfile: /etc/pki/tls/certs/ca-bundle.crt
>   CApath: none
> * SSL connection using TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
> * Server certificate:
> *       subject: CN=ip-172-31-0-254.us-west-2.compute.internal,O=IPA.US-
> WEST-2.COMPUTE.INTERNAL
> *       start date: Dec 13 14:33:16 2016 GMT
> *       expire date: Dec 14 14:33:16 2018 GMT
> *       common name: ip-172-31-0-254.us-west-2.compute.internal
> *       issuer: CN=Certificate Authority,O=IPA.US-WEST-2.COMPUTE.INTERNAL
> > GET /ca/agent/ca/displayBySerial?serialNumber=1 HTTP/1.1
> > User-Agent: curl/7.29.0
> > Host: ip-172-31-0-254.us-west-2.compute.internal
> > Accept: */*
> >
> * NSS: using client certificate: ipaCert
> *       subject: CN=IPA RA,O=IPA.US-WEST-2.COMPUTE.INTERNAL
> *       start date: Dec 13 14:32:28 2016 GMT
> *       expire date: Dec 03 14:32:28 2018 GMT
> *       common name: IPA RA
> *       issuer: CN=Certificate Authority,O=IPA.US-WEST-2.COMPUTE.INTERNAL
> < HTTP/1.1 503 Service Unavailable
> < Date: Tue, 13 Dec 2016 14:44:00 GMT
> < Server: Apache
> < Content-Length: 299
> < Connection: close
> < Content-Type: text/html; charset=iso-8859-1
>
> [root at ip-172-31-0-254 ~]# cat out.html
> <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
> <html><head>
> <title>503 Service Unavailable</title>
> </head><body>
> <h1>Service Unavailable</h1>
> <p>The server is temporarily unable to service your
> request due to maintenance downtime or capacity
> problems. Please try again later.</p>
> </body></html>
> [root at ip-172-31-0-254 ~]#
>
>
> What would cause the service to be unavailable?  Maybe the installer
> changed and I need to provide another option now that I didn't have to
> before the version upgrade?
>
> Thanks,
> Jay
>
> On Tue, Dec 13, 2016 at 1:56 AM, Florence Blanc-Renaud <flo at redhat.com>
> wrote:
>
>> On 12/12/2016 10:32 PM, jay wrote:
>>
>>> Hello,
>>>
>>> I have been testing freeipa on CentOS 7 for a while now with a
>>> relatively simple setup, just a single server and 12 or so Linux clients
>>> in AWS.  I went to rebuild the environment today and part of my Ansible
>>> playbook failed with this error
>>>
>>> ipa: ERROR: Certificate operation cannot be completed: Unable to
>>> communicate with CMS (503)
>>>
>>> This is the command that failed
>>>
>>> /usr/bin/ipa cert-show 1 --out=/root/cacert.crt
>>>
>>> I noticed the version I was using on Friday was
>>> ipa-server-4.2.0-15.0.1.el7.centos.19.x86_64.  But now I'm getting
>>> ipa-server-4.4.0-14.el7.centos.x86_64 installed, so the repo was updated
>>> over the weekend.
>>>
>>> Is there a known issue running cert-show with this version?  I can't
>>> find anything in the debug logs that point to something wrong.  Running
>>> 'ipa cert-find' and 'getcert list -d /etc/httpd/alias -n ipaCert' work
>>> just fine.
>>>
>>> Can someone offer some advice or pointer to what might be going on?  I'm
>>> invoking the install with these options and it has worked flawlessly
>>> before this new version
>>>
>>> 2016-12-12T21:05:21Z DEBUG ipa-server-install was invoked with arguments
>>> [] and options: {'no_dns_
>>> sshfp': None, 'ignore_topology_disconnect': None, 'verbose': False,
>>> 'ip_addresses': [CheckedIPAddr
>>> ess('172.31.0.235')], 'domainlevel': None, 'mkhomedir': None,
>>> 'http_cert_files': None, 'no_ntp': N
>>> one, 'reverse_zones': None, 'no_forwarders': None, 'external_ca_type':
>>> None, 'ssh_trust_dns': True
>>> , 'domain_name': 'ipa.us-west-2.compute.internal', 'idmax': None,
>>> 'http_cert_name': None, 'dirsrv_
>>> cert_files': None, 'no_dnssec_validation': None, 'ca_signing_algorithm':
>>> None, 'no_reverse': None,
>>>  'subject': None, 'unattended': True, 'auto_reverse': None,
>>> 'auto_forwarders': None, 'no_host_dns'
>>> : None, 'no_sshd': None, 'no_ui_redirect': None, 'ignore_last_of_role':
>>> None, 'realm_name': 'IPA.U
>>> S-WEST-2.COMPUTE.INTERNAL', 'forwarders':
>>> [CheckedIPAddress('172.31.0.2')], 'idstart': 5000, 'exte
>>> rnal_ca': None, 'no_ssh': None, 'external_cert_files': None,
>>> 'no_hbac_allow': None, 'forward_polic
>>> y': None, 'dirsrv_cert_name': None, 'ca_cert_files': None, 'zonemgr':
>>> None, 'quiet': False, 'setup
>>> _dns': True, 'host_name': 'ip-172-31-0-235.us-west-2.compute.internal',
>>> 'dirsrv_config_file': None
>>> , 'log_file': None, 'allow_zone_overlap': None, 'uninstall': False}
>>> 2016-12-12T21:05:21Z DEBUG IPA version 4.4.0-14.el7.centos
>>>
>>> Thank you
>>> Jay
>>>
>>>
>>>
>> Hi,
>>
>> the ipa cert-show command is communicating with Dogtag, using port 443.
>> Can you check if Dogtag is properly responding on this port?
>>
>> $ SSL_DIR=/etc/httpd/alias/ curl -v -E ipaCert:`cat
>> /etc/httpd/alias/pwdfile.txt` https://hostname.domainname:44
>> 3/ca/agent/ca/displayBySerial?serialNumber=1 -o out.html
>>
>> The issue can be that Dogtag is down, or a SSL issue (the certificate
>> ipaCert in /etc/httpd/alias is used to authenticate the client to Dogtag).
>>
>> HTH,
>> Flo.
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20161213/40efcc72/attachment.htm>