When attempting to run a local mysql database, and connect to it via localhost;

• SG v1.0.0.7-ALPHA running CraftBukkit version git-Spigot-3b314f5-e2790ae (MC: 1.15) (Implementing API version 1.15-R0.1-SNAPSHOT) on Windows 10 with Eclipse Adoptium\jdk-11.0.13.8-hotspot\bin\java.exe produces this error
• SG v1.0.0.7-ALPHA running on any 1.19 spigot or 1.19 paper instance on windows 10 with Eclipse Adoptium\jdk-17.0.2.8-hotspot\bin\java.exe connects as intended.

Database dumped as 20220614.sql in the vault.

This is a duplicate of #202.

com.zaxxer.hikari.pool.HikariPool$PoolInitializationException: Failed to initialize pool: Communications link failure generally means that you have a problem with your configuration which means it isn't able to connect to your database.
There is also an SSL handshake failure. Are you sure your database configuration is correct? There seems to be some problem connecting to your database using SSL.

As far as I'm aware, neither #202 or this issue are Stargate problems. Rather. it's user error, possibly related to some unknown factor.

It is quite possibly user error, but I am a tad hesitant to believe that in this case:

• The database config is identical to the two other 1.19 instances (which work)
  • I diff'd the file; there is no difference whatsoever.
• The database itself is identical to the two other instances (which work)
  • I have tried dropping and recreating the stargate table, and starting the instances in random orders; consistently, the 1.15 instance fails, whereas the 1.19 instance works.
• I tried connecting to other databases, local and external, with and without SSL
  • the 1.15 instance consistently would not connect, whereas the 1.19 instances would.

Before I feel comfortable closing this, could someone please try to connect a spigot 1.15 sg instance to a mysql database on windows?

What the error message says directly is that Hikari cannot establish a connection because the SSL certificate provided by the sql server has been issued by an unthrusted authority.

I'm not sure why this is only a problem on craftbukkit 1.15 though.

@Pheotis Could you test Craftbukkit, Spigot and Paper 1.15, 1.16, 1.17, 1.18 and 1.19 to decide if this is a Craftbukkit problem or a version problem?

Reproduced in

• Last reproduced for spigot in 1.17
• Last reproduced for paper in 1.15.2
• Last reproduced for craftbukkit in 1.17.1

Reproduced in

* Last reproduced for spigot in 1.17

* Last reproduced for paper in 1.15.2

* Last reproduced for craftbukkit in 1.17.1

This is starting to smell like a Java 8 vs. Java 17 difference.

spigot 1.17 is java 17, So I'm uncertain about that. I also tested to run minecraft 1.16.5 on both java 11 and java 16 with the same results

Spigot 1.17 is techincally Java 16. If it isn't that something changed between Java anything and Java 17 then there must have been a change in something we are depending on without being aware.

Assuming it's not a user-error because of unknown changes between versions, there are three main possibilities for the cause of this bug:

1. The HikariConfig we generate based on the user's input is invalid for some specification, which means some specification defined by something unknown has changed between server versions.
2. There is some indirectly loaded dependency (included in the Server software) that is incompatible with the explicitly loaded HikariCP dependency.
3. Something specifically related to trusted root certificated changed wherever those are defined.

The root exception in the stack trace is: java.security.cert.CertPathValidatorException: Path does not chain with any of the trust anchors
This exception says the certificate is untrusted. It's either self-signed or has an untrusted root certificate. Because of this, we can assume that there has been a change related to where or how the trusted root certificates are fetched. Or, assuming a different trusted certificate "collection" is used between some versions, it could be that whichever SSL certificates are used for testing have become trusted in the new "collection", but were not in the previous "collection" of trusted certificates.
I'm not sure how to find the root cause of all this without a lot of research.

Can you two provide the SSL certificates used by your MySQL servers when encountering the error? And also double check the exact stack trace to make sure whether java.security.cert.CertPathValidatorException is always the root exception, or if we are encountering several problems?

Setting the mysql-connector-java dependency to version 5.1.49 seems to solve the issue. But this is not recommended according to https://www.spigotmc.org/wiki/connecting-to-databases-mysql/

Setting the mysql-connector-java dependency to version 5.1.49 seems to solve the issue. But this is not recommended according to https://www.spigotmc.org/wiki/connecting-to-databases-mysql/

Damit, this was just from me being a moron (and too tired). I forgot to set useSSL to true

The issue was that by default the ssl certificate of a mysql server is self signed. Why this only matters for certain versions of spigot/paper is unknown. But this can be ground down to user error.

A more descriptive error for this has been implemented, to ease the use for end users.