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

[Martin Pauly <pauly AT hrz.uni-marburg.de>]

Hi Patrick,

Am 13.08.21 um 16:17 schrieb Patrick Oberli:
> but our CA is giving us a hard time offering the same certificate for 
> multiple servers.
hm, this maybe misunderstanding #1.
Just don't ask two certs from your CA. Ask for one, copy the public and 
private key files to the redundant server(s).
Your CA _may_ check that the server name exists as an FQDN in the DNS, so you 
can create one.

BTW: Not all commenters have seen that we are _only_ talking about layer 2 
auth, no DNS involved in the process, and no radsec.
Alan Buxey and I are following the cited eduroam document.
The client's _only_ clue to the servername to expect (and check for) is what 
you explicitly tell in the supplicant configuration.

Which brings us to maybe
> But I didn't realize that the client doesn't actually validate the content of 
> the certificate (the server names provided) besides checking if it's always 
> the same one and maybe from a trusted CA.
misunderstanding #2:
The client (layer2, supplicant) MUST check the contents of the server cert.
It MUST be configured to verify
- the server cert is signed by the CA's root cert (often involving one or two 
intermediates) AND
- the server cert contains the correct server name (CN)

The server name is included in the signature process, so any tampering
would render the cert invalid. The client MUST accept the cert only, if both 
criteria are met.
With the client configured like this, you have the cert pinned.

The perhaps confusing difference to Web/IMAP/etc. and other Layer 3 clients 
is that
these technically do the same kind of check, but apply the rules in a much 
more liberal way:
- Accept any PKI whose root cert is in /etc/ssl/certs (or its 
Windows/MacOS/Whatever equivalent)
- Infer the server name to check for from the HTTP/IMAP/etc. request the user 
has issued,
  not from some predefined config

A web browser does a check, but will talk to many different websites when in 
normal use (cert not pinned).
OTOH, when pulling updates from its manufacturer, it may make a lot of sense 
to be strict and pin the cert
to one well-known CA and one pre-configured server name.

Kind regards
Martin

--
  Dr. Martin Pauly     Phone:  +49-6421-28-23527
  HRZ Univ. Marburg    Fax:    +49-6421-28-26994
  Hans-Meerwein-Str.   E-Mail: pauly AT HRZ.Uni-Marburg.DE
  D-35032 Marburg