Share via

APNS token credentials fail ANH validator but pass APNS direct auth — validator bug?

Igor Riera 20 Reputation points
2026-04-21T14:25:33.65+00:00

  Trying to configure APNS token-based authentication on an Azure Notification Hub. Every PATCH/PUT on apnsCredential    

  returns:                               

                                                                                                                         

  BadRequest: Failed to validate credentials with APNS                             

                                                                                                                         

  Direct HTTP/2 authentication to Apple's APNS endpoint using the exact same .p8 key, Key ID, Team ID, and Bundle ID

  succeeds — Apple issues an apns-id and only rejects the synthetic device token (expected):                             

                                                                                                                         

  HTTP/2 400                            

  apns-id: <issued by Apple>                                                                                             

  {"reason":"BadDeviceToken"}                                                                                            

                          

  BadDeviceToken on a synthetic token, with an issued apns-id, proves the credentials authenticate cleanly at Apple.     

  Something in ANH's APNS validator is rejecting credentials that Apple accepts.   

                                                                                                                         

  Resource: APNS Notification Hub in a South Central US namespace, Free tier. Can provide subscription ID and resource

  name privately on request.             

                                          

  What I've tried (all return identical error):                                                                          

                                                                                                                         

  1. az rest PATCH with standard shape on api-version 2023-09-01:                                                        

  {"properties":{"apnsCredential":{"properties":{                                                                        

    "keyId":"<redacted>","appName":"<TeamID>","appId":"<BundleID>",                                                      

    "endpoint":"https://api.development.push.apple.com:443/3/device",

    "token":"<.p8 PEM contents>"                                                                                         

  }}}}                                                                                                                   

  2. Same on older api-version 2017-04-01.

  3. Token with trailing newline stripped.                                                                               

  4. az rest PUT with location field included.                                     

  5. az rest PUT with full GET → merge → PUT of the hub resource.                                                        

  6. az notification-hub credential apns update CLI (rejects at CLI arg validation — requires non-empty                  

  --apns-certificate even in token-auth mode).                                                                           

  7. Drop & recreate the hub. Failure reproduces on the fresh hub.                                                       

                                                                                                                         

  Ruled out:                                                                                                             

                                                                                   

  - Credentials wrong — direct APNS auth above proves otherwise.                                                         

  - APNS not enabled on App ID — Apple issues apns-id which it wouldn't if APNS were disabled or topic mismatched.       

  - App ID in state #2 — state-#3 trigger cert was generated on the App ID.                                              

  - Cached rejection state — drop/recreate doesn't change outcome.                                                       

  - ARM propagation delay — 48+ hours since first PATCH.                                                                 

                                                                                                                         

  Observation for the product team: after a failed PATCH, a subsequent GET on the hub shows no apnsCredential property at

   all — not a rejected-state marker, not a partial object. The validator rejects pre-persist, inside ANH itself, and    

  doesn't leave a trace on the hub record.                                         

                                                                                                                         

  Ask: can the ANH product team inspect the APNS validator for this class of failure? Happy to provide                   

  hub/namespace/subscription identifiers privately, and to PATCH again on request to generate a fresh correlation ID.

Azure Notification Hubs
Azure Notification Hubs

An Azure service that is used to send push notifications to all major platforms from the cloud or on-premises environments.

0 comments

Answer accepted by question author

  1. Q&A Assist
    2026-04-21T14:26:02.16+00:00
    AI generated content. This question contains an answer created with AI from Q&A Assist. Learn more

    The behavior described matches how Azure Notification Hubs validates and persists APNS credentials, but the context does not document any known validator bug of the kind described.

    From the available information, only the following can be confirmed:

    1. For APNS token-based (HTTP/2) authentication, Notification Hubs requires:
      • appId: 10-character Team ID (issuer/iss claim) from the Apple Developer account.
      • appName: application name / Bundle ID.
      • keyId: 10-character Key ID (kid) from the Apple Developer account.
      • token: provider authentication token derived from the .p8 key.
      • endpoint: APNS HTTP/2 endpoint, e.g. https://api.development.push.apple.com:443/3/device for sandbox or https://api.push.apple.com:443/3/device for production.
      These properties are documented as the APNS credential fields for Notification Hubs, and the endpoint values for sandbox vs. production are explicitly defined.
    2. When migrating from certificate-based to token-based APNS authentication, Notification Hubs overwrites the certificate credentials with the token properties internally, and the application should continue to receive notifications without additional changes. The documentation notes that Notification Hubs is “set to use the new authentication system with APNS” once the token properties are configured.
    3. Common misconfiguration checks for Notification Hubs include:
      • Ensuring the notification hub name is identical across client registration, backend send code, and the hub configuration.
      • Ensuring the correct shared access signatures are used (DefaultListenSharedAccessSignature on clients, DefaultFullSharedAccessSignature on backend).
      • For APNS specifically, maintaining separate hubs for sandbox and production, and not mixing certificate types in a single hub.
    4. The ARM schema for Notification Hubs APNS credentials confirms the property names and expected values for token-based authentication (appId, appName, keyId, token, endpoint), but does not describe internal validation behavior or error conditions beyond the requirement that endpoint is present.

    The context does not provide any product-team guidance, known issues, or troubleshooting steps for the specific case where:

    • Direct APNS HTTP/2 calls succeed with the same credentials, but
    • Notification Hubs returns BadRequest: Failed to validate credentials with APNS, and
    • The apnsCredential block is not persisted on the hub after the failed PATCH/PUT.

    It also does not document any limitation related to region, tier (Free vs. paid), or a validator defect that would explain this discrepancy, nor does it describe escalation paths or correlation-ID–based investigation for this scenario.

    Because of that, no definitive root cause or confirmation of a validator bug can be given based on the provided material.

    References:

    Was this answer helpful?

1 additional answer

Sort by: Most helpful
Most helpful Newest Oldest
  1. Golla Venkata Pavani 4,830 Reputation points Microsoft External Staff Moderator
    2026-04-21T17:57:02.8+00:00

    Hi @Igor Riera

    Thank you for reaching us regarding the issue.

    Based on current documentation for Azure Notification Hubs, your configuration (appId, appName, keyId, token, endpoint) matches the expected setup for APNS token-based authentication.

    The behavior you’re seeing is also consistent with how the service works:

    • APNS credentials are validated before being saved
    • If validation fails, you’ll get BadRequest: Failed to validate credentials with APNS
    • The credentials are not persisted, which is expected

    Although your direct tests against Apple APNS succeed, there is no documented issue or known validator bug in Notification Hubs that explains this discrepancy.

    Please submit an Azure support request including your Notification Hub and namespace details, the region, the request payload, and the correlation ID. Providing this information will help the product team investigate the validation failure more effectively.

    Reference:
    https://learn.microsoft.com/azure/notification-hubs/notification-hubs-push-notification-fixer#notification-hubs-misconfiguration
    https://learn.microsoft.com/azure/templates/microsoft.notificationhubs/2017-04-01/namespaces/notificationhubs#property-values
    https://learn.microsoft.com/azure/notification-hubs/notification-hubs-push-notification-http2-token-authentication#overview

    If the answer is helpful,  Please do click "Accept the answer” and Yes, this can be beneficial to other community members.

    If you have any other questions, let me know in the "comments" and I would be happy to help you

    Was this answer helpful?

    0 comments

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.