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

[Stefan Winter <stefan.winter AT restena.lu>]

Hello,

      so I tested the new geteduroam App for a while now - while I am
      not entirely sure, if it the best idea to apply the configured
      (alt)subject-match to the new domain-field (subdomains) - it works
      quite well.

I've looked into this a bit and this seems to be confusing wording on the side of Android/wpa_supplicant to use the term "domain" for that particular input field.

TL;DR: never mind, it just works.

The longer story:

Server names in X.509 certificates can be in the Subject/CN, or a subjectAltName:DNS extension, or both. ("Both" is the strongly suggested variant for best compatibility). Note that there is NO property in a certificate called "domain" of any sorts.

The various EAP types have some guidance on which of the two options for placing a name into to look at. Most specify to look into both the CN or the subjectAltName:DNS. Some, like TEAP, strictly specify to look ONLY into subjectAltName:DNS. No EAP type speaks of a domain of any sorts, because that property does not exist in a certificate.

Now let's look at Android API. This is, to be euphemistic, "historically grown". There are three distinct API calls to configure expected server names.

* By the time eduroamCAT was written, only the oldest, setSubjectMatch, existed. It looks into the *Subject* exclusively (i.e. the CN) https://developer.android.com/reference/android/net/wifi/WifiEnterpriseConfig#setSubjectMatch(java.lang.String)

* That method is deprecated since API level 23, with the suggested replacement setAltSubjectMatch. It looks into, attention, subjectAltName exclusively (it is not a means to specify an "alternative subject" as the word ordering in the name suggests!). This is the method geteduroam uses https://developer.android.com/reference/android/net/wifi/WifiEnterpriseConfig#setAltSubjectMatch(java.lang.String)

* With the advent of Passpoint, the Passpoint specifications made it more explicit that both CN and subjectAltName:DNS are to be considered acceptable (making none of the previous API calls fit for purpose). wpa_supplicant has a "domain_suffix_match" parameter for that, so Android added the API behaviour to check against both CN and sAN:DNS via one single call. And they baptised it the "domain suffix match" check
https://developer.android.com/reference/android/net/wifi/WifiEnterpriseConfig#setDomainSuffixMatch(java.lang.String)

If you check the link above, you probably wouldn't believe me because the setDomainSuffixMatch function description doesn't speak about where to look for the server name. It only talks about this call being needed for Hotspot 2.0 / Passpoint (which is misleading, it is useful all across WPA-Enterprise). But that's because the function description copy&pastes from wpa_supplicant's domain_suffix_match parameter documentation but VERY UNHELPFULLY stops the paste just before the interesting bits come. If you look at the full definition for the parameter in wpa_supplicant, you will find that the function description goes on to say:

"

          # Constraint for server domain name. If
            set, this FQDN is
        
        
        
      
    
    
      
        
          # used as a suffix match requirement for
            the AAAserver certificate in
        
        
        
      
    
    
      
        
          # SubjectAltName dNSName element(s). If a
            matching dNSName is found, this
        
        
        
      
    
    
      
        
          # constraint is met. If no dNSName
              values are present, this constraint is
           
         
        
      
    
    # matched against SubjectName CN using same suffix match
      comparison.

"

It looks like the non-API input field you get in latest Android UI will take the servername and feed it into that last "setDomainSuffix" variant, which effectively means the supplicant will look for a server name match both in CN and sAN:DNS. geteduroam however will call setAltSubjectMatch, which will make the supplicant only check on subjectAltNames.

As mentioned above, our suggestion both on the eduroam Wiki and the CAT realm checks is, for many years now, to have the server name in both the Subject/CN and subjectAltName:DNS. If you follow that suggestion in your server cert, all is well.

Only if you do not, and have the server name exclusively in the Subject/CN then a manual configuration would authenticate the server, while using geteduroam would not.

Greetings,

Stefan Winter

      I hope the update for limiting the MIME-Types will come in soon,
      as I can not make the change public to our users as long as this
      'well not a bug but actually a bug' is fixed. Until then Android
      11 stays on not supported for now...
      
      
      PS: You may want to fine tune the search a bit, searching for
      'Universität/University [NAME]' offers not only the 100% match,
      but also every other 'Universität/University...
      
      
      Greetings
      
      
      Lukas
      
      
      --
      
      Lukas Wringer
      
      
      Universität Augsburg
      
      Rechenzentrum
      
      Service & Support
      
      86135 Augsburg