Több domain külön certtel, azonos wwwroot

 ( neutrino | 2014. május 28., szerda - 15:12 )

Üdv,

Van egy weboldalam, ami a /www/oldalam alatt található. Ehhez eddig volt az oldalam.hu domain és egy startssl cert. Most regisztrálásra került az oldalam.com és ehhez is egy startssl cert. Szeretném azt elérni, hogy az apacheom mindkét domaint kiszolgálja ugyanazzal a docroot-al, viszont különböző certttel.

Próbáltam új configba beirni az új domaint és certet, viszont ebben az esetben nem indul el az apache és a logokba sem ir semmit...

Mi lehet a gond?

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Lehet a certtel van baja, nézz körbe jobban.

Két vhost mutathat egy docrootra külön domainnel, certtel.

Egy ilyet találtam mégis:

[Wed May 28 15:08:33 2014] [error] SSL Library Error: 185073780 error:0B080074:x509 certificate routines:X509_check_private_key:key values mismatch

-------------------------
Dropbox refer: https://db.tt/V3RtXWLl
neut @ présház

Azt hiszem a NameVirtualHost direktíva lesz a barátod. Olvass utána kicsit. A Certet bárhonnan fel lehet olvastatni (ha olvasható a könyvtár a felhasználó által).

Az oldal.hu es oldal.com ugyanazzal a certtel nem fog menni anelkul, hogy a bongeszo ne aggodalmaskodna, hogy nem passzol a cert a domain-hoz.

Van külön cert mindkettőhöz.
-------------------------
Dropbox refer: https://db.tt/V3RtXWLl
neut @ présház

ha 2 certed van akkor 2 ip is kell.

ui: ahogy nézem a guglit, már nem feltétlen kell, SNI miatt. apache 2.2.12-es felett. Hogy fejlődik a technika :D

Fedora 20, Thinkpad x220

Kliens (böngésző) oldalon is támogatni kell. Persze egyre jobb a helyzet, de még mindig nagyon sok esetleges usert kitiltasz ezzel. Ha olyan környezetben kell, ahol ez nem gond, illetve kontrollálható, akkor érdemes csak bevállalni.

Mármint "kitiltja" a régebbi (<3.0) Androidok default browserét és az IE-t XP alatt (esetleg pár egzotikus op.rendszer/browser párost).
Előbbiek használhatnak bármi mást, utóbbiakat meg nem igazán lehet sajnálni :)

+1

Az SSL kapcsolat akkor épül fel mikor a kliens a szerverhez csatlakozik. Ekkor még nem mondja meg a szervernek mit akar. Mikor kiépül az SSL kapcsolat akkor elkéri a kliens a certet, majd ha a cert arra a domain névre van kiállítva amit a kliens el akar kérni akkor elküldi a szervernek a HOST kérést.

Na most, ha a cert nem ahhoz a domainhez tartozik amit meg akarunk nyitni akkor a kliens rögvest hisztizik, hogy a cert amit kapott nem hiteles.

Tehát a két különböző domain HTTPS kapcsolatához, két IP cím szükséges.

