Signed SSL Cert for Captive Portal

cmcdonald

I purchased a 3 year standard SSL cert from GoDaddy (I found a great coupon for $5.99 per year). My experience with SSL is pretty much "none". I want to make sure that I am doing everything correctly as I am pretty sure I only have one shot at signing the correct certificate.

my network utilizes the following domain topography: *.inside.example.com

I do not run Windows Server on my network.

So I know that I need to create a DNS entry in pfsense to point 192.168.10.1 <- captiveportal.inside.example.com

And captiveportal.inside.example.com is the domain that needs to be on the certificate.

Now, do I need to install a root and intermediate cert from godaddy as a CA? This is where I am a little confused. I know how to generate a CSR but do I also need to add the root and intermediate?

Derelict

The web server needs to send intermediate certificate(s) (signed by a browser-trusted root) and the host certificate (signed by the intermediary). The root certificate will be in the browser's trusted certificate store.

cmcdonald

So as I understand it, this is what I need to do:

Create a CSR. Common name = captiveportal.inside.example.com
Import CSR into Godaddy's cert signing site.
Download certificate zip which I assume will include the cert and any necessary intermediate certs, etc.
Update the CSR in pfSense with the signed certificate
Import Intermediate as a CA in pfSense?

Is this correct?

Edit:

Okay, I figured this all out. However, I did run into a snag that I would also like to address. Currently I only have one captive portal. I have two logical networks (one physical) but only one of those is running captive portal. Anyways, I like to think ahead and I believe I've run into a limitation. Currently, I have a DNS record pointing captiveportal.inside.example.com to the CARP VIP on the network in question (in this case it is 172.16.0.1/24). However, lets say I want to deploy another network with a different subnet (like 192.168.0.1/24). If I have firewall rules blocking traffic between interfaces, users on the 192.168.0.1/24 subnet won't be able to communicate with the captive portal because it will be resolving to 172.16.0.1/24. What's a good way around this that puts me in a better position for the future? The sticky at the beginning of this board talks about creating multiple domains for different captive portals on different networks, which would also require multiple SSL certs. Any ideas?

Derelict

My initial thought is that, with some careful firewall rules, you might be able to use the same IP address for all your CP instances since they are differentiated by port numbers.

I do know the ipfw rules initially fwd's CP traffic to 127.0.0.1:8XXX. There would probably need to be some customization to make the httpd always use the same source address for all CP instances in its replies.

That or forget about the DNS forwarder and put ISC BIND up instead. You could easily make it return the correct A record based on the IP address of the resolver making the query.

Or a wildcard cert.

Or separate FQDNs/certificates for each CP instance. Check out www.startssl.com.