I'm trying to access an HTTPS based web service URL from a web/ear application deployed
on a Glassfish application server domain.
We have obtained the certificate from the vendor that exposes the HTTPS URL.
What are the steps required for installing SSL certificates in order to access the web service ?
Thanks
What are the steps required for installing SSL certificates in order to access the web service ?
If the certificate is a self-signed certificate or hasn't be signed by a CA for which the JVM already has a root CA like Thawte, Verisign, etc, you'll have to add it to a client trust store and to configure the web service client or GlassFish (which is a client here) to use this trust store to establish a chain of trust.
To import the stand-alone certificate into a trust store, use keytool. This post explains how to use it (see the section Creating Java Key and Trust Stores).
Then, configure the web service client to use this trust store. To do so, you'll need to define the system properties javax.net.ssl.trustStore and maybe javax.net.ssl.trustStorePassword. You can maybe do it at the GlassFish level (see this this post).
You need to configure Glassfish for https?
https://glassfish.dev.java.net/javaee5/security/faq.html#configssl
or you need to install a client certificate in your browser?
Related
Running a Java web service with embedded Jetty web container. Would like to serve my RESTful API endpoints over HTTPS with a root CA-signed SSL cert (no OpenSSL).
Can I configure my embedded Jetty container to use a "free" AWS Certificate Manager cert cert or are those certs only for use by AWS infrastructure (ELB, CloudFormation, etc.)? If so can I assume these certs are root CA-signed?
Basically I'm trying to figure out whether I need to spend a few hundred bucks on a Thawte/GoDaddy cert or if I can get one for free via AWS.
From Mark's comment:
"AWS Certificate manager certs can only be used by ELB, CloudFront and API Gateway. You would have to place an ELB, or a CloudFront distribution in front of your Jetty application in order to use an ACM SSL certificate."
So yes you can use one of the free AWS root CA-signed certs if you put your Jetty-based services behind ELBs.
Most Web browsers that support SSL have a list of CAs whose certificates they will automatically accept. If a browser encounters a certificate whose authorizing CA is in the list, the browser will automatically accept the certificate, and establish a SSL connection to the site.
There is a Java 1.6 client, running on JBoss 7, which is required to make SSL connection to LDAP server. Since the client is on production, if the LDAP server updates its certificate without notifying me to update the certificate accordingly on JBoss, the client will fail. My question is: how can I securely connect(ssl) to LDAP in a similar way the browser “accepts” the certificate seamlessly?
I don’t know if this is feasible in Java. But, any thoughts and feedbacks are all welcome.
Java has a default truststore that contains all the trusted certificates. This is under %JRE_HOME%\lib\security\cacert and has all the trusted CA certificates (Verisign etc).
So if your client https application tries to connect to a server that deploys a certificate signed by these issuers you would have no issue (same as happens with your browser).
Now to your problem. You don't mention enough information about your LDAP server.
I can think of the following:
The LDAP server deploys a certificate signed by some CA (not one of
the known ones).
The LDAP server deploys a self-signed certificate
For case (1) all you need to do is add the certificate of the signer to your truststore (i.e. the certificate of the issure that signed the certificate of your LDAP server). If the LDAP server changes certificate, you would be unaffected provided that it gets the certificate from the same CA which you would have set now as trusted. This trusted certificate could be added in cacerts but the recommended solution is to use your own separate truststore, import it and set it in JVM to override the default cacerts. Plenty of example in Google.
For case (2) this is a really bad setup and are in trouble as you would need to actually update the truststore manually each time the LDAP server changes certificate.
But in any case I can only assume that the certificate changes due to expiration? I can't think of another reason (except compromise of private key but this is not the problem here from your description)
I have the following:
Web service hosted on trusted enterprise domain intranet (hosted in IIS)
Java console application used to test connection to web service
Java web application hosted in Tomcat (running on localhost)
I can successfully send and receive data to and from the web service via a console application. However, when I use the exact same code and libraries in a web application hosted in Tomcat, I am receiving an SSL certificate error stating:
suncertpathbuilderexception: unable to find valid certification path to requested target
Any reason why it would work via console but not via Tomcat on localhost. For what it's worth, it doesn't work on my dev (non-localhost) box either when hosted in Tomcat. Maybe I am targeting a different JRE when launching Tomcat which doesn't have the trusted certificate?
The certificate is signed by my company's trusted enterprise authority, so I guess it's a sort of enterprise-wide self-signed certificate. The certificate authority is registered in Windows trusted certificate authorities when I check in the Management Console Certificate Snap-In. I suspect that doesn't matter though.
Am I going to have to use keytool to generate a certificate to add to the trust store on every server that will be hosting this Tomcat application?
It is possible that your Tomcat installation uses another JVM. You need to check your installation. Check where JAVA_HOME and JRE_HOME point to.
The JVM does not use the Windows trusted certificate authorities.
You will have to use keytool to import your company's trusted enterprise authorities certificate on each server, but you will NOT need to generate any certificates.
I'm trying to consume a Webservice hosted under https security.
I'm using Java and glassfish and I'm getting the following error:
INFO: HTTP transport error: javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: No name matching testdomain.com found
The thing is that this specific server is used for testing and it's using the production certificate (the one with CN=domain.com)
I already added the domain.com certificate to my glassfish domain's cacerts keystore using keytool -importcert and it didn't work.
I also tried creating a self signed certificate with the CN=testdomain.com and adding it to the cacerts keystore and it didn't work either...
So how do I configure Java/Glassfish to consume this Web Service?
The CN of the server certificate should match the domain in URL to which the client connects. If still doesn't work, I would check if the IP maps to this hostname too (reverse DNS). It is the client, who verifies it. If you want to bypass this hostname verification, see the example code in my article: http://jakubneubauer.wordpress.com/2011/09/06/java-webservice-over-ssl/
The priciple is that you provide your own HostnameVerifier to the service client proxy.
THe self-signed certificate needs to be installed in the keystore of the Web service, along with its private key, and imported into the truststore of Glassfish.
the self signed certificate needs to be installed in key store of your java client. and testdomain.com should be resolved using dns.
The scenario is around calling an external SSL SOAP web service from within Mirth. The web service is requires an SSL/TLS connection along with a client certificate.
The intention is to use the built-in SOAP Sender Destination to call the remote secure web service, and somehow include that client certificate.
I understand that you first need to install that client certificate into the Java runtime. This may be within the Java runtime's certificate store or the Jetty certstore.
The platform:
Windows 2003 SP2
Mirth 1.8
Java jre1.5.0_09
Question: what configuration steps (Mirth, JRE certificate stores, etc.) would you suggest to successfully have a Mirth SOAP Sender include a client certificate (*.cer) when calling a web service secured by SSL?
The Java runtime, or more specifically, the Sun JSSE provider, will present a client certificate if some system properties are set. You can read details in the JSSE Reference Guide, but the important properties are javax.net.ssl.keyStore and javax.net.ssl.keyStorePassword.
There are a few drawbacks to this approach. First, setting the key store password as a system property makes it accessible to any code running in that process—although this can be controlled if a SecurityManager is installed. Second, these settings will be used for any SSL sockets created through the "default" SSLContext. If you need different credentials for different endpoints, you'll need a Mirth-specific solution.
No starting point was specified in the question, but if starting from scratch, the easiest approach is to create a new Java Key Store ("JKS" format) and generate a new key pair and a CSR. After sending the CSR to the CA and getting a certificate back, import it into the same key store. That key store is ready to use.
If a certificate is already available, it is likely to be in a stored with its corresponding private key in PKCS #12 format (.p12 or .pfx file). These can be used directly by a Java application, but the javax.net.ssl.keyStoreType property will need to be set to "PKCS12"
Mirth 1.8 cannot send a client cert when calling a SOAP web service.
I'm late a bit here for this but actually there is a possibility that it could. By sending a few config parameters to the JVM you could get the underlying SOAP engine to switch to HTTPs and provide the proper certificate.
refer to this question for details on which parameters to set for configuring the VM
Java HTTPS client certificate authentication
you will notice there are quite a few things to take care of. Normally HTTPs and client authentication should "just work" once you configured your certificates appropriately. BUT there are some servers out there that are not so friendly to B2B style clients so you have to watch out.
Using JDK 6_21 and a few tweaks with the certificate I was able to get one of them servers to behave but it was long and painful on our side for something that takes about 15 minutes to configure properly on the server.
here is another question that address this very issue (client side authentication towards unfriendly servers).
Client SSL authentication causing 403.7 error from IIS