I have seen this but I do not see that on ,y iPad
In Certificate Trust Settings on my iPad I see this:
There is no: "Enable full trust for root certificates,"
I have seen this but I do not see that on ,y iPad
In Certificate Trust Settings on my iPad I see this:
There is no: "Enable full trust for root certificates,"
I got a copy of the PEM for the certificate, emailed it to the iPad, amd installed it via settings.
I still do not see it as above such that I can utilise it
What is your final goal here?
It sounds like you’re trying to configure your iPad so that it can talk to a test server, in which case I recommend that you follow the advice in QA1948 HTTPS and Test Servers. That is:
Don’t create a self-signed certificate for the server itself.
But instead create a certificate authority (CA) and have it issue a certificate for the server.
That way you can install the CA’s root in the standard way.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
My goal? I have a customer who insists on using a self signed certificate.
I want to be able to install it on their iPad (and mine) so they (and I) can access their server using HTTPS.
Potentially this will be a private (as in not connected to the Internet) Wifi network.
I have a customer who insists on using a self signed certificate.
A customer of your app?
Using a self-signed leaf certificate puts you far off the well-trodden path, and it’s something I actively recommend against. It’s hard to say for sure without seeing the cert but I suspect that it’s not showing up in Certificate Trust Settings because it’s missing the Basic Constraints extension. A cert needs that in order to be considered a CA cert, which is what that UI is all about.
The fix is to re-issue the cert with that extension. But if you’re going to do that then it makes more sense to create a CA and have it issue the server certificate. That puts you back on well-trodden path.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
Thank you for your attention
Using a self-signed leaf certificate puts you far off the well-trodden path, and it’s something I actively recommend against
This is a private network. AFAIK it is not possible to use an established authority to sign a certificate for an internal network. It is not connected to the public Internet. It must be secure as it is transmitting sensitive data over a shop floor
We could enable HTTP for the APP NSAllowsArbitraryLoads but that causes other problems. (We could use a VPN to secure the data, but it would limit how we install the app on the device.)
This is a private network. AFAIK it is not possible to use an established authority to sign a certificate for an internal network.
Right. That’s not what I was suggesting. Rather, my suggestion was that the customer set up their own CA and install it root certificate on the device.
In your [other thread][ref] you wrote:
Using the self-signed certificate root is causing some of our customers conniptions.
That’s understandable, because it represents a significant extension of trust. However, they are painting themselves into a corner here:
They can’t use a trusted CA because of their private network.
They don’t want to install a custom CA.
iOS won’t let them trust a self-signed certificate without the Basic Constraints extension.
Adding that extension effectively creates a custom CA.
I can only see two ways out of this. The first is for the customer to get on board with running their own CA. This is standard practice for enterprises that run private networks. It offers a world of benefits, not least of which is that they don’t have to request that every software vendor jump through hoops to run on their network.
I should stress that you don’t need to be involved in this. The customer owns the CA and can protect its private key appropriately. They then install the CA’s root certificate on their device using their standard management tools. Your app just opens a TLS connection like any other app would.
The alternative is that you customise your app to allow for trust evaluation overrides. I recommend against this because any mistake in your code could introduce a security vulnerability, so you’re writing extra code and making your other customers less secure
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
I can only see two ways out of this. The first is for the customer to get on board with running their own CA. This is standard practice for enterprises that run private networks. It offers a world of benefits, not least of which is that they don’t have to request that every software vendor jump through hoops to run on their network.
This is good. We have a conclusion.
Our customer has themselves confused running their own CA, but they do it. They literally lost track of which root certificate is for what This is a large corporation for where it is in a modern Western (albeit small) country, so they should pull their socks up! But that is not a business like approach for me to take. I will find a way.
But I can see the way this must be done:
This is what I thought, but I am not a specialist in this (TLS and OpenSSL) so we talked past each other a bit.
Thank you for your help, it was invaluable! Be pleased!!