Apple Push Notifications - The credentials supplied to the package were not recognized

823 Views Asked by At

I am receiving "The credentials supplied to the package were not recognized" message when attempting to send a push notification from a site in IIS.

I have a console application that runs exactly the same code on the server which runs fine, it is just when it is from IIS.

I have tried the solution here: PushSharp - The credentials supplied to the package were not recognized

I tried:

"C:\Program Files (x86)\Windows Resource Kits\Tools\winhttpcertcfg" -i certificate.p12 -c LOCAL_MACHINE\My -a "NetworkService" -p <Password>

This is the account that IIS runs from. I have also tried for IIS_IUSRS, USERS but I still get the credentials error

I have also checked that I'm only exporting the Private Key and not the certificate, also I have tried both ways

Is there anything else I can try? It seems odd that it is only IIS that cannot send the push notification

3

There are 3 best solutions below

0
On

I had the same problem in my .NET Core webservice deployed to AWS Elastic Beanstalk. I will outline everything I tried and how I ultimately fixed it.

  1. I followed all the steps you can find anywhere for creating the APNS production cert.
  2. Downloaded the cert and installed into the Mac Keychain app.
  3. Exported the cert with the private key, and provided a password for the key.
  4. Copied the exported .p12 file to my PC into a folder in the wwwroot
  5. In my .NET Core webservice, read this file (providing the password) into an X509 cert.
  6. Use that cert to call the apple push service using an SslStream
  7. Everything worked fine from my local IIS, but as soon as I uploaded the AWS EB I would not get a notification on my phone.
  8. I added logging and found that the sslStream.AuthenticateAsClient method would throw the "The credentials supplied to the package were not recognized" exception
  9. I got stuck here for a long time
  10. I tried logging the Thumbprint and HasPrivateKey properties of the X509 object and they both looked correct, so I felt like the cert was read correctly.
  11. I tried setting the Tls version to Tls12
  12. I tried building the x509 from a hard-coded byte array of the cert.
  13. The next was a bit of a shot in the dark.
  14. I imported the .p12 cert into my local PC.
  15. I noticed that the trust chain was incomplete, so I downloaded the root and intermediate certs from Apple
  16. I verified that the cert showed that it had a private key.
  17. I then exported from the windows cert app including the private key (NOTE: when importing make sure you check the box to allow exporting the private key)
  18. Here's where I noticed something.
  19. First the export asks you to provide a password. I used the same as when I exported from the Mac.
  20. But then export asks you to chose the Encryption (dropdown). Mac does not ask this. I left the default (TripleDES-SHA1).
  21. It saved as a .pfx, which I understood was the same as a .p12 just with a different extension.
  22. I changed my code to use the .pfx instead.
  23. Now when deployed to AWS it worked.
  24. I have no idea what is different, though I suspect it may be related to the Encryption of the private key.

Hope this helps.

0
On

If it works in Console but not in Service, I got one possible culprit: Interactive Sessions.

For security reasons Services since Vista run in non-Interactive Sessions. That means they can not make screenshoots, override the UAC, or interact with the users desktop in any other way.

A handfull of rather old code also requires Interactive Sessions. Particulary the (t)rusty Office COM interop is know to either needing that right, or it will simply not run.

It might just be relevant to your case.

0
On

I have solved the issue.

I changed the identity of the Application Pool that the site ran under to my current user (Administrator)

Just to be sure I also ran winhttpcert for that user and in the Cert file properties securty settings I gave full control to the same user.

The certificate works just fine now