That is not correct. That causes httpd to try to look up the matching IP address using DNS. Use only IP addresses or wildcards.- YOn Fri, May 20, 2022 at 1:06 PM Bender, Charles <charles@xxxxxxxxxxxxxxx.invalid> wrote:Your virtual host is defined wrong. Use the names not IP addresses
<VirtualHost example2.com:443>Servername example2.comSSLEngine onSSLCertificateFile /etc/http/certs/example2.crt...</VirtualHost>
From: frank picabia <fpicabia@xxxxxxxxx>
Sent: Friday, May 20, 2022 12:55 PM
To: users@xxxxxxxxxxxxxxxx <users@xxxxxxxxxxxxxxxx>
Subject: Re: Re: Multi-domain with SSL - Virtualhost all need IPs?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.com
I 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 domain
Is 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
|