I am getting following error with self signed certificate
Error Domain=NSURLErrorDomain Code=-1200 "An SSL error has occurred
and a secure connection to the server cannot be made.
while testing web-services for one of my demo app with
- iOS 9.3
- XCode 7.3
- Swift 2.2
- Alamofire 3.3.0
- and Local server : https://filename.hostname.net
Note: before assuming its Duplicate, I would request please read it all the way,even same i have reported to apple dev forums
Using Alamofire Library
func testAlamofireGETRequest() -> Void
{
Alamofire.request(.GET, "https://filename.hostname.net/HelloWeb/service/greeting/john")
.responseJSON
{ response in
print("Response JSON: \(response.result.value)")
}
}
Using NSURLSession
func testNSURLSessionRequest() -> Void {
let session = NSURLSession.sharedSession()
let urlString = "https://filename.hostname.net/HelloWeb/service/greeting/john"
let url = NSURL(string: urlString)
let request = NSURLRequest(URL: url!)
let dataTask = session.dataTaskWithRequest(request) { (data:NSData?, response:NSURLResponse?, error:NSError?) -> Void in
print("done, error: \(error)")
//Error Domain=NSURLErrorDomain Code=-1200 "An SSL error has occurred and a secure connection to the server cannot be made.
}
dataTask.resume()
}
I spent 2 days with no luck :(
there are bunch of questions already posted but nothing worked for me
- Transport Security has Blocked a cleartext HTTP
- iOS9 getting error “an ssl error has occurred and a secure connection to the server cannot be made”
- How do I load an HTTP URL with App Transport Security enabled in iOS 9? [duplicate]
- CFNetwork SSLHandshake failed iOS 9
- How to handle “CFNetwork SSLHandshake failed” in iOS
- Making HTTPS request in iOS 9 with self-signed certificate
- ios9 self signed certificate and app transport security
posted Alamofire git issue
- 'CFNetwork SSLHandshake failed (-9847)' error when performing a non-SSL request #538
- Self-Signed Certificate not accepted #876
- how can I connecting my server as HTTPS with using self-signed Certificate file #977
My Info.pist file is updated for ATS settings this way
<key>NSAppTransportSecurity</key>
<dict>
<key>NSExceptionDomains</key>
<dict>
<key>filename.hostname.net</key>
<dict>
<key>NSExceptionRequiresForwardSecrecy</key>
<false/>
<key>NSExceptionAllowsInsecureHTTPLoads</key>
<true/>
<key>NSIncludesSubdomains</key>
<true/>
<key>NSTemporaryExceptionAllowsInsecureHTTPLoads</key>
<true/>
</dict>
</dict>
</dict>
Meanwhile I am able to get response for
http://filename.hostname.net
and https://google.com
but not for https://filename.hostname.net
Can anyone please suggest me why I am not able to get this working after huge efforts?
At the command-line in OS X, run the following:
nscurl --ats-diagnostics https://filename.hostname.net --verbose
This will tell you what combinations of ATS settings will and will not permit iOS to access your site, and should point you towards what is wrong with your site.
It could be one or more of the following
- Certificate hash algorithm (must be SHA-256 or above)
- TLS version (must be 1.2)
- TLS algorithms (must provide Perfect Forward Secrecy)
Apple has released the full requirements list for the App Transport Security.
Turned out that we were working with TLS v1.2 but were missing some of the other requirements.
Here's the full check list:
- TLS requires at least version 1.2.
- Connection ciphers are limited to those that provide forward secrecy (see below for the list of ciphers.)
- The service requires a certificate using at least a SHA256 fingerprint with either a 2048 bit or greater RSA key, or a 256bit or greater Elliptic-Curve (ECC) key.
- Invalid certificates result in a hard failure and no connection.
- The accepted ciphers are:
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
I presume the server you are trying to connect has invalid certificates or doesn't match up with the iOS 9 standards for ECC, Ciphers etc.
If you’re using high-level networking APIs—NSURLSession, NSURLConnection, or anything layered on top of those—you don’t have direct control over the cypher suites offered by the client. Those APIs choose a set of cypher suites using their own internal logic.
If you’re using lower-level networking APIs—CFSocketStream, via its NSStream and CFStream APIs, and anything lower than that—you can explicitly choose the set of cypher suites you want to use. How you do this depends on the specific API.
The standard practice is:
create the stream pair
configure it for TLS
get the Secure Transport context using the kCFStreamPropertySSLContext property
configure specific properties in that context
open the streams
You can see an example of this in the TLSTool sample code. Specifically, look at the TLSToolServer class, where you can see exactly this sequence.
In a very short context, you want to configure the stream in such a way that it bypasses the security, however, in the case of Alamofire you can do this directly by:
func bypassAuthentication() {
let manager = Alamofire.Manager.sharedInstance
manager.delegate.sessionDidReceiveChallenge = { session, challenge in
var disposition: NSURLSessionAuthChallengeDisposition = .PerformDefaultHandling
var credential: NSURLCredential?
if challenge.protectionSpace.authenticationMethod == NSURLAuthenticationMethodServerTrust {
disposition = NSURLSessionAuthChallengeDisposition.UseCredential
credential = NSURLCredential(forTrust: challenge.protectionSpace.serverTrust!)
} else {
if challenge.previousFailureCount > 0 {
disposition = .CancelAuthenticationChallenge
} else {
credential = manager.session.configuration.URLCredentialStorage?.defaultCredentialForProtectionSpace(challenge.protectionSpace)
if credential != nil {
disposition = .UseCredential
}
}
}
return (disposition, credential)
}
}
let me know if that helps.
Thank you!
I had same scenario and got stuck for a day. Try with your mobile data, if this works fine with your API, then problem with your network firewall. then enable SSL / TLS from firewall settings.