I'm trying hard to get the lay of the land logic here, and it isn't happening. I'm bouncing between what I read here, and what apache actually does, and it doesn't add up.
In my case we tried to introduce a new domain, let's call it example2.com It will have a different set of cert files. I let it have an IP which nothing else shares. I'm keenly aware of this IP as I've set it up in DNS as well. <VirtualHost 1.1.1.13:443> Servername example2.com SSLEngine on SSLCertificateFile /etc/http/certs/example2.crt ... </VirtualHost> Every other vhost had a different servername, and they used the cert for example1.com . They also had *:443 Only for example1.com do we have multiple aliases on the same IP. When visiting the example2.com site, the web site shows apache has served a certificate for example1.com I had believed this was because we had used *:443 rather than explicitly show the IP for all our vhosts. It seemed the early conversation on SSL/TLS was matching a random vhost via this use of *:443 and that's how it got the cert for example1.com Since before this point all vhosts were on example1.com the wildcard cert it found was always working while we had *:443 in use. What can we say about how multi-domain SSL works that we can rely on? I can find a dozen pages on google search from people who get the wrong certificate and they never get an answer. Some good hard rules on what is required would probably help a lot of people over the years. On Fri, May 20, 2022 at 11:59 AM Frank Gingras <thu...@apache.org> wrote: > 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 >>> >>> >>>
