Mailing List Archive

See if you can add a SAN to that wildcard certificate first.

On Wed, 18 May 2022 at 15:21, frank picabia <fpicabia@gmail.com> wrote:

>
> We have a server with over 300 vhosts on it. Marketing/CMS madness I
> guess.
> All on the same domain name. Many VirtualHosts are defined with *:443
> and then ServerName to rely on SNI.
> We have a wildcard cert for the domain and all the hosts use that.
>
> Now there is a different domain to add for SSL. For some reason
> the first domain name's certificate is being found. I've put the
> IP for our new comer domain so we have <VirtualHost 1.1.1.1:443 >
> but it is still finding the other cert. This IP is uniquely assigned
> with the different domain, as you'd expect with DNS. So it can't
> be a overlap of the IP used elsewhere.
>
> Researching this problem ("wrong cert loaded for vhost"),
> I read that in the initial SSL connection, it
> is talking to the IP, and whatever values we have for ServerName
> have no bearing until the page is being accessed. If that's the case
> then it might have matched another vhost with *:443 first
> I tried putting my new domain at the top of ssl.conf but it made no
> difference.
>
> I'm thinking I need to edit each *:443 case and change it to the
> appropriate IP.
> That will be a lot of work, so I'm looking for affirmation that is likely
> to make the difference.
>
>
>

Sorry, different domain.

300 hosts like *.example1.com
and now we have 1 example2.com


On Wed, May 18, 2022 at 4:31 PM Frank Gingras <thumbs@apache.org> wrote:

> See if you can add a SAN to that wildcard certificate first.
>
> On Wed, 18 May 2022 at 15:21, frank picabia <fpicabia@gmail.com> wrote:
>
>>
>> We have a server with over 300 vhosts on it. Marketing/CMS madness I
>> guess.
>> All on the same domain name. Many VirtualHosts are defined with *:443
>> and then ServerName to rely on SNI.
>> We have a wildcard cert for the domain and all the hosts use that.
>>
>> Now there is a different domain to add for SSL. For some reason
>> the first domain name's certificate is being found. I've put the
>> IP for our new comer domain so we have <VirtualHost 1.1.1.1:443 >
>> but it is still finding the other cert. This IP is uniquely assigned
>> with the different domain, as you'd expect with DNS. So it can't
>> be a overlap of the IP used elsewhere.
>>
>> Researching this problem ("wrong cert loaded for vhost"),
>> I read that in the initial SSL connection, it
>> is talking to the IP, and whatever values we have for ServerName
>> have no bearing until the page is being accessed. If that's the case
>> then it might have matched another vhost with *:443 first
>> I tried putting my new domain at the top of ssl.conf but it made no
>> difference.
>>
>> I'm thinking I need to edit each *:443 case and change it to the
>> appropriate IP.
>> That will be a lot of work, so I'm looking for affirmation that is likely
>> to make the difference.
>>
>>
>>

Not sure if you saw the other answer on the other email:

// If you can't use a SAN, then you need to configure all your vhosts as
IP:443, whereas one vhost uses a separate IP, and the remainder uses the
second IP.

On Wed, 18 May 2022 at 17:26, frank picabia <fpicabia@gmail.com> wrote:

> Sorry, different domain.
>
> 300 hosts like *.example1.com
> and now we have 1 example2.com
>
>
> On Wed, May 18, 2022 at 4:31 PM Frank Gingras <thumbs@apache.org> wrote:
>
>> See if you can add a SAN to that wildcard certificate first.
>>
>> On Wed, 18 May 2022 at 15:21, frank picabia <fpicabia@gmail.com> wrote:
>>
>>>
>>> We have a server with over 300 vhosts on it. Marketing/CMS madness I
>>> guess.
>>> All on the same domain name. Many VirtualHosts are defined with *:443
>>> and then ServerName to rely on SNI.
>>> We have a wildcard cert for the domain and all the hosts use that.
>>>
>>> Now there is a different domain to add for SSL. For some reason
>>> the first domain name's certificate is being found. I've put the
>>> IP for our new comer domain so we have <VirtualHost 1.1.1.1:443 >
>>> but it is still finding the other cert. This IP is uniquely assigned
>>> with the different domain, as you'd expect with DNS. So it can't
>>> be a overlap of the IP used elsewhere.
>>>
>>> Researching this problem ("wrong cert loaded for vhost"),
>>> I read that in the initial SSL connection, it
>>> is talking to the IP, and whatever values we have for ServerName
>>> have no bearing until the page is being accessed. If that's the case
>>> then it might have matched another vhost with *:443 first
>>> I tried putting my new domain at the top of ssl.conf but it made no
>>> difference.
>>>
>>> I'm thinking I need to edit each *:443 case and change it to the
>>> appropriate IP.
>>> That will be a lot of work, so I'm looking for affirmation that is
>>> likely to make the difference.
>>>
>>>
>>>

