We Keep Coding

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.

How to connect with CA to sign ssl certificate?

I have never done https so far, but trying to get grips with it. I understand how to do self-signed certificates which is from what I understood is completely pointless as browsers will fire up straight away the warning. "As one cannot say trust me because I am honest."
From SO posts I understood that Tomcat or any other server environment is responsible for configuration. All clear and good.
The confusion is how these certificate signed when not self-signed. In other words, how do I point my keystore to CA provider.
I am following guide:
http://consultingblogs.emc.com/richardtiffin/archive/2010/10/15/applying-ssl-to-a-spring-web-application-on-tomcat.aspx
The problem is that I don't know what happens after I buy certificate from CA. Do I get a file which I need to point my keystore to or I import keystore itself remotely?
For self-signed we do:
"
Generating a keystore file (Self Certification)
The keystore file is the one which would store the details of the certificates necessary to make the protocol secured, to-do this we'll use the keytool provided as part of JDK 1.6, the following should create the keystore :-
From your Java installation directory %JAVA_HOME%/bin
keytool -genkey -alias emc -keypass password -keystore emc_tomcat.bin -storepass password"
This implies that for not self-signed the details must come from CA provider? So need to add something to the line(URL path?)? Or is it the client responsibility to verify whether my certificate is valid...then how do I link my certificate to the one I purchased. I am completely confused.
Rephrasing other way: how to install CA from official CA providers?
Or I am telling complete rubbish and missing something fundamental. :-)
My apologies if there is duplicate, I've spent quite good bit of time of researching SO and reading wikipedia articles, but the internal mechanics are very difficult for novice users. I've marked bold the actual questions for people short on time. Thanks.

All the information you are asking for is readily provided by any reputable ("trusted") CA. See for example http://www.digicert.com/ssl-certificate-installation.htm
Quoting:
After you create your CSR, purchase your certificate, and the SSL
Certificate validation and processing are complete, you are ready to
install your SSL Certificate(s).
Your certificate will be provided via email or will be available to
download in your DigiCert Management Console. The SSL Certificate is a
text file with encrypted data that your server will use once the
certificate is installed
And following down the Tomcat link:
Tomcat SSL installations can be a bit tricky, but don't worry. Our
knowledgeable support staff is familiar with both the keytool utility
as well as common Tomcat installation methods. We will be happy to
help you generate your Certificate Signing Request (or CSR), install
the certificate to your Java keystore, and configure your server to
use it via either the Tomcat Admintool utility, or by editing the
server.xml configuration file directly.
It seems that this answers all your questions... "buy it and you will see how easy it is".

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.

Last attempt at SSL/TLS

I have been trying to get openSSL/JSSE from Cpp to Java working for weeks. If I can't find a solution I am just going to disregard the whole idea. No matter what I seem to do I keep getting a "sslv3 alert certificate unknown" error. I have a self signed key that works fine on the server en of things but I get the error when connecting to OpenSSL's s_server utility. I have been looking for a solution for weeks. Help would be appreciated! I have a self-signed crt file and a server.key file. I put the cert in the java keystore but I still get the error

Your self signed certificate is probably what is causing your problem.
This site has basic dirty instructions on creating a CA and this site has similar instructions but is a little more verbose.
Here's the way you need to have this play out:
Create your CA
Create your certificate for the server
Create two keystores,
Server keystore containing the server private key, server public certificate (signed by the CA), and the CA certificate.
Client keystore containing only the CA certificate.
This site gives you the system properties needed to configure the java engine to use the keystores as well key stores and trust stores. The trust store will be needed on both ends to allow correct verification of the certificates in question.
As far as the s_client utility, you will have to use the -CApath option to point to the directory containing the CA Certificates you trust or -CAfile to point to your self signed CA as trusted.
Just comment back if you need more help. This is frustrating but once you get the basics down you'll be a pro in no time.

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.