I'm running an application (web service) in tomcat with TLS enabled (with certificates both for the client and the server).
I want that my application will be able to send audit message (logging) when TLS handshake fails. For example I want to log when:
the client certificate is expired,
the client certificate is unknown (not in the server trust store)
any other handshake failure
Is there any event that I can catch and handle in order to do that?
My application is web service based and is running in tomcat. Tomcat is handling all network and the TLS layers, and the application does not aware of that.
As I don't open any socket myself, where should I catch this Exception?
I'm not aware of anything you can add to Tomcat.
Put an Apache HTTPD in front and use a separate, configured, SSL log.
Since I spent the past week debugging Tomcat's SSL configuration, I am pretty sure catching javax.net.ssl.SSLHandshakeException in your code and logging it should take care of all three of those errors.
When you instantiate a new webservice connection in your application, that is when the exception will occur.
Related
I'm making TLS client connections in Node.js. Some servers I communicate with request a client certificate. I'd like to be able to detect when this has been requested, so I can log it. At the protocol level I believe this is sent along with the TLS server hello, so the data is there, but I'm not sure how I can get at it.
I'm never actually providing a client certificate for now, I'm just aiming to report which servers requested one.
I think there's probably two cases here:
A cert has been requested, not provided, and the server has accepted the connection anyway (and then probably given my some kind of 'not authenticated' response).
A cert has been requested, not provided, and the server has rejected the TLS connection entirely.
At the moment I can't detect either case, solutions for either or both very welcome.
I'm able to get an unsecured FTP Client/Server system going, but when I try throwing in the SSL io handlers, setting up both apps to use sslvTLSv1, it shows Connected for the Client status then eventually times out (the only Server message I get is Socket Error # 10060).
After many trials and tribulations trying to resolve this issue, I've determined that there are serious problems with enabling a certificate-less security system; meaning that, if you want it secured (with the current Indy code), you need to use certificates. Perhaps there are some settings in the SSL component that need to be made, but there just isn't specific enough info (working examples of certificate-less SSL) to make this work. Hopefully this deadlock will be resolved in a future release of Indy ;)
We have a web server (IBM HTTP Server 6.1) connected using HTTPS (using SSL certificates - SSLv3) to an application server (IBM WebSphere Application Server 6.1), the application that is hosted on the app server is not upgradable, so we cannot update WebSphere on both layers to later versions.
I'm trying to enable TLS instead of SSLv3, the steps I followed:
On the web server's http.conf file, SSLv2 and SSLv3 and their cipher suites directives were removed, and TLS cipher suites were added (2F, 35b).
On the app server, QoP were changed to TLS (also tried TLSv1) instead of SSL_TLS, removed RC4 cipher suites by creating a customer list.
When opening the website URL from browser, Internal Server Error appears (means that the web is unable to communicate with the app server). When selecting the SSL_TLS again in the app server's QoP settings (keeping the SSLv2 and 3 disabled on the web server level), the website opens properly!
Is it possible the application is not compatible with TLS, pls advise?
Thank you.
The WAS Plugin tries TLS1.0 by default in 6.1.0.31 and later. To debug whatever's going on with your system, you'll have to actually watch the handshake in a packet capture and that will tell you which side to focus on.
Running 6.1 is ill advised, but running 6.1 without the latest maintenance is borderline negligent.
We are experiencing the following error when trying to use an external web service from our application deploy under IIS 7.5.
Error - The underlying connection was closed: Could not establish secure channel for SSL/TLS.
This works from other servers, but on this particular one it fails. This started happening when the server we are trying to connect with disallowed SSL connections and is only accepting TLS. As described in this link http://support.microsoft.com/kb/915599 we changed the registry, but are still seeing the error. Please see the attached image of the registry to make sure this was done properly. It seems like IIS is still trying to use the SSL protocol. I'm a bit confused where in the communication process IIS selects the protocol, SSL vs TLS. Maybe there's something that needs to be done to ensure TLS is selected? Other ideas?
This was fixed at the code level by adding the following line -
ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls;
i have a windows 2008 server and a comodo wildcard cerificate.
i also have a couple of applications running under this certificate.
the application and the certificate work fine and are correctly installed.
i have a gprs module from telit that without ssl works fine but when enabling ssl althougth it works it makes 45seconds in handsake to authenticate the server certification.The delay is surely from the handshake because later on the communication is fast enough.
i am searching quite a while for possible problems. i am leaning to believe that the validation of the certification chain is slow.
how can i reduce this time? do you have any other ideas of possible errors or setting issues?
What is likely happening is that you have not installed the intermediate certificates in the chain on the server. This causes the server not to send those to the client and the client needs to fetch them on its own, which causes the delay. Ensure that all certs in the cert chain, except the root, are present in the local machine Intermediate CAs store.
You can use Wireshark or similar tool to look at the network traffic and see what certificates are being sent from the server to the client. If you could capture the client network traffic, you can see whether my theory above is correct or not and what is causing the delay.