I understand exactly where you are coming from Alexander and in an ideal
world the web sites that I want to get at externally would be on a
different server.  I am not the normal type of FreeIPA user, being a very
small business with only a couple of users and half a dozen or so machines
and, currently, very limited resources.  IPA makes it so easy to administer
the network however that I would be loathed not to use it! We are
developing software and I only have one server that I can dedicate to being
a stable host.  I have two other machines on the network that are currently
always on and both are used for development both running Fedora, one x64
and one Arm.  Neither of these machines could be considered stable.  The
other machines are a mix of Windows and Fedora laptops, soon to have a Mac
added if my partner gets her way.  I currently restrict access to the IPA
name virtual server by not having a publicly accessible name for it (and
using "deny all", "allow *local network*", but I don't think that does
anything as the incoming packets are routed using NAT, but it costs nothing
to have it there!).  I realise that this is insecure as a request on port
443 that does not have a host name will be handled by the default and
therefore IPA name virtual server.  That is something I still have to
address, but was intending to make the default name virtual server just
redirect to a 404 error page.

I had already found, read and tried the guide at the link you sent, that is
how I discovered that mod_ssl and mod_nss wouldn't co-exist.

Your comment Rob has started me thinking along different lines than I was.
 If the mod_ssl/mod_nss incompatibility only exists if the same port and IP
address is used, since I specifically don't want the IPA server to be
available outside the local network, I could either use a different port
for the non-IPA name virtual servers (the gateway could still present 80
and 443 to the outside world since the gateway is redirecting the packets
anyway).  Or a different virtual IP address on the server for the non-IPA
sites (only one NIC on the server and no free slots, so couldn't be
physically separate).  This would kill two birds with one stone (ie. make
the IPA instance more secure and solve the certificate problem).  It would
also make it easier to put the non-IPA web servers on a different machine
when I am in a position to do that.

Thank you both for your help.  I think that you have prodded me in the
right direction for a workaround.

Regards

Simon Williams

On Mon, Oct 8, 2012 at 1:45 PM, Rob Crittenden <rcrit...@redhat.com> wrote:

> Alexander Bokovoy wrote:
>
>> On Mon, 08 Oct 2012, Simon Williams wrote:
>>
>>> I have found a problem with mod_nss that appears to have been reported in
>>> 2010, but I cannot find any further reference to it.  The 2010 reference
>>> contains a comment saying that it is an issue and needs to be fixed.  I
>>> have not been able to find any issue tracking system for mod_nss and so
>>> haven't been able to check on the status.
>>>
>>> The problem is that mod_nss does not appear to respond with the correct
>>> certificate when multiple name virtual servers are configured on an
>>> instance of Apache.  It always responds with the certificate of the first
>>> name virtual server defined.  It does process the other sites'
>>> configurations because it complains if certificates with the aliases used
>>> are not in the database.  This would not be an issue (for me) if mod_ssl
>>> could be used for virtual servers other than the IPA server, but they
>>> cannot co-exist.  If you try to mix them, mod_ssl complains that port 443
>>> is being used for the IPA server, but it is not SSL aware.  I suppose it
>>> would be possible to reconfigure the IPA name virtual server to use
>>> mod_ssl
>>> bu exporting the certificate, but I really don't like to muck around with
>>> the directory server configuration more than is necessary as it is vital
>>> that it remains stable and secure.
>>>
>>> Could anyone enlighten me as to whether this issue is being looked at or
>>> even if it is fixed and the CentOS people (CentOS 6.3 standard
>>> repositories
>>> all packages up to date as of yesterday) just aren't supplying a new
>>> enough
>>> version of mod_nss.  At the moment, I can use my SSL secured sites as the
>>> encryption works okay, but I cannot open them up as they report the wrong
>>> host name in the certificate.
>>>
>> I assume all this comes because you run these virtual servers on the
>> same instance as FreeIPA master itself, thus conflicting mod_ssl and
>> mod_nss.
>>
>> Here is description how to make name-based SSL virtual hosts working in
>> FreeIPA environment using mod_ssl. This howto assumes you are using a
>> separate server than FreeIPA master to provide actual hosting for
>> the virtual hosts which also makes sense because one would need to apply
>> greater security protection to the KDC which runs on the same FreeIPA
>> host.
>>
>> http://freeipa.org/page/**Apache_SNI_With_Kerberos<http://freeipa.org/page/Apache_SNI_With_Kerberos>
>>
>>
>>
> mod_nss doesn't support SNI because NSS doesn't support SNI server-side
> yet 
> (https://bugzilla.mozilla.org/**show_bug.cgi?id=360421<https://bugzilla.mozilla.org/show_bug.cgi?id=360421>
> ).
>
> The mod_nss bug tracker is bugzilla.redhat.com.
>
> mod_ssl and mod_nss can co-exist but not on the same port (which is true
> of any two servers). mod_ssl and mod_nss cannot co-exist on an IPA server
> though, because mod_proxy only provides a single SSL interface and mod_ssl
> always registers it, locking mod_nss out. This is being worked on in
> mod_proxy.
>
> Switching to mod_ssl wouldn't require any changes to the directory server.
>
> rob
>
_______________________________________________
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Reply via email to