Authenticating Users with Google Cloud Identity

[stephenw10]

And just enabling https login causes an error?

[leonida368]

@stephenw10 said in Authenticating Users with Google Cloud Identity:

And just enabling https login causes an error?

Reply

yes

[stephenw10]

Same redirect error?

Anything logged?

[Gertjan]

@leonida368 said in Authenticating Users with Google Cloud Identity:

Enable SSL/TLS Service: I have NOT enabled "Respond to incoming SSL/TLS queries from local clients"

That option is only usable if you control every LAN client, so you can set up each client to use DNS over TLS on port 853. That wasn't even possible with Windows devices nort so long ago.
This option is not usable for a captive portal, where you do not control the connecting devices.

@leonida368 said in Authenticating Users with Google Cloud Identity:

I checked "Enable logout popup window"

You don't need it.
Must users, yourself included, have already disabled those nasty popup windows ages ago.
So that windows never (or very rarely) pops up.

@leonida368 said in Authenticating Users with Google Cloud Identity:

I checked "Enable HTTPS login" so that the captive portal appears even with https traffic
in HTTPS server name I gave "pfsense server name". "domain" as inserted in the common name (CN) of the CA and the certificate created
SSL/TLS Certificate: I gave the created certificate

"https" login is mandatory if you want a portal that isn't flagged as suspicious (or worse) on every client connecting to the portal. Classic "http" is pretty much gone these days.
To have "every" browser trust your certificate, you can't make your own. Nobody trusts you ^^
You to get a certificate from a known trusted Certificate Authority.
That's why where the pfSense package ACME comes in handy : it will 'arrange' a trusted certificate for you. The certificate will be free of charge, will get renewed every xx days, with you doing nothing.
And here it comes : Before Lets-encrypt creates and signs a certificate for you, you have to proof that you own (actually : rent) the domain name.
Maybe your school already has its own domain name ?
And maybe the registrar used support one of the "DNS API" methods that acme offers ?
If so : declare (example) this domain : "portal.your-school-domain-name.tld" and set up acme to it will ask a cert for this sub domain. Use this domain like this :

Or maybe they already have a wildcard certificate for the your-school-domain-name.tld domain ? You can use that also, as that will work for pfsense.your-school-domain-name.tld and portal.your-school-domain-name.tld and printer.your-school-domain-name.tld etc etc .

"Nico" is the name of the acme account where I've set up the cert request for "portal.your-school-domain-name.tld".

Place also a domain override under the Resolver, at the bottom :

and now you have done everything that is needed to create a https web server, as that is what the captive portal login page server actually is (should be).

Btw : you can also buy a cert from a cert signing company, as we did all before. Upload the cert into the pfSense cert manager, and select it on the captive portal's settings page.

Now the clients will connect to the login page web server with a valid, trusted certificate, and everything will work without any issues.

Btw : this step isn't much different as building your own web server.
In the past, you started a web server, threw in a bunch of html files, later on PHP and whatever, but these days you have to get your hands on a valid certificate, and place it in the web serer config files. Without a cert : no https .....
Not a big issue, as a web server on the Internet means : you have a domain name already. So arranging a cert is just another admin job.
A captive portal isn't a public web server, but you still need to own a domain name or sub domain name.

[leonida368]

This post is deleted!

[leonida368]

I can't reply, I always go to spam

[Gertjan]

@leonida368

Try again, I upvoted 6 of your posts, so you're above 5, so the anti spam won't bother you less.

[leonida368]

I meant: so I have to generate a certificate from letsencrypt.org using an ACME client. Is the certbot client ok?
This school's domain was generated using Google Workspace. To prove that you own the domain name, is it sufficient to have the administrator credentials of that school's Google Workspace console?

[Gertjan]

@leonida368 said in Authenticating Users with Google Cloud Identity:

Is the certbot client ok?

Noop, as that's to hard.
There is no 'certbot' package for pfSense.

@leonida368 said in Authenticating Users with Google Cloud Identity:

To prove that you own the domain name

Like certbot, ascme, or actually, none of the two, its Letencrypt that check if you own a domain.

[leonida368]

@Gertjan said in Authenticating Users with Google Cloud Identity:

Noop, as that's to hard.
There is no 'certbot' package for pfSense.

If the certbot client is too difficult, what do you recommend?

[leonida368]

I see that among the PfSense packages there is Acme Certificates. Should I use this?

[stephenw10]

Yes use the ACME package in pfSense if you're maintaining the cert there.