Ok thanks. We've gotten away with the *:443 shorthand for a long time
because
no one wanted to pony up the money for a cert for the other handful of
hobby domains.

On Wed, May 18, 2022 at 6:54 PM Frank Gingras <thumbs@apache.org> wrote:

> Not sure if you saw the other answer on the other email:
>
> // If you can't use a SAN, then you need to configure all your vhosts as
> IP:443, whereas one vhost uses a separate IP, and the remainder uses the
> second IP.
>
> On Wed, 18 May 2022 at 17:26, frank picabia <fpicabia@gmail.com> wrote:
>
>> Sorry, different domain.
>>
>> 300 hosts like *.example1.com
>> and now we have 1 example2.com
>>
>>
>> On Wed, May 18, 2022 at 4:31 PM Frank Gingras <thumbs@apache.org> wrote:
>>
>>> See if you can add a SAN to that wildcard certificate first.
>>>
>>> On Wed, 18 May 2022 at 15:21, frank picabia <fpicabia@gmail.com> wrote:
>>>
>>>>
>>>> We have a server with over 300 vhosts on it. Marketing/CMS madness I
>>>> guess.
>>>> All on the same domain name. Many VirtualHosts are defined with *:443
>>>> and then ServerName to rely on SNI.
>>>> We have a wildcard cert for the domain and all the hosts use that.
>>>>
>>>> Now there is a different domain to add for SSL. For some reason
>>>> the first domain name's certificate is being found. I've put the
>>>> IP for our new comer domain so we have <VirtualHost 1.1.1.1:443 >
>>>> but it is still finding the other cert. This IP is uniquely assigned
>>>> with the different domain, as you'd expect with DNS. So it can't
>>>> be a overlap of the IP used elsewhere.
>>>>
>>>> Researching this problem ("wrong cert loaded for vhost"),
>>>> I read that in the initial SSL connection, it
>>>> is talking to the IP, and whatever values we have for ServerName
>>>> have no bearing until the page is being accessed. If that's the case
>>>> then it might have matched another vhost with *:443 first
>>>> I tried putting my new domain at the top of ssl.conf but it made no
>>>> difference.
>>>>
>>>> I'm thinking I need to edit each *:443 case and change it to the
>>>> appropriate IP.
>>>> That will be a lot of work, so I'm looking for affirmation that is
>>>> likely to make the difference.
>>>>
>>>>
>>>>

On Wed, May 18, 2022 at 11:53 PM Frank Gingras <thumbs@apache.org> wrote:
>
> Not sure if you saw the other answer on the other email:
>
> // If you can't use a SAN, then you need to configure all your vhosts as IP:443, whereas one vhost uses a separate IP, and the remainder uses the second IP.

That sounds wrong to me. Apache should pick a matching certificate for
the hostname specified via SNI by the client, if any, or the first one
configured as a fallback (assuming the vhost IP / * specification
matches). Note that only vhosts with IP:port are considered, if any
are specified and match the request. You should be able to use *:443
for all vhosts.

Rainer

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org

ok this is starting to make more sense as we go along ....

I went through all of this myself when setting up origionally

i found that i can not use vhosts easily with ssl / sni / sans etc

and san is a nightmare to manage everytime you make a cert change.

it was just more reliable to use individual config entries and sni and
proper certs for the domain.

also note certrs today handle the domain.com & www.domain.com in one
cert (or apache - never really did figure that out)

basically domain.com handles both with the ServerAlias


also (why i forgot about it) vhosts allows users to criss cross
directories data wise (ie all rights are users www:www) which is why i
went away from that type of config.

unless this has changed i ended up dumping vhosts config and went with
individual config entries per website.


examples below using *:80 & *:443 respectively

<VirtualHost *:80>
ServerName underconstruction.scom.ca
ServerAlias underconstruction.scom.ca
DocumentRoot /www/underconstruction.scom.ca
</VirtualHost>

<VirtualHost *:443>
ServerName underconstruction.scom.ca
ServerAlias underconstruction.scom.ca
DocumentRoot /www/underconstruction.scom.ca
SSLEngine on
SSLProtocol all
SSLCertificateKeyFile /www/scom.ca/ssl/scom.ca.key
SSLCertificateFile /www/scom.ca/ssl/scom.ca.crt
SSLCertificateChainFile /www/scom.ca/ssl/scom.ca.chain
</VirtualHost>

I know its long and drawn out in the config file which is why i wrote a
python script against a pgsql database to generate my config but IT DOES
WORK!


a better example (more secure) - this keeps all php scripts and users
from bleeding into other user directories. This is how onetoone, myself
and a bunch of other providers got hacked a few years back.

Mainly due to wordpress security issues.

vhosts is convient but not super secure.

<VirtualHost *:80>
ServerName video.guelph.eks.scom.ca
ServerAlias video.guelph.eks.scom.ca
DocumentRoot /www/video.guelph.eks.scom.ca


SuexecUserGroup www www

