Security

Hi,

Got an Amigopod installation where I would like to have different SSL certificates on the Webserver for different interfaces.

Got one Interface for guests getting the Captive Portal page. This is a public interface. Already installed a certificate and that works fine.

Got another interface for management, this interface is going to be used when creating guest accounts for all internal users.

I do not want them to go via the public interface to create accounts. That will mean we would open up managment interface to Internet.

Is this doable?

---

@christian-ns wrote:

Hi,

 

Got an Amigopod installation where I would like to have different SSL certificates on the Webserver for different interfaces.

 

Got one Interface for guests getting the Captive Portal page. This is a public interface. Already installed a certificate and that works fine.

 

Got another interface for management, this interface is going to be used when creating guest accounts for all internal users.

I do not want them to go via the public interface to create accounts. That will mean we would open up managment interface to Internet.

 

Is this doable?

 

---

Question:

Can't your management users create accounts using the management interface?

Yes, that works, but the problem is that they get a certificate warning, because the certificate installed is issued to a public DNS-entry with a public IP (and we can't let the internal users go that public way).

What we would like to do, is to issue a internal certificate pointing to a internal address.

But if I do a new certificate request and import that, I guess the other certificate disappears.

I don't think you can create a cert that would be bound to a particular interface.  Usually a cert is bound to a web server instance or a virtual one, not to a particular ethernet interface.

What we did to get around the issue you see is to add a internal DNS entry for the cert name and told users to use the external name to connect to the Amigopod.

So, a guest in captive portal resolves amigopod.company.com with the public ip address, but interally amigopod.company.com is resolved with the internal (management interface) ip address.  You have to be careful how you do that though and it may or may not be possible depending on your DNS setup.

It might be helpful to modify the CSR process to include the ability to add subject alternative names (SAN) to the request. This way, one certificate can work for mutliple names and even IP addresses. I have created a feature request for this.

That would be great, Avidal!

---

What we did to get around the issue you see is to add a internal DNS entry for the cert name and told users to use the external name to connect to the Amigopod.

---

I had this is mind, but the way all is put together it is also a bit complex.

Because the cert that is used is issues to an external company domain name, .companyexternal.com.

And the internal domain is another name, like .companyinternal.com.

So to get all working, we need to add the external domain as a zone in the internal DNS servers. That could make some problems because that external domain is also used for other services. But I'm looking deeper in to this hoping it could be solved this way...

---

It might be helpful to modify the CSR process to include the ability to add subject alternative names (SAN) to the request. This way, one certificate can work for multiple names and even IP addresses. I have created a feature request for this.

---

This sounds like a nice solution for my problem!

Christian - Yeah, same setup here, so we just told our internal people to use the external name when they connect to the Amigopod to create accounts.

What do you do in the case where the external name resolves to an external IP for guests to access while internal users needing to approve guest accounts need to hit the internal site?