Bug 1158410
| Summary: | ipa-server-install failing with error message - CA did not start in 300.0s | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Kaleem <ksiddiqu> |
| Component: | pki-core | Assignee: | Matthew Harmsen <mharmsen> |
| Status: | CLOSED ERRATA | QA Contact: | Asha Akkiangady <aakkiang> |
| Severity: | high | Docs Contact: | |
| Priority: | medium | ||
| Version: | 7.1 | CC: | abokovoy, alee, cfu, jcholast, mharmsen, mkosek, msauton, nsoman, pvoborni, rcritten, tbordaz |
| Target Milestone: | rc | Keywords: | TestBlocker |
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | pki-core-10.1.2-5.el7 | Doc Type: | Bug Fix |
| Doc Text: |
The CA failed to install during an IPA server installation.
This issue was caused due to recent changes which exclude default use of the SSLv3 protocol through the use of protocol ranges which were restricted to utilize nothing less secure than the TLS protocol.
The original fix contained a manual procedure portion which was corrected in this bug by adding this information in the CA's 'server.xml' file.
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | 2015-03-05 08:19:46 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 1163882 | ||
|
Description
Kaleem
2014-10-29 10:25:54 UTC
After downgrade to 389-ds-base-1.3.3.1-6.el7.x86_64, IPA server install is successful. It looks like that pki-ca-10.1.2-3.el7 can't communicate with 389-ds-base-1.3.3.1-7 because of disabling SSLv3 in 389. Ade, is it a PKI bug or a configuration issue? Logs: * https://bugzilla.redhat.com/attachment.cgi?id=952237 * https://bugzilla.redhat.com/attachment.cgi?id=952246 Changing dn: cn=encryption,cn=config sslVersionMin: tls1.1 to sslVersionMin: tls1 makes dogtag happy to start and use LDAP. We still want to get dogtag using TLS 1.2 (In reply to Kaleem from comment #0) > Description of problem: > IPA server install failing with DS build 389-ds-base-1.3.3.1-7.el7.x86_64. > With build 389-ds-base-1.3.3.1-6.el7.x86_64, installation is successful. > > Done configuring certificate server (pki-tomcatd). > Configuring directory server (dirsrv): Estimated time 10 seconds > [1/3]: configuring ssl for ds instance > [2/3]: restarting directory server > [3/3]: adding CA certificate entry > Done configuring directory server (dirsrv). > CA did not start in 300.0s > [root@dhcp207-187 ~]# > > Failure seems to be caused by fix of > https://bugzilla.redhat.com/show_bug.cgi?id=1153737 > > Details can be found in https://fedorahosted.org/freeipa/ticket/4666 > > Version-Release number of selected component (if applicable): > [root@dhcp207-187 ~]# rpm -q 389-ds-base ipa-server pki-ca > 389-ds-base-1.3.3.1-7.el7.x86_64 > ipa-server-4.1.0-3.el7.x86_64 > pki-ca-10.1.2-3.el7.noarch Which version of NSS is being utilized? Which versions of JSS and tomcatjss are being utilized? Christina recently provided a patch for both TLS v1.1 and v1.2 in the following versions of these components: * jss-4.2.6-35.el7 * tomcatjss-7.1.0-5.el7 > [root@dhcp207-187 ~]# > > How reproducible: > Always > > Steps to Reproduce: > 1.Install IPA Server with CA > > Actual results: > Installation fails > > Expected results: > Installation Should be successful. I have just tried and did not have any luck with: pki-core-10.1.2-4.el7 jss-4.2.6-35.el7 tomcatjss-7.1.0-5.el7 I'm getting the same internal database error as reported above. Setting sslVersionMin to tls1 in cn=encryption,cn=config does not help either. I'm getting a lot of "conn=4 op=-1 fd=64 closed - Cannot communicate securely with peer: no common encryption algorithm(s)." in the DS access log. Please provide info on how you configured tomcatjss in Dogtag's server.xml. Did you follow the information I provided: https://bugzilla.redhat.com/show_bug.cgi?id=871171#c6 clearing the "needInfo" per my response in Comment 8. I was not aware there were manual configuration steps necessary, updating server.xml fixed the issue for me. Will this be configured automatically in the next build of pki-core? Upstream ticket: https://fedorahosted.org/freeipa/ticket/4666 Upstream ticket: https://fedorahosted.org/freeipa/ticket/4676 (In reply to Jan Cholasta from comment #10) > I was not aware there were manual configuration steps necessary, updating > server.xml fixed the issue for me. > > Will this be configured automatically in the next build of pki-core? I filed https://fedorahosted.org/pki/ticket/1198 I wish to do that for next release of Dogtag experiencing the same behavior while testing, could be wrong, but looks like the ipa-server-install ends up with the file
/usr/lib/python2.7/site-packages/pki/server/deployment/pkiparser.py
...snip...
self.pki_master_dict['TOMCAT_SSL_OPTIONS_SLOT'] = \
"ssl2=true," + \
"ssl3=true," + \
"tls=true"
self.pki_master_dict['TOMCAT_TLS_CIPHERS_SLOT'] = \
"-TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA," + \
"-TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA," + \
...snip...
using pkispawn with parameters that need to be updated, for example:
'TOMCAT_SSL_OPTIONS_SLOT': 'ssl2=true,ssl3=true,tls=true',
if this a related problem, not fully sure how the
sslVersionRangeStream="tls1_0:tls1_2"
sslVersionRangeDatagram="tls1_1:tls1_2"
sslRangeCiphers="
from
https://bugzilla.redhat.com/show_bug.cgi?id=871171#c6
should go in
/usr/lib/python2.7/site-packages/pki/server/deployment/pkiparser.py
Need info from IPA team: is the following ticket also related to this bug? https://fedorahosted.org/pki/ticket/1197 If so, can we close the ticket, as we do have https://fedorahosted.org/pki/ticket/1198 scheduled for Dogtag 10.2.2 which should also fix: https://fedorahosted.org/freeipa/ticket/4676 thanks -Christina Looks related. You can close it if you want as long as this Bugzilla is closed and PKI can start if SSLv3 is closed. Should we move this Bugzilla to pki-core or do you have any RHEL Bugzilla ready yourself? Bumping severity - it crashes ipa-server-install. The only known workaround is to use older 389-ds-base version with SSLv3 support. Discussed with Nathan, this will be fixed purely in pki-core. Moving to the right component. Removing needinfo - all is clear. patch info: * new instances should expect the new tls range related parameters in the server.xml * existing instances, after upgrade, should expect 1. the new tls related parameters added to server.xml 2. strictCiphers set from default "false" to "true" (In reply to Christina Fu from comment #25) > patch info: > * new instances should expect the new tls range related parameters in the > server.xml > * existing instances, after upgrade, should expect > 1. the new tls related parameters added to server.xml > 2. strictCiphers set from default "false" to "true" 3. during the process of upgrade, the old server.xml should be archived in /var/log/pki/server/upgrade/10.1.2/1/oldfiles/var/lib/pki/<pki instance name>/conf 4. Unfortunately, due to the limitation of the xml parser/writer, during upgrade, the lines in <Connector ...> turn into one long line. We currently do not have a quick solution for it, but will try to look into that in upstream. Verified.
pki-core, ipa version:
--------------------
[root@dhcp207-1 ~]# rpm -q ipa-server pki-ca
ipa-server-4.1.0-7.el7.x86_64
pki-ca-10.1.2-5.el7.noarch
[root@dhcp207-1 ~]#
[root@dhcp207-1 ~]# ipa-server-install --setup-dns --forwarder=10.65.201.89 --hostname=`hostname` -r TESTRELM.TEST -n testrelm.test -p xxxxxxxx -P xxxxxxxx -a xxxxxxxx -U
The log file for this installation can be found in /var/log/ipaserver-install.log
==============================================================================
This program will set up the IPA Server.
This includes:
* Configure a stand-alone CA (dogtag) for certificate management
* Configure the Network Time Daemon (ntpd)
* Create and configure an instance of Directory Server
* Create and configure a Kerberos Key Distribution Center (KDC)
* Configure Apache (httpd)
* Configure DNS (bind)
Warning: skipping DNS resolution of host dhcp207-1.testrelm.test
Checking forwarders, please wait ...
WARNING: DNS forwarder 10.65.201.89 does not return DNSSEC signatures in answers
Please fix forwarder configuration to enable DNSSEC support.
(For BIND 9 add directive "dnssec-enable yes;" to "options {}")
WARNING: DNSSEC validation will be disabled
Using reverse zone(s) 207.65.10.in-addr.arpa.
The IPA Master Server will be configured with:
Hostname: dhcp207-1.testrelm.test
IP address(es): 10.65.207.1
Domain name: testrelm.test
Realm name: TESTRELM.TEST
BIND DNS server will be configured to serve IPA domain with:
Forwarders: 10.65.201.89
Reverse zone(s): 207.65.10.in-addr.arpa.
Configuring NTP daemon (ntpd)
[1/4]: stopping ntpd
...
Done configuring NTP daemon (ntpd).
Configuring directory server (dirsrv): Estimated time 1 minute
[1/38]: creating directory server user
...
[38/38]: configuring directory to start on boot
Done configuring directory server (dirsrv).
Configuring certificate server (pki-tomcatd): Estimated time 3 minutes 30 seconds
[1/27]: creating certificate server user
...
[27/27]: Configure HTTP to proxy connections
Done configuring certificate server (pki-tomcatd).
Configuring directory server (dirsrv): Estimated time 10 seconds
[1/3]: configuring ssl for ds instance
...
[3/3]: adding CA certificate entry
Done configuring directory server (dirsrv).
Configuring Kerberos KDC (krb5kdc): Estimated time 30 seconds
[1/10]: adding sasl mappings to the directory
...
[10/10]: configuring KDC to start on boot
Done configuring Kerberos KDC (krb5kdc).
Configuring kadmin
[1/2]: starting kadmin
[2/2]: configuring kadmin to start on boot
Done configuring kadmin.
Configuring ipa_memcached
[1/2]: starting ipa_memcached
[2/2]: configuring ipa_memcached to start on boot
Done configuring ipa_memcached.
Configuring ipa-otpd
[1/2]: starting ipa-otpd
[2/2]: configuring ipa-otpd to start on boot
Done configuring ipa-otpd.
Configuring the web interface (httpd): Estimated time 1 minute
[1/15]: setting mod_nss port to 443
...
[15/15]: configuring httpd to start on boot
Done configuring the web interface (httpd).
Applying LDAP updates
Restarting Directory server to apply updates
[1/2]: stopping directory server
[2/2]: starting directory server
Done.
Restarting the directory server
Restarting the KDC
Restarting the certificate server
Configuring DNS (named)
[1/12]: generating rndc key file
...
[12/12]: changing resolv.conf to point to ourselves
Done configuring DNS (named).
Restarting named
Global DNS configuration in LDAP server is empty
You can use 'dnsconfig-mod' command to set global DNS options that
would override settings in local named.conf files
Restarting the web server
==============================================================================
Setup complete
...
Be sure to back up the CA certificate stored in /root/cacert.p12
This file is required to create replicas. The password for this
file is the Directory Manager password
[root@dhcp207-1 ~]# rpm -q ipa-server pki-ca
ipa-server-4.1.0-7.el7.x86_64
pki-ca-10.1.2-5.el7.noarch
[root@dhcp207-1 ~]#
Just for the record, fix also checked into DOGTAG_10_2_RHEL_BRANCH
commit 80aaeb8aa100e7cc4e5ea97a0a4f2e851dd75aeb
Author: Christina Fu <cfu>
Date: Mon Nov 24 16:46:45 2014 -0800
Ticket 1198 (part 1) TLS support: provide proper TLS default values and
...
To ssh://git.app.eng.bos.redhat.com/srv/git/pki.git
249c04e..80aaeb8 DOGTAG_10_2_RHEL_BRANCH -> DOGTAG_10_2_RHEL_BRANCH
Ticket 4676 fixed upstream master: https://fedorahosted.org/freeipa/changeset/337faf506462a01c6dbcd00f2039ed5627691864 ipa-4-1: https://fedorahosted.org/freeipa/changeset/5052af773f652bc19e91fe49e15351e5c5c7d976 I didn't realize that this was a pki-core bug. Moving to ON_QA. Sorry for the noise. From comment 28 - moving it back to verified 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-0346.html |