We Keep Coding

SSL Certificate X.509 Export

I'm trying to use a Web Service but I have many doubts about the certificates, I'm quite a novice in this topic, The team that developed the web services sent me a document where explains how to use it but to enable the connection, I need to USE a certificate (X.509), I generated p7b certificate from they website and I imported that certificate in my local environment, Using Keytool -import it generate a JKS file but they warn that I should install "Entrust" (Root and Intermediate) certificates that they provide me I used keytool -import with these .cer files and the command generated one .JKS for each file, I installed those cer too, my question is:
To use that web service Which certificate file I need to attach in my implementation logic in java, the jks or p7b ?
How I can use this certificate in all the Test environment? (I don't know if this certificate can be use only in the PC that generates the CSR).
I'm trying to simulate the call with the SOAPUI app i'm getting the authentication error so Probably something is worng with the certificate.
He implemented all using windows certificate store and .NET they can't give me support for keytool.

To do client authentication (also called mutual authentication) in SSL/TLS you (your program) needs not just a certificate but a certificate PLUS PRIVATE KEY and usually intermediate/chain certs. There are canonically 5 steps in the process:
On your computer generate a key PAIR which consists of a privatekey and a publickey, and a Certificate Signing Request (CSR) which contains the publickey. These steps may be done separately, or combined in a way that you don't notice there are both a CSR and a privatekey.
Submit the CSR to a Certificate Authority (CA) along with evidence of your identity and authorization as appropriate, and payment if the CA requres it.
The CA issues an 'end-entity' certificate (in this case a client cert) containing your publickey and identity(ies) plus some other information and gives you this certificate, usually along with an intermediate certificate or sometimes a few intermediate certs that form(s) a 'chain' from the entity cert to a trusted CA root or anchor cert. A 'p7b' file is one fairly common way, though not the only one, of transporting a group of related certs, such as your entity cert plus your chain cert(s).
You return the entity cert and the chain cert(s) to your computer and combine with your privatekey from step 1.
You use the combination of privatekey PLUS certificate chain with various program(s) such as a browser, a utility like curl, or a custom application.
Details of steps 1 and 4 (and 5) depend on the systems and software you use, which you don't specify in any recognizable way, although it sounds like you are ending up in the Windows certificate store. If that is the case, and it is specifically the Personal section of the current-user store (as opposed to a machine account like SYSTEM), then when you run MMC (aka Administrative Tools) and select the Cert Mgr addin, or directly run certmgr.msc, the icon for the cert should have a yellow key at the left:
Contrary to your Q, Java JCE (at least Oracle-was-Sun Java on Windows) can handle this; run keytool -list -storetype Windows-MY -keystore NONE and see for yourself.
However, some (probably many) Java programs cannot. For those, you need a keystore file containing the privatekey PLUS certificates; to create that run the Export wizard and select 'Yes, export private key', then format PKCS 12 (aka PFX) with 'include ... path'.
Recent updates of Java 8 by default can automatically handle a PKCS12 keystore (look for keystore.type.compat=true in JRE/lib/security/java.security) and older versions can do so if the program configures the store type (I don't know if SoapUI does that). For older versions that require JKS, after exporting to PKCS12 to let's say mykey.p12 convert with
keytool -importkeystore -srcstoretype pkcs12 -srckeystore mykey.p12 -destkeystore mykey.jks

What you try to archivee is something called a mutual-authentication. In order to understand the basics you need to understand that the humans have simply concepted a password to lock and unlock informations by the same (symetric) password. Everyone who knows the one password can
read the message
rewrite the message to send false informations
this is dangerous. So they have invented two different passwords, one for writing (private) and a compleatly different one for receive(public), we call them asymetric. The problem in asymetric encryption was, that you can choose free only one password, the opposite password is calculated and can not be choosen freely.
Finally they invented certificates to simplify the process. Certificates contains strong Passwords packed into files. Without looking into the certificates you dont know if the passwords are private or public, that means p7b(pkcsv7b) and jks can contain the absolute same informations. The difference is the format only, like the difference between .doc and .docx.
The second problem
In the big japaneese war's spionage was a big thing, the agents gathered informations about the opposite at the point of tactics and send theese informations to their real lords to find weaknesses in the tactics/strategys. Whenever a spoin has been uncovered he has been turned into a double-agent faking honeypots to let the warlord make wrong decisions and fall into traps.
So as an warlord you must trust your agent ... but, how to be sure? Well, you can ask the other agents about the agent you have the informations from to have the guarantee that the message can be trusted. So the first agent must ask other agents to sign the message too, this question between agents is the CSR! If the other agent(s) sign too, we have a "chain of trust". Ok we have four parties now, the agent, the signing-agent(s) the enemy(hacker) and you.
What must be placed where? Well, assuming you are a warlord (server),
you need the public passwords of all your clients(agents) in a truststore to send them messages(download),
you need to know your private password to encode messages(posts, requests, uploads) your agents sent.
Assuming you are a agent(client/browser) of a warlord inside the enemys lines (open field of world-wide-web), you must store:
your private key, to send messages and sign messages of other agents
the public key of the warlord to encode orders of your master.
You have learned now that a certificate can contain aswell private keys as public keys. How to technically use them?
You lucky, the keytools is open source, download the sources from grepcode (click here) and you will have your implementations by copy-and-paste.
Some hints for mutual-authentication:
The server should not offer its public certificate because all authenticated clients already have the public certificate(key) in their truststore.
The client's certificate should be sent in a non-electronic way (printed as rf-code or whatever).
The client should presented the server's public key and the clients private key in two seperate physical letters (you may noticed if you use the electronic-cash-card (ec-card) you had two letters, one for the PIN and one for the ec-card).

Corporate Java Webstart Distribution: use site-wide accepted certificate to sign a code-signing certificate

We are at a big organization with a several applications that are developed for internal and external use. One of those application is distributed as Java Webstart application and after a lot of trial and error we now have proper signing and packaging in place.
The only problem: we use a self-signed certificate. Users see a warning about an unknown/unverified vendor and this is just not nice.
Fortunately, the IT department of the organization has one certificate that is accepted on all workstations (via a site-wide policy, I assume). If we use this accepted certificate to sign the JARs and create the Webstart archive, everything should be fine. Naturally, the IT department does not want to distribute the accepted certificate to all developers or put it on the build server, because this would be against the purpose and introduce a lot of vulnerabilities.
What would be the right way to generate a code-signing certificate signed by this accepted certificate?
My assumption, based on what I know from normal openssl procedures to generate certificates used in web servers:
Generate a CSR with
Send CSR to IT security
IT generates a certificate from the CSR with accepted certificate. This certificate should have a short validity (1 week / 1 month / 1 quarter ?)
Import into java keytool for signing
Make sure keytool is only available to authorized users
Would this work? Are there any objections in terms of security or organizational obstacles?
If the above is correct, I would need some pointers especially with item 3. I found a somewhat related question: How do you sign Certificate Signing Request with your Certification Authority?.
Any help is appreciated.

If the corporation has its own CA root cert, which yes had to be pushed to every client/relier by some means such as GPO or installing all systems (or maybe their JREs?) from a customized image, then your approach is almost correct:
generate keypair and CSR
send CSR to corporate CA, they send you back cert
combine cert with keypair in keystore and use keystore
You can do all steps but the last with OpenSSL, but it's extra work:
1: openssl req -newkey or openssl genpkey|genrsa|etc then openssl req -new
3: openssl pkcs12 -export plus keytool -importkeystore -srcstoretype pkcs12
Since you want to end up with a Java keystore it's easier to just use Java throughout:
1: keytool -genkeypair then keytool -certreq
3: keytool -importcert
keytool is a program available on every machine that has any JRE installed; you can't effectively restrict it. It is the keystore file containing your keypair (and specifically your privatekey) that must be protected. Use a strong password; set file/dir permissions/ACL; keep a secure backup; all the usual.
On the other hand, if the corporation has a code-signing cert (and key) which is trusted because the cert was obtained from (issued by) a well-known CA like Verisign, they almost certainly cannot issue you a subordinate certificate. Only a CA cert (with its key) can issue subordinate certs, and while technically it is possible for a trusted CA to issue your corporation a CA cert, if you then issue any bad certs it reflects on them and can put them out of business (see DigiNotar) and they don't want that.

Is it necessary to add Ca certificate to pkcs12 certificate for tomcat

I am importing certificate and key from my customer and creating PKCS12 certificate for tomcat. The tomcat is configured to use this certificate as keystore. Do I need to import CA certificates as well from customer? If yes why?

If the CA certificate issuing your certificate is a "root" CA certificate (i.e. it is self-signed), it doesn't matter: if a party verifying that certificate doesn't already have it in its trust anchors, nothing will make it trust it.
It is generally more useful when the CA certificate is an intermediate CA certificate. In this case, it is relevant for the server to present the full certificate chain (except the root CA, which would be optional for the reasons stated above). Since the remote party might not have these intermediate CA certificates as known trust anchors, but might trust the CA cert that issued that intermediate CA certificate, this makes them more likely to be able to build a chain of trust from their trust anchors to the certificate to verify.
Strictly speaking, you don't need to present the full chain, but doing so makes it more likely for your certificate to be accepted.
(This is more or less the same problem as in this question. In addition, you're talking about a PKCS#12 store, so you would generally import the CA files in against the right "alias" (using the Java terminology) anyway.)
This being said, private keys should generally stay private. If you're trying to implement your own CA, there are mechanisms to do this in the browser, without sending the private key anywhere, which will let the user have a PKCS#12 file in return (if they choose to export their cert+key from there).

Find if a certificate is self signed or CA signed

I have a web app, which allows user to upload pkcs12. I store the pkcs12 as binary in database. Is there any way for me to know if the certificate in the pkcs12 is self signed or CA signed?
I am running a Java web app on tomcat and have openssl at my disposal.

Following email thread precisely tells the right way to verify if the base64 encoded certificate (i.e. PEM) is self signed or not: http://marc.info/?l=openssl-users&m=116177485311662&w=4
Following is the code snippet:
openssl verify -CAfile self_signed_cert.pem self_signed_cert.pem
should return:
self_signed_cert.pem: OK
OR compare the issuer and subject. If they are same, it is self signed
openssl x509 -in cert.pem -inform PEM -noout -subject -issuer

Edit: there are two better answers on this question today:
https://stackoverflow.com/a/57927684/377270
https://stackoverflow.com/a/14515875/377270
However, I think there's something more important to address -- why would one want to know about self-signed certificates. What's the goal? What problem is being solved? Probably trying to split certificates into two piles, self-signed and not-self-signed, is the wrong approach for most situations. The better approach is almost certainly going to be verifying that any given certificate has a valid signature chain from a trusted certificate authority, and that any connections associated with a given certificate matches the certificate.
Here's the rest of my original answer. It's probably not what you want.
It's a bit hacky, but the openssl x509 command can report both the issuer and the subject. If the subject and issuer are the same, it is self-signed; if they are different, then it was signed by a CA. (Strictly speaking, a great many self-signed certificates are also signed by a CA -- themselves.)
While testing this theory, I ran a handful of tests; it runs something like:
cd /etc/ssl/certs
for f in *.0 ; do openssl x509 -in $f -issuer | head -1 > /tmp/$f.issuer ; openssl x509 -in $f -subject | head -1 > /tmp/$f.subject ; done
cd /tmp
sed -i -e s/issuer=// *.issuer
sed -i -e s/subject=// *.subject
cd /etc/ssl/certs/
for f in *.0 ; do diff -u /tmp/$f.issuer /tmp/$f.subject ; done
Hope this helps.

The accepted answer here isn't strictly correct. Old question, but this is the first result in google for "how to tell if a certificate is self signed" so it needs to be cleared up.
A cert is almost always self-signed if the issuer and subject match, but it's not guaranteed. A certificate can be "self-issued" where it has the same issuer/subject but is signed by a private key that isn't paired with the public key in the cert.
The first part of the answer above from NitinB is the right way to check for a self-signed cert:
openssl verify -CAfile self_signed_cert.pem self_signed_cert.pem
"All self-signed certs are self-issued, but not all self-issued certs are self-signed."
Citation: https://www.rfc-editor.org/rfc/rfc5280
"Self-issued certificates are CA certificates in which the issuer and subject are the same entity. Self-issued certificates are generated to support changes in policy or operations. Self- signed certificates are self-issued certificates where the digital signature may be verified by the public key bound into the certificate."

Have you tried the BouncyCastle lib?
http://www.bouncycastle.org/wiki/display/JA1/Frequently+Asked+Questions
"
There are specific example programs for dealing with Attribute Certificates, PKCS12, SMIME and OpenPGP. They can be found in the packages:
org.bouncycastle.jce.examples
org.bouncycastle.mail.smime.examples
org.bouncycastle.openpgp.examples
Another useful source of examples is the test packages:
org.bouncycastle.crypto.test
org.bouncycastle.jce.provider.test
org.bouncycastle.cms.test
org.bouncycastle.mail.smime.test
org.bouncycastle.openpgp.test
org.bouncycastle.cert.test
org.bouncycastle.pkcs.test
org.bouncycastle.tsp.test
"

Java is unable to analyze PKCS12 so that you have to convert it to keystore using openssl.
Here the keystore has both private key and X509 certificate(or you can choose only to store certificate). Then get the issuer from keystore using standard JAVA API and manually verify issuer.

Details could be found in https://www.openssl.org/docs/man3.0/man3/X509_verify.html
X509_self_signed() checks whether certificate cert is self-signed. For success the issuer and subject names must match, the components of the authority key identifier (if present) must match the subject key identifier etc. The signature itself is actually verified only if verify_signature is 1, as for explicitly trusted certificates this verification is not worth the effort.

Verify certificate against Java certificate store via CLI

How can I verify an X509 (or DER-formatted) certificate against the Java certificate store via the command line?
I've looked into using the keytool utility, but it looks like it only handles import/export/display functionality (no verification).
EDIT: It looks as though keytool can be used for verification, but only if an import is attempted. I suppose a better way of asking this questions is whether or not a more passive approach (as in: not modifying the keystore) is available. Thanks!

You can use keytool to export the needed certificates (those that are in the chain for the one you need to verify) from the Java keystore into X.509 files. Then, concatenate them together into one file. Finally, use openssl to do the verification.
openssl verify -CAfile concatenated-certs.crt cert-to-verify.crt
Not a perfect solution since it involves popping the certs out of the truststore, but it ought to work given what you are starting with.

This page could be oversimplifying:
http://java.sun.com/docs/books/tutorial/security/toolfilex/rstep1.html
But it doesn't look like even import with keytool does a true verification of a certificate. I'm not seeing any description of verifying the signature of the incoming certificate against the signature of another trusted certificate.
jarsigner will verify a signature on a signed jar, but doesn't do anything to verify the signature on the certificate used to sign the jar.
I'm afraid you'd either have to write a tool to do the verfication, or look for a commercial tool that does it. I would think that some of the PKI tool kits would have a certificate verification tool that would do this.