iOS doesn't trust server certificate signed by intermediate issuer
Hi, My institution generated our server certificate by GlobalSign, but we received a server certificate signed by an intermediate issuer, an intermediate issuer. We receveid the server, intermediate and root certificates files. I created a bundle with intermediate and root certificates, in this order an. I configured the /etc/freeradius/mods-enabled/eap as below: private_key_file = <path for server private key that I created> certificate_file = <new path for server.pem received from GlobalSign> ca_file = <path to ca.bundle obtained by cat intermediate.pem >> ca.bundle and cat root.pem >> ca.bundle> I run freeradius service with no issues as well as Android validates server certificate. When I tested the iOS connection the device showed me the server certificate as Not Trusted. I verified server certificate information and it is correct. If I click on the Trust button on the device screen, I can authenticate on Freeradius server with no issues. Is this behavior right? Doesn't iOS trust in server certificate signed by an intermediate chain? -- Igor Sousa
On Dec 3, 2020, at 4:01 PM, Igor Sousa <igorvolt@gmail.com> wrote:
My institution generated our server certificate by GlobalSign, but we received a server certificate signed by an intermediate issuer, an intermediate issuer. We receveid the server, intermediate and root certificates files.
That should work. Mostly. :(
I created a bundle with intermediate and root certificates, in this order an. I configured the /etc/freeradius/mods-enabled/eap as below: private_key_file = <path for server private key that I created> certificate_file = <new path for server.pem received from GlobalSign> ca_file = <path to ca.bundle obtained by cat intermediate.pem >> ca.bundle and cat root.pem >> ca.bundle>
I run freeradius service with no issues as well as Android validates server certificate. When I tested the iOS connection the device showed me the server certificate as Not Trusted. I verified server certificate information and it is correct. If I click on the Trust button on the device screen, I can authenticate on Freeradius server with no issues.
Is this behavior right? Doesn't iOS trust in server certificate signed by an intermediate chain?
iOS doesn't trust _any_ server certificate by default. Authentication isn't web surfing. When you go to https://google.com, you're interested in knowing if it is really "google.com". The certificate presented by google says so, and is signed by a global CA. However, you don't really care what data you get from Google. So web browsers are configured to accept any certificate, signed by any known root CA. For EAP, you *do* care about the server certificate. Anyone can get a cert from Globalsign, so anyone can present a signed server cert. So... do you want your name and password sent to some random person who paid $100 for a certificate? No? For security, iOS doesn't trust *any* certificate. All 802.1X clients should behave this way. But Android doesn't, likely for ease of use. Which means it's relatively easy to do nothing, and have your credentials go to a random server. In short: yes, this is what's supposed to happen. Alan DeKok.
On Thu, Dec 03, 2020 at 04:22:52PM -0500, Alan DeKok wrote:
For security, iOS doesn't trust *any* certificate. All 802.1X clients should behave this way. But Android doesn't, likely for ease of use. Which means it's relatively easy to do nothing, and have your credentials go to a random server.
Hmm, I was at a coworking space some time ago and they had an EAP/PEAP secured network there. Just out of curiosity I tried to log in with my macbook (latest mac os) and to my surprise I did *not* get a certificate warning. I concluded that for probably a bit more money you could get certificates that are accepted by default by supplicants, but I didn't check further. Could this be so? HC
On Dec 4, 2020, at 3:59 AM, Hans-Christian Esperer <hc@hcesperer.org> wrote:
On Thu, Dec 03, 2020 at 04:22:52PM -0500, Alan DeKok wrote:
For security, iOS doesn't trust *any* certificate. All 802.1X clients should behave this way. But Android doesn't, likely for ease of use. Which means it's relatively easy to do nothing, and have your credentials go to a random server.
Hmm, I was at a coworking space some time ago and they had an EAP/PEAP secured network there. Just out of curiosity I tried to log in with my macbook (latest mac os) and to my surprise I did *not* get a certificate warning. I concluded that for probably a bit more money you could get certificates that are accepted by default by supplicants, but I didn't check further. Could this be so?
I've never heard of that. I doubt that OSX works that way. What perhaps happened is that the cert was from a CA you already trusted? Alan DeKok.
On Fri, Dec 04, 2020 at 08:58:37AM -0500, Alan DeKok wrote:
On Dec 4, 2020, at 3:59 AM, Hans-Christian Esperer <hc@hcesperer.org> wrote:
On Thu, Dec 03, 2020 at 04:22:52PM -0500, Alan DeKok wrote:
For security, iOS doesn't trust *any* certificate. All 802.1X clients should behave this way. But Android doesn't, likely for ease of use. Which means it's relatively easy to do nothing, and have your credentials go to a random server.
Hmm, I was at a coworking space some time ago and they had an EAP/PEAP secured network there. Just out of curiosity I tried to log in with my macbook (latest mac os) and to my surprise I did *not* get a certificate warning. I concluded that for probably a bit more money you could get certificates that are accepted by default by supplicants, but I didn't check further. Could this be so?
I've never heard of that. I doubt that OSX works that way.
What perhaps happened is that the cert was from a CA you already trusted?
I do have my own CAs on trust, but I am certain that this network wasn't run by me and they didn't use any of my certificates. Unfortunately I don't have the certificate handy right now, so I cannot say anything else about this at this time. When I get a chance to go to that colab space again I'll check it. HC
Hi So long as ios has the ca and intermediate then it can trust your server cert. If it doesn't have the intermediate but has the root CA, then you can send intermediate along with the server cert. However, for trust, you need to ensure that ios knows to trust that server. Hence it asks you about things... fingerprint etc To avoid this, and best practice is to configure the ios device with a network profile. Usually done with eg MDM software alan On Thu, 3 Dec 2020, 21:02 Igor Sousa, <igorvolt@gmail.com> wrote:
Hi, My institution generated our server certificate by GlobalSign, but we received a server certificate signed by an intermediate issuer, an intermediate issuer. We receveid the server, intermediate and root certificates files.
I created a bundle with intermediate and root certificates, in this order an. I configured the /etc/freeradius/mods-enabled/eap as below: private_key_file = <path for server private key that I created> certificate_file = <new path for server.pem received from GlobalSign> ca_file = <path to ca.bundle obtained by cat intermediate.pem >> ca.bundle and cat root.pem >> ca.bundle>
I run freeradius service with no issues as well as Android validates server certificate. When I tested the iOS connection the device showed me the server certificate as Not Trusted. I verified server certificate information and it is correct. If I click on the Trust button on the device screen, I can authenticate on Freeradius server with no issues.
Is this behavior right? Doesn't iOS trust in server certificate signed by an intermediate chain?
-- Igor Sousa - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
DeKok and Buxey thanks for your help. DeKoK, I was thinking this is a default behavior, but I didn't get it the reason. Your explanation elucidates my issue. After I sent my question to Freeradius list, I've tested it on Windows and its behavior has been like iOS. Thanks again for your help. -- Igor Sousa Em qui., 3 de dez. de 2020 às 18:42, Alan Buxey <alan.buxey@gmail.com> escreveu: > Hi > > So long as ios has the ca and intermediate then it can trust your server > cert. If it doesn't have the intermediate but has the root CA, then you > can send intermediate along with the server cert. > > However, for trust, you need to ensure that ios knows to trust that > server. Hence it asks you about things... fingerprint etc > > To avoid this, and best practice is to configure the ios device with a > network profile. Usually done with eg MDM software > > > alan > > On Thu, 3 Dec 2020, 21:02 Igor Sousa, <igorvolt@gmail.com> wrote: > > > Hi, > > My institution generated our server certificate by GlobalSign, but we > > received a server certificate signed by an intermediate issuer, an > > intermediate issuer. We receveid the server, intermediate and root > > certificates files. > > > > I created a bundle with intermediate and root certificates, in this order > > an. I configured the /etc/freeradius/mods-enabled/eap as below: > > private_key_file = <path for server private key that I created> > > certificate_file = <new path for server.pem received from GlobalSign> > > ca_file = <path to ca.bundle obtained by cat intermediate.pem >> > ca.bundle > > and cat root.pem >> ca.bundle> > > > > I run freeradius service with no issues as well as Android validates > server > > certificate. When I tested the iOS connection the device showed me the > > server certificate as Not Trusted. I verified server certificate > > information and it is correct. If I click on the Trust button on the > device > > screen, I can authenticate on Freeradius server with no issues. > > > > Is this behavior right? Doesn't iOS trust in server certificate signed by > > an intermediate chain? > > > > -- > > Igor Sousa > > - > > List info/subscribe/unsubscribe? See > > http://www.freeradius.org/list/users.html > - > List info/subscribe/unsubscribe? See > http://www.freeradius.org/list/users.html
On 03/12/2020 21:01, Igor Sousa wrote:
I created a bundle with intermediate and root certificates, in this order an. I configured the /etc/freeradius/mods-enabled/eap as below: private_key_file = <path for server private key that I created> certificate_file = <new path for server.pem received from GlobalSign> ca_file = <path to ca.bundle obtained by cat intermediate.pem >> ca.bundle and cat root.pem >> ca.bundle>
That's not right, unless you are using EAP-TLS and want anyone with a certificate generated by GlobalSign to be able to authenticate. private_key_file should be a .pem file with the private key. certificate_file should be a .pem file containing the server certificate and the intermediate certificate, in that order. Don't set ca_file at all. Don't put the GlobalSign root CA in any of the files. The clients have that already to check that the server cert is genuine. -- Matthew
participants (5)
-
Alan Buxey -
Alan DeKok -
Hans-Christian Esperer -
Igor Sousa -
Matthew Newton