Van egy létező webhelyünk, amelynek HTTP-je van a 80-as porton és HTTPS-je a 443-as porton. Ehhez most hozzáadok egy második webhelyet, és amit megértek, nem tudok két webhelyet üzemeltetni ugyanazon az SSL porton.
Tehát a kérdésem az: melyik portszámtartományt használhatom SSL-portként a második helyen?
Megjegyzések
- Tévedhetek, de úgy gondolom, hogy egy érvényes SSL-tanúsításnak a 443-as porton kell lennie, és úgy gondolom, hogy ezért a megosztott tárhely dedikált IP-cím SSL vásárlásakor. De … ez nem az én szakterületem, remélhetőleg más geeky személyek is megerősíthetik.
Válasz
Valójában több SSL-webhelyet is hostolhat a 443-as porton. Az apache konfigurációs fájlban található következő kód megteszi a trükköt.
Ellenkező esetben használhatja a kívánt portokat. A hátrány a felhasználóknak meg kell adniuk a portszámot az URL-ben (pl. https://yourdomain.com:445/ )
## SSL (HTTPS) PORT 443 Listen 443 NameVirtualHost *:443 LoadModule ssl_module modules/mod_ssl.so SSLPassPhraseDialog builtin SSLSessionCache shmcb:/var/cache/mod_ssl/scache(512000) SSLSessionCacheTimeout 300 SSLMutex default SSLRandomSeed startup file:/dev/urandom 256 SSLRandomSeed connect builtin SSLCryptoDevice builtin <VirtualHost *:443> ServerName host1.com SSLEngine on SSLOptions +StrictRequire SSLProtocol -all +TLSv1 +SSLv3 SSLCipherSuite HIGH:MEDIUM:!aNULL:+SHA1:+MD5:+HIGH:+MEDIUM SSLCertificateFile /etc/httpd/ssl/host1.crt SSLCertificateKeyFile /etc/httpd/ssl/host1.key SSLVerifyClient none SSLProxyEngine off SetEnvIf User-Agent ".*MSIE.*" nokeepalive ssl-unclean-shutdown downgrade-1.0 force-response-1.0 CustomLog logs/ssl_request_log "%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b" DocumentRoot /var/www/host1/ <Directory "/var/www/host1/"> Options Indexes FollowSymLinks AllowOverride All Order Allow,deny Allow from all </Directory> </VirtualHost> <VirtualHost *:443> ServerName host2.com SSLEngine on SSLOptions +StrictRequire SSLProtocol -all +TLSv1 +SSLv3 SSLCipherSuite HIGH:MEDIUM:!aNULL:+SHA1:+MD5:+HIGH:+MEDIUM SSLCertificateFile /etc/httpd/ssl/host2.crt SSLCertificateKeyFile /etc/httpd/ssl/host2.key SSLVerifyClient none SSLProxyEngine off SetEnvIf User-Agent ".*MSIE.*" nokeepalive ssl-unclean-shutdown downgrade-1.0 force-response-1.0 CustomLog logs/ssl_request_log "%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b" DocumentRoot /var/www/host2/ <Directory "/var/www/host2/"> Options Indexes FollowSymLinks AllowOverride All Order Allow,deny Allow from all </Directory> </VirtualHost> megjegyzések
- Köszönöm, de ez egy IIS-webhely. Van valami nyom, hogyan folytatnám ugyanezt?
Válasz
Amikor azt mondod, hogy “második webhely” – második domain névre gondolsz? Akárcsak itt, Ön https://www.mycompany.com egy fürtön tárolja, és https://www.yourcompany.com ugyanazon a fürtön? Azt hiszem, amit keres, az a” virtuális tárhely “: http://support.microsoft.com/kb/q190008
Még mindig meg kell vásárolnia egy második SSL-tanúsítványt, de mindkettőt ugyanabban a rendszerben tudja majd hosztolni IP-cím a szokásos portok alatt (ami legalábbis növeli a felhasználók bizalmát a webhelyében).
Megjegyzések
- Hosztot használtam fejlécek nevei, és a két webhely az első.vállalat.com és a másodikVállalat.com formában van. A probléma az, hogy az ” Speciális webhelyazonosításon ” három oszlop áll rendelkezésre a HTTP számára (IP-cím, TCP-port és a Host fejléc értéke). de csak kettő a HTTPS-hez (IP-cím és SSL-port), tehát úgy tűnik, hogy ‘ nem tűnik lehetségesnek abból, amit látok.
Válasz
Hagyományosan SSL-összerendeléshez egy IP-címre van szükség. Az összerendelések beállításakor nem lehet gazdagép fejlécet hozzáadni. Ennek az az oka, hogy a gazdagép fejléc része a böngészők által küldött HTTP fejléceknek, és ezeket a fejléceket az SSL forgalom részeként titkosítják. olvassa el a hosztnév fejlécét, a kiszolgálónak először meg kell oldania a forgalmat, de ehhez tudnia kell, hogy melyik tanúsítványt használja. Ehhez szüksége lenne a gazdagép fejlécére, hogy ördögi körbe kerülhessen.
Megoldás lehet, ha a szerver kipróbálja az összes telepített tanúsítványt, és megpróbálja visszafejteni a kérést. Bár ez néhány tanúsítvánnyal telepítve működhet, a tizedes vagy több száz SSL-webhelyet tartalmazó szervereknél ez nem sikerül. Ez drámai módon lelassítaná a szervert, mivel a szervernek ezt meg kell tennie minden bejövő kérésnél.
Erre a megoldás az SSL protokoll kiterjesztése, az úgynevezett Kiszolgálónév jelzés (SNI) . Ez hozzáadja a hosztnevet az SSL protokollhoz, amely lehetővé teszi a kiszolgáló számára, hogy nézze meg a gazdagép fejlécét, mielőtt visszafejtenie kellene az SSL-forgalmat. Ezt a kiterjesztést az IIS 8-nál korábbi verziói nem támogatják (Windows 2012). Az ügyfél oldalán az SNI-t az OS X 10.5.6 és a Windows Vista vagy újabb verziók támogatják. . Az SNI-t a SChannel nem támogatja Windows XP rendszeren, ezért az Internet Explorer egyetlen verziója (még a 8.0 sem) támogatja a Windows XP rendszeren.
Válasz
Az IIS-ben (mint más webszervereknél is) három kulcsazonosító létezik, amelyek azonosítják a webhelyet a beérkező kérésekhez:
- IP-cím
- TCP port
- Gazdagép fejléc
Ha több weboldalt futtat egyetlen webszerveren, akkor a három közül az egyiknek minden webhelynél különböznie kell. Sok környezetben a kiszolgálónak csak egyetlen IP-címet adnak meg, így elhagyja a módosítható TCP-portot és gazdagép-fejlécet. Lehetséges egy https webhely futtatása egy másik porton, csak meg kell adnia a portot az URL-ben, ami nem mindig kívánatos (ez valami olyasmit mutatna, mint https://www.foo.com:32000/index.html ). Gyakrabban az összes webhelyét a 80-as (http) vagy a 443-as (https) porton szeretné futtatni, hogy tiszta URL-eket kapjon. Ezután a gazdagép fejléce marad az egyetlen módosítandó elem.
Az IIS-ben ugyanazon IP / port kombinációban több olyan webhely is rendelkezhet, amelyek SSL-t és gazdagép-fejléceket használnak.A legfontosabb az, hogy helyettesítő tanúsítványt vagy SAN (Subject Alternative Names) tanúsítványt kell használnia, amely több gazdagépnevet is meghatároz magában a tanúsítványban. Nem állíthatja be a gazdagép fejléc-összerendelését az IIS-kezelő felhasználói felületén az SSL-hely gazdagép-fejlécéhez. Vagy meg kell tennie a parancssoron keresztül, vagy manuálisan kell szerkesztenie a applicationHost.config fájlt a kiszolgálón.
A Technet információi a parancssoron keresztüli beállításról itt találhatók.
Volt egy bejegyzés a Az IIS fórum ehhez hasonló kérdéssel, amely itt található .
A parancs futtatása vagy a konfigurációs fájl kézi szerkesztése után az applicationHost.config fájl hasonló lehet ehhez:
<site name="first.mycompany.com"> ... <bindings> <binding protocol="http" bindingInformation="192.168.10.100:80:first.mycompany.com" /> <binding protocol="https" bindingInformation="192.168.10.100:443:first.mycompany.com" /> </bindings> ... </site> <site name="second.mycompany.com"> ... <bindings> <binding protocol="http" bindingInformation="192.168.10.100:80:second.mycompany.com" /> <binding protocol="https" bindingInformation="192.168.10.100:443:second.mycompany.com" /> </bindings> ... </site> Ezután az IIS-kezelőben megjelenik a kötések. Remélem, hogy ez segít.
* EDIT * A fenti információk ezt feltételezték kérdés az IIS7-hez kapcsolódott. Ha az IIS6-ra vonatkozik, akkor más eljárást kell követni. Erről információkat talál itt .
Válasz
figyelembe véve az utolsó megjegyzését és a szakértői válaszok áttekintését, két megoldást tudok ajánlani.
A legjobb megoldások:
Helyettesítő ssl tanúsítványt vásárolhat, amely lehetővé teszi korlátlan alcsoportok biztonságát .domain.com, amely ugyanazon az IP-n van tárolva (az SSL tanúsítványhoz dedikált IP szükséges).
Alternatív megoldások:
Két különböző SSL tanúsítványt vásárolhat, mindegyiket egy-egy webhelyhez. nem fogadhatja őket ugyanazon az ip-n.