Re: [users@httpd] Re: Multi-domain with SSL - Virtualhost all need IPs?

2022-05-22 Thread Tom Browder
On Fri, May 20, 2022 at 12:09 Yehuda Katz  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


[users@httpd] Re: {Disarmed} Re: [users@httpd] Re: Multi-domain with SSL - Virtualhost all need IPs?

2022-05-21 Thread Paul Kudla (SCOM.CA Internet Services Inc.)



Ok to clarify (this is standard apache from day one moving from 
convential SSL certs towards SNI used today)



# Change this to Listen on specific IP addresses as shown below to
# prevent Apache from glomming onto all bound IP addresses.
#
#Listen 12.34.56.78:80
Listen 80
#Listen 443


the above will specify the listening address / port

by default this is ALL ip's on ALL interfaces (ie no Listen ip statement 
specified)


and is designated by * when setting up a host entry

*:80 means normal httpd port on ALL avaliable ip's either specified 
above or if NO Listen statement then ALL interfaces will Listen.


*:443 means normal ssl port on ALL avaliable ip's either specified above 
or if NO Listen statement then ALL interfaces will Listen.



1.1.1.1:443 (for example) means non standard ip listen address (this is 
typically NEVER used anymore)


so what ever you tell apache to listen on by default or otherwise "*" 
means exactly that ALL INTERFACES SPECIFIED.



when using sni you MUST specify a seperate VirtualHost (NOT VHOSTS)


ServerName underconstruction.scom.ca
ServerAlias underconstruction.scom.ca
DocumentRoot /www/underconstruction.scom.ca



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



sni will pickup on the servername and then comapre the associated ssl 
cert as specified by the file location.


also note proper certs today get registered as the domain ie in this 
case scom.ca with also allow www.scom.ca (ServerAlias above) but nothing 
else (unless you have a wildcard)



this is all there is to it

notes :

ip addresses used to be assigned before the sni days, meaning that ssl 
only ran on one ip address and one certificate per server instance


which is why you needed 16 ipaddress to host 16 different ssl certificates.

