Instellen IIS https met 2 url's.

[Yarisken]

Beste,

Ik zit met een probleem waar ik niet direct een oplossing voor vind.
We gebruiken hier iis 8.5.
Een externe firma is bezig met een web applicatie te deployen op een server.
Het moet over https gaan dus we hebben een cert voor www.domain.com. Geen wildcard cert.
Er zijn 2 sites gedefinieerd in IIS. De site web en de site api.
De Web website heeft als binding www.domain.com gekregen en dit werkt.
Voor de andere site api moet de website gaan naar www.domain.com/api .
Echter kan ik dit certificaat niet mappen omdat het al in gebruik is voor de site web.

Ik vind genoeg info terug over wildcard / san certificaten maar ik heb geen idee hoe ik dit moet instellen.
Iemand een idee / tip ?

[Meekoh]

een wildcard/SAN certificaat moet je kopen (als het een publieke site is). Bij een interne CA is het gewoon een SSL certificaat met *.domain.com als SubjectName.

Maar eigenlijk snap ik niet waarom dit twee sites zijn? Waarom maak je niet een Application/Virtual Directory onder www.domain.com die wijst naar de directory van de www.domain.com/api files?
En is het anders geen optie om de api onder api.domain.com te laten draaien?

[Yarisken]

Meekoh schreef op vrijdag 29 april 2016 @ 11:41:
een wildcard/SAN certificaat moet je kopen (als het een publieke site is). Bij een interne CA is het gewoon een SSL certificaat met *.domain.com als SubjectName.

Maar eigenlijk snap ik niet waarom dit twee sites zijn? Waarom maak je niet een Application/Virtual Directory onder www.domain.com die wijst naar de directory van de www.domain.com/api files?
En is het anders geen optie om de api onder api.domain.com te laten draaien?

In test draaien we deze config met een wildcard certificaat van ons hoofdomein en dit werkt perfect.
In prod wilden ze een andere domeinnaam en hebben we een www.domain.com aangekocht.
Wildcard zou idd alles oplossen maar dat is ook duur :-).

Dat het 2 sites zijn is hun design ... daar kan ik niet veel aan doen. Om api.domain.com te gebruiken hebben we ofwel een extra cert nodig ofwel een wildcard.

Ik zoek dus, indien het mogelijk is, een workaround ... of aparte config van iis.

[Meekoh]

Yarisken schreef op vrijdag 29 april 2016 @ 11:56:
[...]
Ik zoek dus, indien het mogelijk is, een workaround ... of aparte config van iis.

Meerdere IP Adressen en iedere site zijn eigen IP. Je kunt hetzelfde certificaat 1x binden per IP adres.

[Muggie]

Als je het certificaat een niveau hoger plaatst werkt deze voor beide virtual directories alleen moet de binding van /web anders opgelost worden als je die specifieke binding wilt behouden.

[Meekoh]

Muggie schreef op zondag 01 mei 2016 @ 08:35:
Als je het certificaat een niveau hoger plaatst werkt deze voor beide virtual directories alleen moet de binding van /web anders opgelost worden als je die specifieke binding wilt behouden.

Dat is nu juist TS zijn probleem. Het zijn geen virtual directories. Externe toko heeft het aangemaakt als 2 aparte websites in IIS.

[Yarisken]

Meekoh schreef op maandag 02 mei 2016 @ 17:23:
[...]

Dat is nu juist TS zijn probleem. Het zijn geen virtual directories. Externe toko heeft het aangemaakt als 2 aparte websites in IIS.

Idd, ik had vandaag gekeken om een 2de certificaat aan te kopen maar op 1 ip geeft dit ook problemen.
We zullen waarschijnlijk een wildcard certificaat aankopen. Dan zijn onze problemen van de baan :-).
Thx voor de hulp.

[Semt-x]

Weet je zeker dat dit werkt?
Ik geloof direct dat IIS geen problemen constateert. Echter, als een client de site bezoekt, komt deze op 1 van de 2 sites uit, als er een verzoek is voor de API maar op de site uitkomt zonder die API virtual directory, kan deze de API volgens mij niet vinden en krijg je een foutmelding.
Of mis ik iets?

