I have my App in the AppStore which uses push notifications. I already have a valid certificate but it expires in a month. My question is "Is there any way to generate a permanent APNS certificate which doesn't expire"? I've to deploy server in client premises and don't have further access, so I need to generate a permanent APNS certificate.
No, it's not possible to generate a permanent certificate. A production APNS certificate is valid for 1 year. You will be able to generate a new certificate to replace the existing one before it expires.
Related
If a user has uninstalled my app, how long will the APNS take to update that this device is inactive for the bundleID?
Heyo, after reading up a bunch to make the migration to the new APNS provider API, this is what seems most familiar to me regarding this:
Establishing a Certificate-Based Connection to APNs
"Check expiry of a certificate with KeyChain Access. To avoid a disruption in service for your users, update your provider certificates before they expire. Provider certificates are valid for a year and must be updated to continue communicating with APNs".
Also:
"If you think your certificate or private key has been compromised, you can revoke your certificate from your developer account. APNs maintains a list of revoked certificates, and it refuses TLS connections from servers whose certificates are on that list. If your server is using a revoked certificate, close all existing connections to APNs and configure a new provider certificate for your server before opening any new connections".
Seems to me it the expiry is based around certificate creation as well as deleting the app?
I'd like to hear more on this....
I'm supporting one mobile application. Recently I got email that "apns production certificate will expiring soon". After that I checked my backend and found that no any certs using, only auth key. As I know auth keys don't have expiration key. I suppose that apns-cert used on first time after launch or maybe created mistakenly but not using right now. So I have couple of quesions:
1) For well-working APNS, should I have only auth key without APNS certificates? (My idea here - can I safely remove cert without hurting current APNS)?
2) If for example I have non-used in production APNS certificate - I still receive some notifications on my email - like "this certificate will expiring soon"?
Thanks in advance.
1) For well-working APNS, should I have only auth key without APNS
certificates? (My idea here - can I safely remove cert without hurting
current APNS)?
You can safely remove any expired APNS certificate if you are not using. They are not related to the Auth Keys.
2) If for example I have non-used in production APNS certificate - I
still receive some notifications on my email - like "this certificate
will expiring soon"?
Just because you created those certificates, so Apple notifies you of the expiry date whenever they are going to be expired.
You can reference to the following discussion for more details.
https://forums.developer.apple.com/thread/91891
I'm trying to configure my iOS app to receiver notifications with Firebase.
If I export the certificate and the private key without a password and try to upload it (production or development) on Firebase console I get the error "Incorrect password".
If I export the certificate and the private key with a password I get the error "An unknown server error ocurred" or "There was an error reading your certificate".
I don't understand why that is happening. I did follow the tutorial correctly. Can someone help me?
You should be using an APNS Authentication Key rather than the certificates. This is the new preferred method in iOS for a provider to register and send messages with APNS
From Firebase:
Configuration with auth keys is recommended as they are the more
current method for sending notifications to iOS
From Apple:
For a provider to communicate with APNs, it must employ a valid
authentication key certificate (for token-based connection trust) or
SSL certificate (for certificate-based connection trust). You obtain
either of these certificates from your online developer account, as
explained in “Configure push notifications” in Xcode Help. To choose
between the two certificate types, read Provider-to-APNs Connection
Trust. Whichever certificate type you choose, provider connection
trust is prerequisite to a provider sending push notification requests
to APNs.
while exporting just select the Apple Push Service part and don't select the private key from Keychain Access and export than in firebase Production APNs certificate browse the p12 file you just created, it will work.
I don't know when this implementation will be deprecated but it works as of now (19 Feb 2018).
You should export only the certificate and don't select the private key . Please see this screenshot
My certificate expires in a month, my app uses push notifications so I need the certificate to be valid. If I revoke it and then create a new one will I have to upload an "update" for the app with the new certificate? or is easier if it expires first then I renew the certificate and then I'll need to generate again all the provisionings with the new certificate? I need to be sure about this before I revoke it, please help. Can someone share a link where I can verify this.
No, not at all. The certificate is for your server. You don't need to submit an app update by any means, simply revoke the certificate and request a new one, and then upload that certificate to your provider, whether that be Urban Airship :) or whomever. No downtime whatsoever to your current users.
I am developing mdm server and I have a problem with one of enrollment steps. The problem is scep step. I implement a scep server which handles Device CACert request and sends our server certificate in der format. After that, device sends encrypted and signed csr. But I can not verify signature of message. I think device creates a self-signed-certificate and sign message with it. We think that because signature certificate's common name is changing each "PKIOperation" request. But we must verify this signature because of security.
For example in each 3 enrollment request, certificate of csr signature changes. Their common names are:
CN=6E4F65AD-1E64-4E4D-A96E-2039EB140041
CN=2E33C2CC-14B8-47AC-938B-DCC7F8DA8715
CN=6817ED48-AB79-4FF0-A1A9-42C2AC303672
Note: The other steps of enrollment device sign messages with proper certificate and I can verify them. Only scep PKIOperation request is my problem. Is there any profile flag to set or something to solve this problem?
I may be wrong in some details, because I touched this about two years ago.
However, as I remember it's part of a protocol
If you take a look at SCEP draft: https://datatracker.ietf.org/doc/html/draft-nourse-scep-23#page-30 you will see this:
When building a pkiMessage, clients MUST have a certificate to sign
the PKCS#7 [RFC2315] signed-data (because PKCS#7 [RFC2315] requires
it). Clients MUST either use an existing certificate, or create a
self-signed certificate (see Section 2.3).
If the requester does not have an appropriate existing
certificate, then a locally generated self-signed certificate
MUST be used instead. The self-signed certificate MUST use the
same subject name as in the PKCS#10 request.
However, I was under impression that iOS device uses certificate/private keys which are built into the device. And this certificate is signed using Apple certs. And actually, as I remember they had exactly the format of CN, which you shown.
So, generally speaking it's ok if device uses self-signed certificate for first communication to the SCEP server (PKIOperation) and uses a certificate issued by your CA later on.