Vi har en befintlig webbplats med HTTP på port 80 och HTTPS på port 443. Jag lägger till en andra webbplats till den nu, och enligt vad jag förstår kan jag inte vara värd för två webbplatser på samma SSL-port.
Så min fråga är: vilket portnummerintervall är lämpligt för mig att använda som min SSL-port på den andra webbplatsen?
Kommentarer
- Jag kan ha fel men jag tror att en giltig SSL-certifiering kräver att vara på port 443, och tror att det är därför delad hosting ger dig en dedikerad IP-adress när du köper en SSL. Men …. det här är inte mitt fält förhoppningsvis kan någon annan nördig person bekräfta.
Svar
Egentligen KAN du vara värd för flera SSL-webbplatser på port 443. Följande kod i din apache-konfigurationsfil gör tricket.
Annars kan du använda vilka portar du vill. Nackdelen är vara att användare måste inkludera portnumret i webbadressen (t.ex. 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> Kommentarer
- Tack, men det här är en IIS-webbplats. Någon aning om hur jag skulle göra samma sak?
Svar
När du säger ”andra webbplatsen” – menar du ett andra domännamn? Som i är du för närvarande värd för https://www.mycompany.com i ett kluster och du vill vara värd för https://www.yourcompany.com på samma kluster? Jag tror att det du letar efter är” virtuell värd ”: http://support.microsoft.com/kb/q190008
Du måste fortfarande köpa ett andra SSL-certifikat, men du kommer att kunna vara värd för båda samtidigt IP-adress under standardportarna (vilket åtminstone kommer att öka användarnas förtroende för din webbplats).
Kommentarer
- Jag använde värd rubriknamn, och de två platserna har formen first.mycompany.com och second.mycompany.com. Problemet är att på ” Avancerad webbplatsidentifiering ” finns tre kolumner för HTTP (IP-adress, TCP-port och värdhuvudvärde) men bara två för HTTPS (IP-adress och SSL-port), så det verkar inte ’ t från vad jag kan se.
Svar
Traditionellt behöver du en IP-adress per SSL-bindning. Det är inte möjligt att lägga till ett värdhuvud när du ställer in bindningarna. Anledningen till detta är att värdhuvudet är en del av de HTTP-rubriker som skickas av webbläsarna och dessa rubriker är krypterade som en del av SSL-trafiken. För att läs värdnamnshuvudet, servern måste först dekryptera trafiken men för att göra det måste den veta vilket certifikat som ska användas. För det skulle det behöva värdhuvudet för så att du hamnar i en ond cirkel.
En lösning skulle vara att servern skulle försöka alla installerade certifikat och försöka dekryptera begäran. Även om detta kan fungera med några installerade certifikat, kommer det inte att fungera för servrar med tiondelar eller hundratals SSL-webbplatser. Det skulle dramatiskt sakta ner servern eftersom servern måste göra detta för varje inkommande begäran.
Lösningen för detta är en tillägg till SSL-protokollet som heter Server Name Indication (SNI) . Detta lägger till värdnamnet i SSL-protokollet som gör att servern se värdhuvudet innan det måste dekryptera SSL-trafiken. Detta tillägg stöds inte av någon version av IIS tidigare än IIS 8 (Windows 2012). På klientsidan stöds SNI av OS X 10.5.6 och Windows Vista eller högre SNI stöds inte av SChannel på Windows XP och stöds därför inte av någon version av Internet Explorer (till och med 8.0) på Windows XP.
Svar
I IIS (som med andra webbservrar) finns det tre nyckelidentifierare som identifierar din webbplats för inkommande förfrågningar:
- IP-adress
- TCP port
- Värdhuvud
Om du kör flera webbplatser på en webbserver måste minst en av dessa vara olika för varje webbplats. I många miljöer får en server bara en enda IP-adress, så att TCP-porten och värdhuvudet lämnas som kan ändras. Det är möjligt att köra en https-webbplats på en annan port, du behöver bara ange porten i webbadressen som inte alltid är önskvärd (detta skulle se ut som https://www.foo.com:32000/index.html ). Oftare vill du inte köra alla dina webbplatser på port 80 (http) eller 443 (https) så att du får rena webbadresser. Då lämnas värdhuvudet som det objekt som du vill ändra.
I IIS kan du ha flera webbplatser på samma IP / portkombination som använder SSL och värdhuvud.Nyckeln är att du måste använda antingen ett jokerteckencertifikat eller ett SAN-certifikat (Subject Alternative Names) som anger flera värdnamn i själva certifikatet. Du kan inte ställa in värdhuvudbindningar för värdhuvuden på en SSL-webbplats i IIS Manager UI. Du måste antingen göra det via kommandoraden eller manuellt redigera applicationHost.config-filen på servern.
Information från Technet om inställning av detta via kommandoraden finns här .
Det fanns ett inlägg på IIS-forum med en liknande fråga som också som finns här .
Efter att ha kört kommandot eller manuellt redigerat konfigurationsfilen, din applicationHost.config-fil kan se ut som den här:
<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> Du ser sedan bindningarna i IIS-hanteraren. Hoppas det hjälper.
* EDIT * Ovanstående information antog detta problemet var relaterat till IIS7. Om det gäller IIS6 finns det ett annat förfarande att följa. Information om detta finns här .
Svar
genom att överväga din senaste kommentar och efter att ha granskat expertens svar kan jag rekommendera två lösningar.
Bästa lösningarna är:
Köp wildcard ssl-certifikat som gör att du kan säkra obegränsad sub .domän.com som är värd för samma IP (SSL-certifikat kräver dedikerad IP).
Alternativa lösningar:
Du kan köpa två olika SSL-certifikat, ett för varje webbplats. Här kan inte vara värd för dem på samma ip.