Apple - Authentication failed because the remote party has closed the transport stream.

[enobil]

What version of PushSharp are you using?

3.0.1 and 3.0.1.15 nuget packages.

Describe your issue:

I use Windows 8.1.
When I try to send just a single push notification to Apple push notification servers, I get the following error:
Exception: System.IO.IOException: Authentication failed because the remote party has closed the transport stream.
at PushSharp.Apple.ApnsServiceConnection.d__2.MoveNext()

I checked out ports 2195 and 2196 to be open.
I tried telnet:
telnet gateway.sandbox.push.apple.com 2195
telnet gateway.push.apple.com 2195
telnet feedback.push.apple.com 2196
All connect successfully.

I tried running VS in administrator mode.
I tried installing certificates to my local machine (only machine I use).
There isn't any proxy server my machine is configured to use.

I'm using development (sandbox) certificate, I can't test production certificate right now because I don't have Device Token assigned with production certificate.

I read about SSL3 & TLS and I checked PushSharp sources, TLS is trying to be used when I download sources.

What are the steps required to reproduce this issue?

Use a valid sandbox certificate and assigned Device Token.
Use Windows 8.1
Try to send an Apple push notification

Please provide any Exception Stack Traces

Exception: System.IO.IOException: Authentication failed because the remote party has closed the transport stream.
at PushSharp.Apple.ApnsServiceConnection.d__2.MoveNext()

[seantack]

If memory serves me correctly this is related to HTTP/2 and APNs. This appears to still be an issue in 4.0.1. Is there any update/ETA for a resolution to this issue or is there something different we? Was really hoping this would have been tackled in the 4.x release.

[Redth]

I don't believe this is related to HTTP/2 at all (except for possibly being related to certificate types - some users seem to have issues with using the new combined certificate type with the old APNS servers - PushSharp supports using the old types again).

This is something that's usually a matter of the certificate being generated incorrectly, and is not something I'm able to reliably reproduce.

[seantack]

@Redth - Ok, and great. I appreciate the quick reply and will dig further as we did update our certificate. Thanks much...

[enobil]

I will test with different types of certificates and report back ASAP. Thanks

[seantack]

@enobil - We seem to have gotten past this issue after generating a fresh push service certificate and importing it. I think many of us were forced to make the jump to 3.x+ due to the new Apple push cert naming convention (dropping 'Production' and 'Development' from the name) and there has been confusion as to why things were not working. The error was a bit ambiguous. I appreciate the help.

[seantack]

@enobil - Actually, the problem is occurring again this morning. Yesterday after I deleted and re-added the push cert we got 'InvalidToken', which may be the case (or confusion with the version of our app used for testing). But, today we are again getting "Authentication failed because the remote party has closed the transport stream". Same cert and code as yesterday. So, I'm again digging.

[seantack]

@Redth @enobil - Jonathan... thanks for the tidbit on people having trouble with 'combined certificate' files. Here's some additional info... we have the library working in Production, but not in the Sandbox/dev.

• We're using 1 cert file that supposedly works for Production and Sandbox (dev) environments, as per Apple.
• Production works, but we still have trouble from the sandbox/dev environment.
• We have a dev/test client build in iTunes Connect (used for testing), a 'combined' cert file in our dev web service and using ApnsServerEnvironment.Sandbox, but we get 'InvalidToken' when we try to push. The token is correct, but it seems something is confused between production/sandbox.
• Also, we're using Windows 2012 Server. The cert is imported via the .p12 file using mmc.exe. We are passing the .cer filename to the ApnsConfiguration constructor. Both files are located in the same folder. It has been done this way in the past and worked with PushSharp v2.2.1... and this is working in Production this way with v4.0.

Any thoughts would be appreciated. All the best...

[Redth]

@seantack Hmm, doesn't TestFlight require an AdHoc provisioning profile to be used? My guess is that you have generated a token from an app signed with an adhoc provisioning profile, in which case you MUST send notifications to that token through the production apns server. Only tokens generated with a development provisioning profile can be sent through the sandbox apns server.

[seantack]

@Redth - We use a third-party for our mobile client development and we built the built and host the web service it uses. After speaking with the third-party it would appear you're correct. I know you're a busy guy and I commend you on your efforts as well as direct assistance here. Far better response than most paid services. All the best...

[JuanCAlpizar]

@seantack can you please describe a bit more what's up with the new combined certificate? I suddenly got this issue as well today and I'm still confused on what's wrong and what needs to be done

[seantack]

@JuanCAlpizar - I believe I was having two issues thru this thread. I'm not a guru on APNs, but regarding the combined certificate... Apple now (this changed last year I believe) allows you to create one certificate that can be used for both Sandbox (dev/test) and Production push environments. After we created a new cert file, PushSharp v2.2.2.1 would not work as it was checking the name of the cert and looking for specific wording to determine if it was a Sandbox or Production certificate. The latest version of PushSharp does not have this issue... however, we did not get push notifications to work on our Sandbox (test) environment... only Production works. I do not believe there is an issue with the library, but rather something to do with TestFlight and the AdHoc provisioning profile... as Redth mentioned in the post above on Mar 25. I believe TestFlight also had some changes in the past year and since we have a third-party company doing our mobile client (we do the back-end service ourselves) I moved to another project since we got this to work in Production.