javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: 
    PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: 
    unable to find valid certification path to requested target

One cause of the problem can be that the server uses an SSL provider which is based on a root certificate that wasn’t included with the particular version of Java you are using (this is especially true for really old versions like Java 1.5). The issue can be solved by updating to the latest version, but it might be that this isn’t an option. Fortunately I found the following article: No more ‘unable to find valid certification path to requested target’

How to use it:

• Compile the program javac InstallCert.java
• Run it with the target host/port. For example in our case it would be: java InstallCert imap.mailprovider.com:993 (993 is the port for IMAPS)
• navigate trough the menus and select which certificate to import
• now you have a file called jssecacerts. You need to copy this to $JAVA_HOME/jre/lib/security/cacerts (back up the existing file first!)
• Now the root certificate is imported (you can confirm this by rerunning InstallCert)

HTH

However this wasn’t possible with SSL, because the certificate was sent before the headers and a certificate is specific for a site (at least the run-of-the mill ones), and the webserver didn’t know which certificate to pick. When I’ve heard on the SANS Daily Stormcast that the newest version of Apache included a way to do this, I was enthusiastic and intrigued at the same time, so I went looking and found the following thing:

• It is done by doing the initial communication in plaintext and then “upgrading” to TLS. I wonder just how much is in plaintext? (see the What’s new document – the mod_ssl section specifically)
• The official RFC for this is RFC 2817. The RFC specifies both methods for upgrading – before and after the actual request – so the devil will be in the details implementation
• There is no browser support for this as of this moment, so it is pretty much useless (until IE + IIS starts supporting it is pretty much a cool option). But at least we have a reference implementation

Bonus article: The First Few Milliseconds of an HTTPS Connection

Picture taken from AMagill’s photostream with permission.

• you shouldn’t be afraid. Fear is a bad motivator because it wants to force you to act quickly. A much better concern is informed concern.
• if someone really wants to get to you (think TLA’s – Three Letter Agencies, but also some very skilled individuals are in this category), they can, so I’m talking here about the shotgun-type attacks which are people are much more likely to encounter
• the good news: this attack requires someone to be “in the middle” of your conversation (it is a Man-In-The-Middle type of attack). Such attacks can be executed using things like ARP poisoning or BGP hijacking.
• the bad news: it is a MITM attack There are already quite a few malware in the wild with the capability to do ARP poisoning in an automated way and it is quite likely that (in the near future) they will add these methods to their arsenal

What can you do? If you are using Firefox, use the NoScript extension to force sites into HTTPS mode. As a site owner you might want to ensure that “secure” domains are only accessible via HTTPS (for example secure.example.com is listening only on 443 not on 80). This of course is not always possible.

Further info (from the Security4all blog):

Presentation slides and a video of the presentation. Below you can see a short interview about the topic:

Picture taken from JoVivek’s photostream with permission.

A few words about the methodology: I took the top 1 000 000 sites list from Alexa (love them or hate them for their toolbars, but it is very nice of them to provide this list freely and without any registration or stuff – I admit that I went to their site with the intent to scrape it and was very pleasantly surprised). I feed the list to a simple multi-threaded Perl script which tried to download the https://$site/ URL (with cURL – BTW you can hear an interview with the creator of curl on FLOSS weekly) and recorded the error code. It managed to go over 358947 entries before the power went out, so here are the partial results

Even if I ignore the errors associated with my network connection (the two largest categories “Couldn’t resolve host”, “Failed to connect to the host” and “Operation timeout”), and the one which seems to be a statistical fluke (“The server didn’t reply anything”), the sites which have their SSL certificates in order come in dead last (!) with 5%. How can we instruct people to look for proper SSL encryption when the sites themselves fail to provide such?

The biggest percent is made out of the “The remote SSL certificate wasn’t ok” case which seems to caused mostly by sites that reuse SSL certificates issued for other domains (for example google.it use the certificate for www.google.com).

The second biggest problem in case of SSL sites was “SSL connect error” (including on yahoo.com). These servers seems to keep port 443 server open, but don’t respond with anything. Are they tarpiting the connection? Why would they do that?

The last error (which still outnumbers the no-error cases by a factor of 5!) was “Problem with CA cert”. A cursory check seems to indicate that these are mostly self-signed certificates. While such certificates do provide some guarantees, it would be much better for them to use proper ones (they are not that expensive).

My (sad) conclusion: SSL == fail.

PS. The terminal23 blog contains further bad news. I thought that at least EV certificates (although way too expensive), at least they provide some guarantee that proper checks have been done. It seems not…

AskApache (a great blog BTW for technical network related stuff – the only negative thing being that sometimes it is too technical :)) has an article about mixing secure (fetched through HTTPS) and non-secure (fetched through HTTP) elements on a page. Usually the result of doing something like this is that the browser displays a warning and/or a broken lock instead of a normal lock. This can scare away security conscious users. Two things you can do to remedy this:

If you host the resources the link goes to, use the HTTPS protocol to link to them. Most of the times people use plain HTTP to link to static elements (like images, style-sheets and so on) because the encryption in the HTTPS protocol creates an overhead and we want to keep CPU utilization low for our servers. Here are my counter-arguments: modern servers have plenty of CPU power. Also, most (read 99.9%) of modern web browser do multiple requests over the same connection, so that the encryption key is negotiated only once every N minutes (where N is around 15 if I remember right). An other argument would be (if you are using a hosting company): I never seen hosting companies charing by the amount of HTTPS connections made. Finally the big argument: are you ready to loose visitors / sales / whatever your site is about because users mistrusting your site (because of the warnings) to get some little speed and scalability gain?

If the given resources are not hosted by you and are not accessible through a secure connection, you could use mod_proxy to create a virtual proxy to make it seem as the response comes from your server. (You could also simply copy the page / image in question to your local server and serve it up from there, but that includes all kind of copyright problems). Some advantages and disadvantage:

• Advantage: you eliminate the mixed content warning
• Disadvantage: You are using double the bandwidth (because your server first fetches the given resource – thus using downstream bandwidth – then sends it to the client – using upstream bandwidth)
• Advantage: it is seamless for the client
• Disadvantage: you have to have mod_proxy installed. It is not included in the default Apache installation and SysAdmins are not very happy to install it, because it can very well be a security risk it not configured properly
• Advantage: it works with dynamic resources (for which the make-a-copy and serve-it-from-the-local-server wouldn’t work even if you would to resolve somehow the copyright issues)

One final note: the AskApache article talks about hosting videos (Google and YouTube) on a secure page. The interesting thing is that the browser only cares about the fact that the player is loaded through a secure connection, not that the video (loaded by the player) loads through a secure connection. This is done because the browser has no control over the plugins (in this case the Flash player) behavior. The good news is however that because of this if you chose the proxy solution, you don’t have to proxy the entire video, just the player (which is obviously much smaller).