[ Voor 5% gewijzigd door Semt-x op 03-05-2016 09:18 ]

[Yarisken]

Semt-x schreef op dinsdag 03 mei 2016 @ 09:17:
Weet je zeker dat dit werkt?
Ik geloof direct dat IIS geen problemen constateert. Echter, als een client de site bezoekt, komt deze op 1 van de 2 sites uit, als er een verzoek is voor de API maar op de site uitkomt zonder die API virtual directory, kan deze de API volgens mij niet vinden en krijg je een foutmelding.
Of mis ik iets?

In test hebben we het draaien met een wildcard certificaat van een ander domein. Werkt perfect.

[Semt-x]

Ik heb het nagebouwd in een lab met wildcard cert (IIS 8.5), en wat je zegt kan simpelweg niet.

SNI stelt je instaat poort 443 van een ip adres te hergebruiken voor een andere site (hostnaam). niet voor een andere site met dezelfde hostname.
Als je het desondanks probeert te configureren levert het in IIS een foutmelding op.


Ik vermoed dat je denkt dat het werkt, maar in werkelijkheid niet werkt.

Die applicatie ontwikkelaar zou je moeten kunnen helpen. Zij moeten de kennis hebben om je dit bij te brengen, als het goed is hebben ze dit al 2345 keer vaker gedaan.
Er zijn 2 opties;
api site met een andere hostname,
virtuele directory in de hoofdsite (voor sites met weinig bezoekers is dat geen probleem)

[Yarisken]

Semt-x schreef op dinsdag 03 mei 2016 @ 14:37:
Ik heb het nagebouwd in een lab met wildcard cert (IIS 8.5), en wat je zegt kan simpelweg niet.

SNI stelt je instaat poort 443 van een ip adres te hergebruiken voor een andere site (hostnaam). niet voor een andere site met dezelfde hostname.
Als je het desondanks probeert te configureren levert het in IIS een foutmelding op.


Ik vermoed dat je denkt dat het werkt, maar in werkelijkheid niet werkt.

Die applicatie ontwikkelaar zou je moeten kunnen helpen. Zij moeten de kennis hebben om je dit bij te brengen, als het goed is hebben ze dit al 2345 keer vaker gedaan.
Er zijn 2 opties;
api site met een andere hostname,
virtuele directory in de hoofdsite (voor sites met weinig bezoekers is dat geen probleem)

Klopt wat je zegt. Sorry ik was wat onduidelijk.
Initieel was de bedoeling om www.domain.com te gebruiken en dan nog api.domain.com.
Omdat we maar 1 cert hadden gingen we gaan voor www.domain.com en www.domain.com/api.

Met een wildcard kunnen we onze eerste opzet gebruiken nl voor 1 site www.domain.com en voor de 2de site api.domain.com.
Sorry voor de onduidelijkheid.

[Meekoh]

Semt-x schreef op dinsdag 03 mei 2016 @ 14:37:
Ik heb het nagebouwd in een lab met wildcard cert (IIS 8.5), en wat je zegt kan simpelweg niet.

SNI stelt je instaat poort 443 van een ip adres te hergebruiken voor een andere site (hostnaam). niet voor een andere site met dezelfde hostname.
Als je het desondanks probeert te configureren levert het in IIS een foutmelding op.


Ik vermoed dat je denkt dat het werkt, maar in werkelijkheid niet werkt.

Die applicatie ontwikkelaar zou je moeten kunnen helpen. Zij moeten de kennis hebben om je dit bij te brengen, als het goed is hebben ze dit al 2345 keer vaker gedaan.
Er zijn 2 opties;
api site met een andere hostname,
virtuele directory in de hoofdsite (voor sites met weinig bezoekers is dat geen probleem)

