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.

Christian

Attachment: signature.asc
Description: OpenPGP digital signature

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