Freeradius not taking new ACME certificate

mkcharlie

@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.

johnpoz

@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..

mkcharlie

@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.

johnpoz

@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..

mkcharlie

@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

Gertjan

@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.

Gertjan

@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.key

Next 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 xpextensions

Important are :
server_key.pem
server_cert.pem
ca_cert.pem

I 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 onestart

Add a

chmod +x /root/kick-radiusd.sh

for 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

johnpoz

@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

Gertjan

@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.

mkcharlie

@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?

Gertjan

@mkcharlie

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.

mkcharlie

@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.

Gertjan

@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.

mkcharlie

@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.

Gertjan

@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

abhamit533

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.