<Directory "/www/video.guelph.eks.scom.ca/wp-content/uploads/">
<Files "*.php">
Order Deny,Allow
Deny from All
</Files>
</Directory>

<Directory /www/video.guelph.eks.scom.ca>
php_admin_value open_basedir /www/video.guelph.eks.scom.ca:/var/log/
</Directory>

<Directory /www/video.guelph.eks.scom.ca>
php_admin_value sys_temp_dir /www/video.guelph.eks.scom.ca/tmp/
</Directory>

<Directory /www/video.guelph.eks.scom.ca>
php_admin_value session.save_path /www/video.guelph.eks.scom.ca/tmp/
</Directory>

<Directory /www/video.guelph.eks.scom.ca>
php_admin_value soap.wsdl_cache_dir /www/video.guelph.eks.scom.ca/tmp/
</Directory>

<Directory /www/video.guelph.eks.scom.ca>
php_admin_value upload_tmp_dir /www/video.guelph.eks.scom.ca/tmp
</Directory>

<Directory "/www/video.guelph.eks.scom.ca">
AllowOverride All
php_value session.save_path "/www/video.guelph.eks.scom.ca/"
</Directory>

</VirtualHost>


&

<VirtualHost *:443>
ServerName video.guelph.eks.scom.ca
ServerAlias video.guelph.eks.scom.ca
DocumentRoot /www/video.guelph.eks.scom.ca


SuexecUserGroup www www

<Directory "/www/video.guelph.eks.scom.ca/wp-content/uploads/">
<Files "*.php">
Order Deny,Allow
Deny from All
</Files>
</Directory>

<Directory /www/video.guelph.eks.scom.ca>
php_admin_value open_basedir /www/video.guelph.eks.scom.ca:/var/log/
</Directory>

<Directory /www/video.guelph.eks.scom.ca>
php_admin_value sys_temp_dir /www/video.guelph.eks.scom.ca/tmp/
</Directory>

<Directory /www/video.guelph.eks.scom.ca>
php_admin_value session.save_path /www/video.guelph.eks.scom.ca/tmp/
</Directory>

<Directory /www/video.guelph.eks.scom.ca>
php_admin_value soap.wsdl_cache_dir /www/video.guelph.eks.scom.ca/tmp/
</Directory>

<Directory /www/video.guelph.eks.scom.ca>
php_admin_value upload_tmp_dir /www/video.guelph.eks.scom.ca/tmp
</Directory>

<Directory "/www/video.guelph.eks.scom.ca">
AllowOverride All
php_value session.save_path "/www/video.guelph.eks.scom.ca/"
</Directory>

SSLEngine on
SSLProtocol all
SSLCertificateKeyFile /www/scom.ca/ssl/scom.ca.key
SSLCertificateFile /www/scom.ca/ssl/scom.ca.crt
SSLCertificateChainFile /www/scom.ca/ssl/scom.ca.chain

</VirtualHost>

Note I have a wildcard ssl cert but the file location setup is clearly
defined.



Happy Thursday !!!
Thanks - paul

Paul Kudla


Scom.ca Internet Services <http://www.scom.ca>
004-1009 Byron Street South
Whitby, Ontario - Canada
L1N 4S3

Toronto 416.642.7266
Main 1.866.411.7266
Fax 1.888.892.7266

On 5/19/2022 9:11 AM, Rainer Canavan wrote:
>
> On Wed, May 18, 2022 at 11:53 PM Frank Gingras <thumbs@apache.org> wrote:
>>
>> Not sure if you saw the other answer on the other email:
>>
>> // If you can't use a SAN, then you need to configure all your vhosts as IP:443, whereas one vhost uses a separate IP, and the remainder uses the second IP.
>
> That sounds wrong to me. Apache should pick a matching certificate for
> the hostname specified via SNI by the client, if any, or the first one
> configured as a fallback (assuming the vhost IP / * specification
> matches). Note that only vhosts with IP:port are considered, if any
> are specified and match the request. You should be able to use *:443
> for all vhosts.
>
> Rainer
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
> For additional commands, e-mail: users-help@httpd.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org

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

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

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

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 <thumbs@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 <fpicabia@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 <fpicabia@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
>>>
>>>
>>>

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

If you have <VirtualHost *:443>, it will use ALL IPs - if you want to
dedicate an IP for a site, you need to specify IPs for every other site too.

I am not sure how this matches what you see though - non-wildcard
VirtualHost declarations are supposed to have precedence over wildcards and
I have never seen this issue on any of my systems.

