[Freeipa-users] CA installation failed on server

[Rob Crittenden]

Christian Heimes wrote:
> On 2015-11-30 16:27, Rob Crittenden wrote:
>> Christian Heimes wrote:
>>> On 2015-11-30 12:51, Martin Basti wrote:
>>>>
>>>>
>>>> On 28.11.2015 00:14, Rob Crittenden wrote:
>>>>> Martin Štefany wrote:
>>>>>> Hello,
>>>>>>
>>>>>> I remember experiencing this, but I'm not sure of solution. I think it's
>>>>>> related to apache (httpd) and his group.
>>>>>>
>>>>>> My notes for IPA installation on CentOS 7.x say:
>>>>>>
>>>>>> # groupadd -g 48 apache
>>>>>> # yum -y install ipa-server bind bind-dyndb-ldap
>>>>>> # usermod -g apache apache
>>>>>> # ipa-server-install...
>>>>>>
>>>>>> CentOS is somehow not creating group apache for apache user and then
>>>>>> assuming root which is then causing problems with apache later. Pre-
>>>>>> creating such group before installing httpd and then usermod-ing user
>>>>>> apache might solve it.
>>>>>>
>>>>>> Did you get any warnings while running:
>>>>>> # yum install -y ipa-server bind bind-dyndb-ldap ?
>>>>>>
>>>>>>
>>>>>> If possible, try installation from scratch with my notes on fresh
>>>>>> system. If not:
>>>>>>
>>>>>> # systemctl stop apache   # if it runs
>>>>>> # groupadd -g 48 apache   # I use 48 as apache's UID tends to be also
>>>>>> 48, or use 'groupadd -r apache' instead
>>>>>> # usermod -g apache apache
>>>>>> # ipa-server-install...
>>>>>>
>>>>> Sounds unlikely to me. If indeed it did happen you'd need to file a bug
>>>>> against Apache to create its own uid/gid, which I'm pretty certain it
>>>>> already does.
>>>>>
>>>>> In any case, dogtag doesn't run in Apache so it would be unlikely to
>>>>> blow up in the CA installer.
>>>>>
>>>>> cating the contents of a directory into one log is not at all helpful,
>>>>> especially given that you missed all the important bits in the
>>>>> subdirectories beneath it. This is just a mishmash of stuff. We need to
>>>>> see /var/log/pki/pki-tomcat/ca/debug.
>>>>>
>>>>> /var/log/ipaserver-install.log might also be useful to see though it
>>>>> probably just records in a more verbose way the fact that pkispawn
>>>>> failed.
>>>>>
>>>>> rob
>>>>>
>>>> Hello,
>>>>
>>>> I see in log this error message:
>>>>
>>>> 2015-11-26 08:41:53 pkidestroy  : ERROR    .......
>>>> subprocess.CalledProcessError:  Command '['/usr/bin/sslget', '-n',
>>>> 'subsystemCert cert-pki-ca', '-p', '272326334956', '-d',
>>>> '/etc/pki/pki-tomcat/alias', '-e',
>>>> 'name="/var/lib/pki/pki-tomcat"&type=CA&list=caList&host=ipa.home&sport=443&ncsport=8443&adminsport=8443&agentsport=8443&operation=remove',
>>>> '-v', '-r', '/ca/agent/ca/updateDomainXML', 'ipa.home:443']' returned
>>>> non-zero exit status 6!
>>>>
>>>> It means that the CA has no been sucessfully uninstalled, and it can
>>>> cause issues during installation
>>>> PKI bug:
>>>> https://fedorahosted.org/pki/ticket/1704
>>>>
>>>> Christian may have workaround (CCed)
>>>
>>> Hi Martin and Martin,
>>>
>>> last week I have identified an incompatibility between Dogtag's sslget
>>> command and Apache HTTP. sslget sends a server name indication during
>>> the TLS/SSL handshake but doesn't send a HTTP Host header. Newer
>>> versions of Apache HTTP don't accept requests with SNI and without HTTP
>>> Host. You should see a HTTP/400 Bad Request in /var/log/httpd/error_log.
>>>
>>> The simplest workaround is to bypass Apache and talk to Dogtag directly.
>>> In order to do bypass the Apache proxy you have to log onto the server.
>>> You also have to become root so you can access the NSS database that
>>> contains the private key for authentication. Simply copy and paste the
>>> sslget command from the log (everything between "Command '[" and "]'
>>> returend non-zero exit status 6!"), remove the comma, replace
>>> 'ipa.home:443' with 'ipa.home:8443' and run the command. The command
>>> should look like:
>>>
>>> '/usr/bin/sslget' '-n' 'subsystemCert cert-pki-ca' ...
>>> '/ca/agent/ca/updateDomainXML' 'ipa.home:8443'
>>
>> mod_nss added support for SNI in Fedora 23. It should behave the same
>> way as mod_ssl, denying a request that contains an SNI hostname but no
>> Host header.
>>
>> I assume you've filed a bug against dogtag to send a Host header in the
>> request?
>>
>> A better workaround would be to add NSSSNI off to
>> /etc/httpd/conf.d/nss.conf within the default VH. Retrying the install
>> should work then, or at least get past this sslget error.
> 
> That might explain why the issue hasn't popped up earlier. sslget sets
> SNI header without HTTP Host header for a while. Since FreeIPA uses
> mod_nss instead of mod_ssl and mod_nss hasn't processed the SNI header
> before, sslget didn't fail in the past.
> 
> Yes, I have fixed sslget to send a HTTP Host header with hostname and port.
> 
> No, that won't work. You'd have to change the configuration before you
> run uninstall. Install still won't work because uninstall was
> incomplete. It's still necessary to remove the Service Domain for the CA
> from LDAP. The sslget command call removes it. It's also possible to
> remove it with ldapremove over ldapi. The entry is in the
> cn=CAList,ou=Security Domain,o=ipaca subtree.

I'm not sure I follow. You mean my proposed workaround won't work? I
think it should because the IPA installer directly tweaks only a few
things in nss.conf so if one manually sets NSSSNI then it should be
preserved between install/uninstall.

I was under the impression this is a fresh install so there is no
existing data to deal with.

rob