Skip to Content.
Sympa Menu

cat-users - Re: [cat-users] CAT with iPhone/iPad and older Macs

cat-users AT lists.geant.org

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

List archive

Re: [cat-users] CAT with iPhone/iPad and older Macs


Chronological Thread 
  • From: Brian Epstein <bepstein AT ias.edu>
  • To: Stefan Winter <stefan.winter AT restena.lu>
  • Cc: cat-users AT geant.net
  • Subject: Re: [cat-users] CAT with iPhone/iPad and older Macs
  • Date: Wed, 09 Oct 2013 09:10:49 -0400
  • List-archive: <https://mail.geant.net/mailman/private/cat-users/>
  • List-id: "The mailing list for users of the eduroam Configuration Assistant Tool \(CAT\)" <cat-users.geant.net>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Stefan,

Yes, it definitely seems like the issue is surrounding this. I was
using this CN as we have multiple radius servers. I guess it doesn't
really matter, as radius clients probably aren't checking the CN
versus the FQDN.

I looked up the Apple Spec on this field and found it here.

https://developer.apple.com/library/ios/featuredarticles/iPhoneConfigurationProfileRef/Introduction/Introduction.html

"TLSTrustedServerNames - Optional. This is the list of server
certificate common names that will be accepted. You can use wildcards
to specify the name, such as wpa.*.example.com. If a server presents a
certificate that isn't in this list, it won't be trusted.

Used alone or in combination with TLSTrustedCertificates, the property
allows someone to carefully craft which certificates to trust for the
given network, and avoid dynamically trusted certificates.

Dynamic trust (the certificate dialogue) is disabled if this property
is specified, unless TLSAllowTrustExceptions is also specified with
the value true."

I tried using wildcards in the place of spaces, or just a "*" for the
whole field. This isn't working. My guess is that this works much
like wildcard certificates, where a single "*" will only replace that
part of the FQDN, but won't go beyond a period. Either way, I think
your analysis is correct, something is non standard with the Apple
supplicant.

I will recreate the certificate with a proper FQDN and see how that
works out.

Thanks again for your help,
Brian

On 10/09/2013 09:00 AM, Stefan Winter wrote:
> Hi,
>
>> When comparing the two files, I realized I had forgotten the
>> "TLSTrustedServerNames" section in my file. I added it to the
>> iPhone configuration utility "IAS Radius Server Certificate" and
>> it is now failing. I'm going to try to play around with this to
>> see if I can figure out why this is failing.
>
> Ah! It's indeed slightly unusual to have an end entity certificate
> which does not have in its CN a fully-qualified domain name. Don't
> get me wrong - this is perfectly fine PKI-wise and a bug-free
> supplicant would not have issues with this at all.
>
> That said, I'm not really sure if iOS is a bug-free supplicant :-)
>
> Is it possible for you to test with a new certificate which has a
> CN which is/looks like a valid fully-qualified domain name?
>
> If it works at that point, then we have a pretty good indication
> that there is indeed an issue with iOS and the names it allows in
> the CN.
>
> This is then not strictly a CAT issue though; but we can update our
> list of caveats on the "EAP Server Certificate Considerations" page
> for everybody's benefit. The list is getting rather long as of
> recent :-/
>
> Greetings,
>
> Stefan Winter
>



- --
Brian Epstein
<bepstein AT ias.edu>
+1 609-734-8179
Manager, Network and Security Institute for Advanced Study
Key fingerprint = 128A 38F4 4CFA 5EDB 99CE 4734 6117 4C25 0371 C12A
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlJVVdkACgkQYRdMJQNxwSpNbgCdHj5oSZNUXndeZ2V0EkYZLqzp
ggIAn3PeclUO3NPuNKVKttCxDM9UoxSk
=Hhu0
-----END PGP SIGNATURE-----

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature




Archive powered by MHonArc 2.6.19.

Top of Page