Connection to prod APNs with development cert

Question

I'm using this Ruby code to receive errors from APNs on unsuccessful pushes:

if IO.select([ssl], nil, nil, 5)
    read_buffer = ssl.read(6)
    process_error_response(read_buffer)
end

I noticed a weird situation where IO.select is non-nil but read_buffer returns an empty string. After some debugging I realized that this happens if you connect to gateway.push.apple.com with a development APNs cert, and the same thing apparently happens if you connect to gateway.sandbox.push.apple.com with a production cert.

Is there any way to programmatically detect that this is the case, e.g. if you're given a push certificate by a user and told it's production/development but can't actually verify that fact on the Apple developer site? I would have thought that the connection would be rejected, but instead it seems to be created but in a partly-broken state.

Uprising

Answer 1

Well, it is not a way to check if the cert is APNS valid, but you can inspect it if you want to detect whether it is a development or production one. The development will have the "Developer" string in it, whereas the production will have the "Production" string.

Stent

Answer 2

One way is to open the certificate and check the subject, example:

require 'openssl'
def production?(cert_path)
  certificate = ::OpenSSL::X509::Certificate.new(File.read(cert_path))
  !certificate.subject.to_s.include?('Development')
end

For production certificates the subject looks like:

"Apple Production IOS Push Services: com.mybundle.app..."

For development certificates looks like:

"Apple Development IOS Push Services: com.mybundle.app..."

Wishful

Answer 3

I just used the cert to to send it to myself from command line directly...

When using a development cert I see:

api.development.push.apple.com

I'm not testing with a production cert, but I'm pretty sure when you send it with production then instead of the above you'll see:

api.push.apple.com

FWIW a production cert will work in a development (app not signed with distribution cert) environments — as long as both environments have the same bundleId. However a production cert won't work in production environment (app signed with distribution cert)

Aside from that the more secured way nowadays is to not user certificates and instead just use a key/token mechanism. See here

Levelheaded