Kan best hoor.
Maak voor de test een Self signed certificaat voor www.leukdomein.nl
Maak 2 sites aan.
Site 1 gaat naar de hoofdmap van de site, geef het IP 192.168.1.200 en voeg een binding toe voor 443 met het certificaat van www.leukdomein.nl. Doordat het een volledige naam bereft kun je geen host headers toevoegen.

Site 2 gaat naar de hoofdmap van de API en bevat een subdir genaamd API (anders kom je niet op www.leukdomein.nl/api). geeft het IP 192.168.1.201 en voeg een binding toe voor 443 met hetzelfde www.leukdomein.nl certificaat.

Werkt prima

[Question Mark]

Yarisken schreef op maandag 02 mei 2016 @ 17:35:
[...]
We zullen waarschijnlijk een wildcard certificaat aankopen. Dan zijn onze problemen van de baan :-).

Een wildcard certificaat voor een publieke website vind ik een beetje een makkelijke oplossing. Het geeft mij als eindgebruiker nou niet echt een lekker veilig gevoel.

Waarom moet er eigenlijk SSL toegepast gaan worden? Encryptie? (zo ja, nog specifieke eisen en wensen mbt gebruikte ciphers), of voornamelijk domain validation? Als het dat laatste is, dan is een wildcard certificaat sowieso uit den boze.

[Semt-x]

Meekoh schreef op dinsdag 03 mei 2016 @ 15:51:
[...]
Kan best hoor.
Maak voor de test een Self signed certificaat voor www.leukdomein.nl
Maak 2 sites aan.
Site 1 gaat naar de hoofdmap van de site, geef het IP 192.168.1.200 en voeg een binding toe voor 443 met het certificaat van www.leukdomein.nl. Doordat het een volledige naam bereft kun je geen host headers toevoegen.

Site 2 gaat naar de hoofdmap van de API en bevat een subdir genaamd API (anders kom je niet op www.leukdomein.nl/api). geeft het IP 192.168.1.201 en voeg een binding toe voor 443 met hetzelfde www.leukdomein.nl certificaat.

Werkt prima

Clients die de site bezoeken moet www.leukdomein.nl resolven en komen uit op 192.1681.200 of 192.168.1.201? Je komt op de echte site uit of op de API site. Dat lijkt me geen werkbare oplossing.
Daarnaast, een self signed certificaat op en publieke site? oef..

[Yarisken]

Question Mark schreef op dinsdag 03 mei 2016 @ 18:46:
[...]

Een wildcard certificaat voor een publieke website vind ik een beetje een makkelijke oplossing. Het geeft mij als eindgebruiker nou niet echt een lekker veilig gevoel.

Waarom moet er eigenlijk SSL toegepast gaan worden? Encryptie? (zo ja, nog specifieke eisen en wensen mbt gebruikte ciphers), of voornamelijk domain validation? Als het dat laatste is, dan is een wildcard certificaat sowieso uit den boze.

Waarom is een wildcard niet geschikt ? Wij betalen 1299 euro ervoor dus dat lijkt me genoeg geld om veilig te zijn :-).

Ssl is een must voor elke site / applicatie bij ons. Bedrijfspolicy. We zitten met redelijk gevoelige data.

[Meekoh]

Semt-x schreef op dinsdag 03 mei 2016 @ 19:34:
[...]


Clients die de site bezoeken moet www.leukdomein.nl resolven en komen uit op 192.1681.200 of 192.168.1.201? Je komt op de echte site uit of op de API site. Dat lijkt me geen werkbare oplossing.
Daarnaast, een self signed certificaat op en publieke site? oef..

wat betreft het resolven. kan dat een uitdaging worden. Waar het mij meer om ging was dat je prima 2 sites op dezelfde server kunt hebben met hetzelfde certificaat. Ongeacht of het een self singed certificaat is of niet captain obvious

[Paul]

Yarisken schreef op dinsdag 03 mei 2016 @ 20:34:
Ssl is een must voor elke site / applicatie bij ons. Bedrijfspolicy. We zitten met redelijk gevoelige data.

