On 12/13/2016 04:41 PM, jay wrote:
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] ad...@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 <http://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 <http://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 <titleistf...@gmail.com
<mailto:titleistf...@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@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@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?

Hi Jay,

I am not completely familiar with Tomcat, but I understand so far that the httpd server is configured to redirect requests on displayBySerial to Tomcat with this setting in the file /etc/httpd/conf.d/ipa-pki-proxy.conf:

<LocationMatch "^/ca/agent/ca/displayBySerial|^/ca/agent/ca/doRevoke|^/ca/agent/ca/doUnrevoke|^/ca/agent/ca/updateDomainXML|^/ca/eeca/ca/profileSubmitSSLClient|^/kra/agent/kra/connector">
    NSSOptions +StdEnvVars +ExportCertData +StrictRequire +OptRenegotiate
    NSSVerifyClient require
    ProxyPassMatch ajp://localhost:8009
    ProxyPassReverse ajp://localhost:8009
</LocationMatch>

And this port must be configured in /etc/pki/pki-tomcat/server.xml:
    <Connector port="8009"
            protocol="AJP/1.3"
            redirectPort="8443"
            address="::1" />

In my setup I also have /etc/hosts defining localhost:
127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 ::1 localhost localhost.localdomain localhost6 localhost6.localdomain6


Can you check that you also have those settings? If yes, then I assume that Tomcat is not able to create the AJP connector on port 8009. When PKI is started, you should find a trace of the connector initialization in /var/log/pki/pki-tomcat/catalina.$DATE.log:

12-Dec-2016 13:54:17.579 INFO [main] org.apache.coyote.AbstractProtocol.init Initializing ProtocolHandler ["ajp-nio-0:0:0:0:0:0:0:1-8009"] 12-Dec-2016 13:54:25.076 INFO [main] org.apache.coyote.AbstractProtocol.start Starting ProtocolHandler ["ajp-nio-0:0:0:0:0:0:0:1-8009"] 12-Dec-2016 13:56:33.683 INFO [ajp-nio-0:0:0:0:0:0:0:1-8009-exec-1] org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.processApplication RESTEASY002225: Deploying javax.ws.rs.core.Application: class org.dogtagpki.server.ca.rest.CAApplication

Next steps to debug would be to increase Tomcat logs.
Flo.


    Thanks,
    Jay

    On Tue, Dec 13, 2016 at 1:56 AM, Florence Blanc-Renaud
    <f...@redhat.com <mailto:f...@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.com
            <http://ip-172-31-0-235.us-west-2.com>pute.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:443/ca/agent/ca/displayBySerial?serialNumber=1
        
<https://hostname.domainname:443/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.






--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Reply via email to