Bug 1196455

have
tomcatjss-7.1.0-5.el7.noarch

Hello Marc, 

I see two issues here. 

First, that it may report invalid message. Second, that it actually failed. 

1. could be linked to upstream ticket 4885 [https://fedorahosted.org/freeipa/ticket/4885]

2. The mentioned BZ #1158410 should have fixed that. I'm not able to reproduce the issue with the versions of components you stated. Do you know that the failure was indeed because of "TLS range and TLSv1.2"? Do you have a log with the crash (CA or some other)? Are you able to reproduce the issue?

So in upstream 4885, one problem may be if there is some sort of network issue, the CA is seen as down, while it may be up and running.

In my case, there is no CA crash, the CA instance is up and running, and OK:
systemctl status pki-tomcatd
pki-tomcatd - PKI Tomcat Server pki-tomcat
   Loaded: loaded (/lib/systemd/system/pki-tomcatd@.service; enabled)
   Active: active (running) since Wed 2015-02-25 16:11:02 PST; 6 days ago
  Process: 1594 ExecStartPre=/usr/bin/pkidaemon start tomcat %i (code=exited, status=0/SUCCESS)
 Main PID: 1739 (java)
   CGroup: /system.slice/system-pki\x2dtomcatd.slice/pki-tomcatd
           └─1739 java -DRESTEASY_LIB=/usr/share/java/resteasy-base -classpath /usr/share/tomcat/bin/bootstrap.jar:/usr/share/tomcat/bin/tomcat-juli.jar:/usr/share/java/commons-daemon.jar -Dcatalina.base=/var/lib/pki/pki-tomcat -Dcatalina.home=/usr/share/tomcat -Djava.endorsed.dirs= -Djava.io.tmpdir=/var/lib/pki/pki-tomcat/temp -Djava.util.logging.config.file=/var/lib/pki/pki-tomcat/conf/logging.properties -Djava.ut...

Feb 25 16:11:33 ipaserver1.example.com server[1739]: Feb 25, 2015 4:11:33 PM org.apache.catalina.startup.HostConfig deployDescriptor
Feb 25 16:11:33 ipaserver1.example.com server[1739]: INFO: Deployment of configuration descriptor /etc/pki/pki-tomcat/Catalina/localhost/ca.xml has finished in 18,262 ms
Feb 25 16:11:33 ipaserver1.example.com server[1739]: Feb 25, 2015 4:11:33 PM org.apache.coyote.AbstractProtocol start
Feb 25 16:11:33 ipaserver1.example.com server[1739]: INFO: Starting ProtocolHandler ["http-bio-8080"]
Feb 25 16:11:33 ipaserver1.example.com server[1739]: Feb 25, 2015 4:11:33 PM org.apache.coyote.AbstractProtocol start
Feb 25 16:11:33 ipaserver1.example.com server[1739]: INFO: Starting ProtocolHandler ["http-bio-8443"]
Feb 25 16:11:34 ipaserver1.example.com server[1739]: Feb 25, 2015 4:11:34 PM org.apache.coyote.AbstractProtocol start
Feb 25 16:11:34 ipaserver1.example.com server[1739]: INFO: Starting ProtocolHandler ["ajp-bio-127.0.0.1-8009"]
Feb 25 16:11:34 ipaserver1.example.com server[1739]: Feb 25, 2015 4:11:34 PM org.apache.catalina.startup.Catalina start
Feb 25 16:11:34 ipaserver1.example.com server[1739]: INFO: Server startup in 28330 ms
[root@ipaserver1-example-com ~]# 

I can use openssl s_client to use the CA, no apparent problems on it.

It is possible that VM may not have have the newer rpm, and I could not solve this problem for some other testing I needed, so I opened this report.

I till have the VM available, was about to scratch it for another test, so I will wait until you are done with it (and use another one for my other testing)

ssh root.5.175
redhat123

other passwords should be 
pasword

the issue is that it tries to connect to
  'https://ipaserver1-example-com:8443/ca/admin/ca/getStatus' (dashes instead of dots)

and not to 
   'https://ipaserver1.example.com:8443/ca/admin/ca/getStatus'


The probable cause is initial hostname of the machine - I assume: ipaserver1-example-com

Indicator:
2015-02-26T00:08:49Z DEBUG stderr=AH00557: httpd: apr_sockaddr_info_get() failed for ipaserver1-example-com
AH00558: httpd: Could not reliably determine the server's fully qualified domain name, using 127.0.0.1. Set the 'ServerName' directive globally to suppress this message

The CA check code wants to contact ca stored in api.env.ca_host, which is initialized upon api initialization. 

constants.py:
   FQDN = socket.getfqdn()

('ca_host', FQDN),  # Set in Env._finalize_core()

ipa-server-install notices that the hostname differs and sets the correct one:

    if host_name != system_hostname:
        root_logger.debug("Chosen hostname (%s) differs from system hostname (%s) - change it" \
                      % (host_name, system_hostname))
        # configure /etc/sysconfig/network to contain the custom hostname
        tasks.backup_and_replace_hostname(fstore, sstore, host_name)

but it doesn't update the information used by the dogtag check which then leads to the failure.

Workaround is to set correct hostname before installation.

Summary:
- There is a bug in ipa-server-install that it internally uses wrong hostname after it sets the new one.
- In this case, the error message is correct.

I'll create upstream bug for the hostname issue.

Upstream ticket:
https://fedorahosted.org/freeipa/ticket/4936

Fixed upstream
master:
https://fedorahosted.org/freeipa/changeset/825d4fc9e7fc80e07a68daf35b5eb0c171e821af

# less /var/log/ipaserver-install.log

2015-10-09T06:25:39Z DEBUG Waiting until the CA is running
2015-10-09T06:25:39Z DEBUG Starting external process
2015-10-09T06:25:39Z DEBUG args='/usr/bin/wget' '-S' '-O' '-' '--timeout=30' '--no-check-certificate' 'https://ipaserver.testrelm.test:8443/ca/admin/ca/getStatus'
2015-10-09T06:25:52Z DEBUG Process finished, return code=0
2015-10-09T06:25:52Z DEBUG stdout=<?xml version="1.0" encoding="UTF-8" standalone="no"?><XMLResponse><State>1</State><Type>CA</Type><Status>running</Status><Version>10.2.5-6.el7</Version></XMLResponse>
2015-10-09T06:25:52Z DEBUG stderr=--2015-10-09 11:55:39--  https://ipaserver.testrelm.test:8443/ca/admin/ca/getStatus
Resolving ipaserver.testrelm.test (ipaserver.testrelm.test)... 10.65.201.22
Connecting to ipaserver.testrelm.test (ipaserver.testrelm.test)|10.65.201.22|:8443... connected.
WARNING: cannot verify ipaserver.testrelm.test's certificate, issued by ‘/O=TESTRELM.TEST/CN=Certificate Authority’:
  Self-signed certificate encountered.
HTTP request sent, awaiting response...
  HTTP/1.1 200 OK
  Server: Apache-Coyote/1.1
  Content-Type: application/xml
  Content-Length: 167
  Date: Fri, 09 Oct 2015 06:25:52 GMT
Length: 167 [application/xml]
Saving to: ‘STDOUT’

     0K                                                       100% 62.7M=0s
2015-10-09 11:55:52 (62.7 MB/s) - written to stdout [167/167]


2015-10-09T06:25:52Z DEBUG The CA status is: running
...


Verified.

IPA server version ::

ipa-server-4.2.0-13.el7.x86_64

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2015-2362.html