A customer requested the development of an IOS application, and I've started the development with my apple developer account. I release some Ad-Hoc distribution for validation and the client eventually liked the result and decided to publish in the AppStore in his account.
The client gave me access to his account developer that I would generate the distribution provisioning and publish in ItunesConnect.
The client has two other applications, which are awaiting approval from Apple, which were published by another developer. My problem is that even creating my distribution provisioning, when I download and add to the XCode shows the message "profile does not match any valid certificate / private key pair in the default keychain."
I downloaded the distribution certificate that already existed in the account.
What should I do to fix this problem?
Many thanks,
Andre
You'll need the private key used to sign that profile (the .p12 file is used for interchange). Hopefully your client has it.
You may need to revoke and recreate the clients Distribution certificate, since it is unlikely they have their private keys if they didn't create their current certificates.
You might also consider downloading the clients certificates into a separate Mac User account, and building and signing their app using that account, so you don't mix multiple certificates into the Keychain in your own Mac user account.
Related
I have esp32-based devices in the field which are connecting to a back-end server that I fully control.
These devices include a default root certificate bundle
I am worried that one day, all these certificates will expire.
I want to avoid this problem for any future devices that I will deploy into the field.
What is the best long-term solution for the "expiring root certificate" problem?
I have the option for OTA updates, but I would rather find an approach that does not require me to update the devices once they are in the field.
PS: Maybe this is relevant: I will soon be migrating my back end from Heroku to AWS.
Theoretically, you could implement what a web browser does. There is a list of trusted authorities that sign certificates.
The easiest and cheapest way is to use LetsEncrypt, even though their service is oriented for https certificates, you could sign your own certificate. After you sign the certificate it is only a matter of going to their site to download the latest root certificate from your embedded device.
I am looking for device authentication where
I want to make sure that all calls to my web service\Website (hosted on Google App Engine) Is coming from an authorized device only, using a device certificate.
Each device will have a unique certificate that cannot be transferred to other devices.
A device certificate can be revoked anytime.
To achieve the above, I am planning to have another Service which would issue certificate to devices which is approved to use my service. I will issue the certificate via email to the user where he will install it manually. My users will use browser to access my service.
But I am not sure how would I achieve points 2 and 3.
Can you please guide as to how to achieve this using a self signed certificate?
I want to make sure that all calls to my web service\Website (hosted on Google App Engine) Is coming from an authorized device only, using a device certificate.
You can use a SSL channel with client authentication or adding a digital signature to your messages
Each device will have a unique certificate that cannot be transferred to other devices.
it is not possible to ensure this using software certificates. If you distribute them by email, the user could install them in several devices.
You could use a hardware token (nfc/bluetooth) or preinstall the certificate in the Android/iOS KeyChain so it would not be extractable. but this complicates the distribution very much.
A device certificate can be revoked anytime.
Check revocation at server side before accepting a request from a client. There are standard protocols to do this ( OCSP, CRL), or use a custom mechanism since you issue them yourself
I deployed an UWP app on Raspberry with Windows IoT Core.
What will happen when the temporary PFX certificate expire?
the app can still to run on device as the default/startup App?
From: https://msdn.microsoft.com/en-us/library/ff369721.aspx
What do I do if my certificate has expired?
So you have already deployed your application, and now your certificate (purchased or unpurchased) has expired, and you’ve examined the flowchart and determined that your customers are going to have to uninstall and reinstall the application. You can’t even issue an update. Visual Studio will not let you deploy your application with an expired certificate. So what do you do now?
If you need to extend an existing certificate, you can use a program called RenewCert. For details, you can check out my blog post How to extend an existing certificate, even if it has expired.
You can also find a version of RenewCert code on MSDN. I have not tested that specific version, but I’ve heard that it works with test certificates but not purchased certificates. Here’s the link if you want to check it out: http://support.microsoft.com/kb/925521
If you are already using a test certificate, extending it solves your problem. You can sign your deployment with the extended certificate, issue updates, and it will work fine. You can go to lunch, and the rest of us with known publishers can eat at our desks while we continue on. (Can you bring something back for us?)
If you are using a purchased certificate and it has expired, you can use an extended certificate to sign and deploy an update to your application, but it will look like a test certificate. This will seem just like any other update to your customer who already has the application installed, because it does not show the trust dialog when installing an update. New customers will see “Unknown Publisher” in the trust dialog because you are now using a test certificate.
So if your purchased certificate has expired, this enables you to issue an update to the application that programmatically uninstalls the current version and installs a new version signed with the new purchased certificate.
I am in a dilemma.
If I set that to distribution I can't test my application on my own IOS. If I set that to distribution I got this error.
Application failed codesign verification. The signature was invalid, contains disallowed entitlements, or it was not signed with an iPhone Distribution Certificate. (-19011)
So what should I do?
If you Archive your release builds and then use the Xcode Organizer to distribute them (using the various options from the "Distribute" button), then Xcode will re-sign your builds with your distribution certificates. So you should always sign your builds with developer certificates, and let the Organizer re-sign them with distribution certificates as needed.
When testing the build, sign the app with Developer Certificate. When releasing it for the app store, use the Distribution Certificate for Signing.
You won't be able to Debug your app with Distribution profile!
I want to be clear with a question about Sideloading applications for Windows 8 (for use within the company.) Read some articles about it, always write the application before deployment must be cryptographically signed (http://technet.microsoft.com/en-us/library/hh852635.aspx). I found how to sign my app (http://msdn.microsoft.com/ru-RU/library/hh446592%28v=vs.85%29.aspx), but there was a question where to get the key for signature applications. It can be purchased from Verisign, Comodo or a another? If so, what will it take, how much time it takes? Do I understand correctly that the App Packager is not needed for signing app, because the app package generated a Visual Studio, after that you must use CertMgr install the certificate to the domain and sign this certificate application with SignTool? If I'm wrong - please correct me, please
Thank you.
You should be able to generate certificate using Active Directory Certificate Services.
Here is a quick walkthrough on how to generate certificate from AD CS
Active Directory Certificate Services Step-by-Step Guide
If you're doing this without access to AD CS, you may purchase a code signing certificate from any Certificate Authority that offers a RFC3161 timestamping service. The time it takes to get a code signing certificate varies based on how long it takes the certificate authority to verify you are who you say you are.
You will need to manually timestamp the appx file, however, as VS2013 doesn't support using a third party CA's timestamping service when generating appx files. You need to timestamp the appx because otherwise the software will expire the date your code signing certificate expires.
This is how I use the signtool:
signtool sign /fd SHA256 /a /f YourCertKey.pfx /p mypassword /tr http://timestampserver.yourca.com/somepath YourApp.appx
Here is more information on using signtool to sign app packages: http://msdn.microsoft.com/en-us/library/windows/desktop/jj835835(v=vs.85).aspx
If you're attempting to sideload these appx files, you may also need to enable sideload privileges on the computers in question. If you aren't using a domain-joined Windows Enterprise on the client computers, this may involve purchasing side load licenses from Microsoft volume licensing or a partner.
Here is more information about sideloading: http://technet.microsoft.com/en-ca/windows/jj874388.aspx