OpenSIPS version you are running

version: opensips 3.4.0-dev (x86_64/linux)
flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC, Q_MALLOC, F_MALLOC, HP_MALLOC, DBG_MALLOC, CC_O0, FAST_LOCK-ADAPTIVE_WAIT
ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535
poll method support: poll, epoll, sigio_rt, select.
git revision: 6faf77b
main.c compiled on 14:58:32 Mar 24 2023 with gcc 4.8.5

Describe the bug
When OpenSIPS connects to a TLS server that presents a certificate that does not match its hostname, OpenSIPS thinks the certificate passes validation and allows communication anyway.

There is probably a comparable bug regarding checking client certificates.

To Reproduce

1. Get OpenSIPS to connect using TLS, with "verify_cert" enabled, to a server that has a good certificate (I did this using uac_registrant, but any method would be fine).
2. Verify that OpenSIPS successfully connects and sends SIP.
3. Now get OpenSIPS to connect to exactly the same server but using a hostname that is not in the certificate (e.g. a bare IP address, or something from /etc/hosts - any hostname for that machine is fine)
4. Observe that OpenSIPS still successfully connects and sends SIP, even though the certificate is not valid without a matching hostname.

Expected behavior

I expected OpenSIPS to reject a certificate when the common name (or subject alternate names) don't match the hostname it is trying to connect to.

Relevant System Logs

OS/environment information

• Operating System: CentOS 7
• OpenSIPS installation: git
• other relevant information:

Additional context

This probably means existing OpenSIPS installations are MITM-able by anyone who can get a valid certificate for any domain (which is everyone).