I've got a weird situation here; I developed an app in 2011 using a macbook (private key: alida).. then a couple of months ago was having some problems migrating cert to another machine so just decided to revoke it and generate another certificate now using another set of private keys (francisco)
The situation is that now I have both certificates using two private keys in the keychain (and the old cert expired);
The question: is there a way to pair both priv keys (francisco & alida) with one certificate in the keychain? or I just have to left one of my apps behind? both apps I already in the Appstore;
Look hows my keychain (new machine) looks like:
Any suggestion on what should I do? is there any hope to fix this?
Thanks in advanced.
[edit]
another screenshots from the "my certificates" tab in keychain; so, basically I lost one my apps (no updates ever?) I think If thats the case, I will revoke current cert again and renew it with the keys from 2011 (first app generated) and forget the other one :/
In this context, keys come in pairs: (public, private). A certificate is just a file containing your public key plus some extra data including a "subject" which is information associating the public key to a specific person or entity (such as a DNS address) and, most importantly, a signature from a signing authority certifying (hence "certificate") that the public key is owned by the entity. These key-pairs are inextricably bound: there is no meaningful way to associate the private key from one key-pair to the public key/certificate of a different key-pair.
Normally, a signer (such as Apple in this case) will not generate two certificates with the exact same subject without revoking the earlier certificate first.
If you have an app at the iTunes store signed with a revoked certificate, it needs to be replaced with one signed by the newer, non-revoked certificate.
I think there is no way to pair both priv keys. You should now go with new priv key.
Related
We used a static value ‘usernameTest’ as username to request EJBCA to generate X.509 certifcates; after generating certificates using this satic username we changed it to a unique value identifiying uniquely each certificate (Since using a static username is considered as a renew since the username is the same for all certificates (*) ) but now EJBCA refuses to generate certificates and stil reference the old static username ‘usernameTest’; we get this error:
User '250320092916' is not allowed to use same key as the user(s) ‘usernameTest’ is/are using.
We revoked all certificates previously generated for username 'usernameTest', but we still get this error message from EJBCA. Is there any way we can remove username 'usernameTest'?
Each certificate has a unique SubjectDN and username.
The version of EJBCA is ejbca-6.2.0.
(*): All generated certificates in EJBCA Administration GUI are related to the same username.
Thanks in advance.
Tomas is correct. Go to your "Certificate Authorities" under CA Functions. Edit your CA and find the setting called "Enforce unique public keys" under the "Directives" section.
Uncheck enforce and you will be able to use the same public key for different users.
It has nothing to do with the HSM. The default policy setting for CAs is to not allow users to share the same end-user public key. I.e not to issue a certificate with the same public key to different users. This is a checkbox setting in the CA settings.
Problem solved; the problem is not that a reference to usernameTest still in EJBCA but that the same key (RSA public key) is used for the request of the other user ('250320092916').
It seems this is a known limitation when relying on the HSM PTK-C simulator from the Safenet ProtectServer series; the simulator restarts its random generator when we re-initialize it (I suspect a misuse from me), which means it will always generate the same keys in the same order (which leads to such errors).
But also the message error is not clear; talking about the "key" without specifying, this leads to a confusion with subjectDN or other attributes communicated to the EJBCA, as an error message it may be "public key" or "RSA key", ... instead of key ;)
You can configure the PTK-C simulator to not reuse the random seed (yes that is very annoying). For ejbca we have documented it here.
You have to set the environment variable ET_PTKC_SW_AUTOSEEDRNG=true. With this setting the simulator will generate real keys, a new one every time.
For iphone push notifications SSL certificates, you need to provide them with CSR files...
I have saved a CSR file since some time now, and i always give upload the same CSR file, whenever i want to generate the SSL certificates...
Now i've been thinking, since when generating CSR files, i'm actually generating the private key, and probably the public key too...
So i'm wondering what disadvantages i'm facing when i'm using the same CSR file.. though when i download the SSL Certificates, they appear in the keychain as if there's multiple private keys (though they have the same name) and each is attached to a different SSL Certificate.
Is it recommended to generate a new CSR file everytime? and why? and if it's not necessary, then how?
thank you
Certificate Request contains the public key and you have an associated private key. So by re-using it you basically get the same key pair signed again and again.
The disadvantage is obvious - if one key gets leaked, you get all certificates compromised. This is why re-generation of key pairs each time is necessary.
My distribution certificate is going to expire in few days. I have changed my system so I want to know that do I need the old private key to create new certificate signing requrest?
Also I wanted to know that is is necessary to use the same email ID that is used to create the developer account while creating new certificate signing request?
Thanks
If its already expired, don't worry about old certificates.
Else you need to export your private keys on your old system and then install your private key and profiles on your new machine.
I think its not mandatory to use same email ID to create new certificates.
No you do not have to know anything about your previous keys to generate new ones. Just follow the instructions in the portal, and generate new ones.
I just downloaded iphone sdk 4. when I try to install on the device I get
"Code Sign error: The identity 'iPhone
Developer' doesn't match any valid
certificate/private key pair in the
default keychain"
I have gone through the process of creating a provisioning profile and cert through iphone Development Provisioning Assistant. However, after installing the profile and cert the assistant asks to check whether public and private key are paired (surprisingly, it shows a pic of what seems to be a private key and cert being paired, i.e. the cert is 'under' private key in hierarchical terms. This is not the case in my keychain. Public key, private key and cert are there but there doesn't seem to be any associations.
Does anyone know how to pair a private key and certificate in keychain please this please?
ps. I have checked this thread but I'm hoping there's an easier way.
iPhone app signing: A valid signing identity matching this profile could not be found in your keychain
I wrote a wiki page (here) that describes how to export your certificate and private key pair. It's intended for my iOS development clients to send me their ad-hoc, but I believe it will solve your problem, too. The key is to make sure that you export the certificate and private-key PAIR all in one go -- not as two separate exports.
Hopefully, the screenshot near the bottom of that page will help out.
I'm creating application that will create certificates for users. I want to mark somehow those certificates so that later I can search them in windows user certificate store by following categories:
application GUID (or name - I want to know that this cert is for my application)
certificate role (administrative certificate or user certificate)
user email
I know that for the last one I should use "E = J.Doe#mail.com" or OID number "1.2.840.113549.1.9.1 = J.Doe#mail.com"
But I don't know which OIDs to choose for application GUID and certificate role.
Or maybe I should use "Key Usage" field?
I don't know if it's important, but certificates will be used to authenticate to my application and to decrypt data in database.
Are there any standard ways to do it ?
Hmm... so what I'm thinking is that you plan to issue certificates to each user and you plan to make a different certificate for each application. So if you had 10 users using 3 applications each, you'd be making 30 certificates.
And then the certificate also describes the user's role within the application, and the users's email.
To tell you the truth, I wouldn't put all this information in a certificate. PKI is hard to provision - users generally have difficulties setting up certificates, and reissuing certificates is a pain. Generally, PKI deployment strategies try to minimize the number of certificates that must be issued, balancing that with risk.
The most typical scenario I've seen is that a user is given a single certificate which he uses to identify himself. The certificate includes the user's name, and his email. But it doesn't usually include the user's role or the specific application. Instead, this information is managed on an access control server, that is queried when the user accesses the system. That way, the roles and applications available to the user can be changed without having to reissue the certificate. Products like Active Directory, or Select Access do this sort of thing.
The reason to separate into a separate cetificate per usage is to specifically control some type of risk. For example, if a single user where doing a high-risk operation on one machin and a low risk operation on another, more potentially risky machine, there would be a case to have two certificates (one for each machine) so you could revoke the low-risk certificate without disabling the high risk functions. If you plan to store all the certificates on the same machine, it would be easier to only distribute one certificate per user.
That said - if you still see a need to issue 1 cert per user per application per role, I'd recommend finding a way to jam the application GUID, role and email into the Distinguished name.
You won't get much mileage out of Key Usage or Extended Key Usage - these have very specific value and I doubt that they will convey the information you want to describe. Also, they are used in particular ways by various other applications, so if you need to integrate with other things, that could get tricky.
OK, after few hours I came with something like this.
All Certificates will be recognized by Subject field.
For Administrator certificate it will look like this:
CN=<My application Name> Administrator,OU=Administrator,OU=<My application Name>,O=<My company Name>
and for users
E=<User email>,CN=<User email>,OU=User,OU=<My application Name>,O=<My company Name>
If someone has better idea, I'm open for suggestions :-)
Your task is a quite complex task. To solve it the best way is to put on work a little internal certification authority with openssl. Keep in mind that PKI assigned to the entities you referred the following rule:
Distinguished name: it is used to identify the user or entity to witch the certificate is issued. It's no properly correct to use it for identify two different entity within a single certificate: your user and the application. The two entities shuold be identify in two distinct place.
Key Usage is a bit field with 8 digit that defines the usage of the key. Every bit has its predefinited meaning and cannot be used for other purpose.
I suggest to you to:
Put the application GUID as x509 extension. You can assign and personal OIDs to that exension and query for it. If you OIDs is use internally you can utilize whatever value you want. If you plan to distribuite your certificat eyou can obtain your own OID from IANA
Put the mail in the fields subject alternative mail, as suggested by PKI.
For the aministrative or user you can add a second x509 extension or create a tree of certificate. The main CA certificate, the admin CA certificate and the user CA certificate. Every certificate for admin will be signed by the admin CA, every user certificate by the user CA.