sni was invented because ipv4 addresses are running out (aka most 
upstream providers will not alot ip's for this useage anymore)


and most hosts run multiple domains names etc so sni is just simply more 
efficent.



Note when building

Prerequisites to use SNI

Use OpenSSL 0.9.8f or later

Build OpenSSL with the TLS Extensions option enabled (option 
enable-tlsext; OpenSSL 0.9.8k and later has this enabled by default).


Apache must have been built with that OpenSSL (./configure 
--with-ssl=/path/to/your/openssl). In that case, mod_ssl will 
automatically detect the availability of the TLS extensions and support SNI.


Apache must use that OpenSSL at run-time, which might require setting 
LD_LIBRARY_PATH or equivalent to point to that OpenSSL, maybe in 
bin/envvars. (You'll get unresolved symbol errors at Apache startup if 
Apache was built with SNI but isn't finding the right openssl libraries 
at run-time.)


Also i founs that the

Include apache2/conf/extra/httpd-ssl.conf

had to be modified not to use ssl certs by default (as they get 
specified in the Virtual Hosts statement.


Hope this is a better explanation and clarifies the confusion happening 
below ?




Happy Saturday !!!
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/20/2022 6:00 PM, Frank Gingras wrote:

Charles,

No, you are completely incorrect. You should never define vhosts as 
:.


On Fri, 20 May 2022 at 13:09, Yehuda Katz <mailto:yeh...@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
 wrote:

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

http://example2.com>*MailScanner has
detected a possible fraud attempt from "1.1.1.13:443" claiming
to be* :443 <http://1.1.1.13:443/>>
Servername*MailScanner has detected a possible fraud attempt
from "linkprotect.cudasvc.com" claiming to be* example2.com

<https://linkprotect.cudasvc.com/url?a=http%3a%2f%2fexample2.com=E,1,dcUCUjUb4LYF2QKtZR97YwwXQvScdoETUyYneNIzxrVPCY07TRsv343JxU2TC5RtNYHxyF97S7yA3AepHgKTSlaPMWipWynnIbri9ZFZlIJCfOISNr175hJJNl8,=1>
SSLEngine on
SSLCertificateFile /etc/http/certs/example2.crt
...


*From:* frank picabia mailto:fpica...@gmail.com>>
*Sent:* Friday, May 20, 2022 12:55 PM
*To:* users@httpd.apache.org <mailto:users@httpd.apache.org>
        mailto:users@httpd.apache.org>>
        *Subject:* Re: [users@httpd] Re: Multi-domain with SSL -
Virtua

Re: [users@httpd] Re: Multi-domain with SSL - Virtualhost all need IPs?

2022-05-20 Thread Frank Gingras
Charles,

No, you are completely incorrect. You should never define vhosts as
:.

On Fri, 20 May 2022 at 13:09, Yehuda Katz  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
>  wrote:
>
>> Your virtual host is defined wrong. Use the names not IP addresses
>>
>> http://1.1.1.13:443/>>
>> Servername example2.com
>> <https://linkprotect.cudasvc.com/url?a=http%3a%2f%2fexample2.com=E,1,dcUCUjUb4LYF2QKtZR97YwwXQvScdoETUyYneNIzxrVPCY07TRsv343JxU2TC5RtNYHxyF97S7yA3AepHgKTSlaPMWipWynnIbri9ZFZlIJCfOISNr175hJJNl8,=1>
>> SSLEngine on
>> SSLCertificateFile /etc/http/certs/example2.crt
>> ...
>> 
>> --
>> *From:* frank picabia 
>> *Sent:* Friday, May 20, 2022 12:55 PM
>> *To:* 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=E,1,6W_vM4KZBARFuk6DDpPWoNW12LzjGIFV8FRTADGmecW5MGLigif3cCg9i_upqN6olj_Qr7kWBGqNJu2EXeP8QeUVkPmMk1TYwQ1pcBTxx32XgAlhuKEDKcpL=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.
>>
>> 
>> Servername example2.com
>> <https://linkprotect.cudasvc.com/url?a=http%3a%2f%2fexample2.com=E,1,dcUCUjUb4LYF2QKtZR97YwwXQvScdoETUyYneNIzxrVPCY07TRsv343JxU2TC5RtNYHxyF97S7yA3AepHgKTSlaPMWipWynnIbri9ZFZlIJCfOISNr175hJJNl8,=1>
>> SSLEngine on
>> SSLCertificateFile /etc/http/certs/example2.crt
>> ...
>> 
>>
>> 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=E,1,hWtAIAcngoqDN67tYYh-JBMRsDu0loXxcOnLFfiTh0kkC73FcXss_uAVRLOtoJLqXOCEN9jyzjXqVBcPyZW7t70FdDG9MVq19wuX_0SAFBLk7qkKRSlWDw,,=1>
>> .  They also had *:443
>> Only for example1.com
>> <https://linkprotect.cudasvc.com/url?a=http%3a%2f%2fexample1.com=E,1,0PHWaifn8IWmWbVOrikm7fz8IiJtabA_5-R1x0XKMlFFo3oBud94pi8En8RPBR3KLTR3QenHwFjS7HQgJNY1qG-nQe_UmNGE2X8vrXjghYl5KQ,,=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=E,1,QZFYnaarDKwbI4UIuis6AUVr6M_IY5nT64iVqhrFOfC1SFad9Dq-LeBk2Prq7-LyNrzbvo_FfMN1PezvDeICv0bWAkLH1rCsEqr9d-W4KMjU_tMJ5hg,=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=E,1,T_cQOb_HmAeeARzztUhUpYrFdC-M2k8aEzqZWhQryiy784g3BQNmtSe51GNCXcXQIbgEUbfPVEl5zdNv7G3-cgN_D5iSOe-t-0dOr8s9Ogm_ZwvXlaaXXQJDP78,=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=E,1,Mz11UTCKtiWcGt6Y8IkJjBHQLSOD5JkAKituHpPrZu5-qa6kZmzAj0yKhiovnyiw6bX333zd9IKH73D6x3DQsfQOvC7ztgVXyiO7EUHWBXHjoys4q30,=1>
>> Since before this point all vhosts were on example1.com
>> <https://linkprotect.cudasvc.com/url?a=http%3a%2f%2fexample1.com=E,1,8wXSzKIRaGVigrHUZoxWD8812IQ1_5RSU52jRZYKX7BQPnCQrAcHUwhw_BOV_E5zA1jMdtUHbqCd9jwXZ8HLFcDM7HcYG31scrYTMuAWMw,,=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  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 mo

Re: [users@httpd] Re: Multi-domain with SSL - Virtualhost all need IPs?

2022-05-20 Thread Yehuda Katz
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
 wrote:

> Your virtual host is defined wrong. Use the names not IP addresses
>
> http://1.1.1.13:443/>>
> Servername example2.com
> <https://linkprotect.cudasvc.com/url?a=http%3a%2f%2fexample2.com=E,1,dcUCUjUb4LYF2QKtZR97YwwXQvScdoETUyYneNIzxrVPCY07TRsv343JxU2TC5RtNYHxyF97S7yA3AepHgKTSlaPMWipWynnIbri9ZFZlIJCfOISNr175hJJNl8,=1>
> SSLEngine on
> SSLCertificateFile /etc/http/certs/example2.crt
> ...
> 
> --
> *From:* frank picabia 
> *Sent:* Friday, May 20, 2022 12:55 PM
> *To:* 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=E,1,6W_vM4KZBARFuk6DDpPWoNW12LzjGIFV8FRTADGmecW5MGLigif3cCg9i_upqN6olj_Qr7kWBGqNJu2EXeP8QeUVkPmMk1TYwQ1pcBTxx32XgAlhuKEDKcpL=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.
>
> 
> Servername example2.com
> <https://linkprotect.cudasvc.com/url?a=http%3a%2f%2fexample2.com=E,1,dcUCUjUb4LYF2QKtZR97YwwXQvScdoETUyYneNIzxrVPCY07TRsv343JxU2TC5RtNYHxyF97S7yA3AepHgKTSlaPMWipWynnIbri9ZFZlIJCfOISNr175hJJNl8,=1>
> SSLEngine on
> SSLCertificateFile /etc/http/certs/example2.crt
> ...
> 
>
> 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=E,1,hWtAIAcngoqDN67tYYh-JBMRsDu0loXxcOnLFfiTh0kkC73FcXss_uAVRLOtoJLqXOCEN9jyzjXqVBcPyZW7t70FdDG9MVq19wuX_0SAFBLk7qkKRSlWDw,,=1>
> .  They also had *:443
> Only for example1.com
> <https://linkprotect.cudasvc.com/url?a=http%3a%2f%2fexample1.com=E,1,0PHWaifn8IWmWbVOrikm7fz8IiJtabA_5-R1x0XKMlFFo3oBud94pi8En8RPBR3KLTR3QenHwFjS7HQgJNY1qG-nQe_UmNGE2X8vrXjghYl5KQ,,=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=E,1,QZFYnaarDKwbI4UIuis6AUVr6M_IY5nT64iVqhrFOfC1SFad9Dq-LeBk2Prq7-LyNrzbvo_FfMN1PezvDeICv0bWAkLH1rCsEqr9d-W4KMjU_tMJ5hg,=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=E,1,T_cQOb_HmAeeARzztUhUpYrFdC-M2k8aEzqZWhQryiy784g3BQNmtSe51GNCXcXQIbgEUbfPVEl5zdNv7G3-cgN_D5iSOe-t-0dOr8s9Ogm_ZwvXlaaXXQJDP78,=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=E,1,Mz11UTCKtiWcGt6Y8IkJjBHQLSOD5JkAKituHpPrZu5-qa6kZmzAj0yKhiovnyiw6bX333zd9IKH73D6x3DQsfQOvC7ztgVXyiO7EUHWBXHjoys4q30,=1>
> Since before this point all vhosts were on example1.com
> <https://linkprotect.cudasvc.com/url?a=http%3a%2f%2fexample1.com=E,1,8wXSzKIRaGVigrHUZoxWD8812IQ1_5RSU52jRZYKX7BQPnCQrAcHUwhw_BOV_E5zA1jMdtUHbqCd9jwXZ8HLFcDM7HcYG31scrYTMuAWMw,,=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  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  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=E,1,Lf7WCUECY7EjPemnM7RAgRqLA_RtcGdzOib3lOf7AW0vkHA8LZPhA_Cyx4vxm

Re: [users@httpd] Re: Multi-domain with SSL - Virtualhost all need IPs?

2022-05-20 Thread Bender, Charles
Your virtual host is defined wrong. Use the names not IP addresses

http://1.1.1.13:443/>>
Servername 
example2.com<https://linkprotect.cudasvc.com/url?a=http%3a%2f%2fexample2.com=E,1,dcUCUjUb4LYF2QKtZR97YwwXQvScdoETUyYneNIzxrVPCY07TRsv343JxU2TC5RtNYHxyF97S7yA3AepHgKTSlaPMWipWynnIbri9ZFZlIJCfOISNr175hJJNl8,=1>
SSLEngine on
SSLCertificateFile /etc/http/certs/example2.crt
...


From: frank picabia 
Sent: Friday, May 20, 2022 12:55 PM
To: 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=E,1,6W_vM4KZBARFuk6DDpPWoNW12LzjGIFV8FRTADGmecW5MGLigif3cCg9i_upqN6olj_Qr7kWBGqNJu2EXeP8QeUVkPmMk1TYwQ1pcBTxx32XgAlhuKEDKcpL=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.

http://1.1.1.13:443>>
Servername 
example2.com<https://linkprotect.cudasvc.com/url?a=http%3a%2f%2fexample2.com=E,1,dcUCUjUb4LYF2QKtZR97YwwXQvScdoETUyYneNIzxrVPCY07TRsv343JxU2TC5RtNYHxyF97S7yA3AepHgKTSlaPMWipWynnIbri9ZFZlIJCfOISNr175hJJNl8,=1>
SSLEngine on
SSLCertificateFile /etc/http/certs/example2.crt
...


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=E,1,hWtAIAcngoqDN67tYYh-JBMRsDu0loXxcOnLFfiTh0kkC73FcXss_uAVRLOtoJLqXOCEN9jyzjXqVBcPyZW7t70FdDG9MVq19wuX_0SAFBLk7qkKRSlWDw,,=1>
 .  They also had *:443
Only for 
example1.com<https://linkprotect.cudasvc.com/url?a=http%3a%2f%2fexample1.com=E,1,0PHWaifn8IWmWbVOrikm7fz8IiJtabA_5-R1x0XKMlFFo3oBud94pi8En8RPBR3KLTR3QenHwFjS7HQgJNY1qG-nQe_UmNGE2X8vrXjghYl5KQ,,=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=E,1,QZFYnaarDKwbI4UIuis6AUVr6M_IY5nT64iVqhrFOfC1SFad9Dq-LeBk2Prq7-LyNrzbvo_FfMN1PezvDeICv0bWAkLH1rCsEqr9d-W4KMjU_tMJ5hg,=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=E,1,T_cQOb_HmAeeARzztUhUpYrFdC-M2k8aEzqZWhQryiy784g3BQNmtSe51GNCXcXQIbgEUbfPVEl5zdNv7G3-cgN_D5iSOe-t-0dOr8s9Ogm_ZwvXlaaXXQJDP78,=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=E,1,Mz11UTCKtiWcGt6Y8IkJjBHQLSOD5JkAKituHpPrZu5-qa6kZmzAj0yKhiovnyiw6bX333zd9IKH73D6x3DQsfQOvC7ztgVXyiO7EUHWBXHjoys4q30,=1>
Since before this point all vhosts were on 
example1.com<https://linkprotect.cudasvc.com/url?a=http%3a%2f%2fexample1.com=E,1,8wXSzKIRaGVigrHUZoxWD8812IQ1_5RSU52jRZYKX7BQPnCQrAcHUwhw_BOV_E5zA1jMdtUHbqCd9jwXZ8HLFcDM7HcYG31scrYTMuAWMw,,=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 
mailto: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 
mailto:fpica...@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=E,1,Lf7WCUECY7EjPemnM7RAgRqLA_RtcGdzOib3lOf7AW0vkHA8LZPhA_Cyx4vxm2UkTXZdaO6ax9tCWnAP4NJ8QbZC7d6pFPimkBkaFwrXGA,,=1>.


On Fri, May 20, 2022 at 7:05 AM frank picabia 
mailto: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.

Re: [users@httpd] Re: Multi-domain with SSL - Virtualhost all need IPs?

2022-05-20 Thread Yehuda Katz
>
> 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 , 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
>  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  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.
>
> 
> Servername example2.com
> SSLEngine on
> SSLCertificateFile /etc/http/certs/example2.crt
> ...
> 
>
> 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  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  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 
>>> 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...

 
ServerName s1.example1.com
 ...
 

 
ServerName s2.example1.com
 ...
 

 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 *

 
ServerName s1.example1.com
 ...
 
 
ServerName s2.example1.com
 ...
 

 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





Re: [users@httpd] Re: Multi-domain with SSL - Virtualhost all need IPs?

2022-05-20 Thread frank picabia
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.


Servername example2.com
SSLEngine on
SSLCertificateFile /etc/http/certs/example2.crt
...


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  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  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  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...
>>>
>>> 
>>>ServerName s1.example1.com
>>> ...
>>> 
>>>
>>> 
>>>ServerName s2.example1.com
>>> ...
>>> 
>>>
>>> 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 *
>>>
>>> 
>>>ServerName s1.example1.com
>>> ...
>>> 
>>> 
>>>ServerName s2.example1.com
>>> ...
>>> 
>>>
>>> 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
>>>
>>>
>>>


Re: [users@httpd] Re: Multi-domain with SSL - Virtualhost all need IPs?

2022-05-20 Thread Frank Gingras
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  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  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...
>>
>> 
>>ServerName s1.example1.com
>> ...
>> 
>>
>> 
>>ServerName s2.example1.com
>> ...
>> 
>>
>> 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 *
>>
>> 
>>ServerName s1.example1.com
>> ...
>> 
>> 
>>ServerName s2.example1.com
>> ...
>> 
>>
>> 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
>>
>>
>>


[users@httpd] Re: Multi-domain with SSL - Virtualhost all need IPs?

2022-05-20 Thread frank picabia
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  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...
>
> 
>ServerName s1.example1.com
> ...
> 
>
> 
>ServerName s2.example1.com
> ...
> 
>
> 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 *
>
> 
>ServerName s1.example1.com
> ...
> 
> 
>ServerName s2.example1.com
> ...
> 
>
> 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
>
>
>


[users@httpd] Re: Multi-domain with SSL - Virtualhost all need IPs?

2022-05-20 Thread frank picabia
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...


   ServerName s1.example1.com
...



   ServerName s2.example1.com
...


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 *


   ServerName s1.example1.com
...


   ServerName s2.example1.com
...


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