As mentioned, name-based vhosts will work with SNI and *:443 provided that you have the correct certificate assigned to each vhost.
In rare cases, you can use IP:443 vhosts if you want specific handling based on the IP used to handle the request, such as https://IP1/ or https://IP2/. However, it is rarely needed by most servers. For now, you can use *:443, and run apachectl -S to make sure there is no overlap before restarting httpd. On Fri, 20 May 2022 at 07:04, frank picabia <fpica...@gmail.com> wrote: > > Sorry, that should not have said "top level domains". I meant domains. > Like example.com, example.net. > > > On Fri, May 20, 2022 at 7:05 AM frank picabia <fpica...@gmail.com> wrote: > >> >> It looks like there are two requirements for multiple top level domains >> with SSL >> on the same apache. >> >> 1. IP values must be used inside VirtualHost, not *:443 >> 2. All IP values must be unique, even on the same top level domain >> >> Is the above conjecture true? >> >> We have many setup like this example... >> >> <VirtualHost *:443 > >> ServerName s1.example1.com >> ... >> </VirtualHost> >> >> <VirtualHost *:443 > >> ServerName s2.example1.com >> ... >> </VirtualHost> >> >> where s1 and s2 are aliases on the same IP. It has worked like that for >> years. 330 vhosts on about 80 IPs. >> >> When I started to convert them to use the actual IP value rather than * >> >> <VirtualHost 1.1.1.1:443 > >> ServerName s1.example1.com >> ... >> </VirtualHost> >> <VirtualHost 1.1.1.1:443 > >> ServerName s2.example1.com >> ... >> </VirtualHost> >> >> This had nothing to do with the example2.com I also want to put in there >> but on a unique IP. I did a few conversions from *:443, saved it and >> restarted apache. >> Then vhosts I had not touched yet were getting pages for other >> vhosts. It was random chaos and I reverted to the previous ssl.conf copy >> >> >>