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 Freeipaemail@example.com https://www.redhat.com/mailman/listinfo/freeipa-users