Waarom is api.domein.com afgeschoten? Omdat je maar één certificaat hebt? Een 2e certificaat (of van /api een virtuele directory maken) is echt veel goedkoper dan een wildcard certificaat En tenzij je nog XP met IE6 wilt ondersteunen (met gevoelige data...) kun je gewoon SNI gebruiken.

Je maakt 3 sites:
- hostheader www.domein.com met certificaat voor domein.com (volgens mij geeft 99% van de certificaat-uitgevers gratis www.subject als subject alternate name mee op het certificaat, maar ik zou het wel checken) die je met een HTTP/301 verwijst naar domein.com (of andersom, als je de www-variant als 'echte' site aan wilt houden
- hostheader met domein.com en certificaat voor domein.com met je website
- hostheader met api.domein.com en certificaat voor api.domein.com met je api

[Question Mark]

Yarisken schreef op dinsdag 03 mei 2016 @ 20:34:
[...]


Waarom is een wildcard niet geschikt ? Wij betalen 1299 euro ervoor dus dat lijkt me genoeg geld om veilig te zijn :-).

Omdat als één website compromised is, er een nieuwe website aangemaakt kan worden die via het wildcard certificaat aangeboden kan worden. Bovendien kan een gebruiker nog steeds niet controleren of hij wel gebruik maakt van de juiste URL. Een wildcard vangt immers alles af....

Things to consider about Wildcard SSL Certificates
Wildcard certificates aren’t always a perfect fit for every situation or business. Some concerns to be aware of regarding wildcards include:

Security – Although setting up a new subdomain to use a wildcard certificate is easy, it’s also potentially dangerous. Any subdomain that is part of your protected domain will seem like a valid and secure website – even if it’s been set up outside your direct control. (This is the main reason Extended Validation certificates do not allow wildcards.)

Ssl is een must voor elke site / applicatie bij ons. Bedrijfspolicy. We zitten met redelijk gevoelige data.

Dat betekend dat je dus encryptie vereist? Welke ciphers en dergelijjke?

[ Voor 29% gewijzigd door Question Mark op 04-05-2016 09:24 ]

[MaZo]

Je kunt gewoon meerdere SSL sites draaien op één IP bij gebruik van een SAN certificaat. Vervolgens via appcmd configureren (kan niet via de GUI).

[Question Mark]

Met behulp van IIS Budy is het ook via GUI mogelijk.

[Yarisken]

We hebben een wildcard gekocht en nu werkt alles perfect. Bedankt voor jullie input guys.

[Paul]

Yarisken schreef op dinsdag 10 mei 2016 @ 21:34:
We hebben een wildcard gekocht en nu werkt alles perfect. Bedankt voor jullie input guys.

Question Mark schreef op woensdag 04 mei 2016 @ 09:21:
Dat betekend dat je dus encryptie vereist? Welke ciphers en dergelijjke?

@TS: Dit is een hele belangrijke vraag. Een (of meer) certificaten installeren is zo ongeveer het simpelste onderdeel van SSL. Als ik Poodle of Beast zeg, krab je je dan achter de oren of weet je waar ik het over heb?

Twee nuttige sites (die geen vervanging zijn voor begrijpen wat je doet, maar je moet ergens beginnen ):
https://www.nartac.com/Products/IISCrypto
https://www.ssllabs.com/ssltest/

[ Voor 14% gewijzigd door Paul op 11-05-2016 09:19 ]

[Yarisken]

Paul schreef op woensdag 11 mei 2016 @ 09:19:
[...]


[...]

@TS: Dit is een hele belangrijke vraag. Een (of meer) certificaten installeren is zo ongeveer het simpelste onderdeel van SSL. Als ik Poodle of Beast zeg, krab je je dan achter de oren of weet je waar ik het over heb?

Twee nuttige sites (die geen vervanging zijn voor begrijpen wat je doet, maar je moet ergens beginnen ):
https://www.nartac.com/Products/IISCrypto
https://www.ssllabs.com/ssltest/

