No I won't tell you to stop using SSL, not at all. It's a valid environment for the debugger and everything should work fine and actually working fine for many customers. If you're using in prod, meaning with a real SSL cert, not self-signed, it's not a common case and there could be some problems we haven't seen.
I guess ALPN and SNI might cause some problems -- they are part of SSL protocol. Does your server restrict SNIs, for instance? I saw this problem reported by customers who work with CloudFlare env. Or we may have issues with cert chain validation in the HTTPS client that is used in the Wizard.
(RE huge fees associated with SSL certs, FYI some companies provide SSL certs for free as long as you're using their resources, not cheapest though, just a hint)

As of CLI -- it's cli, command line interface, an environment that has nothing to do with your web servers at all. It means that SSL is not applicable to this mode at all. If you select both WEB and CLI mode in the Wizard, does it work?

I dispatch my debugging tests across prod servers, backup servers and home copy of them.

If I use a prod server, that I tend to avoid, it is generally into a test copy of the actual production virtual server into a side-by-side directory, and because I sometimes need resources that couldn't be easily available on test copies (a 10 Gb database, for example).

And why would I want to use a self-signed certificate where I can use a real Let's Encrypt one for the same price?
This also has the advantage of better validating the changes that I make in the test servers before copying them to the prod ones.

I never digged inside the SSL configuration. I installed it using the default Apache values.

Let's Encrypt, however, strongly suggests to use some of their tunings, so I include a file (provided by Let's Encrypt) containing this in all of my SSL virtual servers:All SSL tunings that I could have made should be there.


The only company from which I could use resources is my hosting provider, OVHcloud.
The only SSL certificate resource that OVHcloud provides for free is … Let's Encrypt.

But thank you for the hint, anyway.
I already told that into my September 27th, 2023 (French time) message here.

CLI tests succeed if I use them along with HTTP into the same project wizard (while the HTTP one fails).
CLI tests fail if I use them alone, without HTTP, into their own project wizard.

I understand this is absolutely not logical.

Despite CLI has nothing to do with web servers, I intensively use CLI on my servers for fetching external data (from open data sources), processing them, and putting the result into a database which HTTP scripts next use for displaying.

These CLI scripts are triggered by CRON tasks.
Once per minute.

As this is not handled inside the same directories, I use separate projects for debugging them.
CLI and HTTP scripts share some common libraries, however.

With CLI it was a simple typo in code that led to this non-logical error. With SSL/web mode - it still requires some more investigation and correlation. Can you update SSLProtocol and add -TLSv1.3 ? This will leave 1.2 version only. Then re-start web and re-check in the wizard.
One more question -- if you ignore wizard failure(s) and just save the results, does the project work and successfully starts debugging in CLI and HTTP modes?

Ok.
It seems to work if I add -TLSv1.3.

I tried this on a test server.
I'd like to avoid this on a server used for production, however.

Seems to work also, yes.

But by the way, this leads me to another issue:
Is there a way to force or disable IPv4 or IPv6 on connection account basis (especially when using SSH) rather than globally?
I ran into some issues of this kind when running these last tests on local systems, and the only workaround that I found was entering the addresses as numeric IPs rather than by using domains names, because I don't want to block IPv6 where it works (thus for all projects) for the only reason that it leads to problems elsewhere.

So the issue is there only if combination of multiple factors took place -- web site is SSL, TLS version is 1.3, probably there is also dependency on Cipher and DH/EC exchange schema used as a part of TLS 1.3 and it's only happens in the Wizard.
You see, there is a good explanation why there were no complaints. Oh well, wrong, when posted suggestion to check the project itself pretending the Wizard had succeeded -- I picked the idea from the reports submitted by two customer who said Wizard froze for dozen seconds, then failed, but after all the debugger worked fine for their projects, making 3 reports total. Not too overwhelming. Thanks for the efforts.
As you see, neither debugger nor tunnel are root cause for the failure.
As of you latest post you just added, I open new thread because this one will eventually be resolved with next build. Please post details in that thread, including logs from your server. BTW if you posted logs in the course of this issue, it would save us a day or two, may be even more -- because definitely debugger posted issue in the log and did connected to the IDE and IDE started debug session but locked up because funny openssl has funny implementation of SSL_read tha locks up even though previous call to select() returned readable. Well, it's clear what's wrong with openssl and how to work this bug around, nm.
Also I renamed this topic to reflect what's been happening.