The SSL labs scan at https://www.ssllabs.com/ssltest/analyze.html?d=edupediapublications.org shows that you sent a different certificate for clients that connect without SNI support (which is true of older web browsers). That certificate is self-signed and is different from the Let’s Encrypt certificate that you correctly send when a modern SNI-capable client connects to
edupediapublications.org. If you have a Unix command line you can see the difference with
openssl s_client -connect edupediapublications.org:443 -servername edupediapublications.org # ← OK
openssl s_client -connect edupediapublications.org:443 # ← returns self-signed cert
although the SSL Labs report already explains this correctly. I’m pretty sure that the second one is what Google is complaining about. Even though Google itself is capable of using SNI, they must regard the self-signed cert in the non-SNI case as invalid enough to warn about.
This is not necessarily an urgent problem to fix because both Google and most browsers will be able to connect with no error, but you could look at your configuration to figure out where and why the older self-signed certificate is still configured as the default certificate when no hostname is specified by the client.