Looks like the certificate expired. Whoever runs that service needs to renew it.
It's probably fine, but if you want to be absolutely safe you shouldn't continue. Just wait a bit and it'll probably be fixed
c/cybersecurity is a community centered on the cybersecurity and information security profession. You can come here to discuss news, post something interesting, or just chat with others.
THE RULES
Instance Rules
Community Rules
If you ask someone to hack your "friends" socials you're just going to get banned so don't do that.
Learn about hacking
Other security-related communities !databreaches@lemmy.zip !netsec@lemmy.world !securitynews@infosec.pub !cybersecurity@infosec.pub !pulse_of_truth@infosec.pub
Notable mention to !cybersecuritymemes@lemmy.world
Looks like the certificate expired. Whoever runs that service needs to renew it.
It's probably fine, but if you want to be absolutely safe you shouldn't continue. Just wait a bit and it'll probably be fixed
I've checked the website of xmpp dot japan, it has totally different certificates rn. Like, it has Google Trust certificate while the popup shows Let's Encrypt and ISRG. Seems weird
The website and the XMPP server can have different certificates.
Popup says "valid for xmpp.jp and *.xmpp.jp"
It doesn't mean the website is using the same certificate. One can include as many domains as they want in a certificate, but nothing stops them from using something else.
But it's probable that they have some certificate renewal script that has reloaded the certificate on their website, but the service that you're connecting to still has the old certificate loaded.
Edit: yep, see https://bgp.he.net/certs#_SearchTab%3Fq=api.xmpp.jp , it looks like they did a renewal recently, but probably haven't reloaded their cert. So it'd probably be fine to accept it, or just wait a bit for them to realize and reload.
It would be valid if it would be served by the XMPP server, but it is not:
% openssl s_client -connect xmpp.jp:5222 </dev/null -starttls xmpp
CONNECTED(00000003)
depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = E8
verify return:1
depth=0 CN = xmpp.jp
verify error:num=10:certificate has expired
notAfter=Jun 5 10:51:05 2026 GMT
verify return:1
depth=0 CN = xmpp.jp
notAfter=Jun 5 10:51:05 2026 GMT
verify return:1
***
Certificate chain
0 s:CN = xmpp.jp
i:C = US, O = Let's Encrypt, CN = E8
a:PKEY: id-ecPublicKey, 256 (bit); sigalg: ecdsa-with-SHA384
v:NotBefore: Mar 7 10:51:06 2026 GMT; NotAfter: Jun 5 10:51:05 2026 GMT
...
Both the client and the server machines must have reasonably accurate system clocks for an SSL/TLS handshake to succeed. Either your machine or their machine probably needs a time adjustment.
The mine is configured to network time, but it is not syncing with my region, just the region having same offset from UTC (both have no DST anyway), may that cause any trouble?
If you're able to connect to other websites, then I doubt it's you.