The mailing list for users of the eduroam Configuration Assistant Tool (CAT)

[Hunter Fuller <hf0002 AT uah.edu>]

Arthur,

Since Paul concurs, here is an email I have sent to educause
wireless-lan list before. It may help you. I did not mention it, but
we provision this CA with CAT. We do not provision the server cert
(and in fact CAT warns you against doing this).

---

UAH is using an offline CA we call the "Russ CA," named affectionately
after our previous CISO. Here is how Russ created the Russ CA and
signed our eduroam cert using this CA:

$ openssl genrsa -des3 -out rootCA.key 4096
$ openssl req -x509 -new -nodes -key rootCA.key -sha256 -days 7300
-out rootCA.crt
$ openssl ca -create_serial -keyfile rootCA.key -cert rootCA.crt -in
input.pem -out out.crt -config ./server.cnf

Where:
 - rootCA.key becomes the Root CA private key
 - rootCA.crt becomes the Root CA cert
 - input.pem is the CSR from your RADIUS (ClearPass I guess)
 - out.crt becomes the signed cert for RADIUS

You will be asked to provide a passphrase for the Root CA key. It is
vitally important that this be kept secure and that you do not lose
it.
You will be asked for information about the Root CA when you make the
cert. Give real information. It shows up on iPhones under some
circumstances, at the very least.
Do not lose the root CA key, cert, or passphrase between signings! If
you lose it, you will have to restart from nothing, and reprovision
all your users.

We are using this method for the past couple of years with no trouble.
If you have any other questions let me know.

--
Hunter Fuller (they)
Router Jockey
VBH M-1A
+1 256 824 5331

Office of Information Technology
The University of Alabama in Huntsville
Network Engineering

On Tue, Oct 5, 2021 at 3:34 PM Paul Dekkers <paul.dekkers AT surf.nl> wrote:
>
> Hi,
>
> These certificates from FreeRADIUS are really examples, used for testing; I 
> wouldn't use them in production. And one thing that is indeed missing is 
> attributes we common find in other certificates. And you shouldn't use a CA 
> for the server indeed, without server purpose.
>
> The EAP server certificate considerations page also lists these 
> requirements, like the SubjectAltName:DNS AND the Extended Key Usage, and 
> CA:FALSE. This page indeed lists a few advantages of a "small special 
> purpose CA", but there also disadvantages, and maybe even more so in 2021. 
> A few I think I mentioned, like the risk for man-in-the-middle attacks by 
> this particular CA if it's installed. But also OS vendors treat server 
> certificates differently. One example is Android, where it's now more 
> trivial to configure the client correctly if you are using a public CA.
>
> You cannot alter an existing certificate; you can replace it. If it has 
> similar properties, and depending on the way the clients are configured 
> (like with CAT), you can actually keep the trust on the FQDN. But, in your 
> case, I think you need to swap out to a different CA. Or use this CA to 
> create the actual certificate. But the FreeRADIUS scripts won't help you, 
> that's playing a lot with openssl I think.
>
> Regards,
> Paul
>
>
> On 05/10/2021 18:12, Arthur Petrosyan wrote:
>
> Hi All !
>
> We use the freeradius-provided "cert" folder to generate self-signed cert.
> And it worked/works with "eduroam CAT".
>
> The page we took into consideration when making a decision was:
> https://wiki.geant.org/display/H2eduroam/EAP+Server+Certificate+considerations
>
> Here we read:
> "certificates from a commercial CA are as valid for EAP authentications as 
> are self-made certificates or certificates from a small, special-purpose 
> CA."
> So we found self-made ones more fitting our situation for now.
> I thought many are using them. Am I wrong?
> If yes I would be happy to get more info to maybe improve our approach.
>
> Regarding "subjectAltName DNS:" entry I didn't find any example in 
> freeradius "cert" folder to confugure that.
>
> Can anyone using freeradius's "cert" self-signed certificates share example 
> of configuring "subjectAltName DNS:" entry there?
>
> Is it possible to add that entry to the existing certificate ?
> What will such change mean to current users of realm and their end-user 
> device configuration?
>
> Thanks in advance for all, who might assist us.
> Arthur Petrosyan
>
>
> 2021-10-01 17:16, Paul Dekkers пишет:
>
> Hi,
>
> Op 01-10-2021 om 13:27 schreef Arthur Petrosyan:
>
> Hi all,
>
> On my "Poco X3" smartphone with "Android 11RKQ1.200826.002"
> I can connect to eduroam by downloading the profile for "Fundamental
> Scientific Library NAS RA" from "cat.eduroam.org"
> and installing it using "eduroam CAT" app from Google playstore.
> But when I try to connect using "geteduroam" app, it don't work, and the
> freeradius logs show the following:
>
> Fri Oct  1 14:49:54 2021 : ERROR: (6750) eap_ttls: ERROR: TLS Alert
> read:fatal:internal error
> Fri Oct  1 14:49:54 2021 : Auth: (6750) Login incorrect (eap_ttls: TLS
> Alert read:fatal:internal error): [***@flib.sci.am] (from client ***
> port 0 cli 10-3F-44-FA-80-D7)
>
> I tried to connect with the same account using "geteduroam" on Windows
> and it worked without problem, so I guess the issue is specific for
> Android.
> I remember several discussions here in the list regarding Android issues
> with "geteduroam", but not sure if it's related to this.
>
> Can it be related specifically to our CAT profile (we use only TTLS/PAP
> there)?
> Is there a fix for it ?
>
> I would be very thankful for help !
>
> You seem to be using a private CA (in fact, there is no CA the entire
> certificate is self signed). One issue is likely that you have no
> subjectAltName DNS: entry with your hostname, and the geteduroam
> installer expects that.
>
> By the looks of it, it also doesn't have the server auth purpose, and is
> a CA by the constraints flag - that may not be a problem.
>
> You probably noticed the warning about the certificate on Windows when
> installing a private CA? Keep in mind your CA needs proper protection.
> That's a bit more challenging if this is also your server certificate,
> in that you cannot store it offline but it's always online.
>
> A private CA is risky in the sense that it can be abused to sign
> certificates for other purposes, other websites too. For instance for
> google.com, and thus IF your CA is abused, it can be used for a
> man-in-the-middle for any normally by SSL protected traffic.
> Using a certificate from a public CA is a bit more on the safer side in
> this case, and they tick all the boxes from what is expected in a
> certificate.
>
> Regards,
> Paul
> To unsubscribe, send this message: 
> mailto:sympa AT lists.geant.org?subject=unsubscribe%20cat-users
> Or use the following link: 
> https://lists.geant.org/sympa/sigrequest/cat-users
>
> To unsubscribe, send this message: 
> mailto:sympa AT lists.geant.org?subject=unsubscribe%20cat-users
> Or use the following link: 
> https://lists.geant.org/sympa/sigrequest/cat-users
>
> To unsubscribe, send this message: 
> mailto:sympa AT lists.geant.org?subject=unsubscribe%20cat-users
> Or use the following link: 
> https://lists.geant.org/sympa/sigrequest/cat-users