I use SSL to communicate between two components written in Java. I can't use a CA, so I have to self-sign everything. Unfortunately, this means that when I try to handshake, I get a SunCertPathBuilderException. I can create my own X509TrustManager that just trusts everything, but that sort of defeats the purpose of having a signed cert.
I would like, when first making the connection, to prompt the user with "SSL handshake with invalid cert. Add cert to store?" or something so they could have it added for them to their certificate store, like web browsers do at sites with invalid certs. I can find plenty of examples online of adding a cert to the store through the commandline, but I can't figure out how to do it programmatically. Is there a way to do this?
Yes it is possible.
There is some code here that I've used before. I had to modify it to do what I wanted and I suspect that you will too but this should get you close - you aren't trying to import a key so theoretically you should be able to simplify things. In any case you can get an idea of what you'll need.
The JDK JavaDoc for java.security.KeyStore is pretty useful too.
Why don't you create your own CA and sign your certificates with that? Then all you would need to do is install the CA own certificate on the machines and every certificate signed by that CA would validate.
Why would you need to do this, you are not validating that the client is who they say they are you are only using the certs to encrypt the comms, so a custom trust manager that allows all certs is all you need.
What you are asking is possible and from memory also involves a custom trust manager to validate the certificates and store them in the keystore. I can't remember the details, but at least you know it is possible to do it.
Related
I need to write a Java program using Bouncy Castle to validate certificate chains. By searching through the reference, I find the cert.path package, and I tried to use it. Here is the code I have written. However, when I run it with Facebook certificate chain as input, I got a weird behaviour. The chain is made of a server certificate, an intermediate CA certificate, and a root self-signed certificate. The validation outcome is ok if the input is:
Server and CA cert
Server cert
CA cert and Server
The validation failed, with unhandled extensions key usage and basic constraints, if the input is the whole certificate chain. Can someone point me out how can I correctly validate a chain using also system root certificates?
I found a lot of examples online using java.security package, but since I'm comparing different libraries to validate certificates, I would like to perform the task using only Bouncy Castle packages, if possible.
Thank You,
Nicholas
I have a question about the usage of ssl in java.
My need is quite simple, to connect to a server (https, ldaps, ...), using the CA certificate of the server (pem format)
When using api as curl or many other I guess, in C++ or command line, you can specify a single CA certificate (in pem format for instance) when performing a connection.
If I well searched (hum), in java (i mean with standard librararies) it's slightly different.
either you add your certificate into a trustore, having to manage it by external application as keytool (of course you could programmatically manage your trustore, but it's not my point)
[and additionally, you can specify a trustore with System property, but you can't specify a cert directly]
either you have to code a little, like overloading the SslContext or the TrustManager class, to enable to add a certificate "on the fly".
Am I missing a simpler way, like method "connection.setCA(String caCertPath)" ?
Thank you,
RE: "Am I missing a simpler way, like method "connection.setCA(String caCertPath)" ?"
I guess it depends on the java class you use to implement the application.
But as far as my knowledge goes the answer is: no. You indeed need to first store the certificate in a keystore to be consumed by the class you are using.
I am not aware of any class that would work the way you expect the certificates to be consumed, but I guess you could just write that class to sit on top of the class you don't like.
I have an app delivered via Java Web Start that is signed with an official certificate provided by Verisign, and also a self-signed certificate that we have generated. This is done because we restrict use of the official certificate for the build delivered to customers, but we need to have our test builds signed by a certificate to get the application loaded at all.
My question is; is it normal that Java 7b55 still shows security warnings for the self-signed certificate, even though the official certificate is present? I would expect the official certificate to take precedence but it appears to be not the case.
Just wondering if anyone else has hit this or if it's unique to my environment..
Its shouldn't.... Unless you are using 1 keystore to perform all this.
Sounds like you are using your self signed keystore that is paired up with the private key inside and that you may have imported the official VeriSign one into the same keystore without matching up with the private key in the inside. Which is probably why the Official VeriSign certificate is not getting read during signing
Usually in situation like yours there should be two keystores. 1 with the self signed and another with the Official Signed certificate.
~DomSYMC
I have developed a webservice in Java. This webservice will be called by other servers, which will have been assigned a certificate from us.
Now I don't know much about SSL, and I have been given a
Root CA
Issuing CA
And I need to check that the certificate provided (when the webservice is called), is "a chain from the root ca". What would be the best way to go about this?
I've read a lot about trustmanagers and keystores, but it's quite confusing and I haven't found anything which is very similar to my question.
I also need to extract a line from the certificate (the 'issued to' field) to use in my application.
Thanks in advance
I have been given a
Root CA
Issuing CA
I need to check that the certificate provided (when the webservice is called), is "a chain from the root ca"
Just put those files, and no others, into your truststore. No code required. See the JSSE Reference Guide.
I also need to extract a line from the certificate (the 'issued to' field) to use in my application
You mean dynamically? when the peer connects? You can get the certificate from the javax.servlet.request.X509Certificate request attribute, and you then just use the certificate API to get the IssuerDN.
I got list of URLs, and I want to validate their Extended Validation (EV) attribute using JAVA
I can make request and get their certificate, but I am not sure how to validate “Extended Validation” for a given site.
Is there any special value in certificate? Or any attribute?
Extended validation is mostly useful from a user-interface perspective. It's not so useful if your client doesn't have anything in its user interface to display the certificate. These verifications are not integrated by default in the JSSE, possibly because there is little demand for it (lack of Java browsers). (By the way, you should verify the certificate you get upon connection, not check with a first connection and connect with another, just in case).
The specifications are defined by the CA/browser forum.
The OID values and root CA certificate fingerprints are hard-coded into browsers (see security/certverifier/ExtendedValidation.cpp in Firefox, used to be in in security/manager/ssl/src/nsIdentityChecking.cpp). There is also a list on Wikipedia for reference, although in principle you should check the policy OIDs with each CA.
To analyse the extensions, it might be useful to use BouncyCastle if X509Certificate.getExtensionValue() isn't enough.
One problem you will have to watch out for is that the hard-coded SHA-1 fingerprints of the root CA certificates need to match exactly those certificates in the trust store. Some CAs renew their CA certificates once in a while in the bundles that are shipped with most browsers/OS/JREs: make sure you're using the same.