[RADIATOR] iPhones and SSL certificates

[Hirayama, Pat]

Thank you, Heikki!  I will look into your suggestions.

				-p

> -----Original Message-----
> From: Heikki Vatiainen <hvn at open.com.au>
> Sent: Thursday, September 12, 2019 6:20 AM
> To: Hirayama, Pat <phirayam at fredhutch.org>; radiator at lists.open.com.au
> Subject: Re: [RADIATOR] iPhones and SSL certificates
> 
> On 11/09/2019 1.00, Hirayama, Pat wrote:
> 
> > Certificate is presented to iPhone user as "Not trusted".
> >
> > And yes, I know "Not trusted" isn't necessarily an error.  On the
> > other hand, if I train users to just ignore this error, then, they
> > get used to ignoring other warning messages ....
> 
> Yes, I agree with this. When compared to HTTPS, the browser knows the
> name of server it should be talking to; with Wi-Fi, the information
> about expected server certificate has to come from somewhere else.
> 
> > And I don't really have a Mac MDM system to push the cert onto
> > everyone's iPhones -- not that I necessarily want to be touching
> > people's devices.
> 
> To freshen my memory I took a look at what the "Not Trusted" dialog. It
> does show the server name and issuing CA name, but it's hard to tell to
> which root CA the certificate chain leads to. In other words, good
> instructions with screenshots are likely not enough.
> 
> > Any other ideas or suggestions, or am I just going to have to accept
> > that iPhones will just claim "Not trusted"?  I know that if they
> > trust the certificate ... it'll happen again the next time I renew
> > the certificate as well.
> 
> If you do not want to touch, in serviced fashion, people's devices,
> would a self service model with clear instructions with a downloadable
> profile be an option?
> 
> In other words: the profiles created with Apple Configurator 2 are XML
> files that can be made available on a web server. They can even be sent
> by email, but installing profiles from email attchment sounds risky.
> 
> Assuming profiles on web server, Safri launces a dialog for installing a
> profile. The profile must then be separately accepted, so instructions
> would be needed, but there's no need to have the devices physically
> serviced anywhere.
> 
> As an advanced step: Because the profiles are XML, they could be
> generated per user to have a Wi-Fi specific username/password created
> for each user. A colleaque mentioned it would even be possible to embed
> a PKCS12 blob with a certificate and a private key to enable EAP-TLS
> authentication.
> 
> Thanks,
> Heikki
> 
> --
> Heikki Vatiainen <hvn at open.com.au>
> 
> Radiator: the most portable, flexible and configurable RADIUS server
> anywhere. SQL, proxy, DBM, files, LDAP, TACACS+, PAM, Active Directory,
> EAP, TLS, TTLS, PEAP, WiMAX, RSA, Vasco, Yubikey, HOTP, TOTP,
> DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, etc.