I have a certificate for a Glassfish server within a Java keystore. It has a 4part certificate chain, which I can see with the list command. Now one of the intermediate CA certificates has been revoked and I have to change the chain of my certificate, because it is now untrusted.
In the Windows IIS I have added the new intermediate certificate to the certificate store and all was fine. For the Java keystore I have no idea how I could do that? Should I export the certificate incl. the chain as PEM and replace the text parts for the intermediate CA? The CA says, I don't have to use a new certificate, it is only necessary to correct the chain, so it makes no sense to generate a new certificate request.
Any ideas?
Related
Can someone please help me with the following, I googled before hand but did not find a blog outlining what I wanted to do, thanks in advance.
I have and internal test PKI (based on AD CS). I have imported the Root CA certificate and the Issuing CA Certificate (minus their private keys) into the CACerts java key store (keying the GUI tool "KeyStore Explorer 5.5.1"
I have a leaf (end-entity certificate) 'outside of the Java keystore' as I want to simulate a situation where the client would obtain (be given) the leaf certificate via a WEB browser (for example when opening a TLS connection to a WEB server).
The leaf certificate is stored in a .pem flat file on the same computer where it was create (using Windows default method so private key for the cert is in the Windows keyStore). The computer also contains the Java KeyStore CACerts (where I imported the CA certs as above) and the Java JDK (so Keytool.exe for example)
So what I need to do (ideally using Keytool or a pre-made script suitable for Windows) is point to the leaf .pem certificate and say go check the certificate chain of this leaf certificate but using the CA certs held in CACerts keystore
Can someone kindly tell me how to do this as the only examples I have seen this far are about checking the chain for certs already in the CACerts keystore. Whereas I want to check the chain of a .pem flat file against the CA certs held in the CACerts java keystore
When I create an SSLServerSocket in Java 7 the server correctly uses my server certificate and key. The certificate was issued by a sub-ca of a ca. Therefore the complete chain from the root cert to the server cert has four certificates.
The complete chain is present in the keystore/truststore.
However when a client connects the server always sends only the server certificate itself.
This also applies to Java based web servers like Jetty.
Because most clients have only the root ca certificate installed and not the two sub-ca certificates this is a big problem.
How can I force Java to send the full certificate chain in the SSL/TLS handshake?
A key entry in a keystore isn't just for a single certificate, but for a certificate chain (see KeyStore.setKeyEntry, which takes a Certificate[] chain parameter).
If you want a specific chain to be used, it needs to be set up as a chain in the entry where you have the certificate and its private key. Whether the intermediate certificates are also in the same keystore, in different entries doesn't really matter.
This is a very similar problem to getting a client to send the full client-certificate chain. The same keystore configuration steps should also work from a server point of view, as described in this question.
I have 1) X509 Certificate (child) -> Authentication CA (parent) certificate and -> root CA (root) certificate.
Questions:
Can I retrieve this Authentication CA certificate from current X509Certificate certificate?
when I double click my certificate, I see the hierarchy of certificates. And from here, I can open each one. So, can I get Authentication CA certificate location or something like that from that certificate?
what ways can you recommend , in order to retrieve Authentication CA certificate?
I need to do this using java code. not key tool or something like that. I have Root CA certificate and X509 Certificate (child). and I need parent of child certificate.
I use bouncycastle and java's classes in order to work with certificates.
An X.509 certificate does not contain within it the certificate of the issuing CA. If you double-click on the child certificate and see a chain, this suggests that your operating system has access to the intermediate certificates (somehow).
If you need a chain of certificates, then you need to retrieve this from some external source. Many protocols (such as SSL) will provide a full certificate chain by default. The answer really depends upon the context of your problem, which is not clear from your question.
So this may be a stupid question but I have been scouring the internet all day trying to figure out how to get a trusted SSL certificate into my java server.
Details:
I created a java server that creates an SSLServerSocket accepts connections. I used keytool to create a keystore called domain.key as well as a certificate request (csr). I then contacted a certificate authority (starfield) and gave them my csr, they did their thing and returned to me the certificates (crt). I have 3 of them. one is called domain.com.crt, one is called sf_bundle.crt, and one is called sf_intermediate.crt
After much searching I found that I need to import the certificates into a keystore and that the keystore can be the same one that has my public/private keys or it can be in a seperate file. I chose to put it into a seperate file called domain.trust.
I then modified my server to import the trust store as well as the keystore using:
System.setProperty("javax.net.ssl.keyStore", "domain.key");
System.setProperty("javax.net.ssl.trustStore", "domain.trust");
along the corresponding lines for the keystore password and the truststore password.
The problem is that when i try and connect using any client it always says that the certificate is sell signed.
I have been using http://certlogik.com/ssl-checker/ to test it.
I obviously have missed a step but I cant find out where.
Any help would be greatly appreciated
The problem is that when i try and connect using any client it always
says that the certificate is sell signed.
This indicates that the root CA certificate is being send to the client.
You don't mention how you created this separate keystore you use.
You should be doing something like the following:
keystore.setKeyEntry("alias", privateKey, password, chain);
And chain would have:
chain[0] --> Your server's certificate
chain[1] --> The signer's certificate
....
chain[N] --> Signer up to the root
You first need to understand what happens during an SSL Handshake. Maybe then you can narrow down the problem. You can refer to various docs on internet., http://www.pierobon.org/ssl/ch/detail.htm
Your running server must have either have the CA StarField installed in it. Or it should have a trust relationship with the CA StarField.
You rclient certificate must be CSR signed by CA StarField, which I guess you have already done.
Now when you present your certificate to the Server, it checks with the CA's it has.
So, if the Sever has the CA StarField and your certificate is signed by StarField then there is no way you would get the Self Signed error.
You get that only when your certificate is not signed by the CA. Just open your certificate and check it's Issuer details to confirm.
Firstly, you seem to be confused about the difference between keystore and truststore. This answer may be of interest.
Essentially, unless you want to use client-certificate authentication, you have no need to change the trust store, from a server point of view.
After much searching I found that I need to import the certificates
into a keystore and that the keystore can be the same one that has my
public/private keys or it can be in a seperate file.
To be able to use the certificate you got from the CSR you initially had, you MUST import that certificate back in the keystore with which you generated the CSR, and you MUST import it, along with the whole certificate chain, into the correct alias, where the private key is stored.
This is essentially the same problem as the one in this question, but from the server side here.
Find the alias name that has your private key using keytool -list -keystore store.jks:
Your keystore contains 1 entry
myalias, Feb 15, 2012, PrivateKeyEntry,
Certificate fingerprint (MD5): xxxxxxxx
The prepare a bundle with your certificate and the chain of CA certificates in the right order (your own certificate first, and then each issuer one by one):
-----BEGIN CERTIFICATE-----
MIICajCCAdOgAwIBAgIBAjANBgkqhkiG9w0BAQUFADA7MQswCQYDVQQGEwJVSzEa
....
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIICkjCCAfugAwIBAgIJAKm5bDEMxZd7MA0GCSqGSIb3DQEBBQUAMDsxCzAJBgNV
....
-----END CERTIFICATE-----
(You can verify the content of each certificate using openssl x509 -text -noout and pasting each ---BEGIN/END--- block, including delimiters into its standard input.)
Then, import that file in a single step:
keytool -importcert -keystore store.jks -alias myalias -file bundle.pem
When I create an SSLServerSocket in Java 7 the server correctly uses my server certificate and key. The certificate was issued by a sub-ca of a ca. Therefore the complete chain from the root cert to the server cert has four certificates.
The complete chain is present in the keystore/truststore.
However when a client connects the server always sends only the server certificate itself.
This also applies to Java based web servers like Jetty.
Because most clients have only the root ca certificate installed and not the two sub-ca certificates this is a big problem.
How can I force Java to send the full certificate chain in the SSL/TLS handshake?
A key entry in a keystore isn't just for a single certificate, but for a certificate chain (see KeyStore.setKeyEntry, which takes a Certificate[] chain parameter).
If you want a specific chain to be used, it needs to be set up as a chain in the entry where you have the certificate and its private key. Whether the intermediate certificates are also in the same keystore, in different entries doesn't really matter.
This is a very similar problem to getting a client to send the full client-certificate chain. The same keystore configuration steps should also work from a server point of view, as described in this question.