I want to sign an applet using netbeans, but i don't want to self-sign it because since the Java 7u51 was released it is considered as unsigned. How do I get a keystore password?
You're asking the wrong question.
You need a keypair.
You need a CSR.
You need to get the CSR signed by a CA.
All this stuff goes into a keystore, and not the one that came with the JDK or JRE. That's a truststore, and has an entirely different purpose.
So, you need to either create a new keystore, with the keytool, in which case you get to choose your own password, or you need to use an existing keystore, typically $HOME/.keystore, in which case you must already know its password.
Then you do:
keytool -genkey ...
keytool -certreq ...
Get the CA to sign the CSR just generated.
keytool -importcert ..., importing the signed CSR, using the same alias as at 1-2.
Note that NetBeans has nothing to do with any of this.
Related
we run a standard web API over https with a regular purchased SSL certificate. Our clients just access it via https, the certificate is trusted via default system RootCA.
A new client is using a Java communication server that requires the certificate in a PKCS12 keystore. How can we generate the PKS12 keystore from our key/csr/crt/pem files?
I did some research, most examples are requiring a private key. Of course I do not want to share our private key with the client.
Can a PKCS12 keystore be created without private key, similar to standard RootCA in browsers?
Thanks, bluepuma
YES-ish.
Although PFX-now-PKCS12 was designed primarily to store or transfer a privatekey and cert and chain cert(s) as a clump, and most commonly is used for that, it is capable of storing one or more 'lone' cert(s) not matched to any privatekey. And you are correct the client wanting to connect to you should have in their truststore ideally the root cert for your server cert's chain, or alternatively your server cert itself, but decidedly not your privatekey.
openssl can actually create such a PKCS12:
openssl pkcs12 -export -in certfile.pem [-name $name] -nokeys -out blah.p12
# if you don't specify -name it defaults to 1 (the digit one) which can be mildly confusing
# instead of being prompted for the password you can use -passout with several forms
# described on the openssl man page, but consider the warning below
But the result won't work in Java if they use the standard (Sun/Oracle/OpenJDK) cryptoproviders, which (in 8+) support lone cert(s) in a PKCS12 as 'trustedCert' entries in Java only if the(each) certbag has a special Sun-defined attribute which the Java providers write when they create such a file, but OpenSSL doesn't.
Instead use Java's keytool in 8:
jre8/bin/keytool -importcert -keystore blah.p12 -storetype pkcs12 -file $certfile [-alias $name]
or in 9+ where pkcs12 is now the default:
jre9+/bin/keytool -importcert -keystore blah.p12 -file $certfile [-alias $name]
If you don't specify the alias it defaults to mykey. In both cases you can add -storepass $pw to avoid being prompted for it, but as a result the password will be visible on your screen, in the command history of your shell or other command processor it is has one, and in most cases to other processes run on your system concurrently, (any of) which may be a security issue or not. You can also add -noprompt to avoid the confirmation prompt.
But user207421 is (roughly) correct that using such a truststore can break other SSL/TLS connection(s) made from their system, at least from the same JVM, unless the individual calls specify individual, separate truststores, and if they had coded that they would know how to handle (and ask for) a simpler certificate format, such as PEM.
I'm using java keytool to generate keystore for server.
It contains
1.CN
2.OU
3.O
4.L
5.ST
6.C
But customize CA only has
1.CN
2.OU
3.O
4.C
How to generate keystore only with C/O/OU/CN by JAVA keytool?
It's not clear to me what you mean by 'customize CA'.
If you are talking about the selfsigned cert created automatically by -genkeypair, which doesn't actually involve any CA although it does have a name in Subject and Issuer, the latter of which would normally be a CA name:
if using prompting answer the applicable questions and enter nothing (just CR) for the others
if using -dname specify the desired attributes and don't specify the others
If you mean requesting a cert from a CA, you can control what goes in the request (CSR) with -dname, but the CA can ignore that; only the CA controls what goes in the cert, and since you haven't said anything about who the CA is, it's impossible to even attempt to answer.
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.
Some quick background on what I'm trying to do: a client is using a third party web service that requires mutual authentication. The service requires the client certificate be signed by a public certificate authority (ie: not self-signed). The client has some software written in Java that connects to the service, hence they used Java keytool to generate the original signing request and the key/certificate are stored in a jks keystore.
Our software that the client is going to be using is written in C#/.NET and will need to connect to the third party web service. As such we will we need to be able to access the client certificate.
I can't seem to find any way to export the certificate (along with private key) to either the Windows Certificate Manager or some other format that can be opened by .NET security libraries.
Exporting to a PKCS12 file does not work because keytool does not support it for trusted certificates (not sure if that is a keytool limitation or a limitation of the format).
I also found some Java code for getting the private keys, but I can't seem to figure out how I can get that into Windows Certificate Manager and associate it with the certificate. (How do I list / export private keys from a keystore?)
As a side note, the client doesn't want to generate a new certificate as there is a whole process involved in sending it to and getting it approved by the third party service they are connecting to.
Ultimately I'm hoping there are some commands I can run with keytool/openssl/etc that will allow the certificate & key to be exported/transferred into the Windows Certificate Manager (or some format that it can import).
(Sorry if my terminology is off or if some of this doesn't make sense. I kind of got stuck supporting this despite not being all that familiar with managing certificates.)
This seems to work for exporting the certificate but not the entire chain, the trick is to specify the srcalias:
keytool -v -importkeystore -srckeystore .keystore -srcalias mykey -destkeystore myp12file.p12 -deststoretype PKCS12
Thanks to Warren for pointing me to this: How to export private key from a keystore of self-signed certificate
Current situation:
We do a POST to a certain url using HTTPS/SSL. For this to work my (former) colleague posted this question: Java HTTPS client certificate authentication
So basicly we have a keystore in .p12 format and the truststore is a .jks file.
We have no control over the server that receives our POST request.
Issue:
The server admins have provided us with some new .der files because their old certificate was about to expire.
As I'm fairly new to SSL certificates and keytool- and openssl-commands I have no idea how to proceed from here.
1) Is it necessary to generate new .p12 and .jks files? Or do I only need to generate a new .jks file?
2) How do I generate these files from a .der certificate? I have found some websites with the most keytool/openssl commands but I haven't been able to successfully generate what I need.
The last command I tried (to no avail) was:
keytool -storepass dsmserver -keystore c:\temp\newkeystore.jks -importcert -alias "c:\temp\newcert.der" -trustcacerts
Wait, which certificate expired? If it was theirs, there shouldn't have been any need to send you a new file (after all, you don't have to update your browser when, say, stackoverflow.com's SSL certificate expires and they install a new one). If you're doing mutual authentication (client certificate authentication), then there are four certificates involved: your certificate, their certificate, the certificate of the authority that signed your certificate, and the certificate of the authority that signed their certificate. They send you their certificate and you check to see that it was properly signed by a certificate authority that you trust (that's what the truststore is for - it's a list of the certificate authorities that you trust to sign certificates from their side). Subsequently, you send your certificate and they check to see that it was properly signed by a certificate authority that they trust. (Of course, all of this is automatically done for you behind the scenes in JSSE by the SSL handshake procedure)
Remember, a certificate is a (signed) assertion that such-and-such name is identified by a particular public key. So if their certificate expired, they'll generate a new one, get it signed by a CA that you already trust, and replace the old one with this one. When your software (automatically, as part of the behind-the-scenes SSL handshake) gets the new one, it will check to see who the signer ("issuer") was and if it's in your list of trusted authorities (and properly signed). If this checks out, you'll accept it automatically. They don't need to send you anything out-of-band to make this happen, unless they're changing certificate authorities and you don't already trust the new one. If so, you can use
keytool -import -keystore <truststore> -file <certificate file> -alias <someca>
If, on the other hand, your certificate is the one that expired, then they shouldn't be sending you anything unrequested. Instead, you should be generating a CSR via:
keytool -genkey -alias <myalias> -keystore <keystore>.p12 -storetype pkcs12
keytool -certreq -alias <myalias> -file request.csr -keystore <keystore>.p12 -storetype pkcs12
This will update the keystore with a new private key and create a file named "request.csr" which you should then send to them (or to a CA that's in their truststore) for a signature. They will respond with a signed certificate which you will then import back into your keystore using:
keytool -import -alias <myalias> -file <signed certificate>.cer
If I had to guess, it looks like they tried to perform these three steps for you, and tried to send you the certificate and the corresponding private key, which is invalid - Java will (rightly!) try its best to stop you from importing that because the private key itself was tainted when they sent it over an untrusted channel (e-mail, I presume?) This defeats the purpose of PKI - nobody should ever have access to your private key except for you.
Download the file from the below link:ImportKey.Java
Run the following commands:
javac ImportKey.java
java ImportKey key.der cert.der
- arg1 is your key and arg2 iscertificate.
Commands will put your keys to Java Key Store.