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
<char...@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 <fpica...@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 <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
> <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 <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
> <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
>
>
>

Reply via email to