When I use ios11 beata 3.0 to do https request(mutual authentication), I get the following error:
2017-07-17 14:58:32.047352+0800 NetDemo[480:120901] [BoringSSL] Function boringssl_session_handshake_error_print: line 3029 boringssl ctx 0x155d3c670: 5734916752:error:1000041b:SSL routines:OPENSSL_internal:TLSV1_ALERT_DECRYPT_ERROR:/BuildRoot/Library/Caches/com.apple.xbs/Sources/boringssl/boringssl-108/ssl/tls_record.c:547:SSL alert number 51
2017-07-17 14:58:32.050702+0800 NetDemo[480:120901] TIC TCP Conn Failed [1:0x1c0179b00]: 3:-9834 Err(-9834)
2017-07-17 14:58:32.051284+0800 NetDemo[480:120901] NSURLSession/NSURLConnection HTTP load failed (kCFStreamErrorDomainSSL, -9834)
2017-07-17 14:58:32.051373+0800 NetDemo[480:120901] HTTP load failed (error code: -1205 [3:-9834]) for Task <6AE1FB36-068B-418B-A794-551AA49204EF>.<1>
2017-07-17 14:58:32.052639+0800 NetDemo[480:120906] Task <6AE1FB36-068B-418B-A794-551AA49204EF>.<1> finished with error - code: -1205
2017-07-17 14:58:32.062215+0800 NetDemo[480:120867] Error Domain=NSURLErrorDomain Code=-1205 "The server “xxxxxxxx” did not accept the certificate." UserInfo={NSURLErrorFailingURLPeerTrustErrorKey=
"
"
), _kCFStreamPropertySSLClientCertificateState=2, kCFStreamPropertySSLPeerTrust=
"
"
), _kCFStreamErrorDomainKey=3, _kCFStreamErrorCodeKey=-9834}}, NSErrorPeerCertificateChainKey=(
"
"
), NSErrorClientCertificateChainKey=(
"
"
), NSLocalizedDescription=The server “xxxxxxx” did not accept the certificate., NSErrorFailingURLKey=xxxxxxx, NSErrorFailingURLStringKey=https:xxxxxxxx, NSErrorClientCertificateStateKey=2}
the same here did you find solution ?
Just an update, I think this is fixed in the latest release iOS 11 beta 5. This is not afnetworking issue.
Still exists after update
any updates ?
I'm experiencing the same issue on iOS 11 beta 9. Has anybody found a workaround?
I have also just filed a bugreport with Apple.
@fifafu can you share your radar number so that I can reference it?
FWIW I was seeing this on an iOS11 simulator, but was able to successfully talk to the service on a physical device running the iOS11 beta. Has anyone seen this behavior on a physical device?
For some details: This occurred while trying to talk to a service for which I have pinned a certificate via a custom subclass of AFSecurityPolicy.
Yes i have device with iOS 11 and appear issue that server not accept certification
I need workaround or any thing make me sure that my cer no longer valid
I'm also experiencing this on a real device.
@michaelkirk I filed it via our apple enterprise portal, thus I don't have a radar number yet
Is the ssl cert for the domain you're trying to reach trusted by the ios default certificate authorities? (You could test this by visiting the URL in safari on that device and seeing if you get a cert error)
Are you using certificate pinning within your app? Or anything else you can think of outside of the SSL happy path?
@sallyahmed could you check what this terminal command outputs for your host:
openssl s_client -connect your-host.com:443 -tls1
What cipher suite does it use? In my case the server uses
Cipher : DHE-RSA-CAMELLIA256-SHA
and I think this may not be supported in iOS 11 anymore.
@fifafu output of command
Can you help me on it , Thanks at all
Output
getservbyname failure for
usage: s_client args
-host host - use -connect instead
-port port - use -connect instead
-connect host:port - who to connect to (default is localhost:4433)
-verify depth - turn on peer certificate verification
-cert arg - certificate file to use, PEM format assumed
-certform arg - certificate format (PEM or DER) PEM default
-key arg - Private key file to use, in cert file if
not specified but cert file is.
-keyform arg - key format (PEM or DER) PEM default
-pass arg - private key file pass phrase source
-CApath arg - PEM format directory of CA's
-CAfile arg - PEM format file of CA's
-reconnect - Drop and re-make the connection with the same Session-ID
-pause - sleep(1) after each read(2) and write(2) system call
-showcerts - show all certificates in the chain
-debug - extra output
-msg - Show protocol messages
-nbio_test - more ssl protocol testing
-state - print the 'ssl' states
-nbio - Run with non-blocking IO
-crlf - convert LF from terminal into CRLF
-quiet - no s_client output
-ign_eof - ignore input eof (default when -quiet)
-no_ign_eof - don't ignore input eof
-ssl2 - just use SSLv2
-ssl3 - just use SSLv3
-tls1 - just use TLSv1
-dtls1 - just use DTLSv1
-fallback_scsv - send TLS_FALLBACK_SCSV
-mtu - set the link layer MTU
-no_tls1/-no_ssl3/-no_ssl2 - turn off that protocol
-bugs - Switch on all SSL implementation bug workarounds
-serverpref - Use server's cipher preferences (only SSLv2)
-cipher - preferred cipher to use, use the 'openssl ciphers'
command to see what is available
-starttls prot - use the STARTTLS command before starting TLS
for those protocols that support it, where
'prot' defines which one to assume. Currently,
only "smtp", "pop3", "imap", "ftp" and "xmpp"
are supported.
-engine id - Initialise and use the specified engine
-rand file:file:...
-sess_out arg - file to write SSL session to
-sess_in arg - file to read SSL session from
-servername host - Set TLS extension servername in ClientHello
-tlsextdebug - hex dump of all TLS extensions received
-status - request certificate status from server
-no_ticket - disable use of RFC4507bis session tickets
-legacy_renegotiation - enable use of legacy renegotiation (dangerous)
Sallys-Macbook-Pro: 4.10 tro$ openssl s_client -connect
CONNECTED(00000003)
depth=2 /C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Global Root CA
verify error:num=19:self signed certificate in certificate chain
verify return:0
84698:error:14094416:SSL routines:SSL3_READ_BYTES:sslv3 alert certificate unknown:/BuildRoot/Library/Caches/com.apple.xbs/Sources/OpenSSL098/OpenSSL098-64.50.6/src/ssl/s3_pkt.c:1145:SSL alert number 46
84698:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake failure:/BuildRoot/Library/Caches/com.apple.xbs/Sources/OpenSSL098/OpenSSL098-64.50.6/src/ssl/s3_pkt.c:566:
Sallys-Macbook-Pro: 4.10 tro$ openssl s_client -connect
CONNECTED(00000003)
depth=2 /C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Global Root CA
verify error:num=19:self signed certificate in certificate chain
verify return:0
84701:error:14094416:SSL routines:SSL3_READ_BYTES:sslv3 alert certificate unknown:/BuildRoot/Library/Caches/com.apple.xbs/Sources/OpenSSL098/OpenSSL098-64.50.6/src/ssl/s3_pkt.c:1145:SSL alert number 46
84701:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake failure:/BuildRoot/Library/Caches/com.apple.xbs/Sources/OpenSSL098/OpenSSL098-64.50.6/src/ssl/s3_pkt.c:566:
Sallys-Macbook-Pro:4.10 tro$ openssl s_client -connect
CONNECTED(00000003)
depth=2 /C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Global Root CA
verify error:num=19:self signed certificate in certificate chain
verify return:0
84765:error:14094416:SSL routines:SSL3_READ_BYTES:sslv3 alert certificate unknown:/BuildRoot/Library/Caches/com.apple.xbs/Sources/OpenSSL098/OpenSSL098-64.50.6/src/ssl/s3_pkt.c:1145:SSL alert number 46
84765:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake failure:/BuildRoot/Library/Caches/com.apple.xbs/Sources/OpenSSL098/OpenSSL098-64.50.6/src/ssl/s3_pkt.c:566:
@michaelkirk i used certificate pinning
@fifafu from where can i know cipher suite of server
My most recent information is that this is a bug in iOS 11 that only shows when combining client side certificates with servers that only support TLSv1. Let's see whether it gets fixed soon. Apple knows about it and is looking into it.
Is there a RADAR for this bug?
has anybody find solution?
The issue is related to TLS 1.0 server side. Moving to TLS 1.2 server side fixed the issue.
Yes when we update TLS version to be v1.2 problem solved
Thanks
And what if you can't change the TLS version server-side?
_a.k.a: We don't have the rights to do so._
How soon do I know "it gets fixed soon"?
Our server works java 6 and we need a lot of time to update its java 7.
Where do I see this question for Apple site?
Please create a bug report with Apple (https://bugreport.apple.com)
Nobody knows when/if it will be fixed
Has anyone tested if 11.0.1 fixes this problem?
Still fail under 11.0.1 update.
@sallyahmed Did you solve the issue? How? I have the same issue?
It is fixed in iOS 11.1 beta.
@fifafu I test in iphone7(ios 11.01),still fail, the same issue.
@sallyahmed is your server ipv4 network ?
Not 11.0.1
11.1 beta.
@fifafu But,Apple Review in ios 11 . Be Rejected!
Yes you need to either update your server or wait for the 11.1 public release.
How to do? My server does not ipv6.
Got it fix for iOS 11.0.1, simply rekey the certificate and reinstall it on the server solve the problem.
On Sep 28, 2017, at 1:30 AM, 许晓伟 notifications@github.com wrote:
How to do? My server does not ipv6.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub https://github.com/AFNetworking/AFNetworking/issues/3999#issuecomment-332766937, or mute the thread https://github.com/notifications/unsubscribe-auth/AAM7Q6sZrHxCNUJofLGWjiUsCHme5w7Zks5sm1lDgaJpZM4Oa7yC.
No server ipv6 andcwe update TLSv 1.2
Yes, In iOS11.1 is fixed is bug.
I changed my server to TLS 1.2 but I've got the error HTTP load failed (error code: -999 [1:89])
and also when I get the certificate data to compare this is empty, when Im debugging step by step has data and then the error is lost connection
Anyone has the solution?
Hello @sallyahmed can you help me to out this issue?
Solution from server make server support TLS version 1.2
@sallyahmed Thank for your reply but after version update of TLS still its not solved
Please look at my response
Error Domain=NSURLErrorDomain Code=-999 "cancelled" UserInfo={NSErrorFailingURLKey=https://..., NSLocalizedDescription=cancelled, NSErrorFailingURLStringKey=https://...}
Try this
- (void)connection:(NSURLConnection *)connection didReceiveAuthenticationChallenge:
(NSURLAuthenticationChallenge *)challenge
{
if ([[[challenge protectionSpace] authenticationMethod] isEqualToString: NSURLAuthenticationMethodServerTrust])
{
do
{
SecTrustRef serverTrust = [[challenge protectionSpace] serverTrust];
if(nil == serverTrust)
break; /* failed */
OSStatus status = SecTrustEvaluate(serverTrust, NULL);
if(!(errSecSuccess == status))
break; /* failed */
SecCertificateRef serverCertificate = SecTrustGetCertificateAtIndex(serverTrust, 0);
if(nil == serverCertificate)
break; /* failed */
CFDataRef serverCertificateData = SecCertificateCopyData(serverCertificate);
NSData *serverData = CFBridgingRelease(SecCertificateCopyData(serverCertificate));
(id)CFBridgingRelease(serverCertificateData);
if(nil == serverCertificateData)
break; /* failed */
NSData* cert1 = serverData;
NSString *file = [[NSBundle mainBundle] pathForResource:@"certName" ofType:@"der"];
NSData* cert2 = [NSData dataWithContentsOfFile:file];
if(nil == cert1 || nil == cert2)
break; /* failed */
const BOOL equal = [cert1 isEqualToData:cert2];
if(!equal)
break; /* failed */
// The only good exit point
return [[challenge sender] useCredential: [NSURLCredential credentialForTrust: serverTrust] forAuthenticationChallenge: challenge];
} while(0);
// Bad dog
return [[challenge sender] cancelAuthenticationChallenge: challenge];
}
}
Sounds like this was fixed in iOS 11.1? If there’s a bug in AFNetworking please open a new issue with steps to reproduce. For general help, please ask on StackOverflow.
Most helpful comment
My most recent information is that this is a bug in iOS 11 that only shows when combining client side certificates with servers that only support TLSv1. Let's see whether it gets fixed soon. Apple knows about it and is looking into it.