Hostname provided via sni and http no compatible ssl setup at all vhosts

SYSTEM INFORMATION
OS type and version Debian 12
Webmin version 2.303
Virtualmin version 7.30.8
Webserver version Apache 2.4.62
Related packages Apache

I’m experiencing an issue with Apache where all of my VirtualHosts fail with the following error:

AH02032: Hostname onedomain.tld provided via SNI and hostname otherdomain.tld provided via HTTP have no compatible SSL setup

A few key observations:

  • The error occurs on all of my VirtualHosts.
  • The hostname reported in the logs as being provided via SNI changes with each request.
  • This happens regardless of which domain I try to access.

I have also checked from multiple devices an operating systems. the issue is the same

Has anyone encountered this issue before? Any ideas on what might be causing this mismatch?

Update:

the issue seams fixed by deactivating mod_mpm_event and enabling mod_mpm_prefork and mod_php.
i dont how how this could be related because i use php-fpm for my vhosts.
and the issue with diffrent SNI and hostname was also there even if the vhost is just a reverse proxy.

does anyone have an idea what could cause this?

Dont use mod_php ever.

That’s a problem with URLs. Make sure you have a certificate for all of the domains your app is using to communicate with the server.

No, your problem is masked by doing that, and you should never use mod_php. That has been true for roughly two decades. It shouldn’t be a thought you have as a solution to any problem.

Note that switching to mod_php would also “fix” some problems if you were using mod_php on a previous system and migrated the sites to the new server without correcting ownership and permissions for a modern deployment. (But, again, switching to mod_php is not an option, you need to fix the root cause.)

ok i discoverd that i had not used php-fpm on some legacy websites. i changed that now and disabled mod_php completly.
thanks for your advice

given that mod_php is such a bad thing is it not time that it was prevented or at least given a massive warning on any attempt to install it?

That could be possible via the virtualmin/webmin interface, however I very much doubt that this could be added if someone adds mod_php from the command line. That said on 1 server I have mod_php installed (for development purposes) which doesn’t break any domains added by virtualmin/webmin but I am sure some will say I’m wrong

Yeah, the where and how to do the warning may, or may not be easy. That said, it is now pretty much ‘officially’ deprecated and at some point the admin has to take responsibility. I doubt it is much of an issue overall since the software works pretty much out of the box if you don’t take the time and effort to f it up. I’m guessing that is the VAST majority of users.

I use mod_php as part of xampp on my local pc for testing so it is not dead yet for development anyway.

I did think “warning” - if the owner of the box wants to go off and deliberately install then that is their :coffin: but it might save all the replies here where it seems to cause issues. (often loading old website code)

Without taking some steps to prevent it, every update that includes the mod_php package can potentially break all sites using other execution modes. Depends on the OS, I think, too, as to how disruptive it can be. I don’t remember. I just tell people to never do it, because there is never a reason to use mod_php, and that’s more because of performance, memory use, and most importantly, security, than because it’ll break your other sites. A broken site is not a security risk, but having every website run as the same user (a user that can read all domains homes) is.

2 Likes

I run mod_php8 heavily as I have a lot of pages that use php and I find the module version more secure than the cgi version. What is wrong with using php?

Quote: PHP may not be the flashiest programming language on the market, but its entrenched presence in mission-critical systems, modern frameworks, and globally scaled platforms makes it far from obsolete . In fact, PHP continues to deliver value where performance, cost-efficiency, and rapid development matter most.

PHP is unique among web programming languages because it was designed from the start to be embedded directly into HTML, making it feel more like a natural extension of the web rather than a separate backend system. Unlike modern frameworks and languages that enforce strict separation between logic and presentation, PHP allows developers to mix HTML and server-side code seamlessly, making it incredibly accessible for beginners and efficient for quick development.

Even after 30 years, no other mainstream language has replicated this approach successfully. Most alternatives either rely on templating engines, APIs, or complex frameworks that separate backend logic from HTML.

When PHP came to the scene, everyone was impressed with main differences from Perl:

  1. Input variables already in the global scope, no boring parsing.
  2. HTML embedding. Just <?php ... ?> anywhere. No boring templates.
  3. On-screen error messages. No boring error log peeks.
  4. Easy to learn. No boring book reading.

You should never use mod_php. CGI is more secure with suexec or fcgiwrap, but you shouldn’t use CGI either. To run PHP applications, you should use PHP-FPM.

Developers of both PHP and Apache began discouraging use of mod_php about two decades ago, I’m not going to rehash those arguments, if you haven’t been convinced to stop using it by two decades of the maintainers of the software telling you to stop, what hope do I have?

PHP is not mod_php. mod_php is an Apache module for running PHP applications in Apache processes. Its use has been discouraged for many years for security, performance, and efficiency reasons.

No one is telling you not to use PHP. You’re having a completely different argument completely unrelated to anything I said.

Don’t use mod_php. If you want to use mod_php, I can’t support you. That’s a mistake, and I won’t participate in doing ridiculous things.

1 Like

Interesting…

Security Benefits to Using php-fpm and Apache

Second, there are security benefits to using php-fpm. Since each pool can have its own configuration, you can run each application using a different system user, and these can in turn be different than what Apache HTTPD uses as well. This can help prevent privilege escalation or access to restricted areas of the filesystem, which could reduce information disclosure.

I hadn’t heard of this method of running php before. Each app can run as a different user? Nice. I switched my server from mod_php to php-fpm just now and all my php applications still seem to work after I moved my ini settings from /etc/php8/apache2/php.ini to /etc/php8/fpm/php.ini.

1 Like