[Gertjan]

@leonida368 said in Authenticating Users with Google Cloud Identity:

I see that among the PfSense packages there is Acme Certificates. Should I use this?

@Gertjan said in Authenticating Users with Google Cloud Identity:

That's why where the pfSense package ACME comes in handy : it will 'arrange' a trusted certificate for you.

[leonida368]

Good morning, today I will dedicate myself to generating the certificate using this Acme Certificates package in order to close the captive portal configuration with authentication with Google Workspace (tomorrow I will be at the customer's site, DAY OF TRUTH!). Before starting I ask:

• based on what logic does Letencrypt check if I own the customer's domain?

@Gertjan said in Authenticating Users with Google Cloud Identity:

I checked "Enable logout popup window"

You don't need it.
Must users, yourself included, have already disabled those nasty popup windows ages ago.
So that windows never (or very rarely) pops up.

If the popup doesn't appear, how will the user log out of their session?

A thousand thanks

[Gertjan]

@leonida368 said in Authenticating Users with Google Cloud Identity:

based on what logic does Letencrypt check if I own the customer's domain?

Oh...
You found the site of letsencrypt. They tell you the why, what, when : Getting started.

Basically, it goes like this :
The client app, acme.sh in this case, or certbot, or whatever other app/script/code start, and connects to letencrypt with your "ID" (some sort of account).
The client; acme;sh, tells letencrypt : I want a cert for example.tld.
letencrypt give the client back a code ([hash-1]) to be used as a "file name" and a code ([hash-2]) to be put into this file.

The client now accesses the registrar using the method the registrar offers : the default, ancient method is called "RFC 2136" and uses 'nsupdate', who connects itself to the master domain name server, and adds into to the domain name zone this very exact sub domain : .well-known/acme-challenge/.
So in the sub domain a text (TXT) record is created, called hash-1.
The content of hash-1 will be hash-2.
Exactly like the creation of a creating a A record in the sub domain "www", and the A record contains ... the IPv4 of your web site.

When our client (acme.sh) has created successfully this hash-1/.well-known/acme-challenge/example.tld, then you might want need to 'wait' bit, hence the delay field.
When the wait is over, the client signals letsencrypt that it can starting checking.

What does letsencrypt ? Easy : it resolves (it uses 'dig' of course !) for a TXT record at hash-1/.well-known/acme-challenge/example.tld and it should get back hash-2.
If it find it, then you have proven that you can access = control the domain "example.tld".
letsencrypt will now create a certificate for your domain and sign it, and send it over to the client.

Why the wait (DNS-Sleep) ? Because the acme client updates the master domain name server. When done, this master will signal all the domain name slaves. These slaves decide when they sync up with the master. This syncying has to be done before letsencrypt starts to test. If not, it could hit the master, or one of the slaves : if the slave didn't contain the "hash-1/.well-known/acme-challenge/example.tld", it would be a fail.

Look here : https://github.com/acmesh-official/acme.sh/tree/master/dnsapi
I explained how dns_nsupdate.sh (the "RFC 2136" works) as it talks to 'bind' or bind comptabile direcly.
But most registrars didn't want all their clients to 'talk' to their master domain name server, as it hosts thousands (or way more) domain names. That's potentially an issue.
So, all the other methods talks to "registrar APIs" and these API will then do the domain name syncing for your in the background, on their side.
Every registrar created its own method of course ;)

[Gertjan]

@leonida368 said in Authenticating Users with Google Cloud Identity:

how will the user log out of their session?

They don't and you shouldn't care.
As you said yourself :

@leonida368 said in Authenticating Users with Google Cloud Identity:

I set the following 2 timeouts
Idle timeout (Minutes)
Hard timeout (Minutes)

As this concerns a school, starting at 08h00 and everybody out at 17h00, make the soft time out 9 hours, hard time out 12h00.
The DHCP lease duration can be kept to default, like 6 or 12 hours or so. AS most devices are Wifi anyway, and the wifi connection will get interrupted a thousands time a day, the device will get the same Lease (IP) all day long. Keep track of the number of devices, though, so that you have enough IPs in the pool. Don't open a portal with a /24 (255 devices max) on a school with 1000+ potential users. A /22 will be needed.

That said : there is a way to have the user disconnect themselves. It's undocumented ..... but it is also a RFC ( 8390 !! ).
The story is hidden in the "captive portal is not working on mobiles" This title, which was of course a none issue, hides a nice feature. You have to use DHCP ISC and not Kea. You have to add a DHCP option, and add a file, place it in the captive portal root folder /usr/local/captiveportal/
This is just optional, though.
I use this method, as portal identification goes much faster with this.

