URGENT: Major Marti dice error occurring with users.


  • Donators Moderators Admin

    URGENT: Major MARTI dice error occurring with users. We're trying to host a PBEM tournament and several users are reporting this issue.

    ** per some good advice from Redrum, which helped another user, I originally advised him that it is usually due to an old version of Java. He already uninstalled TripleA, downloaded the latest Java 8, and reinstalled TripleA, but the problem continues. He said that he updated Java manually to jre1.8.0_191, uninst/reinst TripleA, same error msg. Read issue 2554, manually deleted jre1.8.0_144, uninst/reinst TripleA, same error msg.

    --- original email from user Icelander below ---

    Hi all,
    I need your help to fix a strange issue with the dice roller.
    Probably since I updated to last engine 1.9.0.0.12226, for each new game the Dice Roller Test fails giving the error message attached below.
    Fun thing is that the same test succeeds with each old game I load, even after changing the recipients.
    So there is no issue with our email addresses.
    We tried having Handsome create the new game, but the Dice Roller Test still fails.
    Of course I also tried playing regardless, but the game crashes at the first battle with dice.
    Please help 🙂
    Thanks
    Icelander

    Test
    Contacting dice.tripleawarclub.org
    An error has occured!
    Possible reasons the error could have happened:
    1: An invalid e-mail address
    2: Firewall could be blocking TripleA from connecting to the Dice Server
    3: The e-mail address does not exist
    4: An unknown error, please see the error console and consult the forums for help
    Visit https://forums.triplea-game.org/ for extra help
    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
    at sun.security.ssl.Alerts.getSSLException(Unknown Source)
    at sun.security.ssl.SSLSocketImpl.fatal(Unknown Source)
    at sun.security.ssl.Handshaker.fatalSE(Unknown Source)
    at sun.security.ssl.Handshaker.fatalSE(Unknown Source)
    at sun.security.ssl.ClientHandshaker.serverCertificate(Unknown Source)
    at sun.security.ssl.ClientHandshaker.processMessage(Unknown Source)
    at sun.security.ssl.Handshaker.processLoop(Unknown Source)
    at sun.security.ssl.Handshaker.process_record(Unknown Source)
    at sun.security.ssl.SSLSocketImpl.readRecord(Unknown Source)
    at sun.security.ssl.SSLSocketImpl.performInitialHandshake(Unknown Source)
    at sun.security.ssl.SSLSocketImpl.startHandshake(Unknown Source)
    at sun.security.ssl.SSLSocketImpl.startHandshake(Unknown Source)
    at org.apache.http.conn.ssl.SSLConnectionSocketFactory.createLayeredSocket(SSLConnectionSocketFactory.java:396)
    at org.apache.http.conn.ssl.SSLConnectionSocketFactory.connectSocket(SSLConnectionSocketFactory.java:355)
    at org.apache.http.impl.conn.DefaultHttpClientConnectionOperator.connect(DefaultHttpClientConnectionOperator.java:142)
    at org.apache.http.impl.conn.PoolingHttpClientConnectionManager.connect(PoolingHttpClientConnectionManager.java:373)
    at org.apache.http.impl.execchain.MainClientExec.establishRoute(MainClientExec.java:381)
    at org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:237)
    at org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:185)
    at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:89)
    at org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:111)
    at org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:185)
    at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:118)
    at games.strategy.engine.random.PropertiesDiceRoller.postRequest(PropertiesDiceRoller.java:147)
    at games.strategy.engine.random.PbemDiceRoller$HttpDiceRollerDialog.rollInSeperateThread(PbemDiceRoller.java:222)
    at java.lang.Thread.run(Unknown Source)
    Caused by: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
    at sun.security.validator.PKIXValidator.doBuild(Unknown Source)
    at sun.security.validator.PKIXValidator.engineValidate(Unknown Source)
    at sun.security.validator.Validator.validate(Unknown Source)
    at sun.security.ssl.X509TrustManagerImpl.validate(Unknown Source)
    at sun.security.ssl.X509TrustManagerImpl.checkTrusted(Unknown Source)
    at sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(Unknown Source)
    ... 22 more
    Caused by: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
    at sun.security.provider.certpath.SunCertPathBuilder.build(Unknown Source)
    at sun.security.provider.certpath.SunCertPathBuilder.engineBuild(Unknown Source)
    at java.security.cert.CertPathBuilder.build(Unknown Source)
    ... 28 more


  • Admin

    Hmm if the user is absolutely sure that there isn't any old java version on the system left there are really only two options.
    The first one being that there's some sort of proxy on the system or the local network.
    In case the proxy is on the system (probably the case if you're not trying to play in a corporate network or something similar where traffic gets filtered) there's an issue on github with troubleshooting steps.
    I can't find the issue right now (probably too tired from the day), but I recall @ssoloff guiding a user through troubleshooting steps to fix this issue.
    In case the proxy is on the network it might help to fiddle around with some proxy settings inside the triplea settings menu.
    Option 2 would be that the connection is actually being "attacked" which is unlikely.


  • Donators

    Hi, I deleted the jre1.8.0_144 folder in c:\program files\common files, should I search the whole disk for other cacerts files?

    No idea about any proxy, I'm using my home connection.

    However, not only I connected to the dice server until a few days ago, but when I load those game files, the connection still works now.
    The connection only fails for any game I start now.

    I'm trying to upload two game files, the first (new) fails, the second (old) succeeds.
    Hope that can help.
    Thanks
    0_1541460465273_triplea_Ger0.tsvg
    0_1541460485363_triplea_Ger3.tsvg


  • Admin

    I can't find the issue right now (probably too tired from the day), but I recall @ssoloff guiding a user through troubleshooting steps to fix this issue.

    https://github.com/triplea-game/triplea/issues/2821

    However, not only I connected to the dice server until a few days ago, but when I load those game files, the connection still works now.
    The connection only fails for any game I start now.

    @Icelander There are some instructions in this thread for dumping your system properties. Pasting those here would help us verify which version of Java on your system TripleA is actually using.

    I'm trying to upload two game files, the first (new) fails, the second (old) succeeds.

    I'll take a look at those and see if there's anything specific in the save games that might identify the problem.

    bamaackbar created this issue in triplea-game/triplea

    closed Error on 1st Run #2821


  • Admin

    @Icelander So, both of those saves seemed to work fine with MARTI on my box with a 1.9.0.0.12226 client and Java 1.8.0_181.

    However, I dug into the dice roller settings stored in each of those files and think I know why newer saves fail for you while older ones do not: the newer save (Ger0) is using HTTPS to connect to MARTI, while the older save (Ger3) is using HTTP to connect to MARTI. So, that's good in a sense, because it means your HTTPS connections were probably never working, and it has nothing to do, per se, with the latest version of TripleA (other than it enabled HTTPS by default).

    The next step will be to take a look at your system properties, as discussed above. If that shows the version of Java TripleA is using is good, then the most likely candidate is you have some kind of TLS/SSL proxy running on your local machine/network (see issue 2821 referenced above).


  • Moderators Admin

    Maybe this helps:
    In all related cases we had on axisandallies.org this error has been caused by an outdated Java present in

    c:\program files\common files\i4j_jres\

    TripleA always seems to "prefer" to use the old i4j-Java (that once had been bundled with TripleA-installation files) instead of using the installed latest JRE. The solution in these cases is to manually delete the above mentioned i4j_jres folder with its subfolder(s).

    I see from the above postings that "common files" have been inspected before, but maybe not "i4j_jres" (?).


  • Admin

    I see from the above postings that "common files" have been inspected before, but maybe not "i4j_jres" (?).

    And if you install TripleA as a non-admin, the bundled JREs go someplace under your user profile. I think the i4j_jres folder gets placed in C:\Users\<username> (possibly with a leading period), but it might be somewhere under C:\Users\<username>\AppData\Local.


  • Donators

    Thanks all, I found the damned jre1.8.0_66 my TripleA was still fond of using 🙂
    Manually deleted and HTTPS connection is now working properly.
    I see current TripleA installer comes with jre1.8.0_144, could it be designed to replace older versions, so that other users don't incur this HTTPS issue?

    Again, thank you all for being such an helpful team, keep up!


  • Donators Moderators Admin

    Devs - thanks to all for solving this issue !!
    Numerous other users have now indicated that it is working OK.
    Thanks as well for the very swift responses, which is super helpful at the start of a new tournament !!

    Cheers, Deltium