Mogelijkheden voor: meerdere SSL Sites op 1 IP

[cyspoz]

Ik heb momenteel de uitdaging om meerdere sites op 1 IP te draaien. Zonder SSL is dat niet zo moeilijk want dan kun je gebruik maken van hostheaders. Maar bij SSL kan dat niet meer ben ik achter gekomen. Ik ben nu aan het kijken welke mogelijkheden er allemaal zijn. De situatie is als volgt:

Windows Server 2003 Enterprise Edition met IIS6
1 Dynamisch internet IP met NAT voor server.
Eigen CA Server op de Windows Server. (niet beschikbaar op internet)

Er zijn twee oplossingen waar ik momenteel al ben opgekomen. Meer IP's aanvragen bij de provider zodat iedere SSL Site op zijn eigen ip kan draaien, of iedere site op een andere port zetten. Dit zijn geen slechte oplossingen, echter kost de eerste geld en moet je bij de tweede goed onthouden welke porten welke site draait. Je zou natuurlijk een toegangsportal site kunnen maken waarbij je vervolgens weer doorlinkt.

Ik ben eigenlijk benieuwd of dit alle oplossingen zijn, of dat er misschien nog meer zijn.

[Victor]

Helaas, dat zijn inderdaad alle oplossingen. Een SSL certificaat heeft nu eenmaal een eigen IP adres nodig.

[Sendy]

King_Louie >
Dat is niet helemaal correct. Een SSL certificaat heeft geen IP adres nodig, je webserver heeft een manier nodig om het juiste SSL certificaat bij de verbinding te vinden. Omdat je niet in de verbinding kunt kijken blijft er maar 1 manier (buiten het gebruik van porten) over om dit te zien: het ip adres.

[cyspoz]

Dan zal ik wel gebruik maken van een portal pagina die doorlinkt naar de andere pagina's op verschillende poorten. Is voor mijn toepassing de beste oplossing. Bedankt voor de reacties in iedergeval.

[bakkerl]

las weer eens niet goed

[ Voor 92% gewijzigd door bakkerl op 23-05-2005 12:07 ]

[Angelfire]

host headers is wat je zoekt. Je maakt je ssl certificaat op basis van host headers (niet op basis van IP), in IIS en Apache kan je heel goed aangeven welke host header bij welke site hoort. Je kan dan ook elke site gewoon op port 80 laten draaien.

Ik doe dit zelf ook (alleen nu zonder SSL, maar in het verleden ook met SSL), kijk maar voor de grap eens op: mijn site(ja ik weet het, tis niet mooi, maar wel functioneel voor mij)

Je moet natuurlijk je host headers wel extern hebben aangemaakt, hiermee bedoel ik dat je naam.domein.nl in de externe DNS gekoppeld hebt aan je IP. En dit dan voor alle sites die je hebt.

[Victor]

Sendy schreef op maandag 23 mei 2005 @ 11:28:
King_Louie >
Dat is niet helemaal correct. Een SSL certificaat heeft geen IP adres nodig, je webserver heeft een manier nodig om het juiste SSL certificaat bij de verbinding te vinden. Omdat je niet in de verbinding kunt kijken blijft er maar 1 manier (buiten het gebruik van porten) over om dit te zien: het ip adres.

Je hebt helemaal gelijk, maar het komt dus neer op het feit dat je voor een SSL verbinding een eigen IP nodig hebt. (Of een andere poort dus)

[Sendy]

Angelfire schreef op maandag 23 mei 2005 @ 12:12:
host headers is wat je zoekt. Je maakt je ssl certificaat op basis van host headers (niet op basis van IP), in IIS en Apache kan je heel goed aangeven welke host header bij welke site hoort. Je kan dan ook elke site gewoon op port 80 laten draaien.

Ik doe dit zelf ook (alleen nu zonder SSL, maar in het verleden ook met SSL), kijk maar voor de grap eens op: mijn site(ja ik weet het, tis niet mooi, maar wel functioneel voor mij)

Je moet natuurlijk je host headers wel extern hebben aangemaakt, hiermee bedoel ik dat je naam.domein.nl in de externe DNS gekoppeld hebt aan je IP. En dit dan voor alle sites die je hebt.

