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
>>
>>
>>

Reply via email to