SSL vhost setup fails due to ssl.conf (CentOS)

[mikemunger]

After setting up an ssl vhost through the apache_vhosts_ssl variable, starting apache fails with error "default VirtualHost overlap on port 443, the first has precedence", which is referring to the "" directive in ssl.conf (CentOS).

So perhaps the task could include commenting out or removing the vhost section in ssl.conf?

[fritz-c]

I had a similar issue on CentOS. In my case, I wanted to free up port 443 for another service, but the ssl.conf settings set up the example virtual host on 443. I fixed it at a later stage by removing the ssl.conf file and restarting apache, but I'd prefer a solution that's contained within this role.

[ascotan]

I just ran into this bug while using this to provision a EL6 box. I'm wondering if this project is dead considering this bug has been open for over 2 years....

[root@a64103c38983 /]# service httpd restart
Stopping httpd:                                            [  OK  ]
[Sun Feb 05 22:37:22 2017] [warn] _default_ VirtualHost overlap on port 443, the first has precedence

[ascotan]

BTW for future reference this is a workaround on centos6:

    apache_vhosts_filename: "ssl.conf"
    apache_global_vhost_settings: |
      LoadModule ssl_module modules/mod_ssl.so
      Listen 443
      SSLPassPhraseDialog  builtin
      SSLSessionCache         shmcb:/var/cache/mod_ssl/scache(512000)
      SSLSessionCacheTimeout  300
      SSLMutex default
      SSLRandomSeed startup file:/dev/urandom  256
      SSLRandomSeed connect builtin
      SSLCryptoDevice builtin

[geerlingguy]

I'm wondering if this project is dead considering this bug has been open for over 2 years....

Welcome to open source ;-)

This is not a bug that particularly affects me or my workflow, and this role is actively in use for thousands of server configurations (I manage at least three dozen different server configs with and without SSL across about 55 servers personally).

Since it doesn't affect my own workflow, I haven't really given it a ton of attention, since it is sort-of an edge case on one particular OS, and since there are multiple ways to work around the edge case.

If someone would like to take the work to give a reliable 'steps to reproduce', a PR with a fix, and a detailed explanation of why it's necessary, I can merge it in a heartbeat. But as it is, I think this issue suffices for a band-aid for those needing it for now (which is why I've left it open and not closed it).

[till]

@geerlingguy There is a fix in another fork:
wcm-io-devops#3

Would you mind merging it in?

I just ran into the same problem this morning and TBH, not sure right now how it ever worked. The _default_:443 VirtualHost got in between and blocked the actual VirtualHost which I had previously created with this role.

I found this in my logs:

[Tue Oct 01 12:28:39.420616 2019] [ssl:warn] [pid 10915] AH02292: Init: Name-based SSL virtual hosts only work for clients with TLS server name indication support (RFC 4366)

[stale]

This issue has been marked 'stale' due to lack of recent activity. If there is no further activity, the issue will be closed in another 30 days. Thank you for your contribution!

Please read this blog post to see the reasons why I mark issues as stale.

[till]

🤷🏻‍♂️

[stale]

This issue is no longer marked for closure.