Dan ben ik heel benieuwd hoe jij dat doet. Een SSL versleutelde verbinding kan je alleen ontsleutelen met het bijbehorende SSL certificaat. Hoe kan je nu zonder in de verbinding te kijken (om de HOST: header te achterhalen) weten welk SSL certificaat je nodig hebt? Laat maar zien dan.

Verder, jullie spreken over "hostheaders". Dat is een kul-woord. Er is in HTTP/1.1 slechts een (1) header genaamd HOST. Geen headers dus.

edit:
Dat Angelfire de woorden "host header" gebruikt voor een A RR in de DNS zegt al genoeg natuurlijk

edit:
He! Op de link die richardversluis geeft, ergens beneden, zie ik dat vermaledijde host headers staan. Jullie hebben dat dus van Microsoft.

[ Voor 18% gewijzigd door Sendy op 23-05-2005 19:12 ]

[Angelfire]

Sendy,
sorry hoor, dan is het host header. Als je dat liever hebt, ik kom hier ergere spelfouten tegen dan een s-je teveel.

Even zien, je maakt in IIS een website aan. Geeft deze website een host header (naam.domein.nl) deze naam.domein.nl wijst naar een IP. Voor deze website installeer je een SSL certificaat in IIS die geldig is voor naam.domein.nl . Je klopt met https://naam.domein.nl aan bij de webserver (IIS) deze weet aan de hand van de naam (host header) welke website in IIS daar bij hoort, deze zelfde naam komt overeen met de naam waarvoor het SSL certificaat geldig is, vervolgens wordt het SSL certificaat gecontroleerd etc. (of misschien net andersom, ik kijk er niet dagelijks met een sniffer naar). Ik heb dit onder IIS 5 lang geleden werkend gehad, ik zie totaal geen reden waarom het onder IIS 6 niet zou werken, apache kan ik niet beoordelen.

[CyBeR]

Angelfire schreef op maandag 23 mei 2005 @ 13:31:
Sendy,
sorry hoor, dan is het host header. Als je dat liever hebt, ik kom hier ergere spelfouten tegen dan een s-je teveel.

Even zien, je maakt in IIS een website aan. Geeft deze website een host header (naam.domein.nl) deze naam.domein.nl wijst naar een IP. Voor deze website installeer je een SSL certificaat in IIS die geldig is voor naam.domein.nl . Je klopt met https://naam.domein.nl aan bij de webserver (IIS) deze weet aan de hand van de naam (host header) welke website in IIS daar bij hoort, deze zelfde naam komt overeen met de naam waarvoor het SSL certificaat geldig is, vervolgens wordt het SSL certificaat gecontroleerd etc. (of misschien net andersom, ik kijk er niet dagelijks met een sniffer naar). Ik heb dit onder IIS 5 lang geleden werkend gehad, ik zie totaal geen reden waarom het onder IIS 6 niet zou werken, apache kan ik niet beoordelen.

Nee, dat kan dus niet. Je verstuurt het Host: header pas nadat je SSL negotiation gedaan hebt. Dus weet de webserver nog helemaal niet welke naam de bezoeker ingevuld heeft. En aangezien de SSL certificaten die naam bevatten moet 'ie dat dus weten om het goede certifcaat tevoorschijn te toveren. Daarom moet je dus een andere manier hebben om te differentieren tussen verschillende hosts, en de makkelijkste is het gebruik van meerdere IP-adressen.

[Angelfire]

Dan heb ik het blijkbaar op een andere manier werkend gekregen. Er staat me wel weer iets van bij dat ik intern wel diverse IP's gebruikte, maar extern maar 1. Ik ga eens even in mijn grijze massa spitten hoe ik dit ook alweer gedaan had.

Kom ik nog ff op terug.
Ik ben er dus achter hoe ik dat in het verleden deed : MS ISA. Hierin maakte ik regels aan die luisterden naar http://naam.domein.nl ISA bevatte de certificaten en stuurde door naar de webserver. Dan kan je meerdere SSL certificaten naast elkaar gebruiken. Tis wat kloten onder ISA 2000, onder 2004 is het iets makkelijker, maar het kost wel wat tijd om dat te doen. Waarschijnlijk niet conform enige standaard, maar wel werkend.

