As far as I know IoT Edge will generate test (self signed) certificates (Device CA etc.) at startup if none were provided, right? Those are valid for 30 days.
What happens after those certificates expire?
Is IoT Edge going to create new ones when it is restarted?
When IoT Edge is restarted, the certificates are renewed. However, this is not a production feasible approach imho. :)
You should have your own certificates installed on the device, but those certificats will offcourse expire as well on some day. So, you'll need some kind of certificate rolling operation, but there doesn't seem to be any good documentation regarding this. Therefore, I've created an issue on github for this
Related
I am currently 3 days from the expiration of 1 of my two allowed Apple Developer enterprise certificates; the provisioning profile for the app in question is also expiring on the same day. What I'm trying to figure out is what is the safest and cleanest way to renew the certificate, minimizing any time where existing builds would not be able to open or install from the Airwatch MDM catalog.
I have been able to find good information on AppStore certificates, in that it's totally fine if you revoke or allow the certificates to expire, the apps still continue to function, just no resigning of new versions. But the only relevant documentation I've been able to find mentions that on expiration, enterprise apps will stop functioning.
In the process of determining the best path, we did revoke our 2nd certificate and regenerated it - the revoke immediately broke the application that was using it and it was no longer able to be downloaded or opened. This causes us pause when considering revoking the 1st certificate prior to it expiring.
Any help would be amazing; sorry if this seems off-topic as I have seen marked on other questions on the topic.
[Updated after the profile replacement scenario ended up failing once the original cert and profile expired]
No great answers here (talked with Apple support for a while), but it actually worked fine.
Learnings:
Works:
- Multiple computers can sign using the same cert via sharing the private key using export/import from keychain or xcode (could be used in scenarios where multiple teams need to sign for the same enterprise account)
Doesn't Work:
- (what we tried, failed) Just uploading a new provisioning profile (based on a new/2nd cert) to existing apps in Airwatch (or other MDM or doing some of the re-sign, replace profile scripts that are out there) seems to keep them alive no problem. Then you can regenerate your expiring cert once the deadline passes, then resign back to the proper cert sometime in the 3 years until other cert expires
I have an application that performs requests to a server. The server has a certificate that is going to expire soon. My application is performing SSL pinning with certificates (not public keys).
Supposedly, they're going to renew the server certificate before it expires, but I'm not sure if that alone will suffice and my pinned certificates will still work (since the certificates are renewed, they claim those certificates will remain the same), or I have to forcefully change my certificates in the application in order to keep the pinning working.
Do I have to change my application certificates?
I've googled around, but I can't make a definitive assumption.
Thanks in advance.
If you're pinning the leaf certificate, you will need to update your app with the new leaf certificate or pinning will fail. You can ship both the old and new certificates with the app at the same time and pinning should continue to work just fine.
If you're pinning the public key or one of the branch certificates, and you can verify those items aren't changing with the new certificate, you may not need to do anything.
Ultimately it's important to find out how pinning is currently being achieved (you tagged Alamofire, so I'm assuming you're using it) and how the new cert is being generated.
I read a lot about certs and watched a WWDC, but should clear for myself and for others next question. When we creating certificates in the developer portal, we see next possibilities:
So, what is the purpose of creating only Sandbox certificate instead of Sandbox&Production one? Also there is two fields in app description for certificates.
Does it is a rudiment and we can use only S&P certificate or we should also implement development cert?
After some investigation, I didn't find cases were needed only Sandbox Certificate. It seems, that it's a rudiment. You can generate only one cert for Sandbox & Production and use only it for both environments.
Well just right now every Samsung phone got a push notification with a title of 1 and body of 1.
https://www.theverge.com/2020/2/20/21145130/samsung-find-my-mobile-app-1-notification-galaxy
Why? I guess because the person was testing how remote notifications work. Just that he was using the production certificate and it got sent to every Samsung user.
So it's certainly safer to be using the sandbox version to test things initially with your debug builds ie build that have used your development certificate.
You won't run into an issue when you're working with a tool that you require a given device token e.g. see Push Notification Mocker. But if you give this production certificate to your QA server and QA server sends tries testing out a 'send to all users' notification then such a cluster mess will happen.
I've just renewed an iOS Enterprise certificate for a client and I've also created a new distribution profile against that certificate.
On the test devices there are apps installed that use the old certificate, which have also been trusted by the user, which is standard. The apps still work as the old certificate hasn't expired yet.
So far so good.
When a new app (using the new certificate / profile) is installed it asks the user to trust the Developer again :-(
If I go to Settings->General->Profiles & Device Management there are now 2 entries under 'ENTERPRISE APP' both with, what seems to be the same name. On closer inspection one says:
iPhone Distribution:MY COMPANY LTD/ (the old certificate, notice the trailing /)
and the other one is
iPhone Distribution:MY COMPANY LTD (but without the trailing /)
The App still works OK but it's very confusing to the end user. Has anyone any ideas why the trailing / is now missing? Is there a fix? It's not the end of the world but I'd like to be able to clean this up, if I can.
Thanks for any help/advice you can give.
Regards
Steve
I don't know why the name would have changed just from renewing the certificate - Apple probably just added some sort of filter to remove invalid characters, and that's why the / doesn't appear in the new one.
Unfortunately, there's probably nothing you can do about this. The Company Name field on the certificate comes from the name you provided when you signed up for your developer account, and they don't provide a way to change that (at least not through the web site - maybe try a call to support?)
The other apps that use the old certificate will stop working once the old cert expires, so they'll need to be rebuilt with the new credentials anyway - the confusion will go away at that point, so at least it's not permanent.
We are struggling with the Distribution Certificate handling from Apple.
We have several developers setup in the Apple Developer Portal, for the sake of the example:
Alice: Team Admin
Bob: Admin
Charles: Admin
Dan: Developer
Alice, Bob, and Charles should be able to build Apps for Distribution (Adhoc for internal testing, Testflight for external testing, and Appstore for distribution). Dan is only producing code and debugging on his local machine.
All users use individual accounts for the development.
From what we understood from the Apple documentation, Alice, Bob, Charles need a valid distribution certificate. If xCode generates it for them, they will start playing “ping pong”, and keep revoking each other’s certificate – at least this is what appears to be happening at the moment.
We are not sure why this would happen. One would think, that if you create a different new user this account can also maintain his own (distribution) certificates.
Anyway, so they will need to share a distribution certificate, by sharing the private key (p12 file) of it, as you can find in the answer here.
In our account, it appears as if we can have up to two valid distribution certificates.
We don’t really know how this ultimately worked – we didn’t do it manually over the developer portal, but used xCode for it. Alice generated her certificate, Bob revoked and regenerated, Alice did the same thing – but suddenly they both had a valid distribution certificate, instead of invalidating Bobs certificate.
In the documentation it was mentioned that you can have up to 2 valid distribution certificates. We have also manually tried to generate the distribution certificates and could confirm that it is limited to two.
However, we then got recently invited to a customer’s developer program to sign apps on his behalf.
I assume the customer was not aware that we require the private key from his distribution certificate. We therefore tried to manually generate a distribution certificate, and saw that it was not possible. To our surprise though, the customer managed to generate 3 valid distribution certificates.
Any idea how this worked?
Our questions in a nutshell:
1. What is best practice when you manage a team of developers?
Do you normally share the private key of the first developer who generated the certificate with all other team members, which should be able to sign the app?
2. What is the best practice when you work with clients?
Do you ask them to generate another private key, or is there some hidden functionality to generate as many distribution certificates as you want, given that every developer uses his own account?
3. What happens when we revoke a certificate.
It doesn’t affect the apps in the app store, but only seems to limit other developers to build their app. However, what happens with APNS / Push Server certificates? When we revoke a distribution certificate through xCode, will this also suddenly stop working for the sender?
Thank you for your help.
After a long time of investigation and trying things out, here is what we think is the best fit for us. Not sure if it is best practice but it seems to work for us just fine.
1. What is best practice when you manage a team of developers?
One person generates a distribution certificate using his mac. He then exports the certificate (public AND private key) in a p12 file, as suggested by washloops and shares it with the team.
2. What is the best practice when you work with clients?
We have two sorts of clients:
Clients working with multiple suppliers (so we are just taking care of 1 app, out of their portfolio) - We ask them to share their distribution certificate (public + private key). If they don't have it, they need to get it from another vendor.
Clients working only with us - We generate the certificate and share it with the client later on. This allows them to share it with other vendors if they need to.
3. What happens when we revoke a certificate.
From our tests: "nothing". If you revoke a distribution certificate, it will prevent developers using this certificate from submitting / building apps. However, existing APNS / Push certificates are not affected.
For us it seems as APNS / Push certificates are totally independent, and if you wish to revoke them, you need to revoke both.
You have to create just 1 distribution certificate. After that you go to Keychain Access, select the certificate and export it as ".p12", and maybe add a password to it.
After that you just install it in the other computers.
Regards :)