Poortnummers voor SSL

We hebben een bestaande website met HTTP op poort 80 en HTTPS op poort 443. Ik voeg daar nu een tweede site aan toe, en voor zover ik begrijp, kan ik niet twee sites hosten op dezelfde SSL-poort.

Dus mijn vraag is: welk poortnummerbereik is geschikt voor mij om te gebruiken als mijn SSL-poort op de tweede site?

Reacties

  • Ik zou het mis kunnen hebben, maar ik geloof dat een geldige SSL-certificering vereist is op poort 443, en ik denk dat dit de reden is waarom shared hosting je een speciale IP-adres bij aanschaf van een SSL. Maar … dit is niet mijn vakgebied, hopelijk kan een andere nerd het bevestigen.

Antwoord

Eigenlijk KUNT u meerdere SSL-sites hosten op poort 443. De volgende code in uw apache-configuratiebestand zal het lukken.

Anders kunt u elke gewenste poort gebruiken. Het nadeel is zijn dat gebruikers het poortnummer in de URL moeten opnemen (bijv. 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> 

Reacties

  • Bedankt, maar dit is een IIS-site. Enig idee hoe ik zou doorgaan om hetzelfde te doen?

Antwoord

Wanneer je “tweede site” zegt – bedoel je een tweede domeinnaam? Net als in, “host u momenteel https://www.mycompany.com op één cluster en wilt u https://www.yourcompany.com op datzelfde cluster? Ik denk dat je” virtuele hosting “zoekt: http://support.microsoft.com/kb/q190008

U “zult nog steeds een tweede SSL-certificaat moeten kopen, maar u kunt beide tegelijkertijd hosten IP-adres onder de standaardpoorten (wat op zijn minst het vertrouwen van de gebruiker in uw site zal vergroten).

Reacties

  • Ik heb host gebruikt koptekstnamen, en de twee sites hebben de vorm first.mycompany.com en second.mycompany.com. Het probleem is dat op ” Advanced Web Site Identification ” er drie kolommen zijn voor HTTP (IP-adres, TCP-poort en Host-headerwaarde) maar slechts twee voor HTTPS (IP-adres en SSL-poort), dus het lijkt niet ‘ t echt mogelijk te zijn van wat ik kan zien.

Answer

Traditioneel heb je één IP-adres per SSL-binding nodig. Het is niet mogelijk om een host-header toe te voegen bij het instellen van de bindingen. De reden hiervoor is dat de host-header deel uitmaakt van de HTTP-headers die door de browsers worden verzonden en deze headers worden gecodeerd als onderdeel van het SSL-verkeer. lees de hostnaam-header, de server moet eerst het verkeer ontsleutelen, maar om dat te doen moet hij weten welk certificaat hij moet gebruiken. Daarvoor zou hij de host-header nodig hebben, zodat je in een vicieuze cirkel terechtkomt.

Een oplossing zou zijn dat de server alle geïnstalleerde certificaten probeert en probeert het verzoek te decoderen. Hoewel dit zou kunnen werken met een paar geïnstalleerde certificaten, is dit niet het geval voor servers met tienden of honderden SSL-websites. Het zou de server drastisch vertragen aangezien de server dit voor elk inkomend verzoek zou moeten doen.

De oplossing hiervoor is een uitbreiding van het SSL-protocol met de naam Server Name Indication (SNI) . Hiermee wordt de hostnaam toegevoegd aan het SSL-protocol waarmee de server zie de host-header voordat het SSL-verkeer moet ontsleutelen. Deze extensie wordt niet ondersteund door een eerdere versie van IIS dan IIS 8 (Windows 2012). Aan de clientzijde wordt SNI ondersteund door OS X 10.5.6 en Windows Vista of hoger . SNI wordt niet ondersteund door de SChannel op Windows XP en dus niet ondersteund door enige versie van Internet Explorer (zelfs 8.0) op Windows XP.

Answer

In IIS (net als bij andere webservers) zijn er drie sleutel-IDs die uw site identificeren voor inkomende verzoeken:

  1. IP-adres
  2. TCP port
  3. Host-header

Als u meerdere websites op een enkele webserver draait, moet ten minste één van deze drie voor elke site anders zijn. In veel omgevingen krijgt een server slechts één IP-adres, zodat de TCP-poort en de host-header overblijven die kunnen worden gewijzigd. Het is mogelijk om een https-website op een andere poort te draaien, u hoeft alleen de poort in de URL op te geven, wat niet altijd wenselijk is (dit zou er ongeveer zo uitzien https://www.foo.com:32000/index.html ). Vaker wel dan niet, wilt u al uw websites op poort 80 (http) of 443 (https) draaien, zodat u schone URLs krijgt. Dat laat dan de host-header achter als het enige item dat u wilt wijzigen.

In IIS kunt u meerdere sites op dezelfde IP / poort-combinatie hebben die SSL en host-headers gebruiken.De sleutel is dat u een wildcard-certificaat of een SAN-certificaat (Subject Alternative Names) moet gebruiken dat meerdere hostnamen in het certificaat zelf specificeert. U kunt de host-header-bindingen voor host-headers op een SSL-site niet instellen in de gebruikersinterface van IIS Manager. U moet dit doen via de opdrachtregel of het bestand applicationHost.config handmatig op de server bewerken.

Informatie van Technet over het instellen van dit via de opdrachtregel is hier te vinden.

Er was een bericht op de IIS Forum met een soortgelijk probleem dat ook hier kan worden gevonden.

Na het uitvoeren van de opdracht of het handmatig bewerken van het configuratiebestand, uw applicationHost.config-bestand kan er ongeveer zo uitzien:

<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> 

U zult dan de bindingen zien in IIS Manager. Hoop dat dat helpt.

* EDIT * Bij de bovenstaande informatie werd aangenomen dat dit probleem was gerelateerd aan IIS7. Als het voor IIS6 is, is er een andere procedure die moet worden gevolgd. Informatie daarover is hier te vinden.

Antwoord

door uw laatste opmerking in overweging te nemen en na het bekijken van de antwoorden van experts, kan ik twee oplossingen aanbevelen.

De beste oplossing is:

Koop een wildcard ssl-certificaat waarmee u een onbeperkt aantal .domain.com dat wordt gehost op hetzelfde IP-adres (SSL-certificaat vereist speciaal IP-adres).

Alternatieve oplossingen:

U kunt twee verschillende SSL-certificaten kopen, één voor elke website. Hier kunt u kan ze niet hosten op hetzelfde ip.

Geef een reactie

Het e-mailadres wordt niet gepubliceerd. Vereiste velden zijn gemarkeerd met *