Vi har et eksisterende nettsted med HTTP på port 80 og HTTPS på port 443. Jeg legger til et annet nettsted til det nå, og etter hva jeg forstår, kan jeg ikke være vert for to nettsteder på samme SSL-port.
Så spørsmålet mitt er: hvilket portnummerområde som passer for meg å bruke som SSL-port på det andre nettstedet?
Kommentarer
- Jeg kan ta feil, men jeg tror en gyldig SSL-sertifisering krever å være på port 443, og tror dette er grunnen til at delt hosting gir deg en dedikert IP-adresse når du kjøper en SSL. Men … dette er ikke mitt felt, forhåpentligvis kan en annen geeky person bekrefte.
Svar
Egentlig KAN du være vert for flere SSL-nettsteder på port 443. Følgende kode i apache-konfigurasjonsfilen vil gjøre susen.
Ellers kan du bruke hvilke porter du vil. Ulempen vil være at brukerne må ta med portnummeret i URL-en (f.eks. 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
- Takk, men dette er et IIS-nettsted. Noen anelse om hvordan jeg vil fortsette å gjøre det samme?
Svar
Når du sier «andre side» – mener du et andre domenenavn? Som i er du for øyeblikket vert for https://www.mycompany.com i en klynge, og du vil være vert for https://www.yourcompany.com på den samme klyngen? Jeg tror det du leter etter er» virtuell hosting «: http://support.microsoft.com/kb/q190008
Du vil fortsatt ha behov for å kjøpe et nytt SSL-sertifikat, men du vil kunne være vert for begge samtidig IP-adresse under standardporter (som i det minste vil øke brukernes tillit til nettstedet ditt).
Kommentarer
- Jeg brukte verten toppnavn, og de to nettstedene er i form first.mycompany.com og second.mycompany.com. Problemet er at på » Avansert nettstedsidentifikasjon » er det tre kolonner for HTTP (IP-adresse, TCP-port og Host-topptekstverdi) men bare to for HTTPS (IP-adresse og SSL-port), så det ser ikke ut ‘ t fra det jeg kan se.
Svar
Tradisjonelt trenger du en IP-adresse per SSL-binding. Det er ikke mulig å legge til et vertsoverskrift når du setter opp bindingene. Årsaken til dette er fordi vertsoverskriften er en del av HTTP-overskriftene som sendes av nettleserne, og disse overskriftene er kryptert som en del av SSL-trafikken. For å les vertsnavnet, serveren må først dekryptere trafikken, men for å gjøre det, må den vite hvilket sertifikat du skal bruke. For det trenger den vertsoverskriften for å komme inn i en ond sirkel.
En løsning ville være at serveren prøvde alle de installerte sertifikatene og prøv å dekryptere forespørselen. Selv om dette kan fungere med noen få sertifikater installert, vil det ikke fungere for servere med tideler eller hundrevis av SSL-nettsteder. Det ville dramatisk redusere serveren, da serveren måtte gjøre dette for hver innkommende forespørsel. > Løsningen på dette er en utvidelse av SSL-protokollen kalt Server Name Indication (SNI) . Dette legger vertsnavnet til SSL-protokollen som gjør det mulig for serveren å se vertsoverskriften før den må dekryptere SSL-trafikken. Denne utvidelsen støttes ikke av noen versjon av IIS tidligere enn IIS 8 (Windows 2012). På klientsiden støttes SNI av OS X 10.5.6 og Windows Vista eller høyere SNI støttes ikke av SChannel på Windows XP og støttes dermed ikke av noen versjon av Internet Explorer (til og med 8.0) på Windows XP.
Svar
I IIS (som med andre webservere) er det tre nøkkelidentifikatorer som identifiserer nettstedet ditt for innkommende forespørsler:
- IP-adresse
- TCP port
- Vertens overskrift
Hvis du kjører flere nettsteder på en enkelt webserver, må minst en av disse tre være forskjellige for hvert nettsted. I mange miljøer får en server bare en enkelt IP-adresse, slik at TCP-porten og vertsoverskriften forlates som kan endres. Det er mulig å kjøre et https-nettsted på en annen port, du må bare spesifisere porten i URL-en som ikke alltid er ønskelig (dette vil se ut som https://www.foo.com:32000/index.html ). Oftere enn ikke, vil du kjøre alle nettstedene dine på port 80 (http) eller 443 (https) slik at du ender med rene nettadresser. Det etterlater vertsoverskriften som det elementet du vil endre.
I IIS kan du ha flere nettsteder på samme IP / portkombinasjon som bruker SSL og vertsoverskrifter.Nøkkelen er at du må bruke enten et jokertegnsertifikat eller et SAN-sertifikat (Subject Alternative Names) som spesifiserer flere vertsnavn i selve sertifikatet. Du kan ikke angi vertens overskriftsbindinger for vertsoverskrifter på et SSL-nettsted i IIS Manager UI. Du må enten gjøre det via kommandolinjen eller redigere applicationHost.config-filen manuelt på serveren.
Informasjon fra Technet om innstilling av dette via kommandolinje finner du her .
Det var et innlegg på IIS-forum med et lignende problem som dette, som du finner her .
Etter å ha kjørt kommandoen eller manuelt redigert konfigurasjonsfilen, applicationHost.config-filen din kan se ut som denne:
<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 vil da se bindingene i IIS-manager. Håper det hjelper.
* EDIT * Informasjonen ovenfor antok dette problemet var relatert til IIS7. Hvis det er for IIS6, er det en annen prosedyre å følge. Informasjon om det finner du her .
Svar
ved å vurdere den siste kommentaren din og etter å ha gjennomgått ekspertens svar, kan jeg anbefale to løsninger.
Beste løsningene er:
Kjøp wildcard ssl-sertifikat som lar deg sikre ubegrenset sub .domain.com som er vert på samme IP (SSL-sertifikat krever dedikert IP).
Alternative løsninger:
Du kan kjøpe to forskjellige SSL-sertifikater, ett for hvert nettsted. Her kan ikke være vert for dem på samme ip.