Freeradius not taking new ACME certificate
-
Hi,
----- Problem -----
I am using an ACME certificate as SSL server certificate in a PEAP setup (PKI certificate on server side - clients use username password). This works very well, but when the certificate is automatically renewed by ACME, Freeradius keeps using the old one. It seems as if there is a copy maintained by Freeradius, and not a reference to the certificate. Here are my Freeradius EAP settings:
----- Things I have tried -----
I have tried to restart the radiusd service upon renewal of the certificate:
I have even tried to do a full reboot after renewal. But the old certificate keeps being used. It is only when clicking 'save' (without changing ANY setting) again in the Freeradius settings that the new certificate is used.This is of course not maintainable in a production environment. Any hints on how to solve this?
I'm using a Netgate 7100, 22.05-RELEASE (amd64) (I know there's an update - but want to wait a bit before installing). Freeradius is version 0.15.7_33 (here also there's an update available, but could not find anything related to my problem in the change logs).
-
I've been using Freeradius for years now, way before Letsenscrypt, the acme.sh pfSense package existed.
Back then, I had to create a CA for Freeradius :
and a certificate :
and use these two for the settings of FreeRdius.
Question : why do you need to use a certificate from Letsencrypt ?
The CA and certificate is use for the communication between the radius server and client. The fact that it is auto signed, or not, doesn't matter, as you've gave Freeradius the CA, so it trust the certificate.
Next question :
Did you check what that does ??
I guess not.Here :
[23.01-RELEASE][admin@pfSensenear.by]/root: service radiusd onestart radiusd already running? (pid=60617).So, without checking the logs (bad, I know, we should always check the logs first) I'm pretty sure that that command 'does nothing'.
The 'service' command winds up checking if the PID exists, and it does, so, it concludes the process is already running.But even if you wrote your own shell (bash, whatever) script file with
service radiusd stop service radiusd onestartand you call that script as a restart command after cert renewal, it still wouldn't work.
The renewed certificate files are stored in the Certificate Manager, and have to be places 'somewhere'. Then the exact place has to be indicated in the (a) main config file of Freeradius.
This file gets created and re created when you "Save" this page : Services > FreeRADIUS > EAP
It might be necessary that you 'script'' this save.But why doing through the hassle of all this ? Please explain.
-
@gertjan Hi Gertjan,
Wauw, great answer. I seem to indeed not have checked what that command does. It's been a while, but that's my bad. In any case, as you explain it would not help. Scripting the save seems like an ugly solution..
So, why: our client devices have been configured to only accept PEAP certificates of trusted providers. We currently have no way to auto-provision our own certificate authority to these devices, as some of them are BYOD. People are explicitly asked in the documentation to check that the domain name and issuer of the Radius certificate matches a certain value before connecting. Managed devices are configured to only accept certificates of Let's encrypt (ISRG root X1).
But still, even if I would use our own authority I suppose I should renew it regularly.
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. Our user's passwords are protected using the TLS tunnel of the Freeradius server certificate (reminder: we use PEAP), so it is important to make sure people can validate that this tunnel can be trusted.
enabled services:
- snort
- pfblockerNG
-
@mkcharlie said in Freeradius not taking new ACME certificate:
so it is important to make sure people can validate that this tunnel can be trusted.
What people - a client for your freerad server would be what is authing the user, like your AP.. Or say a server your end user is trying to log into, it wouldn't be an end user..
-
@johnpoz said in Freeradius not taking new ACME certificate:
@mkcharlie said in Freeradius not taking new ACME certificate:
so it is important to make sure people can validate that this tunnel can be trusted.
What people - a client for your freerad server would be what is authing the user, like your AP.. Or say a server your end user is trying to log into, it wouldn't be an end user..
A user device, like a smartphone or a PC. But that device shows the certificate information.
-
@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..
-
@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.