[ Voor 46% gewijzigd door Angelfire op 23-05-2005 14:03 . Reden: er op terug gekomen ]

[Martkrui]

Het kan inderdaad wel, maar dan krijg je een SSL certificaat voor alle hostnames.

Dan kan het voorkomen dat de gebruiker de waarschuwing krijgt dat de hostname in het certificate niet overeenkomt met wat de gebruiker in zijn browser heeft staan.

[Sendy]

Angelfire schreef op maandag 23 mei 2005 @ 13:50:
Dan heb ik het blijkbaar op een andere manier werkend gekregen. Er staat me wel weer iets van bij dat ik intern wel diverse IP's gebruikte, maar extern maar 1. Ik ga eens even in mijn grijze massa spitten hoe ik dit ook alweer gedaan had.

Kom ik nog ff op terug.
Ik ben er dus achter hoe ik dat in het verleden deed : MS ISA. Hierin maakte ik regels aan die luisterden naar http://naam.domein.nl ISA bevatte de certificaten en stuurde door naar de webserver. Dan kan je meerdere SSL certificaten naast elkaar gebruiken. Tis wat kloten onder ISA 2000, onder 2004 is het iets makkelijker, maar het kost wel wat tijd om dat te doen. Waarschijnlijk niet conform enige standaard, maar wel werkend.

Tja, ik geloof er helemaal niets van. Ik ken MS ISA niet, maar werkt dat alleen met IE op een intranet of iets dergelijks?

[Verwijderd]

Sendy schreef op maandag 23 mei 2005 @ 17:26:
[...]


Tja, ik geloof er helemaal niets van. Ik ken MS ISA niet, maar werkt dat alleen met IE op een intranet of iets dergelijks?

het kan inderdaad wel, maar zoals al aangegeven krijg je dan een dns mismatch op het certificaat. oftewel een irritante popup.

de enige goede manier is dan ook per ssl site 1 ip.

(volgens koppel je een certificaat aan een ip, maar in het certificaat zit de hostheader (dnsnaam) verwerkt. kom je binnen op over ssl binnen op een ip dan krijg je match op hostheader die je gebruikt met de hostheader in het certificaat. klopt dat dan merk je niks van het certificaat, klopt het niet >> popup).

[Sendy]

Ah, dat wordt er bedoeld. Dat kan je nog veel simpler doen. Gewoon zeggen dat je certificaat bestand voor alle verschillende hosts geldig is.

Alleen de host waarvoor dat certificaat geldig is krijgt nu geen waarschuwing dat er niets van het certificaat klopt. Als je dat werken noemt...

Lees bijvoorbeeld een uitleg hier.
Als je de belangrijkste waarschuwing (n.l. "dit certificaat behoort niet bij deze server", de irritante popup) wegklikt ben je toch wel een grote prutser.

[ Voor 12% gewijzigd door Sendy op 23-05-2005 18:05 ]

[Verwijderd]

Sendy schreef op maandag 23 mei 2005 @ 18:00:
Ah, dat wordt er bedoeld. Dat kan je nog veel simpler doen. Gewoon zeggen dat je certificaat bestand voor alle verschillende hosts geldig is.

Alleen de host waarvoor dat certificaat geldig is krijgt nu geen waarschuwing dat er niets van het certificaat klopt. Als je dat werken noemt...

Lees bijvoorbeeld een uitleg hier.
Als je de belangrijkste waarschuwing (n.l. "dit certificaat behoort niet bij deze server", de irritante popup) wegklikt ben je toch wel een grote prutser.

exactly, alhoewel ik dit trucje ook wel eens uitgehaald heb voor een beheer site (slechts voor 2 man benodigt) die draaide op het certificaat van de normale website (en ze niet wilde betalen voor een 2de ip ). voor gebruikers is dit iig geen oplossing!

