Continuation of the threadhttps://forums.mirc.com/ubbthreads.php/topics/269593/extra-options-for-certificates
If connecting to a servertarget not found in the main serverlist, the /server command is defaulting to use a local-override certificate, instead of using the global certificate, even though it's not using any -switches
It's borrowing the local certificate filename shown in the titlebar of the status window which got there due to either of 2 conditions being met:
1. When first starting mIRC and being the only server connection, and $readini($mircini,mirc,host) contains :GROUP:anything-or-blank:0,"localcert.pem", indicating the last connection from the prior instance used a local cert
2. Regardless of the content of $readini($mircini,mirc,host), using /server or /server -m to connect to the new servertarget from a status window which is connected to some network that was using a local certificate.
To replicate the problem:
A1. Create a new cert filename ecdsa256.pem that isn't used anywhere else.
A2. Pick any entry in the serverlist that you're not using. For this example I used dalnet. Edit that serverlist entry to uncheck 'use global certificate' and choose this new ecdsa256.pem as the local certificate to use for just that 1 network.
A3. When you connect to that network using the serverlist, the status window will show the filename of the local certificate being used for that connection.
A4. I went to netsplit.de to find a server that's not in the serverlist. I ended up choosing UmbrellaNet, but any server not in the serverlist that recognizes SSL at +6697 will work fine, including the server target listed in TECO's posts, or even one of the Libera $server names not listed in servers.ini like calcium or zirconium.
From the Status window using the local cert, I then used /server -m to open a new server window to connect to the new servertarget that's not in the serverlist
/server -m new_servertarget.org +6697
When it connects, it uses the local certificate shown in the titlebar of the status window from where the server command was made.
In between steps A3 and A4, it doesn't matter if you make any additional server windows using serverlist entries which use the global cert, or reconnect another existing status window that also uses a global cert. All that matters is that the /server -m command is being made from a status window that's using a local cert.
A 2nd way to re-create the issue:
B1. Repeat steps A1,A2,A3 and quit mIRC
B2. After restarting mIRC, the status window shows the last server connection made in the prior client instance, and this comes from:
//echo -a $readini($mircini,mirc,host)
... and shows the "ecdsa256.pem" preceded by '0' indicating that it used the local instead of global cert.
B3. connect to the server that's not in the serverlist. It doesn't matter whether connecting into that only status window that's disconnected or using /server -m to open up a brand new server window:
/server -m new_servertarget.org +6697
Even if you don't include the +6697 and it connects in a normal non-SSL connection at port 6667, looking at the host=string in mirc.ini shows that it still remembers the local cert even though it's not using it, and then if you now connect to any $servertarget not in the serverlist, the /server command still borrows the local cert for the future +port SSL connection
I'm thinking that part of the way to avoid this is related to the 'add a new server to the serverlist' dialog which shows the GROUP as being (optional), which makes it more likely that unrelated networks get linked together as being part of the $null GROUP. Perhaps instead of telling the user that GROUP is (optional), it could suggest they use the expected $network string, though I'm not sure how to do so in a way that makes sense to non-scriptors who don't know what the $network identifier means.
But also, when the /server command is being recognized as connecting to the GROUP=$null and is a $servertarget that's not in the serverlist, the certificate global-vs-local settings in the absence of using the -key switch should only match against $servertarget and not against the $null GROUP.
i.e. treat /server's default certificate settings the same as the password settings, as I wasn't able to do this same thing to setup dalnet's serverlist entry with login method "/nickserv" and then have the /server command send the dalnet password to umbrellanet.