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

2016-12-14 Thread Alexander Bokovoy

On ke, 14 joulu 2016, Florence Blanc-Renaud wrote:

On 12/13/2016 05:29 PM, jay wrote:

Well Flo, the issue was IPV6 was disabled.  As soon as I enabled it
again, added that /etc/hosts entry back, and rebooted the server, things
are working again!

So is that now a requirement for 4.4.x?  Server worked fine on 4.2

Hi Jay,

this behavior was introduced with the fix for ticket 4291 (CA not 
start during ipa server install in pure IPv6 env) in FreeIPA 4.4.1 
[1].


I agree that the doc [2] does not explicitely mention that IPv6 is 
required, but it sort of suggests that it should be set up.

We actually require IPv6 stack on IPA masters for very long time.

There is no reason why IPv6 stack should be disabled. You may lack
addresses, even local ones, but given that IPv4 and IPv6 share the same
port space, a single API is recommended to be used in implementing
networking applications by the documentation in ipv6(7):


 IPv4 connections can be handled with the v6 API by using the
 v4-mapped-on-v6 address type; thus a program needs to support only
 this API type to support both protocols. This is handled
 transparently by the address handling functions in the C library.

 IPv4 and IPv6 share the local port space.  When you get an IPv4
 connection or packet to a IPv6 socket, its source address will be
 mapped to v6 and it will be mapped to v6.


Thus, most of IPA code actually is implemented using this approach. You
need to have IPv6 enabled in the kernel but not necessary used.

This is mentioned as a requirement in the Windows Integration guide but
it is valid for a normal IPA install as well:
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html-single/Windows_Integration_Guide/index.html#trust-req-ipv6


I found an e-mail thread mentioning why IPv6 should not be disabled 
[3], and also on freeipa.org a wiki for Deployment recommendations 
[4].


I will open a documentation bug asking to add this requirement in Red 
Hat Enterprise Linux 7 Linux Domain Identity, Authentication, and 
Policy Guide.


Flo

[1] https://fedorahosted.org/freeipa/ticket/4291
[2] 
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/installing-ipa.html#dns-reqs
[3] 
https://www.redhat.com/mailman/private/freeipa-users/2015-September/msg00175.html
[4] 
http://www.freeipa.org/page/Deployment_Recommendations#Active_Directory_Integration


without IPV6 enabled.  Or has that always been a requirement and I just
got lucky somehow.  I'm looking through the docs now.

Regardless, thank you very much for the help Flo!

Jay

On Tue, Dec 13, 2016 at 10:20 AM, Florence Blanc-Renaud > wrote:

   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.in
   TERNAL:
   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 
   >>
   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
   *   

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

2016-12-14 Thread Florence Blanc-Renaud

On 12/13/2016 05:29 PM, jay wrote:

Well Flo, the issue was IPV6 was disabled.  As soon as I enabled it
again, added that /etc/hosts entry back, and rebooted the server, things
are working again!

So is that now a requirement for 4.4.x?  Server worked fine on 4.2

Hi Jay,

this behavior was introduced with the fix for ticket 4291 (CA not start 
during ipa server install in pure IPv6 env) in FreeIPA 4.4.1 [1].


I agree that the doc [2] does not explicitely mention that IPv6 is 
required, but it sort of suggests that it should be set up.


I found an e-mail thread mentioning why IPv6 should not be disabled [3], 
and also on freeipa.org a wiki for Deployment recommendations [4].


I will open a documentation bug asking to add this requirement in Red 
Hat Enterprise Linux 7 Linux Domain Identity, Authentication, and Policy 
Guide.


Flo

[1] https://fedorahosted.org/freeipa/ticket/4291
[2] 
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/installing-ipa.html#dns-reqs
[3] 
https://www.redhat.com/mailman/private/freeipa-users/2015-September/msg00175.html
[4] 
http://www.freeipa.org/page/Deployment_Recommendations#Active_Directory_Integration



without IPV6 enabled.  Or has that always been a requirement and I just
got lucky somehow.  I'm looking through the docs now.

Regardless, thank you very much for the help Flo!

Jay

On Tue, Dec 13, 2016 at 10:20 AM, Florence Blanc-Renaud > wrote:

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.in
TERNAL:
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 
>>
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.INT
ERNAL
*   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


503 Service Unavailable


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

2016-12-13 Thread jay
Well Flo, the issue was IPV6 was disabled.  As soon as I enabled it again,
added that /etc/hosts entry back, and rebooted the server, things are
working again!

So is that now a requirement for 4.4.x?  Server worked fine on 4.2 without
IPV6 enabled.  Or has that always been a requirement and I just got lucky
somehow.  I'm looking through the docs now.

Regardless, thank you very much for the help Flo!

Jay

On Tue, Dec 13, 2016 at 10:20 AM, Florence Blanc-Renaud 
wrote:

> 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  (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 > > 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
>> 
>> 
>> 503 Service Unavailable
>> 
>> Service Unavailable
>> The server is temporarily unable to service your
>> request due to maintenance downtime or capacity
>> problems. Please try again later.
>> 
>> [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:
>
>  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
> 
>
> And this port must be configured in /etc/pki/pki-tomcat/server.xml:
>  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 

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

2016-12-13 Thread Florence Blanc-Renaud

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  (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 > 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


503 Service Unavailable

Service Unavailable
The server is temporarily unable to service your
request due to maintenance downtime or capacity
problems. Please try again later.

[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:


"^/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


And this port must be configured in /etc/pki/pki-tomcat/server.xml:


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
> wrote:

On 

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

2016-12-13 Thread jay
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 (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  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
> 
> 
> 503 Service Unavailable
> 
> Service Unavailable
> The server is temporarily unable to service your
> request due to maintenance downtime or capacity
> problems. Please try again later.
> 
> [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?
>
> Thanks,
> Jay
>
> On Tue, Dec 13, 2016 at 1:56 AM, Florence Blanc-Renaud 
> 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

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

2016-12-12 Thread Florence Blanc-Renaud

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: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