Hi Miguel,
first, let me make sure I'm reading your setup right: Power9 running IBM i 7.2 (I assume "Windows 7.2" was a typo), and you're connecting the console from your PC. My guess is you're using IBM i Access Client Solutions (ACS), since the old Client Access / IBM i Access for Windows Operations Console has been out of support for years. If you're still on the old client, that's actually the first thing I'd change.
Also, I'm assuming MSGSSL04 is actually MSGSSL004. Could you post the full message text? The wording after the message ID matters a lot for pinning down the cause.
Now, before anything else, one question that changes the whole answer: are you connecting DIRECTLY to the partition's service tools LAN adapter (classic Operations Console LAN), or are you going through an HMC 5250 console? People call both "LAN console", but ports 2300/2301 mean different things in the two cases. The fact that your connection verification shows 2301 answering makes me lean towards the HMC scenario, because for a direct LAN console the ports that matter are actually 2300, 2323, 3001 and 3002 (IBM lists them here: https://www.ibm.com/support/pages/how-check-firewall-blockage-operations-console-or-hmc-5250-console), while 2301 shows up mainly on the HMC side. But let me cover both.
CASE A, direct LAN console to the 7.2 partition.
There's an official IBM document that matches your symptom exactly: "ACS LAN Console MSGSSL004 and/or MSGSSL007" (https://www.ibm.com/support/pages/acs-lan-console-msgssl004-andor-msgssl007). Short version: newer Java releases refuse certificates built with MD5/weak RSA, and the certificate the LIC service tools server presents on older IBM i uses exactly those. The proper fix for 7.2 per that document is PTF MF60290 (which requires MF99102). Note that after applying it the service tools servers move to 4096-bit keys, and depending on how old your Java is you may also need the unlimited JCE policy (the document covers that too). The client-side workaround is editing the java.security file of the JRE that ACS uses, removing MD5/MD5withRSA from the jdk.certpath.disabledAlgorithms and jdk.tls.disabledAlgorithms lines. It works, but be aware it weakens ALL Java traffic on that PC, so I'd treat it as a temporary measure. And to answer your question directly for this case: there is no port or SSL/non-SSL selector for the direct LAN console in ACS settings, so "just switching to 2300" isn't really an option you can pick there.
CASE B, HMC 5250 console.
Here the two ports are exactly what you think: 2300 is the non-TLS console port, 2301 is the TLS one, and yes, in the ACS configuration for the HMC 5250 console you can set the port. But here's the catch, and it answers your question about always using 2300 in future releases: IBM has gone in the opposite direction. Starting with HMC V10R2 (around the M1040/SP1042 level) port 2300 has been disabled for security reasons and only TLS on 2301 is available (it's stated in https://www.ibm.com/support/pages/configuring-ibm-i-acs-hmc-remote-console). So if your HMC is recent, 2300 simply won't answer no matter what you put in the client config, which would match exactly what you're seeing. And honestly, even where 2300 still works, I'd think twice: that's your console traffic, service tools credentials included, going over the wire in clear text.
So my suggestion is to stop chasing 2300 and make 2301/TLS work instead, which usually comes down to: update ACS to the latest version, check which Java it's using, and if you're in Case A on 7.2, get MF60290/MF99102 loaded (7.2 has been out of support for a while, so I'd order those from Fix Central sooner rather than later).
If you post the complete MSGSSL text, your ACS version, and whether you're going direct or through an HMC (and the HMC level if so), we can narrow it down further.
Regards
Roberto