I am a developer working on several iPhone apps. I am an administrator in our Apple dev portal team. The Agent of our team is NOT a developer. I understand that ONLY the Agent can request an ad hoc deployment cert, and prepare an app for ad hoc distribution.
I assume that the Agent can generate the certificate and pass them to me so that I can provision and build the app for ad hoc distribution, but I have read horror stories about using multiple certificates in xCode. Just getting set up for development testing on the device was complicated enough!
Has anyone dealt with this issue? What pitfalls are there in using multiple certs in xCode? I suppose that I would also need to have the Agents public and private key in my keychain.
It's not a nightmare, it can just get a little confusing, especially if you give your profiles unhelpful names like "distribution profile." If you expect to have multiple sets of profiles, certificates, and keys on your computer, make sure they are named so that you know what goes with what and belongs with what.
I posted some recommendations in this area a while ago.
My number one piece of advice is to give your private keys descriptive names. Fortunately, you can do this at any time in Keychain Access. By default they are simply named "Private Key" and if you lose the certs you'll have to resort to some openssl geekery to figure out which key goes with which.
You are expected to use separate development and distribution certificates; you actually set up different configurations for them. The "nightmare" comes when you use several different development certificates. If anyone touches the certificate setting on the Debug configuration, it must thereafter be set manually (which is a pain in the ass, of course).
So no, there's no problem with the Team Agent giving you his distribution certificate and private key (you'll need both). He needs to realize that Apple will hold him responsible for your distribution of packages, though.
The main issue is that you'll need the Agent to export the private key they used to generate a certificate request for on the portal. The portal has instructions for backing up and transferring that private key... only when you have that key on your system can you make use of the certificates they create for Ad-Hoc.
The docs at this point for the whole process are pretty good, but you must read through them very, very carefully and follow eery step to the letter.
Related
My team uses a certificate to sign our Windows Application. Unfortunately the Certificate is expiring soon and we need a new one.
We want to avoid the SmartScreen that pops up when installing apps signed with new certs and I am reading that EV Certificates come with built-in reputation.
Microsoft provides a list of authorities that sell code-signing certs, but from my understanding all of these would be a physical device that one of the devs would have to keep at their house.
We don't want that. Is it possible to have something on the cloud that we can all use?
Yes, it is possible to do EV code signing in the cloud without requiring a physical dongle that you keep with yourself. In fact, we do this at my company. Here is how:
Create the new signing key in a cloud-based HSM or KMS
Integrate your signing tool with the cloud-based HSM or KMS
For #1, there are several options including AWS CloudHSM, AWS KMS, Azure Key Vault, Google KMS, Entrust's nShield as a Service, Thales' DPoD, etc. They all have various pros and cons so you need to know your technical requirements ahead of time. Two items to definitely know are the list of signature algorithms the signing tools you use require and your CA's attestation requirements.
Some tools like signtool allow you to specify the hash algorithm you want to use. Unfortunately, other tools don't give you an option and you are stuck with the hardcoded hash algorithm. Two examples are Apple's productsign which currently uses SHA-1 under the hood for one of the signatures it produces and Microsoft's VBA Macro signing which uses MD5 under the hood. Not all of the KMS offerings support all these algorithms and, until they do, you would not be able to sign with those algorithms and your key wouldn't be useful (most only support SHA-256, SHA-384, and SHA-512, although Azure Key Vault does support RSNULL which allows you to get around this).
For key attestation, depending on your CA, you may need to provide an attestation for your key that chains up to a hardware root of trust, which only some of the HSM/KMS providers support. Other CAs may allow you to show them your cloud environment remotely (e.g., via Zoom or something) to show that the key is protected in hardware, and others just require you to sign a document stating that your key is protected.
Price is the next obvious factor. Some charge per hour (or other time unit) that the HSM is on, while most of the KMS options charge a small fee per key and per usage. Generally, if you only have a small number of keys, one of the KMS options will be the cheaper and easier choice. But once the number of keys grows, a dedicated HSM might become more cost effective.
After you pick your cryptographic device, you will need to integrate your signing tool with it. This is done with a cryptographic provider. Providers are unique to the platform you are signing on. For example, on Windows you need a KSP (or a CSP for legacy systems), Java/Android requires a JCE provider, macOS uses a CTK provider, OpenSSL uses the Engine framework (although that change in their latest release), Linux uses a mix of GPG and PKCS11, etc. Some HSMs provide some of the cryptographic providers, but not all. The KMS options don't have them at all and you're left writing your own code.
Then there is the issue of authentication/authorization, performance, auditing, and more. You will eventually find yourself in the boat where you want to auth/authz via your identity provider (e.g., Active Directory, Azure, etc.), you want client-side hashing to improve performance, you want all kinds of audit requirements, etc. For these reasons, and others, we use a tool called GaraSign for all of this which provides everything we need out of the box. Here's their code signing page.
SSL.com also provides remote signing for their EV Certificate. It's a paid service called eSigner.
I have a specific need inside my organization and want to know if it would be possible. Any suggestion would be appreciated;
Inside my organization, for several reasons, there are distributed a lot of certificates installed inside each worker computers. Each worker may have maybe 5 or 6 certificates to access several webs, sign documents, etc. Each time a computer is broken and reinstalled, or a new worker is hired or someone is fired, the management of that certificates, become a real headache; removal, re-installation, etc.
I am proposing to my organization to develop some kind of certificate repository to centralize the several certificates of my organization.
My questions are about to the possibility to develop and change or implement the keystore o a new CSP or KSP so this new crypto provider could access a central service/server/repository to present (authenticate), and sign documents every time a specific user needs it.
In the case of computer reinstallation, just installing the developed driver/csp, would give access to the central certificate repository.
The concrete questions are if you think it would be possible to develop that driver/CSP/KSP piece of software and what is your opinion about the possibilities to implement it successfully in a maintainable way into MS-Windows environments. How would you focus this development?, just some tips about what it would be possible or not.
Regards,
Definitely it can be done because there are solutions like RedTrust from Evolium that do exactly this.
A centralized certificate store that also allows to manage the usage of the certificates.
It's hard to fully understand all this certificate stuff for IOS development and it's implications.
One piece of info I can not find in the docs or via google: In order to join multiple developer programs (when working on software for different clients), should I create a unique developer certificate for each, or can I use the one I already have?
Is there an advantage/disadvantage in either way?
You can use the one you have, but I suggest you make specific ones for each client. Certificates expire, so multiple certs gives you more flexibility when re-creating, re-building, and re-submitting apps. You also may want/need to share creds with other devs or testers. With multiple certificates, you can share specific ones without sharing all of them.
But you're right, this stuff is very confusing.
My best advice: name things carefully and well.
We have a code-signing certificate, purchased from GlobalSign for Authenticode signing (as they call it). Now we need to sign Java applet and soon Adobe AIR module (applet?). The question is: from technical point of view is there any difference between certificate-for-Authenticode and certificate-for-Java or certificate-for-AIR, if they are issued by the same CA (say Comodo or GlobalSign)? I don't see a point in buying different certificates if they are replaceable.
I understand that key usage field of certificates must be the same (code signing), but maybe extended code usage or policy or other extension differs in those certificates. I would appreciate if somebody who has code-signing certificates of two or more types issued by one CA could check this for me.
There's an explicit statement at http://www.adobe.com/devnet/air/articles/signing_air_applications.html that:
"A developer can use any class-3,
high-assurance certificate provided by
any CA to sign an Adobe AIR
application."
Unfortunately, I can't find anything similar for Java. However, regardless of the minimum certificate requirements for the various platforms, your best bet might be to contact your existing certificate provider to ask if there are any meaningful differences between the certificates they offer for these platforms.
Some of the blah-blah on the Verisign website suggests that the format in which the certificate is delivered to the purchaser is the only real difference between their offerings, but they don't actually state this directly, so who knows...?
From what I gather from RFC 5280, the key usage extensions can only decide whether the certificate is usable for code signing or not. There doesn't seem to be anything in the RFC that can constrain whether you sign Java code or AIR or whatever. This seems to imply that if you can sign one piece of code (or any other kind of non-key data) you can sign any.
That said, there may be CA-specific extensions in your certificate. Without seeing the certificate it's hard to tell if there are limitations.
From a technical perspective, as long as the client (i.e. the browser if we're talking about applets) recognises the CA and is happy with your combination of key usage and certificate type (DIGITAL_SIGNATURE and OBJECT_SIGNING) then you should be fine.
It seems that any code signing certificate will work for any mentioned platform. I asked GlobalSign support about the difference - they didn't respond, however soon after that they have changed their web page and now you would be buying one code signing certificate for all platforms.
My guess is that the answer is "no", but I figured I'd ask anyway.
Lets say that I have a shared library that multiple applications build into their executables. Now lets say that this shared library provides an API to some web service that uses the same username/password for all n number of applications that use the library.
Is it possible then to set the username/password in one place such as the system settings and allow multiple applications to access the settings, or is NSUserDefaults still completely sandboxed?
This seems like the sort of thing that the keychain is for, but can you use it for arbitrary data vs. just authentication data? Can a settings bundle be used to change keychain data shared between apps with the same apple id prefix?
You can store arbitrary data in the keychain, and I swear that I read
somewhere that apps with the same bundle ID root can share a keychain. Can't for the life of me find the reference now.
Maybe I dreamt it.
EDIT
I'm pretty sure it was in the KeyChain Services doc, but all references to it seem
to be gone.
At the time I thought it was so interesting that I jotted it down:
can use "bundle seed id" to share keychain access between multiple apps w. a single app ID
That's it. I haven't checked it out yet, so I'm not sure if it means you can make and distribute several apps that use one keychain, or if it just means that successive versions of one app see the same keychain.
I'd love to be able to find the original reference.
Here's a developer forum post that says it's possible.