iOS 11 simulator problems with private CA - ios

I am running a Tomcat server to develop and test a native iOS app. The server is presenting a certificate signed with a private CA. This is Apple's recommendation for test servers rather than using self-signed certificates. I have tested the certificate at sslshopper.com and it shows that the certificate has a CA chain. The root CA certificate has been installed on the simulator.
Initially, without any ATS exceptions, my app gives me the following:
The error is the usual:
NSURLSession/NSURLConnection HTTP load failed (kCFStreamErrorDomainSSL, -9802)
This error is usually the result when the app encounters a self-signed certificate. As I said above, the certificate is not self-signed.
After adding an exception domain to the app's plist, I get this:
This is usually what we see for certificates with an invalid CN. I have verified that the CN is correct in the certificate.
The error is :
NSURLSession/NSURLConnection HTTP load failed (kCFStreamErrorDomainSSL, -9813)
I couldn't find the error in the Apple docs and finally had to resort to looking it up in the header file. It is as follows:
errSSLNoRootCert = -9813, /* cert chain not verified by root */
Since the chain is present and the root certificate is installed on the simulator, I'm not sure what this error means. I did notice when installing the root certificate that it would not be usable until it was enabled in the Certificate Trust Settings, but the only live content on that pane in the simulator is a link to the Apple developers site. I went to my test site in Safari and was able to access it after confirming the certificate exception. The root certificate profile says that it is verified (green checkmark).
Any help is appreciated.

This ended up being a bug in the iOS certificate manager. The root certificate did not have a CN, which is optional. The CN in the root is not used for any part of the verification function. The lack of the CN was confusing the cert manager and it didn't display it in the certificate management panel. One of the Apple Developer SMEs has filed a bug report.

You need to browse the link within the internal network if you are using internal CA certificate/Private certificate. Anyone browsing from external network he should have the root and the intermediate certificate installed on his/her browser
Also, different browsers and operating system have different procedures. For example, Chrome takes the trust store of the operating system (with the exception of EV certificates) as seen on the Root CA Policy of chromium.

Related

What is the correct way to trust a self-signed certificate in iOS 10.3.3?

This is specific to 10.3.3. The option to trust the certificate under "Certificate Trust Settings" is no longer available to me (it was post-10.3 and pre-10.3.3). I reset my simulator and didn't realise this was an issue.
The server and certificate chain fully passes nscurl --ats-diagnostics <url>. The profile and certificate is installed on the device, and is verified. It contains the correct v3 required extensions, and is not SHA-1 (or other archaic options).
I can browse to the server with Safari (after the initial "verify" alert). Does anyone know what has changed in 10.3.3 and its certificate handling?
Edit: Rebuilding the certs is not a concern if required.

iOS 11, 12, and 13 installed certificates not trusted automatically (self signed)

