Vi har et eksisterende websted med HTTP på port 80 og HTTPS på port 443. Jeg tilføjer et andet websted til det nu, og efter hvad jeg forstår, kan jeg ikke være vært for to websteder på den samme SSL-port.
Så mit spørgsmål er: hvilket portnummerinterval er passende for mig at bruge som min SSL-port på det andet sted?
Kommentarer
- Jeg kunne have taget fejl, men en mener, at en gyldig SSL-certificering kræver at være på port 443, og mener det er grunden til, at delt hosting giver dig en dedikeret IP-adresse, når du køber en SSL. Men …. dette er ikke mit felt, forhåbentlig kan en anden nørd person bekræfte.
Svar
Faktisk KAN du hoste flere SSL-sider på port 443. Følgende kode i din apache-konfigurationsfil gør tricket.
Ellers kan du bruge de porte, du vil have. Ulempen er være, at brugerne skal medtage portnummeret i URLen (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
- Tak, men dette er et IIS-sted. Nogen anelse om, hvordan jeg ville fortsætte med at gøre det samme?
Svar
Når du siger “andet sted” – mener du et andet domænenavn? Som i er du i øjeblikket vært for https://www.mycompany.com i en klynge, og du vil være vært for https://www.yourcompany.com i den samme klynge? Jeg tror, hvad du leder efter er” virtuel hosting “: http://support.microsoft.com/kb/q190008
Du skal stadig købe et andet SSL-certifikat, men du kan være vært for begge på samme IP-adresse under standardporte (hvilket i det mindste øger brugernes tillid til dit websted).
Kommentarer
- Jeg brugte vært headernavne, og de to websteder er i formen first.mycompany.com og second.mycompany.com. Problemet er, at på ” Avanceret webstedsidentifikation ” er der tre kolonner til HTTP (IP-adresse, TCP-port og værtsoverskriftsværdi) men kun to til HTTPS (IP-adresse og SSL-port), så det virker ‘ faktisk ikke muligt fra det, jeg kan se.
Svar
Traditionelt har du brug for en IP-adresse pr. SSL-binding. Det er ikke muligt at tilføje et værtsoverskrift, når du opretter bindingerne. Årsagen til dette er, at værtsoverskriften er en del af HTTP-overskrifter, der sendes af browserne, og disse overskrifter er krypteret som en del af SSL-trafikken. For at læs værtsnavnets overskrift, serveren skal først dekryptere trafikken, men for at gøre det skal den vide, hvilket certifikat der skal bruges. Til det skal den bruge værtsoverskriften til, så du kommer ind i en ond cirkel.
En løsning er, at serveren prøver alle de installerede certifikater og prøver at dekryptere anmodningen. Selvom dette muligvis fungerer med et par installerede certifikater, vandt det ikke for servere med tiendedele eller hundreder af SSL-websteder. Det ville dramatisk sænke serveren, da serveren skulle gøre dette for hver indgående anmodning.
Løsningen til dette er en udvidelse af SSL-protokollen kaldet Server Name Indication (SNI) . Dette føjer værtsnavnet til SSL-protokollen, som gør det muligt for serveren at se værtsoverskriften, før den skal dekryptere SSL-trafikken. Denne udvidelse understøttes ikke af nogen version af IIS tidligere end IIS 8 (Windows 2012). På klientsiden understøttes SNI af OS X 10.5.6 og Windows Vista eller højere SNI understøttes ikke af SChannel på Windows XP og understøttes derfor ikke af nogen version af Internet Explorer (endog 8.0) på Windows XP.
Svar
I IIS (som med andre webservere) er der tre nøgleidentifikatorer, der identificerer dit websted til indgående anmodninger:
- IP-adresse
- TCP port
- Værtsoverskrift
Hvis du kører flere websteder på en enkelt webserver, skal mindst en af disse tre være forskellige for hvert websted. I mange miljøer får en server kun en enkelt IP-adresse, så der efterlades TCP-porten og værtsoverskriften, der kan ændres. Det er muligt at køre et https-websted på en anden port, du skal bare angive porten i URLen, som ikke altid er ønskelig (dette ser ud som https://www.foo.com:32000/index.html ). Oftere end ikke vil du køre alle dine websteder på port 80 (http) eller 443 (https), så du ender med rene webadresser. Derefter efterlades værtsoverskriften som det element, du vil ændre.
I IIS kan du have flere websteder på den samme IP / portkombination, der bruger SSL og værtsoverskrifter.Nøglen er, at du skal bruge enten et wildcard-certifikat eller et SAN-certifikat (Subject Alternative Names), der angiver flere værtsnavne i selve certifikatet. Du kan ikke indstille værtsoverskriftens bindinger til værtsoverskrifter på et SSL-websted i IIS Manager UI. Du skal enten gøre det via kommandolinjen eller manuelt redigere applicationHost.config-filen på serveren.
Oplysninger fra Technet om indstilling af dette via kommandolinje kan findes her .
Der var et indlæg på IIS-forum med et lignende problem som dette, som kan findes her .
Efter at have kørt kommandoen eller manuelt redigeret konfigurationsfilen, din applicationHost.config-fil kan se ud 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 ser derefter bindingerne i IIS-manager. Håber det hjælper.
* EDIT * Ovenstående oplysninger antog dette problemet var relateret til IIS7. Hvis det er til IIS6, er der en anden procedure at følge. Oplysninger om dette kan findes her .
Svar
ved at overveje din sidste kommentar og efter at have gennemgået ekspertens svar, kan jeg anbefale to løsninger.
Bedste løsninger er:
Køb wildcard ssl-certifikat, der giver dig mulighed for at sikre ubegrænset sub .domæne.com, der er hostet på samme IP (SSL-certifikat kræver dedikeret IP).
Alternative løsninger:
Du kan købe to forskellige SSL-certifikater, et til hvert websted. Her kan du kan ikke være vært for dem på samme ip.