Captive portal certificate chain
-
Oh! Yes, this would be a VERY useful feature. Just email me with any questions and I'll see what I can do.
Cool. I actually may have some work cycles that I can dedicate to this since it's related. I'll probably have some q's for you tomorrow.
-
At the risk of using multiple mechanisms to communicate about the same thing, I have patches that make this work in my environment. As you know, I sent them to the coreteam@. I can post them here if others want to see them.
nb
-
Hi everyone,
I'm re-opening this thread 'cause it's exactly what I'm looking for :P
I already manage to make this "ssl.ca-file" field work for my captive portal by adding it in the "/var/etc/lighty-CaptivePortal-SSL.conf" file and restarting light_http process. Works greatly, no more certificate issuer alert in IE or Firefox.
But on the next reboot of the pfsense box, no more ssl.ca-file field…. Arrrgh, this file is dynamically created on boot ?
So I found this thread, but editing the file /etc/inc/captiveportal.inc (if it is this one) frighten me...
Thanks for all your help you can afford me...
Benoit.
-
It requires more than just modifying the /etc/inc/captiveportal.inc file. I had to modify the system.inc and the system_advanced.php page to make it work well enough to put the certificate in the xml and persist across boots. The lighthttp conf files are rebuilt at each boot from the xml as far as I remember. I had it all working but an upgrade a while ago broke it and I never got around to fixing it. It is on my list of things to fix but it may be a while. I sent my patches to coreteam@ but I dunno if they added them to -HEAD or not. I can give you my diffs if you want to take a crack at it, else you're at the mercy of my poor time management or someone on coreteam to make it work.
The poor mans work around could be to write a small shell script to run from cron @boot (but after all the services are started) to add that line to the conf file and restart the process.nb
Hi everyone,
I'm re-opening this thread 'cause it's exactly what I'm looking for :P
I already manage to make this "ssl.ca-file" field work for my captive portal by adding it in the "/var/etc/lighty-CaptivePortal-SSL.conf" file and restarting light_http process. Works greatly, no more certificate issuer alert in IE or Firefox.
But on the next reboot of the pfsense box, no more ssl.ca-file field…. Arrrgh, this file is dynamically created on boot ?
So I found this thread, but editing the file /etc/inc/captiveportal.inc (if it is this one) frighten me...
Thanks for all your help you can afford me...
Benoit.
-
Buraglio, thanks a lot !!!!!!!
As I already put the file on the pfsense file system, I just needed to find how to keep the ssl.ca-file in the config file on reboot. Modifying the php web interface file is far from what I'm able to do…...
And you gave me the file I needed : /etc/inc/system.inc.
Just for information in case it can afford a temporary solution before the next release incorporating the ssl.ca-file field, here's what I modified in the /etc/inc/system.inc file : I just added the last line :
$lighty_config .= "## ssl configuration\n";
$lighty_config .= "ssl.engine = "enable"\n";
$lighty_config .= "ssl.pemfile = "{$g['varetc_path']}/{$cert_location}"\n";
$lighty_config .= "ssl.ca-file = "/path/to/my/cert/mycert.pem"\n\n";So, Buraglio, thanks to you, I success in getting rid of this IE7 scaring alert (and so all other web-browsers of course ;o).
Thanks !!!!!
Benoit. -
Can I get updated patches to commit this feature?
-
I'll try and get something worked out soon.
nb
Can I get updated patches to commit this feature?
-
Thanks! e-mail them to coreteam@ if you get it sorted out.
-
Hmm, I'm trying to get this to work again backporting my patches. Does the modification of /etc/inc/system.inc like you did work for both the /var/etc/lighty-webConfigurator.conf and the /var/etc/lighty-CaptivePortal-SSL.conf ?
Mine works fine for the webgui but not for the Captive portal. I know it really should be split out into independent options but I want to make it work the way it did originally first and seem to be getting stuck. Here is what works:webgui configuration of the chain file, storage in the xml, writing it to a file in /var/etc/
system.inc building of the /var/etc/lighty-webConfigurator.conf file with correct parameters.certificate chain
ssl.ca-file = "/var/etc/cert-chain.crt"
is appended to the conf file and the file /var/etc/cert-chain.crt contains the chain.Here is what is still broken:
/var/etc/lighty-CaptivePortal-SSL.conf adds
certificate chain
ssl.ca-file = "/var/etc/1"
which obviously isn't correct.Anyone else wanna take a crack at it as well? I think it's close. I attached my diffs. I'm going to try and keep working on it as well but may get crunched for time.
nb
-
Well, I only needed the captiveportal-ssl.conf to be filled with the ssl.ca-file field.
But it seems it has worked for both (see below)
pwd
/var/etc
grep ssl.ca-file *
lighty-CaptivePortal-SSL.conf:ssl.ca-file = "/var/etc/mycert.pem"
lighty-webConfigurator.conf:ssl.ca-file = "/var/etc/mycert.pem"But in the system.inc file, I didn't use the variable as in ssl.pemfile, I directly put the path to my cert file (not very beautiful, ok ;o)) :
$lighty_config .= "ssl.pemfile = "{$g['varetc_path']}/{$cert_location}"\n";
$lighty_config .= "ssl.ca-file = "/var/etc/mycert.pem"\n\n";For your dev, it seems the $cert_location is not understood while making the portal-ssl.conf, but why…
-
That is a fine question…..
I started cleaning up the way it works and have the gui done and working for a unique chain file for the portal and webgui, now all I need to do it make the conf files build correctly and be done with it.nb
-
Yeah, it wasn't interpreting the variable. I changed it to link to the file directly and it works fine. The file is already written at that point anyway so it shouldn't matter. Still working on the separation of chain files for system and portal.
Patches submitted to coreteam@
nb
-
I think I spoke too soon. In doing some testing again today, I have found that my mods build the lighttpd files correctly but the redirect no longer works, which is the same behavior I saw before. Infinitely frustrating. Back to the code I guess.