On our internal network, we use a self-signed CA certificate. This has worked fine for years, in both Safari and our iOS product, all the way through iOS 10. We simply install the CA certificate on any new device or simulator and everything works, even with ATS. This allows access to all of our internal test servers without having to trust each server individually.
Starting with iOS 11 the installed CA certificate no longer allows Safari or our app to trust the certificate for any of the servers. We receive the following relevant details with CFNETWORK_DIAGNOSTICS enabled for our app:
Error Domain=kCFErrorDomainCFNetwork Code=-1200
_kCFNetworkCFStreamSSLErrorOriginalValue=-9802
_kCFStreamErrorDomainKey=3
_kCFStreamErrorCodeKey=-9802
NSLocalizedDescription=An SSL error has occurred and a secure connection to the server cannot be made.
NSLocalizedRecoverySuggestion=Would you like to connect to the server anyway?
I spent considerable time trying to resolve this issue, scouring StackOverflow and the rest of the web. Although we use AFNetworking in our app, that seems to be irrelevant, as Safari no longer trusts these servers via the CA. Disabling ATS via NSAllowsArbitraryLoads allows access to the servers, but obviously isn't a solution.
No changes have been made to our -URLSession:didReceiveChallenge:completionHandler code, and we have a proper (worked for years) implementation of challenge response via challenge.protectionSpace.serverTrust.
I have re-evaluated and tested both the CA and server certificates every way I can think of, and they work everywhere except iOS 11. What might have changed in ATS for iOS 11 that could cause this issue?
While writing this question, I discovered the answer. Installing a CA from Safari no longer automatically trusts it. I had to manually trust it from the Certificate Trust Settings panel (also mentioned in this question).
I debated canceling the question, but I thought it might be helpful to have some of the relevant code and log details someone might be looking for. Also, I never encountered the issue until iOS 11. I even went back and reconfirmed that it automatically works up through iOS 10.
I've never needed to touch that settings panel before, because any installed certificates were automatically trusted. Maybe it will change by the time iOS 11 ships, but I doubt it. Hopefully this helps save someone the time I wasted.
If anyone knows why this behaves differently for some people on different versions of iOS, I'd love to know in comments.
Update 1: Checking out the first iOS 12 beta, it looks like things remain the same. This question/answer/comments are still relevant on iOS 12.
Update 2: Same solution seems to be needed on iOS 13 beta builds as well.
I've been struggling with this for 3 days now while attempting to connect to a local API running Laravel valet. I finally figured it out. In my case I had to drag and drop over the LaravelValetCASelfSigned.pem file from ~/.config/valet/CA/LaravelValetCASelfSigned.pem
After verifying the installing within the simulator I had to go to Settings > About > Certificate Trust Settings > and Enable the Laravel Valet VA Self Signed CN
Finally working!!!
Recommended solution is to install and trust a self-signed certificate (root). Assuming you created your own CA and the hierarchy of the certificated is correct you don't need to change the server trust evaluation. This is recommended because it doesn't require any changes in the code.
Generate CA and the certificates (you can use openssl: Generating CA and self-signed certificates.
Install root certificate (*.cer file) on the device - you can open it by Safari and it should redirect you to Settings
When the certificated is installed, go to Certificate Trust Settings (Settings > General > About > Certificate Trust Settings) as in MattP answer.
If it is not possible then you need to change server trust evaluation.
More info in this document: Technical Q&A QA1948 HTTPS and Test Servers
This has happened to me also, after undating to IOS11 on my iPhone. When I try to connect to the corporate network it bring up the corporate cert and says it isn't trusted. I press the 'trust' button and the connection fails and the cert does not appear in the trusted certs list.
Apple hand three categories of certificates: Trusted, Always Ask and Blocked. You'll encounter the issue if your certificate's type on the Blocked and Always Ask list. On Safari it show’s like:
And you can find the type of Always Ask certificates on Settings > General > About > Certificate Trust Setting
There is the List of available trusted root certificates in iOS 11
Blocking Trust for WoSign CA Free SSL Certificate G2
If you are not seeing the certificate under General->About->Certificate Trust Settings, then you probably do not have the ROOT CA installed. Very important -- needs to be a ROOT CA, not an intermediary CA.
I just answered a question here explaining how to obtain the ROOT CA and get things to show up: How to install self-signed certificates in iOS 11
I follow all recommendations and all requirements. I install my self signed root CA on my iPhone. I make it trusted. I put certificate signed with this root CA on my local development server and I still get certificated error on safari iOS. Working on all other platforms.

iOS app not working on device after SSL cert expired and renewed

I have an SSL wildcard that my web service uses. My iOS app works with this back end. The certificate expired and my app stopped working.
The SSL is now renewed (godaddy) but my app only works in the simulator. When loaded on an actual device, it's still not liking the SSL.
Here's the error I'm receiving:
NSURLErrorDomain error -1012
How can I fix this and have the device work again with the new SSL?
Thanks for the advice above, but, the fix was needed on the server, as other versions are live now...
so first I checked my certificate was not configured properly on AWS ELB,
the thing is i had to include the certificate chain,
for checking the correct configuration of my SSL I used an app called "SSL detective", and geotrust SSL toolbox,
Now basic cert and cert chain working, no need to change app.

Certificate issue after migrate from HTTP to HTTPS

I am working on mobile HTML5 site using HTML5/JQueryMobile and server is in php. I changed sever settings from HTTP to HTTPS but now from my mobile it shows these type of error
[Error] Failed to load resource: The certificate for this server is invalid. You might be connecting to a server that is pretending to be “www.example.com” which could put your confidential information at risk.
when using in IPhone 5 with IOs 7.1.2.
How to handle that issue. What things i have to do?
For us this happened with the update to iOS 13. The requirements for trusted certificates changed, so we needed to adjust the certificate.
See the official page of Apple
You are using a self-signed certificate. Thus your iPhone doesn't trust your certificate.
Either add the certificate to your iPhone as a trusted certificate. (recommended)
Or create a official certificate from a trusted authority. (recommended for production usage)
Or make requests and allowing insecure (self-signed) certificates. (not really recommended, but might be the fastest solution)

Why is my server certificate being rejected?

I am trying to connect my app to a server using TLS 1.2. The server is using a certificate that has been signed by a self-signed CA certificate that is already installed on the device (I emailed the CA certificate to myself, tapped it. Now it shows up under Settings -> General -> Profiles). This was previously working in my app, but we have changed the CA certificate we're using so I've updated the server's certificate as well. Now I'm getting SSL failures.
The error I'm seeing is errSSLXCertChainInvalid from my call to SSLHandshake on the client. As far as I can tell, the server certificate should be valid. openssl verify -CAfile ca-cert.pem server-cert.pem returns OK, and that ca-cert.pem is the same CA certificate I've installed on the device.
Any ideas? Thanks!
There's some information in apple's documentation regarding this error:
errSSLXCertChainInvalid — The peer has an invalid certificate chain; for example, signature verification within the chain failed, or no certificates were found.
And if you use SSLSetPeerDomainName:
You can use this function to verify the common name field in the peer’s certificate. If you call this function and the common name in the certificate does not match the value you specify in the peerName parameter, then handshake fails and returns errSSLXCertChainInvalid.
I'd suggest uninstalling your device configuration profile, and creating a new one.
Also, it might be a good idea to check if you can access the server without errors from, say, a web browser. This will reveal if there is a problem with the certificate, or just your configuration profile on your iOS device.

Resources