Nee nee ik heb een gezonde interesse in security en ik gebruik mooi ssllabs.com voor al mijn https sites.
IISCrypto had ik al gebruikt op onze tmg en ook op de sites die nu in productie staan.
Ik heb een mooie "A" of "A+" ( ook en vooral linux ) voor al onze sites buiten 1 waar ik persé winxp met ie6 moet laten openstaan .
Ik krijg die applicatie owner niet overtuigd omdat er nog steeds mensen zijn die op die site komen met xp en ie6 .... .

[Question Mark]

Yarisken schreef op woensdag 11 mei 2016 @ 13:02:
[...]

Nee nee ik heb een gezonde interesse in security en ik gebruik mooi ssllabs.com voor al mijn https sites.

Waarom dan de keuze voor een wildcard certificaat, en niet een SAN certificaat met de twee benodigde entry's? Die laatste is waarschijnlijk goedkoper én veiliger.

Gewoon een vraag hoor, geen kritiek

[Yarisken]

Question Mark schreef op woensdag 11 mei 2016 @ 13:17:
[...]

Waarom dan de keuze voor een wildcard certificaat, en niet een SAN certificaat met de twee benodigde entry's? Die laatste is waarschijnlijk goedkoper én veiliger.

Gewoon een vraag hoor, geen kritiek

Wel ik moet het niet betalen :-).
Vooral flexibiliteit. Als er nu nog een url bijkomt dan moeten we niet het san-certificaat laten aanpassen.

Voor exchange gebruiken we bv een san-certificaat. Ondertussen weten we dat we beter ons "bestaand" wildcard certificaat hadden gebruikt en nog een klein san-certificaat voor wat aparte services.

Met trial and error leer je hé :-).
De kost voor de wildcard voor 3 jaar was 1299 euro.

[Paul]

Auw, dure certificaat-uitgever hebben ze dan gekozen

Met SNI (mits je die ene XP-beheerder om weet te halen of je daarvoor een apart IPv4-adres hebt) had je gewone certificaten voor 3 jaar voor € 20 per stuk (of een SAN voor € 40) bij sslcertificaten.nl (en mogelijk elders nog goedkoper), daar had je 65 diensten ( of 64 als een daarvan webmail + autodiscover is. Met een DNS-provider die SRV-records ondersteunt had je zelfs Exchange met één normaal certificaat kunnen doen) voor kunnen ontsluiten zonder een 'vies' wildcard-certificaat

[Yarisken]

Paul schreef op woensdag 11 mei 2016 @ 13:56:
Auw, dure certificaat-uitgever hebben ze dan gekozen

Met SNI (mits je die ene XP-beheerder om weet te halen of je daarvoor een apart IPv4-adres hebt) had je gewone certificaten voor 3 jaar voor € 20 per stuk (of een SAN voor € 40) bij sslcertificaten.nl (en mogelijk elders nog goedkoper), daar had je 65 diensten ( of 64 als een daarvan webmail + autodiscover is. Met een DNS-provider die SRV-records ondersteunt had je zelfs Exchange met één normaal certificaat kunnen doen) voor kunnen ontsluiten zonder een 'vies' wildcard-certificaat

Idd, wij zitten bij een "dure". Da's historisch onze leverancier en ik bestel daar ook gewoon bij.
Die bellen ons als een certificaat gaat vervallen dus da's ook wel een mooie service.
Binnenkort toch eens kijken naar let's encrypt :-).

Kan je dat is uitleggen "dns provider die srv-records ondersteunt" ? Hoe kunnen we dan de certs van exchange en lync opvangen ?

[Paul]

Lync ken ik niet zo goed, maar voor Exchange zijn er een aantal manieren om autodiscover te regelen, en een daarvan is een RSV-record genaamd "autodiscover" dat wijst naar de webmail-host en poort 443. Je moet alleen zorgen dat autodiscover.domein.bla niet resolved (of naar 0.0.0.0, dat blijkt ook te werken, een van onze klanten had een wildcard DNS-entry...) en dat er geen /autodiscover (virtual) directory bestaat op http(s)://domein.bla

[ Voor 12% gewijzigd door Paul op 11-05-2016 16:01 ]