Az Apache minden további nélkül képes több IP címen kiszolgálni (Listen direktíva pl.: http://httpd.apache.org/docs/2.4/bind.html )

Én azt javaslom, hozz létre két vhost configot, az egyiket az oldalam.hu -hoz, a másikat az oldalam.com -hoz. A DocumentRoot direktívában pedig mind a két vhost -ban ugyan azt a path -t add meg

Ha több segítség kell biztos össze tudjuk dobni a vhost configot

----
올드보이
http://molnaristvan.eu/

Tehát a két különböző domain HTTPS kapcsolatához, két IP cím szükséges.

Mint ahogy fentebb is irtak ez nem egeszen igy van mar 2.2.12-es apache felett (2.2.12, OpenSSL v0.9.8j), lasd SNI.
Windows XP nem tamogatott, ha a nagy atlagot nezzuk felhasznalas szempontjabol.

  1. Mozilla Firefox 2.0 or later
  2. Opera 8.0 or later (with TLS 1.1 enabled)
  3. Internet Explorer 7.0 or later (on Vista, not XP)
  4. Google Chrome
  5. Safari 3.2.1 on Mac OS X 10.5.6

A kerdezonek, ha nincs ket IP cime, akkor ez marad:


<NameVirtualHost *:443>

<VirtualHost *:443>
DocumentRoot /var/www/site.com
ServerName www.site.com
SSLEngine on
SSLCertificateFile /path/to/www.site.com.crt
SSLCertificateKeyFile /path/to/www.site.com.key
SSLCertificateChainFile /path/to/DigiCertCA.crt
</VirtualHost>

<VirtualHost *:443>
DocumentRoot /var/www/site.hu
ServerName www.site.hu
SSLEngine on
SSLCertificateFile /path/to/www.site.hu.crt
SSLCertificateKeyFile /path/to/www.site.hu.key
SSLCertificateChainFile /path/to/DigiCertCA.crt
</VirtualHost>

ha van, akkor
namevirtualhost ip1:port
namevirtualhost ip2:port
..
Virtualhost ip1:443
...
Virtualhost ip2:443
...

Több domain névhez az egyetlen UCC-s CERT a barátod. Kettő darab CERT ugyanahhoz az IP:port -hoz nem nyerő.

Miért ne menne? Most is be van állitva egy önaláirt cert a géphez defaultnak és egy weboldalhoz külön.
-------------------------
Dropbox refer: https://db.tt/V3RtXWLl
neut @ présház

Gondold végig. Kliens jön a 443-as tcp-portra, ssl-t össze kell hozni. Melyik certet fogja használni a webszerver? Az SNI lehetőségétől most eltekintve.

A kliens jön a 443-as portra, találkozik az apaccsal, majd megmondja melyik domaint keresi és az apacs a megfelelő direktíva alapján elkezd vele kommunikálni.

Igen, ez az SNI, aminek még kérdéses a támogatottsága.

Anélkül nem az zajlik, amit te mondasz. Hanem először lezajlik a TLS handshake, ahol először a szerver mondja meg, hogy neki mi a hostneve a tanúsítványban. És csak utána jön az a rész, ami plain HTTP-nél szokásos, hogy a kliens megmondja, hogy mi az a host, amit keres, a host headerben. És ennek passzolnia kell a szerver által a tanúsytványban mutatott hostnévhez, különben jön a böngészős figyelmeztetés.

Minden támogatja észrevétlenül amit érdemes használni. Ami meg nem azt nem kell használni.

+1

--
Fontos! Ha berágok, nem feltétlen személyed ellen szól...
openSUSE 13.1 x86_64

Ha ezt el tudod magyarázni az összes, még mindig IE6-ot és társait használó túlvégi usernek, akinek a szoftverpalettájára nincs ráhatásod, akkor nagyon +1.
Ellenkező esetben sajnos nem annyira nyerő.

Nemrégiben nézegettem netbankok forgalmát, és teljesen minimális mennyiségű IE6-tól érkező kérést találtam (100 millió request-ből 100 alatti darabszámú). Az IE6-tal már tényleg nem érdemes foglalkozni. Az IE7 sokkal problémásabb :-(

Azok a userek gondolkodás nélkül elfogadnak bármilyen certet is :)

Alapertelmezetten Layer6-ban megtortenik az ssl kapcsolat es csak Layer7-ben van szo arrol, hogy apache lekezelje a kliens altal kuldott domain nevet, hogy hozza tartozo weboldalt es beallitasokat adja vissza. Vagyis a problema az 1 ip-n tobb cert-el (ugyanazon porton), hogy mielott apache le tudna kezelni melyik ssl certet mutassa mar lezajlott az ssl kapcsolat ip alapjan.
Az SNI kiegeszites annyi pluszt ad a tls-hez, hogy mar tls/ssl kapcsolat kiepiteskor kliens elkuldi a domain nevet es igy szerver oldalon van mi alapjan visszaadni a megfelelo certet. Ehhez kell a tobbek altal is emlitett kliens es szerver oldali tamogatas, ha viszont ez nem opcio akkor csak eltero ip+port -on lehet eltero cert-et megadni.

Nekem még az is böki a csőrömet, hogy ha ezt szeretné az ipse, akkor ki kell kapcsolni az összes olyan cipher -t ami nem tudja ezt a csatlakozási módot, ergo marad a TLS1.1, vagy újabb.

Továbbá a doksikból nekem nem egészen tiszta, hogy honnan tudja a böngésző, hogy ezt a cipher -t kell használnia. Tehát a kapcsolódás és a válaszidő ettől növekszik. Illetőleg, a proxy -k támogatottága szintén nem annyira tűnik egyértelműnek. De, hogy fokozzam, az alkalmazás tűzfalak viselkedése ilyen esetben még inkább homályos.

----
올드보이
http://molnaristvan.eu/

ha jolemlexem, ehhez a mod_ssl modul helyett mod_gnutls kell.

nem