[ Voor 4% gewijzigd door Verwijderd op 23-05-2005 18:11 ]

[richardversluis]

Ik heb hier ook erg lang naar gezocht, uiteindelijk heb ik maar besloten meerdere ip's te gebruiken. Wel zegt MS sinds iis6 sp1 SSL over host headers te ondersteunen maar daar kwam ik niet uit:

http://www.microsoft.com/...4d-885d-f8941b07554c.mspx

Misschien kan jij er wat mee!

[Sendy]

richardversluis >
Dat gaat over een wildcardcertificaat. Zo'n certificaat krijg je natuurlijk niet op *.com. of *.nl. Misschien nog niet eens op *.domein.nl.

edit:

Maar dit zou natuurlijk wel een oplossing voor de TS kunnen zijn.

[ Voor 31% gewijzigd door Sendy op 23-05-2005 19:26 ]

[cyspoz]

Ik dacht eigenlijk dat alle oplossingen waren geweest. Maar het is dus wel mogelijk middels hostheaders meerdere SSL sites op dezelfde port en ip te draaien. Met of zonder invalid certificaat waarschuwing. Dat maakt niet zo heel veel uit, aangezien ik zelf de Certificaat Authority ben en buiten mijn eigen netwerk dus toch altijd al die popup krijg. Of er dan 1 of 2 waarschuwing bijstaan maakt mij niet zo heel veel uit.

Ik ga morgen aan de gang met de link die richardversluis die ziet er zeer bruikbaar uit. Laat nog wel even weten of ik iets aan de gang krijg. 't is maar voor eigen gebruik dus hoeft niet perfect te zijn.

[alt-92]

Ach ja.. voor eigen gebruik kan je natuurlijk altijd nog de Certificate Chain completeren door jouw eigen root (?) CA cert ook aan die desbetreffende gebruikers als Trusted Root ter beschikking te stellen.

Dat is voor een kleine groep zonder AD truken nog wel te behapstukken.

[PiOn]

Als je die waarschuwing voor lief neemt (die van: geen door Verisign gecertificeerd certificaat adres) is het wel mogelijk, echter wel met een paar beperkingen. Ik voer deze actie geregeld uit, met de volgende 'randvoorwaarden':
(uitgevoerd op een IIS bak, maar idee is volgens mij algemeen geldig)
- gebruik van een ISAserver oid
- alle website hebben het zelfde basisdomein, e.g. site1.domein.com, site2.domein.com, etc.

Idee is als volgt:

Maak op de IIS bak een 'website' iets.domein.com aan. Koppel hier een certificaat aan, echter niet met de juiste fqdn, maar met een wildcard (*.domein.com). Exporteer het certificaat naar de ISA server oid.

Maak nu alle gewenste 'websites' aan, e.g. site1.domein.com, site2.domein.com. Koppel hier waar gewenst een certificaat aan met de JUISTE fqdn aan.

Je krijgt nu geen meldingen meer van dat de hostnaam niet klopt, alleen nog die waarschuwing van niet officieel erkend certificaat (tenzij je er natuurlijk 1 koopt, dan krijg je uberhaupt geen waarschuwingspopup meer )

[Sendy]

En waarom maak je die certificaten met juiste fqdn? Als je een wildcard certificaat gebruikt dan krijg je toch al geen meldingen? (Misschien is dit een Microsoft quirk hoor; ik verwacht alleen dat het in Apache handiger gaat.)

En een wildcard certificaat kan je niet zo makkelijk kopen

[cyspoz]

Ik heb dat artikel van Microsoft doorgelezen wat richardversluis mij gaf. Daarmee moet ik er wel uit komen. Hopelijk zit ik safe door van te voren een backup te maken van de Metadatabase (ga er van uit dat alleen daar wijzigingen worden gedaan)

Een wildcard certificaat kun je misschien wel niet zo makkelijk kopen nee, maar ik gebruik de CA server die bij Windows Server zit. Dus ik hoef niks te kopen en kan het gewoon zelf aanmaken. Ik ben momenteel niet thuis, maar hoop het een deze dagen re realiseren. Laat hier wel even weten of het is gelukt.