I've followed the guidelines and configured fine my desktop for Ad-Hoc distribution (requested certificate from the CA, created the main Certificate with my name, created a provisioning associated to devices, and so on).
Now I have my laptop and I need to configure it with the same account (not creating a team development account, but an admin one). I didn't recreate the certificate from the CA because I already have my valid certificate online (the one associated with the provisioning), and I downloaded it and installed it in my keychain. But if I open Xcode and look for a valid provisioning, it says "profile doesn't match any valid certificate/private key pair in the default keychain".
Do I need to recreate my own certificate every time I switch from my workstation to the one in my office?
When you create a CA it uses a private key on your system. You need to copy that to your laptop in order for XCode to use the CA.
http://developer.apple.com/ios/manage/certificates/team/howto.action (need to be logged in)
Here is a helpful article on the topic:
http://www.buggyprogrammer.co.uk/2010/12/13/sharing-ios-distribution-certificate/
I'm in the process of doing this myself, so I'm not sure if this works, but seems like it should.
Related
I've created a UWP app using Xamarin Forms in Visual Studio. It is ready for release, and I do not intend publishing it to the Windows Store. Under the "Packaging" tab of Package.appxmanifest, I created a test certificate via
Configure Certificate... >> Create test certificate...
and then created the app package. I can install the application on my own device (that was used to create and publish the app) using the .appxbundle file in the package, but any other device will not install the app, saying that "Either you need a new certificate installed for this app package, or you need a new app package with trusted certificates. Your system administrator or the app developer can help. A certificate chain processed, but terminated in a root certificate which isn't trusted (0x800B0109)"
On the devices giving this error, I have installed the certificate using the Certificate Import Wizard to both the local machine's "Trusted Publishers" and "Trusted Root Certification Authorities" stores, as well as whatever stores were chosen using the automatic option, then restarted the device. When I go into Digital Signature Details under the .appxbundle file's properties, it says that "The difital signature is OK", but still gives me the same error when I try to install the app.
If there is an issue with my certificate, which says it expires on 1/7/2019, how can I create a certificate that will work? Otherwise, have I incorrectly installed the certificate on the device? I have double and triple checked and the device is set to Developer Mode. It is also on the same version of Windows 10 that my device is on.
I have also tried right clicking the .ps1 file and running with powershell, which gives me the same error. I have been following these instructions to this point: https://learn.microsoft.com/en-us/windows/uwp/packaging/packaging-uwp-apps#before-packaging-your-app
I've discovered the issue on my own. I had mistakenly installed the certificate to "Third-Party Certification Authorities" instead of "Trusted Root Certification Authorities". Once I installed the certificate to the proper stores the app was able to install.
For UWP apps, the certificate must be placed in the Trusted People store.
In my case I have installed certificate for current user instead of local machine. I installed for local machine and it works .
Also installed for for all 3 types of as shown below
Personal
Trusted root ....
Trusted Publisher
and things start working for me after 2 hours of effort.
So I had a certificate from Comodo and bought via KSoftware that I use to sign my software so it does not generate a warning when users download it, this has been working fine but the 2 year certificate expired last month. I purchased a new certificate last week and applied to a new version of my application but now when I download it warns me unknown publisher, and wierdly when I click on more info it shows my full address instead of just my company name JThink.
I have looked at my old and new certificate in browser and noticed I had Jthink ltd in old certificate and JThink in new one, would this cause an issue ?
Update
Comodo tell me there is a period of time before Microsoft start accepting new certificates and it would still be a problem even if the company information was identical because the certicate no is different.
Is this true, and what length of timescale are we talking about here ?
You need to just wait some time. Windows collects different data for your new certificate (total downloads count, etc.) and in some near future (depends on downloads rate) it will mark it as white listed (if it's all OK). And all your downloads signed using this new certificate will not be blocked anymore.
The same mechanism applies (as I think) on downloads without certificates at all. Windows collects the file reputation and after some critical amount of "good-experience" downloads it marks the file as OK. The same logic applies to certificates. Thus you do not need to wait anymore if your certificate has a "good reputation".
You need to use Extended Validation Code signing certificate which provides more trusted security certificate for your Windows binary. Regular code signing certificates are not validated by Windows smart screen protection.
I had the similar issue when Windows 10 was released with Windows smart screen protection with more advanced security features.
https://www.digicert.com/code-signing/ev-code-signing.htm
I have a client who forgot to pay for their enterprise account and therefore their apps stopped working, as expected.
However, one would think that it should be sufficient to just start paying again to be able to use the apps as before. But as it seems, all certificates in the apple developer portal are now deleted?!
Is this expected behaviour or will they show up after some time again?
As it is now, we will have to rebuild all apps again with new distribution certificates. Is this the solution?
Short answer to your question:
I wouldn't expect the certs to automatically reappear. I recommend opening a support incident with Apple. Since the account was recently renewed, you should have two incidents available.
There's this section of the App Distribution Guide which talks about re-creating deleted certificates but I'm guessing it's more geared toward iTunes distributed apps and circumstances where certificates (private keys) are deleted but not revoked at Apple's CA.
Instead of recompiling your apps, you might be able to instead push out updated Provisioning Profiles and Certs. See below for more details.
Additional info:
It makes sense that Apple would revoke Enterprise certs upon membership expiration since that's the only way they could force apps to stop working. Since Enterprise apps stop working when either the Provisioning Profile or the Certificate expire, Appple can't push out an expired Provisioning Profile, and there's no in-app check for a Profile either (which is why if you delete your Profile in the developer portal, it won't affect any already downloaded/installed apps), which leaves the only other option: revoke the certs. The affected apps stop working once they sync with Apple's CA. Devices without connectivity will continue working until the Profile expires.
It may be possible to remove your certs from the Certificate Revocation List (CRL) but Apple support would be your only likely resource to help with this.
If you're out of options for re-enabling your old certs, you can update the Provisioning Profiles (and I think Certs) and push that out without recompiling all your apps. Also, if you use wildcard App IDs, an update to one app Provisioning Profile will apply to all installed apps that share that App ID.
If your users' devices are managed via MDM, it's possible to push updated provisioning profiles via MDM, and according to this post, via Device Enrollment Program (DEP). I thought I read a while back that you could also update provisioning profiles from a desktop/laptop to a connected device using iTunes - not sure where that is now. I don't know if it's possible to direct users to a link to update the Profile OTA like they would install an app.
I hope this helps in some way. Please let us know what happens - I fear the same could happen to me, whether a cert is deleted by Apple or a haphazard developer.
My Ad Hoc profile is about to expire in 14 days. There is a a "renew" button for my ad hoc profile in the organizer but when I click it I get...
There are no current certificates on this team matching the provided certificate IDs.
The profile in the provisioning portal shows active, expiring on the 30th. I also see a distribution certificate with the same expiration date. I must assume that this certificate is the one that was used to sign the profile. Is there any way to fix this without revoking and creating a new ad hoc profile and certificate?
If I have to start over, what is the best way to proceed without messing up my testors.
There are a lot of posts and answers on this subject but I can't find any that address this particular problem with the certificate not matching the certificat ID of the profile.
Ad-Hoc Provisioning Profiles are composed of three main elements:
Exactly 1 AppID
The Public Key of your Distribution Certificate
One or more Registered Test Device IDs
When you first generated this Provisioning Profile (about a year ago if your current one is expiring soon!), you instructed it to use your then current Distribution Certificate when constructing that provisioning profile -- the resulting Ad-Hoc Profile's expiration date is set to match the expiration of the Distribution Certificate as you can't launch an app signed with an expired certificate (Aside: This doesn't necessarily apply in Jailbroken scenarios...)
Your main question of 'Can it be fixed without revoking?' is a solid 'No' -- Even if you could make adjustments, the soon-expiring Distribution Certificate would cause the newly reissued Ad-Hoc Profile to have an expiry matching that of the Distribution Certificate. You'll be back in this same situation in 14 days when both your certificate and Provisioning Profile have both expired. Unfortunately at that time you'll also have a new problem, any existing builds you have out to your testers will no longer launch as the signing certificate and provisioning profile will have lapsed.
Instead, these last two weeks are your opportunity to be proactive and get your users migrated to a new build with a new Certificate and Provisioning Profile. With my own testers, I treat the last few weeks of my current Distribution Certificate as a migration window to get builds switched over and get my testers to download and install the latest test build so that they can keep going with their testing. The great news is that you caught your certificates expiring with more than enough time to get things straightened out and get your testers migrated -- some aren't so lucky and have to play catchup after things have expired and have testers shouting about your app crashing/no longer launching...definitely an undesirable outcome for any developer, especially if you are a one-person shop and having to coordinate both development and beta tester communications yourself.
So what do I have to do?
At a high level, doing the migration is nearly identical to getting this Ad-Hoc profile setup the first time -- It just requires cleaning up the old data from your Keychain and Provisioning Profiles as well as sending out some tester emails encouraging your team to upgrade once you make a new build available to them. At a high level this process looks like this:
Revoke your existing Distribution Certificate and reissue a new Distribution Certificate.
Delete the existing Distribution Certificate from your Keychain and install the new one.
Update and install the now 'Invalid' Ad-Hoc profile to use your newly created Distribution Certificate
Update Code Sign Build Settings if necessary.
Construct and issue your Ad-Hoc build to your testers.
Wait -- Won't revoking my existing certificate disrupt my testers?
Nope, not in the least bit! Your existing Ad-Hoc builds will continue to work perfectly well until after the expiration date because they have all the information they need to verify code signatures right inside the Ad-Hoc build you've already sent them. Once the certificate expires, however then things will fail to launch and you'll have screaming testers on your hands.
I'm going to assume that you are using an Individual account, so certificates will appear in the format "iPhone Developer: FirstName LastName" and "iPhone Distribution: FirstName LastName". If you are using a Company Account, then the format will be slightly different. I'm also going to assume that you only have your one account; if you are enrolled in multiple developer accounts, take extra care when searching for and deleting your existing certificates and profiles from Keychain as there may be multiple similar entries.
To begin, quit out of Xcode and then head over to developer.apple.com/ios login to the "Certificates, Identifiers & Profiles" area. This is formerly known as the "Provisioning Center".
Revoking and Reissuing the Distribution Certificate
Navigate to the Distribution Certificates Area.
Locate your soon-to-expire Distribution Certificate and revoke it. You'll likely encounter a message informing you that revoking this certificate will invalidate any linked provisioning profiles -- that is entirely expected and OK. In fact, that is exactly what we want it to do so that you can get things updated!
Click the 'Add' button in the upper right corner and walk through the steps to make a new "App Store and Ad Hoc" Distribution Certificate. Download the file to your machine, but don't install it just yet -- we should clean up the old certificate from your Development Machine first.
Deleting the Revoked Certificate and Installing the New Certificate
Open Keychain Access and search for 'iPhone Distribution'.
Delete any blue certificates that match 'iPhone Distribution'. The certificate icon may also show a red 'X' indicating that it is either expired or revoked. These may be cleaned up as well as they are no longer of use.
Double-click the newly downloaded certificate and install it.
Edit the Ad-Hoc Provisioning Profiles
Navigate to the Distribution Provisioning Profiles section and locate your Ad-Hoc Profile.
Edit that profile updating the test device list if necessary.
Click Generate and download the newly created Provisioning Profile. If the Generate button is disabled check that there are no special characters in the Provisioning Profile's name and that you've selected at least one test device.
Drag and drop the newly downloaded provisioning profile on to Xcode. Any old versions of the profile may be deleted from Organizer.
At this point you should be back in business and ready to update Code Sign settings if necessary (that is, if you set them to match a specific profile instead of using the Automatic Profile Selector option you'll need to update that setting to point to the now current version of your Provisioning Profile).
Again, you are fortunate in that you are taking steps to get this issue fixed while you testers are still able to use your app and not having to rush or hurry to get this done. Take your time and make sure to cleanup the older certificates and expiring provisioning profiles to make it easier for Xcode to figure out that you want it to use the newest profile.
I distribute a Windows desktop app which has all executable files digitally signed by a Verisign Class 3 Code Signing certificate. For the vast majority of users, this seems to work fine.
However a small number of users report the certificate is invalid. They say it comes up with the message "A certificate chain processed, but terminated in a root certificate which is not trusted by the trust provider". This corresponds to error code CERT_E_UNTRUSTEDROOT (0x800B0109). This has also been reported on a fully-updated Windows 7 machine. So presumably my certificate is OK, but Windows sometimes doesn't trust VeriSign certificates.
Why does Windows sometimes not trust VeriSign? Is there anything I can add to my installer (also signed) which will tell Windows to trust the certificate?
There are frequent updates of the Root Certificates which Microsoft rolls out via Windows Update, but which are tagged as "optional update". Hence not all users may have them installed and may need to install them manually. This also holds for "fully updated" machines, as the automatic installation is often set to only install "important updates", which the Root Certificate updates are not.
Depending on the type of desktop application, you may have to follow certain rules when signing, too. For example applications interacting with the Windows Security Center require essentially the same signing method as drivers. That is, the certificate chain gets embedded along with the signature (/ac switch to signtool). You can get the MSCV-VSClass3.cer applicable to VeriSign certificates here.
The process is often called cross-signing, which seems to be a misnomer. While this is one step in getting your driver binary or catalog cross-signed, the vital step is that Microsoft signs the driver (or more usually the catalog file these days), which is the actual cross-signing.