I am working on ADFS external authentication project. I am using a self signed certificate, which is imported in Trusted people store. I need to verify whether importing a CA certificate to Trusted people store work or not.
When I tried using the CA certificate in Trusted people, it does not work. Can you explain why?
You can use self-signed certificate or you can purchase from third party vendor it will work if you import into any ADFS store or trusted store. But the certificates must met the ADFS certificate requirements. Kindly check the requirements in this link
Related
I have some difficulties to understand the difference between code signing and PKI.
Is it possible to use a PKI (with a hierarchy of CA) to issue certificate used to sign code source, and then use the revocation to invalid some software (for instance an old version that should not be used) ? Or are X.509 certificate incompatible with code signing and i'm missing something ?
Thanks your very much.
The PKI is an infrastructure that allows you to issue certificates with which you sign your binaries (among other things). You don't sign the source code.
You can create a separate certificate for every software release you have, however, I didn't see anybody use it this way and for that purpose.
Usually you enroll a few certificates and use them to sign all releases until they expire.
Even if a certificate does expire, it won't prevent from the customer keep using your software.
I gather that most developers (except perhaps for larger companies) use self-signed certificates to sign their apk. Since this is required for app installation, the ability to sign your app is available to anyone. Fairly simple to use keytool and jarsigner from Java SDK. However these self-signed certs and associated private keys do NOT guarantee any degree of security unless you can somehow match that certificate with someone you actually trust. There is no ability to revocate these self-signed certificates (no CRL) and there is no "issuer" (since the certs are almost always self-signed) who "vouches" in some way for the identity of the certificate/key holder who signs the code.
So does Andriod platform have or plan to have any ability to prevent installation of apps SIGNED WITH A PARTICULAR SIGNATURE? or to enable settings only allowing installation of apps signed by a cert/key issued by a list of trusted CA (certificate-authorities/issuers) ?
However, there is some security available: In settings/Security you can prevent installation of anything (even signed and manually copied to your SIM) unless it comes from the Play Store, the default setting. Also you might be able to install a User certificate and ONLY allow apps signed by that cert to install (even if from the Play Store?).
I dont think the purpose of these certificates is to ensure an identity as a normal certificate signed by a CA would. As it seems to me the purpose of the certificates is just to have an extra security factor to ensure that the person that published the app for the first time is the one that publishes updates.
Without this someone that hacks your google account would be able to publish malicious updates to you entire user base.
So I would say its basically a two-factor authentication for publishing.
VSTO ClickOnce wants to add a certificate to the published client deployable. Is there anything wrong with using a test certificate for this even in a Live environment - note we are on an Intranet (and hence trust isn't really an issue).
If we use a Test cert. in Live will it ever expire - if so, can we make it not expire
For intranet you can create your own code signing certificate by setting up microsoft certificate server or use makecert.
With this approach you can create a certificate with 10-20 year of validity and use certmgr to register. This new certificate can be used in visual studio to sign your project.
I'm working on an Eclipse-based product and am currently facing an issue when installing plugins on it. Despite the certificates being issued by VeriSign (and the plugins being properly signed with the certificate on export), when installing the "Do you trust these certificates?" window still pops up.
Now, the question is, is this the expected behavior? I was hoping that once we used a trusted CA then we wouldn't have to deal with users facing this dialogue. And if not, any tips as to where I should look to start fixing the problem?
You can find images of the trust certificate window here and the details for the cert here
Short answer: Your certificate is missing an e-mail field in the subject.
When we moved to using a software vendor certificate from an individual developer certificate, we encountered the same problem. The only difference between our certificates is that the individual developer cert has an e-mail address in the subject (the field named "E") and the new software vendor cert does not. GlobalSign allows you to reissue certificates, so we reissued our software vendor certificate with a generic e-mail address in the subject field. That fixed the Eclipse problem and customers no longer see the "Do you trust these certificates?" window.
By the way, our certificate does not have an Organizational Unit defined, and that does not cause problems with Eclipse.
this is mostly a deployement than a programming question.
If I were to buy an SSL certificate from a CA, would I be able to use it to sign other applications (such as symbian, android, iphone ones)?
You need to get two different certificates. One to secure a server (https) and one to sign code. You can compare code signing certificates here
Server certificates (those that you'd use to enable HTTPS on a web server) are rarely enabled for code signing. I haven't looked at every CA in the world, and there probably are exceptions, but the more "legit" a CA is, the less likely they are to issue one certificate for both applications. In the end, I wouldn't expect to use the same certificate for both.
There is a better chance that a single code-signing certificate is accepted by most platforms. The developer documentation of each platform should list what CA certificates are built-in as trusted roots. In addition, most platforms will allow a user to view and modify the list.
You need to buy a certificate that is specifically authorized for code singing. In other words, the certificate must have the Extended Key Usage (EKU) for Code signing. Object ID (OID) for code signing can be found here
Most commercial CA's should be able to tell you which of their certificates have this.