[leonida368]

dear @Gertjan as usual I'm a landslide in my presentation. Let me explain better: at the school on the same device (e.g. laptop in class not personal device) over the course of a day various teachers gradually alternate so the Idle timeout (Minutes) must be just 10min and is necessary have the possibility that the teacher can disconnect voluntarily so I will study this DHCP option you are talking about.

[leonida368]

So, I mentioned myself in the configuration and the following doubts/problems emerged:

DNS Resolver
I imagine that the "SSL/TLS certificate" field is useless since I don't tick "Enable SSL/TLS service", right?

Acme certified
After clicking on "issue" in System / Certificates / Authorities I expected to find an external Acmecert CA as per the guide but instead there isn't one

in services / Captive Portal for the "SSL/TLS Certificate" field I should be able to choose the ACME account created but I can't find it.

I performed the following steps:

1. I installed the ACME package
2. I went to Services / Acme Certificates
   Account keys
   add
   in name I entered pfs.client domain (in my case pfs.associazionedonvitale.edu.it)
   in ACME Server I chose "Let's Encrypt Production ACME v2"
   I clicked on Create new account key
   I clicked on Register ACME account key
   Save
   Certificates
   add
   I gave the name of the certificate pfs.client domain (in my case pfs.associazionedonvitale.edu.it)
   Status: Active
   I gave the account created before
   private key: 2048-bit RSA
   Domain SAN list section
   mode: Enabled
   domainname: pfs.client domain (in my case pfs.associazionedonvitale.edu.it)
   method: DNS-Manual
   Certificate renewal after: 3650
   Save
   I clicked on "issue"
   General settings
   I checked "Cron Entry"
   Save

[Gertjan]

@leonida368 said in Authenticating Users with Google Cloud Identity:

DNS Resolver
I imagine that the "SSL/TLS certificate" field is useless since I don't tick "Enable SSL/TLS service", right?

Not needed, totally not recommended for captive portal usage.

@leonida368 said in Authenticating Users with Google Cloud Identity:

I should be able to choose the ACME account created but I can't find it.

You have to select the certificate that you've imported into the Certificate manager
Or
You have to select the certificate that the acme.sh package put in there. Did you get one ?

@leonida368 said in Authenticating Users with Google Cloud Identity:

method: DNS-Manual

When you chose "DNS-Manual" you agree with the fact that you have to do this every give or take 60 days.

Do you have access with some sort of GUI to the associazionedonvitale.edu.it domain ? Really ?

But I get it, your top level domain is "edu.it" so you have to find the guy that works on the Ministry of education to get access to the domain "associazionedonvitale.edu.it". Italy is in Europe, so that will take months if not years before you have access to that one

@leonida368 said in Authenticating Users with Google Cloud Identity:

Certificate renewal after: 3650

600 max should do - but this value doesn't matter if you use the DNS-Manual method.

edit : read this : https://github.com/acmesh-official/acme.sh/issues/1029 and the reality is mentioned on the very first line

So many users are using dns manual mode, but they don't really understand the manual mode .
I'd like to add a new command parameter, something like:
acme.sh --issue -d example.com --dns --yes-I-understand-dns-manual-mode
Which forces the user to read our wiki and make sure they know they will need to manually renew the cert in 90 days.
Without given this new parameter, acme.sh will show the wiki link and refuse to work.

Think about what I've said earlier : for about 10 € a year ( !! ) you have your own domain name.
You don't have to / won't have to use it as a visible domain on the Internet. That's what I did : I have a domain name like my-hotel-in-france.fr, this domain is sued to access our web site, our mails etc
I have a second domain name, my-hotel-in-france.net that I use like this :

I use this domain only 'internally' and especially for the https access of my captive portal.
Because I run my own DNS, I can go easy on myself and use RFC2136, as I control both sides.
Btw : But you have to be nuts to run your own "domain name DNS" these days.

acme :

and since then I never looked back. https access totally automated. Actually even better as before when we had to renew the certs every year (when StartTLS was a thing - but they went 'bust' (in short))

[leonida368]

@Gertjan said in Authenticating Users with Google Cloud Identity:

You have to select the certificate that you've imported into the Certificate manager
Or
You have to select the certificate that the acme.sh package put in there. Did you get one ?

in ServicesAcmeCertificates

in SystemCertificatesCertificates