If, Do not automatically enroll checkbox is ticked, what will happen if a certificate gets expired?
Does "renewal period" will conflict with "do not auto reenroll"?
When a cert is going to expire, a new one will be issued when only 6 weeks are remaining till expiry...but "do not auto reenroll" should block it from getting issued because it will be duplicate certificate?
If a certificate in AD expires, the client will re-enrol. The checkbox simply stops multiple devices re-enrolling on behalf of the user if a valid certificate is in AD.
When un-ticked and a user moves from one device to another, they would enrol for a certificate at each device which would be stored in AD. AD would therefore grow considerably.
When a client renews a certificate (at some point up to 6 weeks before expiry in your case), the old certificate is archived. The above is only relevant in the period up to the 6 week renewal period.
Related
I have integrated FCM in my IOS application. I have added both Development and Production push certificate in the Firebase console. I have been developing the application for the last 1 year. Everything was working fine before 2/3 months back.
I installed the application in the device and received a token from firebase and when I tried to send the notification to this token. It is showing as InvalidRegistration/Not Registered. When I run my application, say for 3/4 times, I will get new push tokens which are also invalid ones and at last, I will get the valid push token.
I updated the Firebase, regenerated new push certificates but still the same issue. Is there anything I need to do in order to receive the valid push token and hence the notifications.
Please suggest.
You have two Certificates types, the old .p12 and the new p8 certificate.
The .p12 certificate is only valid for 1 year, the p8 a lot longer.
When you create your certificates, make sure that you upload your certificates to apple and Firebase.
I recommend to use the new p8 certificate.
In iOS, if pinned SSL certificate expires, do I need to re-submit the app? Will the apps with old version continue to work or will not work unless they are updated?
That entirely depends on how you pinned the certificate. Pinning a certificate means checking the certificate and its chain against a set of designated requirements that determine whether the new certificate should be accepted. There are nearly an infinite number of ways to do this, and thus nearly an infinite number of ways to shoot yourself in the foot while doing so.
As a rule:
If you are checking to see if the certificate's public key matches, you're fine as long as the new cert has the same public key. This is normally the simplest approach to get right, because you have the power to guarantee that a key under your direct control does not change. However, be aware that some automated certificate updating tools generate new keys by default.
If you are comparing the entire certificate, it will likely break, because obviously some aspects of the certificate (minimally, the expiration date) will change.
If you are comparing specific aspects of the certificate, such as the public key of the CA cert that signed it, it may or may not break, depending on whether those designated requirements match.
Be aware, however, that CAs periodically rotate out their signing keys to limit damage in the event of a key getting compromised. What this means is that the specific CA cert key that you pinned may not be the one that gets used to sign a subsequent certificate. And if you are doing this in an automated fashion, it isn't a question of whether you will break, but when.
For this reason, if you feel the need to do key pinning, it is strongly recommended that you pin only keys that are under your direct control, and that you force any automated update tools to reuse the existing key pair.
No. once you install ssl on your site or renew old one, it will start working. no need to resubmit the app.
read more at SSL Pinning and certificate expiry
Before I always had to give push notifications certificates (p12 files) to the server developer, so he could send push notifications to my applications.
But as far as I understand now it's possible to do without these certificates according to https://developer.apple.com/library/content/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/Chapters/APNsProviderAPI.html#//apple_ref/doc/uid/TP40008194-CH101-SW1
According to Apple:
A provider authentication token is a JSON object that you construct, whose header must include:
The encryption algorithm (alg) you use to encrypt the token
A 10-character key identifier (kid) key, obtained from your developer account
The claims payload of the token must include:
The issuer (iss) registered claim key, whose value is your 10-character Team ID, obtained from your developer account
The issued at (iat) registered claim key, whose value indicates the time at which the token was generated, in terms of the number of seconds since Epoch, in UTC
The question is where to take these kid, iss, iat values from the developer account?
Actually I've watched the video from WWDC https://www.youtube.com/watch?v=IDBCTvHrix8, it explained almost everything.
1) for kid you need to https://developer.apple.com -> Certificates, Identifiers & Profiles -> APNs Auth Key -> Press + button -> choose Apple Push Notification Authentication Key (Sandbox & Production) (it was added not so long ago) -> After you create it, you will see Key ID in this item (new item will appear in APNs Auth Key menu). This is your kid value
2) iss is your team ID, to take it you need to Certificates, Identifiers & Profiles -> Identifiers -> App IDs -> Press on any of your App IDs (if you don't have any, you need to create one for your application) -> you will see the details where you will see Prefix: 8jkjlj2k . This is your team ID and it will be the same for all your apps in your developer account.
3) iat : As far as I understand it's the time when server developer generated the token on his side, so you don't need to provide this value to the server developer
I've got several hundred users on this enterprise app. I've got 2 which are throwing a NSURLErrorServerCertificateUntrusted and won't talk to the server. I've checked the server and the cert is valid, but that didn't surprise me because this issue only impacts these 2 users.
I've had them check date/time on their iPads and they are set correctly and automatically.
I've had them connect try through both cell network and a local WiFi hotspots. It seems unlikely these two users are always being targeted by a man in the middle attack.
This Question never got an answer and Apple's TN2232 document on Trust offered some common issues, but hasn't gotten me to a resolution yet since mostly these things would impact all users, not just a couple.
missing issuer certificate — For any given certificate (except the trusted anchor), the system must be able to locate the certificate of the issuer.
date problems — For any given certificate, the verify date must be within the certificate's valid date range.
self-signed certificate — For any given certificate, if the certificate is self-signed, it will cause evaluation to fail (unless it's a trusted anchor).
no trusted anchor — The system must be able to follow the path of issuer certificates leading to a trusted anchor.
DNS name mismatch — The DNS name that you're trying to connect to must match the name in the server certificate, as described in the previous section.
Any ideas on what is causing this and how to resolve it? Yes, I could just bypass the security and trust my domain, but that's not really an option I'm willing to entertain.
For one of my iOS apps I need to check two things:
Is there an active device lock (pass code)
Has the device lock been triggered by the correct authority / certificate (e.g. my own certificate). This is required to assure specific security guidelines.
For the first part of my question I found this answer - which is sufficient for me. How would you accomplish the second part?
Answering my own question.
First of all the correct question is not about validation of a certificate. It's about validation of meta information placed within a configuration profile (which in my case provides security guidelines for the device lock).
You have to create a custom CA and issue one certificate. The issued certificate has to be placed within your app, the custom CA's certificate goes into the configuration profile.
If the configuration profile is installed it is possible to check whether the certificate within the app binary was signed with the root certificate placed in the configuration profile.
It's not the most secure solution, but definitely a way to go.
--
This post put me into the right direction (Apple Developer Account required).