Did you consider virtualization for host accessible from public networks?

Performance degradation is usually small nowadays and you can save some headaches (and create different one :-)).

Petr^2 Spacek

On 10/08/2012 04:19 PM, Simon Williams wrote:
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.


Simon Williams

On Mon, Oct 8, 2012 at 1:45 PM, Rob Crittenden <rcrit...@redhat.com
<mailto: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
            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
            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
            could be used for virtual servers other than the IPA server, but 
            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
            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
            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
            all packages up to date as of yesterday) just aren't supplying a new
            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

        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


    mod_nss doesn't support SNI because NSS doesn't support SNI server-side
    yet (https://bugzilla.mozilla.org/__show_bug.cgi?id=360421

    The mod_nss bug tracker is bugzilla.redhat.com <http://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

    Switching to mod_ssl wouldn't require any changes to the directory server.


Freeipa-users mailing list

Reply via email to