Apache error: (98)Address already in use: AH00072: make_sock: could not bind to address 0.0.0.0:443

I’m setting up SSL in my apache server. After activating SSL in sysconfig and restart apache, I get this error


aldebaran:/etc/apache2 # apachectl start
(98)Address already in use: AH00072: make_sock: could not bind to address 0.0.0.0:443
no listening sockets available, shutting down
AH00015: Unable to open logs
aldebaran:/etc/apache2 # 

I have found that if I edit /etc/apache2/listen.conf



Listen 80


<IfDefine SSL>
        <IfDefine !NOSSL>
        <IfModule mod_ssl.c>

#               Listen 443

        </IfModule>
        </IfDefine>
</IfDefine>




and comment the Listen 443 line, the error is gone and apache starts ok (no SSL).
So i thought that there must be some Listen 443 line in any other place and they were entering in conflict, but



aldebaran:/etc/apache2 # cat *conf |grep Listen
# Listen: Allows you to bind Apache to specific IP addresses and/or
# Change this to Listen on specific IP addresses as shown below to 
#       Listen directives: "Listen ::]:443" and "Listen 0.0.0.0:443"
#Listen 12.34.56.78:80
#Listen 80
#Listen 443
Listen 80
#               Listen 443




aldebaran:/etc/apache2 # cat vhosts.d/*conf |grep Listen
aldebaran:/etc/apache2 # 



… so no more Listen 443

So what may be the problem?

best regards

Is SSL enabled for the webserver?


sudo a2enmod -l

yes


aldebaran:/etc/apache2/vhosts.d # a2enmod -l
php7 php5 authz_host actions alias authn_file authz_user authz_groupfile auth_basic autoindex cgi dir include log_config mime negotiation setenvif status asis imagemap auth auth_host authz_core auth_core authn_core rewrite headers env version ssl
aldebaran:/etc/apache2/vhosts.d # 



So, that’s not the issue. I usually setup vhosts in /etc/apache/vhosts.d ( as YaST’s http module does ). You need vhosts if you want both port 80 and 443 to work, If you want I can show you the ones for my nextcloud instance, which has 2 vhosts entries, one for port 80 ( which does nothing but redirect to https ) and one for 443.

0.0.0.0 is the IP address which means “broadcast” (all addresses, no specific address).
Which doesn’t make sense for SSL.

Re-inspect your website setup, make sure it’s configured for a specific IP address and not “all addresses.”

TSU

Missed that, well spotted.

I have changed /etc/apache2/Listen.conf


Listen 80

<IfDefine SSL>
        <IfDefine !NOSSL>
        <IfModule mod_ssl.c>

                Listen 192.168.2.5:443

        </IfModule>
        </IfDefine>
</IfDefine>

and then


aldebaran:/etc/apache2 # apachectl start
(98)Address already in use: AH00072: make_sock: could not bind to address 192.168.2.5:443
no listening sockets available, shutting down
AH00015: Unable to open logs
aldebaran:/etc/apache2 # 

then searching I have tested


aldebaran:/etc/apache2 # lsof -i :443
COMMAND    PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
vmware-ho 2014 root   16u  IPv4  29838      0t0  TCP *:https (LISTEN)
vmware-ho 2014 root   17u  IPv6  29839      0t0  TCP *:https (LISTEN)

So vmware is doing things…


aldebaran:/etc/apache2 # ps aux |grep vmware-ho
root      2014  0.0  0.7 1156108 28984 ?       Sl   dic07   0:46 /usr/lib/vmware/bin/vmware-hostd -a /etc/vmware/hostd/config.xml
root      5099  0.0  0.0   8688   952 pts/0    S+   01:10   0:00 grep --color=auto vmware-ho

aldebaran:/etc/apache2 # kill 2014

Now I can enable any of

            Listen 192.168.2.5:443

or

            Listen 443

in Listen.conf, apache boots with no complaint with both of them.

Which one is better?

I disabled shared vms in vmware, and that’s it.

thanks

First,
Because you’re deployed on vmware, you should have posted in the Virtualization forums
And now it sounds like you are executing functions that are specific to the virtualization and not typical of an application running on any kind of install (even on bare metal).

You’ll need to describe what VMware setup you have… ESX? Maybe you’re executing your vmware command within the context of some other kind of virtualization manager?

If you’re deployed in a VPS,
Then it’s conceivable that certain Management commands might invoke configurations within the virtual machine, but otherwise in this Applications forum, we hope to stick to commands that execute only on the local system.

TSU

No, it is not deployed on vmware it’s only that there were a vmware workstaton running on this machine (in fact i’m not using it , I installed it some time ago to test how shared vms worked, and it seems I forgot to remove it) and the https of the vmware (for the ws server, for sharing vms) was eneting in conflict with apache.

regards

For future posterity, the first thing you might have wanted to do was look at what was running at :443

ss -napl | grep -i 443

or if you prefer lsof

lsof -iTCP:443 -sTCP:LISTEN

That would have shown the process in question using port 443.

Your Workstation is likely configured with remote management enabled, the default port is port 443 (sharing the default SSL port).

If you are not using VMware Workstation for anything, and don’t intend to use it in the future it’d likely be good practice to uninstall and remove it…
If uninstalling isn’t sufficient to remove the app,
I outlined some steps for purging all remnants of an app from a system in the following post which needed to purge the system of PostgreSQL, you can modify for VMware Workstation. Since VMware Workstation likely was originally installed running the VMware Installer, you should run the installer again which should detect you installation and offer to uninstall for you.
https://forums.opensuse.org/showthread.php/533714-Postgresql?p=2885264#post2885264

Then,
You you test your machine again for any processes using port 443, your Apache should work without the conflict Workstation was causing for you.

TSU