Freeradius not taking new ACME certificate
-
@johnpoz said in Freeradius not taking new ACME certificate:
@mkcharlie Doh - My only excuse is not enough coffee ;) hehehe
You are correct in a PEAP setup the client and server would create a tunnel.. There is no client cert..
This sort of auth is normally not done where the client is outside of your control.. When outside devices try and connect to say a work network, they normally just use a guest network.. Device that would auth to the work network, would trust the CA creating this server cert..
True, it is a bit of a strange setup. But still it should work right?
By the way where I live there are many ISPs that set up WiFi sharing like this. I.e. you can use your ISP's credentials to connect to a shared WiFi.. It is more secure than a guest network with shared password.Feel free to answer - after a cup of coffee
-
@mkcharlie said in Freeradius not taking new ACME certificate:
Your quote "The fact that it is auto signed, or not, doesn't matter, as you've gave Freeradius the CA, so it trust the certificate." is not something I agree with
If the end user gets a popup on a screen that they have to accept a cert because it's cert CA is not listed on the user's device, then,yes, all bet are off, you need certs signed from a 'globally' trusted source.
So, ok, no issues with that.
Still, this is a special case, and I use the word special because I' haven't seen this question on the forum.
Special (== strange setup ;) ) case means : probably not known to the developers (or known but why implementing something nearly no one uses etc etc) .
Thus : special cases needs 'special' solution.
That's the beauty of pfSense.
It works.
If it doesn't : you, me, whoever can make it work.
IMHO : the GUI is nice, for the easy things. Special cases : get a keyboard.
Hence the 5 lines script : nothing magic actually : it copies over the renewed cert files to the correct place, with the correct file names. And then it restarts radius.
Nothing can go wrong
Example : I'm using the same, original acme.sh on my own Debian servers, and I've written my own 'extension' that handles all the special cases, as I have to reload postfix (mail server), restart apache2, sighup courier (pop/imap server), restart 'monit' etc etc.
That's what needs to be done so the renewed cert are taken in account.
Nothing new actually, for me.Btw : I'm using the pfSense captive portal : I'm serving the login page over https, because it's more serious like that. Most browser will complain these days if you serve a plain http anyway.
My (hotel) clients can connect just fine.
If they want security & privacy afterwards : up to them to visit only https (TLS) sites, and make sure they retrieve there mail over 993/995 and send mail using 465 (also both TLS).
They want to hide their DNS ? That fine to me : that's where a VPN comes in handy.
The 'free wifi access', for me, is just a service with zero $ access fee.And yes, if they use a VPN I can't 'see' their DNS request anymore. So pfBlocker won't 'help' them.
So they will see whatever publicity, can go to p*rnh#b, I don't care. I'm there to give them access, not to check what they do.
( that is, as long as they don't try to launch nukes from a hotel room, as then I would receive the guys in black )@mkcharlie said in Freeradius not taking new ACME certificate:
you can use your ISP's credentials to connect to a shared WiFi..
That's the first thing I've shut down in my ISP router ..... (like the phone service, video service, etc)
edit : it's 18h23 here, I should stop the coffee.
-
@mkcharlie said in Freeradius not taking new ACME certificate:
why: our client devices have been configured to only accept PEAP certificates of trusted providers.
I think there is a solution.
First : Check "Write Certificates" here :
so from now on, the latest, renewed certificates and other files will be available in /cf/conf/acme/
For me, this is the case : I found 5 files :[23.01-RELEASE][root@pfSense.near.by]/usr/local/etc/raddb/certs: ls -al /cf/conf/acme/ total 68 drwxr-xr-x 2 root wheel 7 Jan 18 18:49 . drwxr-xr-x 5 root wheel 35 Apr 27 14:43 .. -rw-r--r-- 1 root wheel 7309 Feb 27 15:09 V2_near.by.all.pem -rw-r--r-- 1 root wheel 1826 Feb 27 15:09 V2_near.by.ca -rw-r--r-- 1 root wheel 2236 Feb 27 15:09 V2_near.by.crt -rw-r--r-- 1 root wheel 4062 Feb 27 15:09 V2_near.by.fullchain -rw-r--r-- 1 root wheel 3247 Feb 27 15:09 V2_near.by.keyNext thing to find out : where are the certificate files that Freeradius needs (selected in the GUI) :
They are here :[23.01-RELEASE][root@pfSense.near.by]/usr/local/etc/raddb/certs: ls -al total 89 drwxr-xr-x 2 root wheel 17 Feb 17 08:38 . drwxr-xr-x 10 root wheel 23 Feb 17 08:38 .. -rw-r--r-- 1 root wheel 4559 Feb 17 08:38 01.pem -rw-r--r-- 1 root wheel 4408 Feb 17 08:38 02.pem -rw-r----- 1 root wheel 6465 Feb 17 08:38 Makefile -rw-r----- 1 root wheel 8010 Feb 17 08:38 README.md -rwxr-x--- 1 root wheel 2798 Feb 17 08:38 bootstrap -rw-r--r-- 1 root wheel 478 Feb 17 08:38 ca.crl -rw-r--r-- 1 root wheel 1680 Apr 27 14:43 ca_cert.pem -rw-r--r-- 1 root wheel 1704 Apr 27 14:43 ca_key.pem -rw-r--r-- 1 root wheel 424 Feb 17 08:38 dh -rw-r--r-- 1 root wheel 166 Feb 17 08:38 passwords.mk -rw-r--r-- 1 root wheel 3503 Apr 27 14:43 server_cert.pem -rw-r--r-- 1 root wheel 1704 Apr 27 14:43 server_key.pem -rw-r----- 1 root wheel 2581 Feb 17 08:38 user@example.org.p12 -rw-r----- 1 root wheel 3687 Feb 17 08:38 user@example.org.pem -rw-r----- 1 root wheel 3046 Feb 17 08:38 xpextensionsImportant are :
server_key.pem
server_cert.pem
ca_cert.pemI know this because I looked here : /usr/local/etc/ raddb/mods-enabled/eap (remember : opensource : you have the manual of everything)
Now, 'all' you have to do is, write a shell script called /root/kick-radiusd.sh - and put this '/root/kick-radiusd.sh' on the list with action to execute when a certificate renewal has taken place :
Here we go :
#!/usr/local/bin/bash cp -f /cf/conf/acme/V2_near.by.key /usr/local/etc/raddb/certs/server_key.pem cp -f /cf/conf/acme/V2_near.by.crt /usr/local/etc/raddb/certs/server_cert.pem cp -f /cf/conf/acme/V2_near.by.ca /usr/local/etc/raddb/certs/ca_cert.pem service radiusd stop service radiusd onestartAdd a
chmod +x /root/kick-radiusd.shfor good manners.
Before you start/use this script, I advise you to compare the source and destination of the 3 files : they should be the same, right now, because you assigned them already to Freeradius.
The idea is easy to understand :
When a cert change (renewal) happens, the new crt/key/ca files are dispo.
The scripts copies them over.
Restart radius
Done ;)Btw : please, even if you think it works : test !
I've executed the script myself, and found freeradius was running ... and authentication continued ...
But I've not the same 'eap' file settings as you (I think).Your friends are :
/var/log/radius.log
and the command radsniff -
@gertjan isn't this already like a documented thing to have to do when you change the certs, I have this for my haproxy for example when the certs using there get updated by acme
-
@johnpoz said in Freeradius not taking new ACME certificate:
haproxy
Can't tell, as I don't have / use haproxy.
The radius(.sh) process control file does only wha it paid to do : start stop retart the process. It presumes all config files are fine.That why I added the 3 copy lines.
-
@gertjan
Thanks, I was trying that and suddenly I thought about your comment of having the manual of everything.So I looked at https://github.com/pfsense/FreeBSD-ports/blob/3c5dd718f5947beffa173aa72c3f72478af9fbea/net/pfSense-pkg-freeradius3/files/usr/local/pkg/freeradius.inc and thought of simply running the freeradius_settings_resync() command. It's there, and it's probably doing what you say but potentially more future-proof and more complete.
So I now have set up the following:
Seems to work at first sight, but still, proof of the pudding will be in the eating. What do you think?
-
I was looking at that function, with the same thoughts.
I decided to 'copy' because nothing has to be changed realy, just the content of the 3 cert files had to get updated with the new content.Your solution looks more 'clean', I agree.
-
@Gertjan seems 23.01 changed behind the scenes. The above was crashing. I had to remove the 'exec' keyword since it threw an error
[29-May-2023 03:16:38 Europe/Brussels] PHP Fatal error: Uncaught Error: Undefined constant "exec" in /usr/local/pkg/acme/acme_command.sh(61) : eval()'d code:1
Without the exec keyword, it seems to work fine. I have no idea what changed. Let's hope it keeps on working after upgrading to 23.05.
-
@mkcharlie said in Freeradius not taking new ACME certificate:
I had to remove the 'exec' keyword since it threw an error
Remove from where ?
Here :
?
The error says that the PHP eval function, while evaluation (== executing) discoverer a non valid PHP instruction : 'exec' : it bailed out.
-
@Gertjan said in Freeradius not taking new ACME certificate:
@mkcharlie said in Freeradius not taking new ACME certificate:
I had to remove the 'exec' keyword since it threw an error
Remove from where ?
Here :?
The error says that the PHP eval function, while evaluation (== executing) discoverer a non valid PHP instruction : 'exec' : it bailed out.
Correct, there.
So I suppose the execute function is now built in the acme, so you do not have to specify it. -
@mkcharlie said in Freeradius not taking new ACME certificate:
So I suppose the execute function is now built in the acme, so you do not have to specify it.
It works like this :
Line 61 becomes :
eval ("require_once('/usr/local/pkg/freeradius.inc'); freeradius_settings_rysync();");"exec" is not a recognized PHP command : so => error.
The issue was not acme related, but your own PHP 'mini' script
-
There’s nothing more expensive about providing a wildcard.
But, if they were the same price nobody would buy a single domain certificate, because it would be simpler and as cheap to buy the wildcard.
People who provide certificates have invested time and money to be in that club. Therefore they want to get back as much as they can from selling them. People are willing to pay more for wildcards so they are charged more. It’s just ordinary economics.
