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.
When a request is received, the server first maps it to the best matching <VirtualHost> based on the local IP address and port combination only. Non-wildcards have a higher precedence. If no match based on IP and port occurs at all, the "main" server configuration is used.
If multiple virtual hosts contain the best matching IP address and port, the server selects from these virtual hosts the best match based on the requested hostname. If no matching name-based virtual host is found, then the first listed virtual host that matched the IP address will be used. As a consequence, the first listed virtual host for a given IP address and port combination is the default virtual host for that IP and port combination.
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.comIt 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.comSSLEngine onSSLCertificateFile /etc/http/certs/example2.crt...</VirtualHost>Every other vhost had a different servername, and they used thecert 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.comI had believed this was because we had used *:443 rather than explicitly show the IPfor all our vhosts. It seemed the early conversation on SSL/TLS was matching a randomvhost via this use of *:443 and that's how it got the cert for example1.comSince 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 <thumbs@xxxxxxxxxx> 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 <fpicabia@xxxxxxxxx> 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 <fpicabia@xxxxxxxxx> wrote:It looks like there are two requirements for multiple top level domains with SSLon the same apache.1. IP values must be used inside VirtualHost, not *:4432. All IP values must be unique, even on the same top level domainIs the above conjecture true?We have many setup like this example...
<VirtualHost *:443 >ServerName s1.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 *This had nothing to do with the example2.com I also want to put in therebut 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
|