From the documentation (
https://httpd.apache.org/docs/2.4/mod/core.html#virtualhost):

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


Use `httpd -S` (or `apache2ctl -S`, depending on your distribution) to
verify the list of VirtualHosts being served.

- Y

On Fri, May 20, 2022 at 12:56 PM frank picabia <fpicabia@gmail.com> wrote:

> 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 <thumbs@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 <fpicabia@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 <fpicabia@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
>>>>
>>>>
>>>>

Your virtual host is defined wrong. Use the names not IP addresses

<VirtualHost example2.com:443<http://1.1.1.13:443/>>
Servername example2.com<https://linkprotect.cudasvc.com/url?a=http%3a%2f%2fexample2.com&c=E,1,dcUCUjUb4LYF2QKtZR97YwwXQvScdoETUyYneNIzxrVPCY07TRsv343JxU2TC5RtNYHxyF97S7yA3AepHgKTSlaPMWipWynnIbri9ZFZlIJCfOISNr175hJJNl8,&typo=1>
SSLEngine on
SSLCertificateFile /etc/http/certs/example2.crt
...
</VirtualHost>
________________________________
From: frank picabia <fpicabia@gmail.com>
Sent: Friday, May 20, 2022 12:55 PM
To: users@httpd.apache.org <users@httpd.apache.org>
Subject: Re: [users@httpd] 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.com<https://linkprotect.cudasvc.com/url?a=http%3a%2f%2fexample2.com&c=E,1,6W_vM4KZBARFuk6DDpPWoNW12LzjGIFV8FRTADGmecW5MGLigif3cCg9i_upqN6olj_Qr7kWBGqNJu2EXeP8QeUVkPmMk1TYwQ1pcBTxx32XgAlhuKEDKcpL&typo=1>
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<http://1.1.1.13:443>>
Servername example2.com<https://linkprotect.cudasvc.com/url?a=http%3a%2f%2fexample2.com&c=E,1,dcUCUjUb4LYF2QKtZR97YwwXQvScdoETUyYneNIzxrVPCY07TRsv343JxU2TC5RtNYHxyF97S7yA3AepHgKTSlaPMWipWynnIbri9ZFZlIJCfOISNr175hJJNl8,&typo=1>
SSLEngine on
SSLCertificateFile /etc/http/certs/example2.crt
...
</VirtualHost>

Every other vhost had a different servername, and they used the
cert for example1.com<https://linkprotect.cudasvc.com/url?a=http%3a%2f%2fexample1.com&c=E,1,hWtAIAcngoqDN67tYYh-JBMRsDu0loXxcOnLFfiTh0kkC73FcXss_uAVRLOtoJLqXOCEN9jyzjXqVBcPyZW7t70FdDG9MVq19wuX_0SAFBLk7qkKRSlWDw,,&typo=1> . They also had *:443
Only for example1.com<https://linkprotect.cudasvc.com/url?a=http%3a%2f%2fexample1.com&c=E,1,0PHWaifn8IWmWbVOrikm7fz8IiJtabA_5-R1x0XKMlFFo3oBud94pi8En8RPBR3KLTR3QenHwFjS7HQgJNY1qG-nQe_UmNGE2X8vrXjghYl5KQ,,&typo=1> do we have multiple aliases on the same IP.

When visiting the example2.com<https://linkprotect.cudasvc.com/url?a=http%3a%2f%2fexample2.com&c=E,1,QZFYnaarDKwbI4UIuis6AUVr6M_IY5nT64iVqhrFOfC1SFad9Dq-LeBk2Prq7-LyNrzbvo_FfMN1PezvDeICv0bWAkLH1rCsEqr9d-W4KMjU_tMJ5hg,&typo=1> site, the web site shows apache has served a certificate for example1.com<https://linkprotect.cudasvc.com/url?a=http%3a%2f%2fexample1.com&c=E,1,T_cQOb_HmAeeARzztUhUpYrFdC-M2k8aEzqZWhQryiy784g3BQNmtSe51GNCXcXQIbgEUbfPVEl5zdNv7G3-cgN_D5iSOe-t-0dOr8s9Ogm_ZwvXlaaXXQJDP78,&typo=1>

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<https://linkprotect.cudasvc.com/url?a=http%3a%2f%2fexample1.com&c=E,1,Mz11UTCKtiWcGt6Y8IkJjBHQLSOD5JkAKituHpPrZu5-qa6kZmzAj0yKhiovnyiw6bX333zd9IKH73D6x3DQsfQOvC7ztgVXyiO7EUHWBXHjoys4q30,&typo=1>
Since before this point all vhosts were on example1.com<https://linkprotect.cudasvc.com/url?a=http%3a%2f%2fexample1.com&c=E,1,8wXSzKIRaGVigrHUZoxWD8812IQ1_5RSU52jRZYKX7BQPnCQrAcHUwhw_BOV_E5zA1jMdtUHbqCd9jwXZ8HLFcDM7HcYG31scrYTMuAWMw,,&typo=1> 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@apache.org<mailto:thumbs@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 <fpicabia@gmail.com<mailto:fpicabia@gmail.com>> wrote:

Sorry, that should not have said "top level domains". I meant domains. Like example.com<http://example.com>, example.net<https://linkprotect.cudasvc.com/url?a=http%3a%2f%2fexample.net&c=E,1,Lf7WCUECY7EjPemnM7RAgRqLA_RtcGdzOib3lOf7AW0vkHA8LZPhA_Cyx4vxm2UkTXZdaO6ax9tCWnAP4NJ8QbZC7d6pFPimkBkaFwrXGA,,&typo=1>.


On Fri, May 20, 2022 at 7:05 AM frank picabia <fpicabia@gmail.com<mailto:fpicabia@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<https://linkprotect.cudasvc.com/url?a=http%3a%2f%2fs1.example1.com&c=E,1,wsz87BMMp2oMlSddl_CqoJGdX4XfnA4SBhZHzfihJZJUFFJolpRBPQ1tm6G08DwlDNVBTcY1p7ZsxfEAtdfJ59gsZRoDVQeNBtWtKHbD&typo=1>
...
</VirtualHost>

<VirtualHost *:443 >
ServerName s2.example1.com<https://linkprotect.cudasvc.com/url?a=http%3a%2f%2fs2.example1.com&c=E,1,7pvCP6udZ3aZHoj-a0jz-AgOyf0BqRRLwQMOAtBCbrpGJX7So009M8zSgwIQRUxx3EB6zyyZKInj66oF7Td7UcJqi0h7gBdt_0zI0uL4PwM06AV6AQ,,&typo=1>
...
</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<http://1.1.1.1:443> >
ServerName s1.example1.com<https://linkprotect.cudasvc.com/url?a=http%3a%2f%2fs1.example1.com&c=E,1,NvBi26pDh9IxdmyKgHLNK4p32Qv1cFQtyVXbIlC9HHOgiLAV95Pz_D8y_lWST789soOsTkxYjzJJJhMaqd4C8KT5RkVYHb73BPZZCPeWlhB7bt3Z6lPIEdWSe3Wd&typo=1>
...
</VirtualHost>
<VirtualHost 1.1.1.1:443<http://1.1.1.1:443> >
ServerName s2.example1.com<https://linkprotect.cudasvc.com/url?a=http%3a%2f%2fs2.example1.com&c=E,1,8X1MRWLchBd0jtI-FkYh2nb2lyg0LtCgOeCkKgkA16Wdz7Q11brpocrr15c9F9_OqRnWEqwExVy6LEiVykh8JwIhtyIlb2Madiz9yfOano0,&typo=1>
...
</VirtualHost>

This had nothing to do with the example2.com<https://linkprotect.cudasvc.com/url?a=http%3a%2f%2fexample2.com&c=E,1,ul_Sx0-1ZWGylDIVnZp9Xcqxf0r3cNY7JsJnUxT2ir53quY-0jVC5gTotkqGkJbvAzWE3tNI01fkJt3aoWuCI0MkdIM9ZPWyrJuBGzFiVA,,&typo=1> 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

That is not correct. That causes httpd to try to look up the matching IP
address using DNS. Use only IP addresses or wildcards.

- Y

On Fri, May 20, 2022 at 1:06 PM Bender, Charles
<charles@beachcamera.com.invalid> wrote:

> Your virtual host is defined wrong. Use the names not IP addresses
>
> <VirtualHost example2.com:443 <http://1.1.1.13:443/>>
> Servername example2.com
> <https://linkprotect.cudasvc.com/url?a=http%3a%2f%2fexample2.com&c=E,1,dcUCUjUb4LYF2QKtZR97YwwXQvScdoETUyYneNIzxrVPCY07TRsv343JxU2TC5RtNYHxyF97S7yA3AepHgKTSlaPMWipWynnIbri9ZFZlIJCfOISNr175hJJNl8,&typo=1>
> SSLEngine on
> SSLCertificateFile /etc/http/certs/example2.crt
> ...
> </VirtualHost>
> ------------------------------
> *From:* frank picabia <fpicabia@gmail.com>
> *Sent:* Friday, May 20, 2022 12:55 PM
> *To:* users@httpd.apache.org <users@httpd.apache.org>
> *Subject:* Re: [users@httpd] 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.com
> <https://linkprotect.cudasvc.com/url?a=http%3a%2f%2fexample2.com&c=E,1,6W_vM4KZBARFuk6DDpPWoNW12LzjGIFV8FRTADGmecW5MGLigif3cCg9i_upqN6olj_Qr7kWBGqNJu2EXeP8QeUVkPmMk1TYwQ1pcBTxx32XgAlhuKEDKcpL&typo=1>
> 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
> <https://linkprotect.cudasvc.com/url?a=http%3a%2f%2fexample2.com&c=E,1,dcUCUjUb4LYF2QKtZR97YwwXQvScdoETUyYneNIzxrVPCY07TRsv343JxU2TC5RtNYHxyF97S7yA3AepHgKTSlaPMWipWynnIbri9ZFZlIJCfOISNr175hJJNl8,&typo=1>
> SSLEngine on
> SSLCertificateFile /etc/http/certs/example2.crt
> ...
> </VirtualHost>
>
> Every other vhost had a different servername, and they used the
> cert for example1.com
> <https://linkprotect.cudasvc.com/url?a=http%3a%2f%2fexample1.com&c=E,1,hWtAIAcngoqDN67tYYh-JBMRsDu0loXxcOnLFfiTh0kkC73FcXss_uAVRLOtoJLqXOCEN9jyzjXqVBcPyZW7t70FdDG9MVq19wuX_0SAFBLk7qkKRSlWDw,,&typo=1>
> . They also had *:443
> Only for example1.com
> <https://linkprotect.cudasvc.com/url?a=http%3a%2f%2fexample1.com&c=E,1,0PHWaifn8IWmWbVOrikm7fz8IiJtabA_5-R1x0XKMlFFo3oBud94pi8En8RPBR3KLTR3QenHwFjS7HQgJNY1qG-nQe_UmNGE2X8vrXjghYl5KQ,,&typo=1>
> do we have multiple aliases on the same IP.
>
> When visiting the example2.com
> <https://linkprotect.cudasvc.com/url?a=http%3a%2f%2fexample2.com&c=E,1,QZFYnaarDKwbI4UIuis6AUVr6M_IY5nT64iVqhrFOfC1SFad9Dq-LeBk2Prq7-LyNrzbvo_FfMN1PezvDeICv0bWAkLH1rCsEqr9d-W4KMjU_tMJ5hg,&typo=1>
> site, the web site shows apache has served a certificate for example1.com
> <https://linkprotect.cudasvc.com/url?a=http%3a%2f%2fexample1.com&c=E,1,T_cQOb_HmAeeARzztUhUpYrFdC-M2k8aEzqZWhQryiy784g3BQNmtSe51GNCXcXQIbgEUbfPVEl5zdNv7G3-cgN_D5iSOe-t-0dOr8s9Ogm_ZwvXlaaXXQJDP78,&typo=1>
>
> 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
> <https://linkprotect.cudasvc.com/url?a=http%3a%2f%2fexample1.com&c=E,1,Mz11UTCKtiWcGt6Y8IkJjBHQLSOD5JkAKituHpPrZu5-qa6kZmzAj0yKhiovnyiw6bX333zd9IKH73D6x3DQsfQOvC7ztgVXyiO7EUHWBXHjoys4q30,&typo=1>
> Since before this point all vhosts were on example1.com
> <https://linkprotect.cudasvc.com/url?a=http%3a%2f%2fexample1.com&c=E,1,8wXSzKIRaGVigrHUZoxWD8812IQ1_5RSU52jRZYKX7BQPnCQrAcHUwhw_BOV_E5zA1jMdtUHbqCd9jwXZ8HLFcDM7HcYG31scrYTMuAWMw,,&typo=1>
> 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@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 <fpicabia@gmail.com> wrote:
>
>
> Sorry, that should not have said "top level domains". I meant domains.
> Like example.com, example.net
> <https://linkprotect.cudasvc.com/url?a=http%3a%2f%2fexample.net&c=E,1,Lf7WCUECY7EjPemnM7RAgRqLA_RtcGdzOib3lOf7AW0vkHA8LZPhA_Cyx4vxm2UkTXZdaO6ax9tCWnAP4NJ8QbZC7d6pFPimkBkaFwrXGA,,&typo=1>
> .
>
>
> On Fri, May 20, 2022 at 7:05 AM frank picabia <fpicabia@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
> <https://linkprotect.cudasvc.com/url?a=http%3a%2f%2fs1.example1.com&c=E,1,wsz87BMMp2oMlSddl_CqoJGdX4XfnA4SBhZHzfihJZJUFFJolpRBPQ1tm6G08DwlDNVBTcY1p7ZsxfEAtdfJ59gsZRoDVQeNBtWtKHbD&typo=1>
> ...
> </VirtualHost>
>
> <VirtualHost *:443 >
> ServerName s2.example1.com
> <https://linkprotect.cudasvc.com/url?a=http%3a%2f%2fs2.example1.com&c=E,1,7pvCP6udZ3aZHoj-a0jz-AgOyf0BqRRLwQMOAtBCbrpGJX7So009M8zSgwIQRUxx3EB6zyyZKInj66oF7Td7UcJqi0h7gBdt_0zI0uL4PwM06AV6AQ,,&typo=1>
> ...
> </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
> <https://linkprotect.cudasvc.com/url?a=http%3a%2f%2fs1.example1.com&c=E,1,NvBi26pDh9IxdmyKgHLNK4p32Qv1cFQtyVXbIlC9HHOgiLAV95Pz_D8y_lWST789soOsTkxYjzJJJhMaqd4C8KT5RkVYHb73BPZZCPeWlhB7bt3Z6lPIEdWSe3Wd&typo=1>
> ...
> </VirtualHost>
> <VirtualHost 1.1.1.1:443 >
> ServerName s2.example1.com
> <https://linkprotect.cudasvc.com/url?a=http%3a%2f%2fs2.example1.com&c=E,1,8X1MRWLchBd0jtI-FkYh2nb2lyg0LtCgOeCkKgkA16Wdz7Q11brpocrr15c9F9_OqRnWEqwExVy6LEiVykh8JwIhtyIlb2Madiz9yfOano0,&typo=1>
> ...
> </VirtualHost>
>
> This had nothing to do with the example2.com
> <https://linkprotect.cudasvc.com/url?a=http%3a%2f%2fexample2.com&c=E,1,ul_Sx0-1ZWGylDIVnZp9Xcqxf0r3cNY7JsJnUxT2ir53quY-0jVC5gTotkqGkJbvAzWE3tNI01fkJt3aoWuCI0MkdIM9ZPWyrJuBGzFiVA,,&typo=1>
> 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
>
>
>

Charles,

No, you are completely incorrect. You should never define vhosts as
<host>:<port>.

On Fri, 20 May 2022 at 13:09, Yehuda Katz <yehuda@ymkatz.net> wrote:

> That is not correct. That causes httpd to try to look up the matching IP
> address using DNS. Use only IP addresses or wildcards.
>
> - Y
>
> On Fri, May 20, 2022 at 1:06 PM Bender, Charles
> <charles@beachcamera.com.invalid> wrote:
>
>> Your virtual host is defined wrong. Use the names not IP addresses
>>
>> <VirtualHost example2.com:443 <http://1.1.1.13:443/>>
>> Servername example2.com
>> <https://linkprotect.cudasvc.com/url?a=http%3a%2f%2fexample2.com&c=E,1,dcUCUjUb4LYF2QKtZR97YwwXQvScdoETUyYneNIzxrVPCY07TRsv343JxU2TC5RtNYHxyF97S7yA3AepHgKTSlaPMWipWynnIbri9ZFZlIJCfOISNr175hJJNl8,&typo=1>
>> SSLEngine on
>> SSLCertificateFile /etc/http/certs/example2.crt
>> ...
>> </VirtualHost>
>> ------------------------------
>> *From:* frank picabia <fpicabia@gmail.com>
>> *Sent:* Friday, May 20, 2022 12:55 PM
>> *To:* users@httpd.apache.org <users@httpd.apache.org>
>> *Subject:* Re: [users@httpd] 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.com
>> <https://linkprotect.cudasvc.com/url?a=http%3a%2f%2fexample2.com&c=E,1,6W_vM4KZBARFuk6DDpPWoNW12LzjGIFV8FRTADGmecW5MGLigif3cCg9i_upqN6olj_Qr7kWBGqNJu2EXeP8QeUVkPmMk1TYwQ1pcBTxx32XgAlhuKEDKcpL&typo=1>
>> 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
>> <https://linkprotect.cudasvc.com/url?a=http%3a%2f%2fexample2.com&c=E,1,dcUCUjUb4LYF2QKtZR97YwwXQvScdoETUyYneNIzxrVPCY07TRsv343JxU2TC5RtNYHxyF97S7yA3AepHgKTSlaPMWipWynnIbri9ZFZlIJCfOISNr175hJJNl8,&typo=1>
>> SSLEngine on
>> SSLCertificateFile /etc/http/certs/example2.crt
>> ...
>> </VirtualHost>
>>
>> Every other vhost had a different servername, and they used the
>> cert for example1.com
>> <https://linkprotect.cudasvc.com/url?a=http%3a%2f%2fexample1.com&c=E,1,hWtAIAcngoqDN67tYYh-JBMRsDu0loXxcOnLFfiTh0kkC73FcXss_uAVRLOtoJLqXOCEN9jyzjXqVBcPyZW7t70FdDG9MVq19wuX_0SAFBLk7qkKRSlWDw,,&typo=1>
>> . They also had *:443
>> Only for example1.com
>> <https://linkprotect.cudasvc.com/url?a=http%3a%2f%2fexample1.com&c=E,1,0PHWaifn8IWmWbVOrikm7fz8IiJtabA_5-R1x0XKMlFFo3oBud94pi8En8RPBR3KLTR3QenHwFjS7HQgJNY1qG-nQe_UmNGE2X8vrXjghYl5KQ,,&typo=1>
>> do we have multiple aliases on the same IP.
>>
>> When visiting the example2.com
>> <https://linkprotect.cudasvc.com/url?a=http%3a%2f%2fexample2.com&c=E,1,QZFYnaarDKwbI4UIuis6AUVr6M_IY5nT64iVqhrFOfC1SFad9Dq-LeBk2Prq7-LyNrzbvo_FfMN1PezvDeICv0bWAkLH1rCsEqr9d-W4KMjU_tMJ5hg,&typo=1>
>> site, the web site shows apache has served a certificate for example1.com
>> <https://linkprotect.cudasvc.com/url?a=http%3a%2f%2fexample1.com&c=E,1,T_cQOb_HmAeeARzztUhUpYrFdC-M2k8aEzqZWhQryiy784g3BQNmtSe51GNCXcXQIbgEUbfPVEl5zdNv7G3-cgN_D5iSOe-t-0dOr8s9Ogm_ZwvXlaaXXQJDP78,&typo=1>
>>
>> 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
>> <https://linkprotect.cudasvc.com/url?a=http%3a%2f%2fexample1.com&c=E,1,Mz11UTCKtiWcGt6Y8IkJjBHQLSOD5JkAKituHpPrZu5-qa6kZmzAj0yKhiovnyiw6bX333zd9IKH73D6x3DQsfQOvC7ztgVXyiO7EUHWBXHjoys4q30,&typo=1>
>> Since before this point all vhosts were on example1.com
>> <https://linkprotect.cudasvc.com/url?a=http%3a%2f%2fexample1.com&c=E,1,8wXSzKIRaGVigrHUZoxWD8812IQ1_5RSU52jRZYKX7BQPnCQrAcHUwhw_BOV_E5zA1jMdtUHbqCd9jwXZ8HLFcDM7HcYG31scrYTMuAWMw,,&typo=1>
>> 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@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 <fpicabia@gmail.com> wrote:
>>
>>
>> Sorry, that should not have said "top level domains". I meant domains.
>> Like example.com, example.net
>> <https://linkprotect.cudasvc.com/url?a=http%3a%2f%2fexample.net&c=E,1,Lf7WCUECY7EjPemnM7RAgRqLA_RtcGdzOib3lOf7AW0vkHA8LZPhA_Cyx4vxm2UkTXZdaO6ax9tCWnAP4NJ8QbZC7d6pFPimkBkaFwrXGA,,&typo=1>
>> .
>>
>>
>> On Fri, May 20, 2022 at 7:05 AM frank picabia <fpicabia@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
>> <https://linkprotect.cudasvc.com/url?a=http%3a%2f%2fs1.example1.com&c=E,1,wsz87BMMp2oMlSddl_CqoJGdX4XfnA4SBhZHzfihJZJUFFJolpRBPQ1tm6G08DwlDNVBTcY1p7ZsxfEAtdfJ59gsZRoDVQeNBtWtKHbD&typo=1>
>> ...
>> </VirtualHost>
>>
>> <VirtualHost *:443 >
>> ServerName s2.example1.com
>> <https://linkprotect.cudasvc.com/url?a=http%3a%2f%2fs2.example1.com&c=E,1,7pvCP6udZ3aZHoj-a0jz-AgOyf0BqRRLwQMOAtBCbrpGJX7So009M8zSgwIQRUxx3EB6zyyZKInj66oF7Td7UcJqi0h7gBdt_0zI0uL4PwM06AV6AQ,,&typo=1>
>> ...
>> </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
>> <https://linkprotect.cudasvc.com/url?a=http%3a%2f%2fs1.example1.com&c=E,1,NvBi26pDh9IxdmyKgHLNK4p32Qv1cFQtyVXbIlC9HHOgiLAV95Pz_D8y_lWST789soOsTkxYjzJJJhMaqd4C8KT5RkVYHb73BPZZCPeWlhB7bt3Z6lPIEdWSe3Wd&typo=1>
>> ...
>> </VirtualHost>
>> <VirtualHost 1.1.1.1:443 >
>> ServerName s2.example1.com
>> <https://linkprotect.cudasvc.com/url?a=http%3a%2f%2fs2.example1.com&c=E,1,8X1MRWLchBd0jtI-FkYh2nb2lyg0LtCgOeCkKgkA16Wdz7Q11brpocrr15c9F9_OqRnWEqwExVy6LEiVykh8JwIhtyIlb2Madiz9yfOano0,&typo=1>
>> ...
>> </VirtualHost>
>>
>> This had nothing to do with the example2.com
>> <https://linkprotect.cudasvc.com/url?a=http%3a%2f%2fexample2.com&c=E,1,ul_Sx0-1ZWGylDIVnZp9Xcqxf0r3cNY7JsJnUxT2ir53quY-0jVC5gTotkqGkJbvAzWE3tNI01fkJt3aoWuCI0MkdIM9ZPWyrJuBGzFiVA,,&typo=1>
>> 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
>>
>>
>>

On Fri, May 20, 2022 at 12:09 Yehuda Katz <yehuda@ymkatz.net> wrote:

> That is not correct. That causes httpd to try to look up the matching IP
> address using DNS. Use only IP addresses or wildcards.
>

You should try the Apache Macro to see if it might help.

I have used for years for over a dozen virtual hosts defined by SNI. See
the Apache section on my "config-scripts" module at github
(tbrowder/config-scripts).

Essentially, you use the macro (with args) to define a template for a host.
Then use it with one-line definitions for each host. Finally, undef the
macro.

-Tom