Gezocht: Overzicht hosting producten

[LittleBit]

Voor meerdere domains zoek ik webhosting mogelijkheden.

Een resellerpakket met virtual hosting lijkt me dan interessant.

Diverse partijen bieden daaromtrent diensten aan.

En eerlijkheidshalve zitten daar ook prijsgunstige oplossingen bij van slechts enkele euris per maand.

Echter.... als ik dieper spit zie ik dat bv Versio standaard geen https-mogelijkheid bied.

Dan moet je een extra SSL-certificaat en een extra dedicated IP-adres ( 100 EUR/jr ) afnemen.

Prijstechnisch betekent dat dat je abonnement ineens 3x zo duur wordt.

Vervelend is ook dat je op de website van de provider niet zomaar kunt vinden of er SSL bij zit

en/of wat daarvan de meerprijs is.

Bij een webhosting vergelijker als http://www.webhosters.nl kan ik wel filteren op capaciteit

en sorteren op prijs maar ik kan helaas niet op SSL filteren.

Bij de vergelijkingssite www.ispgids.com kan ik SSL selecteren maar dan zitten bv ook de Versio pakketten bij de oplossingen omdat daar SSL optioneel te bestellen is en dat is dus eigenlijk vals spelen omdat het een kale prijs is.

 

Kortom Weet iemand een vergelijking van reseller hosting abonnementen waarbij ik kan zien welke provider SSL meelevert en waar ik fair de prijzen (incl SSL-opties) kan vergelijken ?

 

 

[PimEffting]

Het is normaal dat er voor https ondersteuning een SSL certificaat moet worden gekocht. Dit is namelijk onderdeel van hoe het systeem werkt. Zonder certificaat, zal https een foutmelding geven (er moet een gevalideerd certificaat zijn geïnstalleerd).

 

Een belangrijkere vraag is: wat wil je bereiken met je webhosting?

Wat vind je zelf belangrijk?

Denk aan:

- Beschikbaarheid van dienstverlening

- Klantenservice (telefonisch of alleen email)

- Niveau van service (alleen een "veelgestelde vragen", copy&paste antwoorden of echt meedenken met de klant)

- Professionaliteit van de organisatie (vind je het erg als je een paar broekies van 18 aan de lijn krijgt?)

- Wil je zelf backups maken of wil je dat de provider dat oplost?

- Welk budget had je zelf voor ogen?

 

Je zult begrijpen dat enkele van de vragen samenhangen met de vraag over budget ;-)

Met resellerhosting zou ik oppassen omdat de provider hierbij vaak een bepaald kennisniveau van de klant vereist.

Oftewel: als je de provider nodig heeft kunnen ze "niet thuis" geven (denk aan backups bijvoorbeeld).

 

Als je bovenstaande vragen invult wil ik je graag een paar partijen opnoemen.

[fvddungen]

Ga er maar van uit dat geen enkele provider standaard ssl aanbiedt en dat het dus altijd optioneel is. Ssl vereist zoals Pim al zegt een certificaat welke ook niet echt goedkoop is. En in een shared hosting omgeving is een apart ip-adres ook wel een vereiste omdat https aan ip-adres is gebonden en niet aan host header name zoals bij gewoon http.

[Raoul K]

Een ssl kan sowieso niet op meerdere domeinen. Per domein, een certificaat. Of op subdomeinen een wildcard. (wildcard normaal ook duurder)

[LittleBit]

@Pim

> Het is normaal dat er voor https ondersteuning een SSL certificaat moet worden gekocht.

Dat iemand dat moet kopen is mij duidelijk

maar net zoals de provider ook de server betaald, kan deze ook het SSL-certificaat betalen, toch ;-)

De vraag is feitelijk dat ik niet simpel vooraf kan zien of dat SSL prijstechnisch al in de abo aanbieding zit.

 

@Frank

> Ga er maar van uit dat geen enkele provider standaard ssl aanbiedt

Momenteel heb ik ook webhosting bij Denit.net en die bieden dat toch echt standaard aan.

 

@Raoul

> Een ssl kan sowieso niet op meerdere domeinen

Ik heb een web provider welke het standaard aanbied (zie hierboven),

voor alle domeinen die ik binnen dat abonnement aanmaak.

en ik heb nu een provider welke SSL-optioneel aanbied,

en waarbij de SSL-optie dan geldt voor mijn abonnement

en ik mag aannemen dus voor alle domeinen welke binnen dat abonnement worden aangemaakt.

Dus het lijkt me dat 1 SSL voor meerdere domeins kan.

 

Maar het komt mij dus zo onduidelijk over

en ik zie ook geen enkele website van een webhostingprovider

waarbij simpel een SSL-optie-prijs wordt genoemd,

blijkbaar moet je dat pas gaan ontdekken nadat je het abonnement al hebt afgesloten.

En daarbij blijkt een SSL-optie (SSL-certificaat+extra dedicated IP-adres) soms duurder te zijn dan het abonnement zelf.

 

[HCS Legal (Heleen)]

ssl voor meerdere domeinen kan wel, maar een certificaat voor meerdere domeinen niet. Een certificaat wordt gekoppeld aan een (sub-)domein. ssl is de techniek, een certificaat is de sleutel.

 

ssl zonder certificaat geeft een melding voor bezoekers, en dat is voor (potentiële) klanten ongewenst. Als het alleen is om jouw inlog voor een cms te encrypten, is dat niet zo erg. Dan voeg je eenmalig een uitzondering in de browser toe.

 

Overigens zijn certificaten te koop vanaf een euro of 10 (die geen melding geven), maar kijk wel of ze voor jouw doel geschikt zijn.

 

Een hostingpartij kan dus nooit vooraf een certicaat installeren voor alle domeinen die ooit op een server gehost worden.

[willemj]

Bij de standaard shared hosting van je provider staat dat ssl een optie is.

 

Zoals gezegd is dat zo'n beetje de standaard. Het standaard aanbieden van SSL inclusief certificaat is helemaal niet handig. Er zijn namelijk veel verschillende typen SSL-certificaten die varieren in prijs van zeg 20 euro tot 100 euro. Daarnaast hoort een provider meer resources (met name cpu, of speciale hardwarematige ondersteuning) te reserveren op een server met sites die SSL gebruiken. Niet handig als slechts een fractie van de sites er gebruik van maakt.

 

De enige variant die ik ooit gezien heb waar je kant & klare SSL, dus inclusief een certificaat, op je site hebt is met een url van de provider. Dus iets als https://ssl.provider.nl/mijn_domein_naam/ Voor beveiligde backend toepassingen voldoende maar ziet er wat vreemd uit voor je klanten.

 

Maar als SSL het enige punt is dat je mist kun je toch een pakketselectie doen en voor de top tien even checken wat SSL kost? Kan nooit veel langer duren dan de tijd die je nu besteed hebt aan het typen van deze vraag ;)

 

 

[Jerry van de Beek]

SSL zegt iets over de manier waarop verbinding wordt gelegd (beveiligd). En beveiligen van de verbinding doe je m.b.t. een certificaat.

 

Bij mijn weten is een SSL certificaat (sub)domeingebonden. Maar een certificaat over meerder domeinen weet ik het bestaan niet van.

 

Er zijn wel verschillende varianten in SSL certificaten:

 

1) kwa (sub)domeinnaam gebruik.

2) kwa veiligheidsnivo (128bits,256,1024 etc)

 

Hoe hoger het veiligheids nivo, hoe hoger de prijs.

 

Verder zijn er wereldwijd een vrij een beperkt aantal instanties die certificaten uitgeven. Veel hosting providers moeten deze certificaten inkopen bij deze instanties: Geotrust, Thawte, Verisign. Dus al kunnen ze goedkoop een hostingpakket / abonnement aanbieden, dan zitten ze nog steeds aan de forse inkooptarieven voor een certificaat vast.

Waaschijnlijk ben ik er nog een aantal vergeten, maar het zijn er niet echt veel.

 

 

 

[LittleBit]

Ter aanvulling:

> Momenteel heb ik ook webhosting bij Denit.net en die bieden dat toch echt standaard aan.

Als ik daar ga testen, dan werkt het wel maar dan krijg ik de melding dat het geen betrouwbaar certificaat is

(is dat een self-signed certificaat wellicht).

Dus mijn eerdere opmerking dat Denit het standaard gratis meeleverd moet ik nu gaan terugnemen.

 

Bij webhosting provider Denit kan ik SSL-certificaten zelf toevoegen (die ik elders kan inkopen)

maar bij webhosting provider Versio moet ik eerst een extra dedicated IP-adres aankopen

alvorens ik SSL-certificaten kan toevoegen.

 

Eigenlijk gek dat we in deze thread https/ssl duidelijkheid moeten zoeken

terwijl dit iets is wat me eerder een taak lijkt voor de webhostingproviders zelf

of wat webhosting-vergelijkingssites zouden kunnen doen.

 

Maar goed, als er nog ervaringen zijn inzake https/SSL-gebruik bij webhosting, dan horen we hier graag.

 

[LittleBit]

 

Willem schreef:

> Maar als SSL het enige punt is dat je mist

> kun je toch een pakketselectie doen en voor de top tien even checken wat SSL kost?

 

@Jerry en @Willem

Jullie verhaal is duidelijk.

 

Als je voor httpS/SSL een optioneel certificaat nodig hebt dan moet je dat erbij kopen.

Volgens mij ben je zelfs vrij om dat te kopen

(klopt het dat je een SSL-certificaat bij X kunt kopen

om het bij je webhosting-provider Y te gebruiken ?)

 

Maar zoals ik aangaf is bij een provider als Versio ook een additioneel een dedicated IP-adres vereist ( E 100,-/jr )

en dat laatste lijkt me toch echt een keuze van de webhostingprovider

en geen verplichting voor een SSL-certificaat gebruik.

En ik zou dus niet weten hoe ik 'even' moet checken

wat er bij een pakket allemaal optioneel nodig is voor hhtpS gebruik.

Ik blijf wat worstelen met de onduidelijkheden daaromtrent.

 

[fvddungen]

Als je voor httpS/SSL een optioneel certificaat nodig hebt dan moet je dat erbij kopen.

Volgens mij ben je zelfs vrij om dat te kopen

(klopt het dat je een SSL-certificaat bij X kunt kopen

om het bij je webhosting-provider Y te gebruiken ?)

Dat kan niet eens anders. Er zijn maar paar partijen, die certificaten uitdelen. Je provider kan dat niet zelf doen, maar ik kan me wel voorstellen dat je provider dit graag zelf regelt, omdat deze dan weet wat precies nodig is.

 

Maar zoals ik aangaf is bij een provider als Versio ook een additioneel een dedicated IP-adres vereist ( E 100,-/jr )

en dat laatste lijkt me toch echt een keuze van de webhostingprovider

Tja, maar een certificaat koppel je aan een ip-adres. Als je gebruik maakt van een shared hosting pakket en je zou het certificaat koppelen aan dat ip-adres dan geldt het gelijk voor alle websites op die server en dat is niet echt wenselijk. Het wordt al helemaal lastig als een andere klant op dezelfde shared host ook gebruik wil maken van ssl/https en dus een certificaat wil aanschaffen. Dat kan dan dus niet. Dus op een shared hosting omgeving ontkom je er niet aan om een extra ip-adres te nemen. Als je een vps hebt, hoeft het niet perse.

 

Je hostingprovider weet heus wel waar hij mee bezig is, hoor. Ze doen het niet om jou onnodig op extra kosten te jagen.

 

[LittleBit]

@Fvddungen

 

> Tja, maar een certificaat koppel je aan een ip-adres.

> Als je gebruik maakt van een shared hosting pakket

> en je zou het certificaat koppelen aan dat ip-adres dan geldt het gelijk voor alle websites op die server

Als ik goed geluisterd heb naar andere reacties in deze thread dan geldt het SSL-certificaat zelfs voor slechts 1 domein.

Daarbij geldt het SSL-certificaat voor 1 IP-adres

maar een shared hosted pakket staat meestal al op een server met een vast IP-adres dus de noodzaak dat sommige webhosting providers je verplichten een optioneel dedicated IP-adres te kopen, ontgaat me nog even.

 

[LittleBit]

Begrijp ik jullie dan ook goed

dat als je een reseller webhosting abonnement (met bv 20 domeins waarvan 10 domeins met SSL-certificaat)

ooit gaat verhuizen naar een andere webhostingprovider,

dan je dan weer 10 nieuwe SSL-certificaten mag gaan kopen ?

 

[willemj]

maar een shared hosted pakket staat meestal al op een server met een vast IP-adres dus de noodzaak dat sommige webhosting providers je verplichten een optioneel dedicated IP-adres te kopen, ontgaat me nog even.

 

Dit klopt niet en snap je verwarring. IP adressen kosten geld (en ip v4 adressen zijn schaars) daarom bieden, met name de goedkopere hostingpartijen, standaard geen eigen ip-adres per website aan. Een eigen ip-adres is een eis voor een SSL-certificaat en dus moet je bij die partijen eerst een ip-adres 'kopen' voor je SSL kunt gebruiken.

 

De server heeft uiteraard wel een vast ip-adres maar meerdere sites delen dat adres.

[willemj]

dat als je een reseller webhosting abonnement (met bv 20 domeins waarvan 10 domeins met SSL-certificaat)

ooit gaat verhuizen naar een andere webhostingprovider,

dan je dan weer 10 nieuwe SSL-certificaten mag gaan kopen ?

 

Nee, je certificaat is gekoppeld aan je domeinnaam niet aan het ip-adres. Dat je niet meerdere domeinnamen met SSL op één ip-adres kunt gebruiken is een limitering van SSL.

 

(je kunt certificaten ook op je ip-adres zetten, dan zou je wel nieuwe certificaten moeten kopen, maar denk niet dat dat je bedoeling is)

[fvddungen]

maar een shared hosted pakket staat meestal al op een server met een vast IP-adres dus de noodzaak dat sommige webhosting providers je verplichten een optioneel dedicated IP-adres te kopen, ontgaat me nog even.

Bij een shared hosting omgeving deel je dat ip-adres met vele tientallen andere websites.

[LittleBit]

@Willem

 

> IP adressen kosten geld (en ip v4 adressen zijn schaars) daarom bieden,

> met name de goedkopere hostingpartijen, standaard geen eigen ip-adres per website aan

Dan ga ik wellicht weer iets doms zeggen:

Waarom bieden die dan geen IPv6 adres daarvoor aan, die zijn er in overvloed ?

 

[DannyvdM]

Dan sluit je een hele grote groep gebruikers uit die geen ipv4 kunnen gebruiken. ipv6 wordt erg traag ingevoerd. Hebt je het zelf al?

 

http://www.hetlab.tk/artikelen/ipv6-testpagina

 

Ik nog niet namelijk, einde van het jaar pas als het goed is.

[LittleBit]

@Frank

> Bij een shared hosting omgeving deel je dat ip-adres met vele tientallen andere websites.

Dat is mij duidelijk

maar is dat een knelpunt voor gebruik van de SSL-certicaten want die zijn toch gekoppeld aan 1 domain/website ?

[fvddungen]

Ja, dat is een knelpunt, want een ssl certificaat wordt op technisch vlak gekoppeld aan een ip-adres.

[LittleBit]

@Danny,

> Dan sluit je een hele grote groep gebruikers uit die geen ipv4 kunnen gebruiken. Hebt je het zelf al?

Jip, IPv6 is voldoende voer voor een aparte thread.

En wellicht zeg ik iets doms maar als ik een reseller webhosting abonnement overweeg,

dan wil ik enkele websites hosten en als dat hostingabonnement dan IPv6 is, so what ?

Alleen bij de DNS-config moet ik dan even opletten maar verder praat ik alleen in URL's of URI's

en hoeft dat IP-adres niet meer voor te komen. Toch ?

Volgens mij moet je een website zelfs van een server met IPv4 adres naar een server met Pv6/adres kunnen verplaatsen.

 

Als bovenstaande opmerkingen kloppen

zou het voor mij dus niets uitmaken of het nieuwe abonnement IPv6 gebaseerd is,

Integendeel, als dat betekent dat ik dan geen extra IP-adressen nodig heb voor SSL-gebruik,

zou het zelfs een voordeel kunnen zijn.

 

[HCS Legal (Heleen)]

Als je internet (access) provider geen ipv6 ondersteunt kan je alleen via een tunnel naar een ipv6 adres. Heb je dat niet, kan je met een ipv4 pc geen ipv6 adressen bezoeken. Dat scheelt op dit moment een groot gedeelte van je bezoekers.

[LittleBit]

 

Willem zegt:

> Nee, je certificaat is gekoppeld aan je domeinnaam niet aan het ip-adres.

 

En Frank zegt:

> een ssl certificaat wordt op technisch vlak gekoppeld aan een ip-adres.

 

Kunnen jullie dit toelichten ?

 

[HCS Legal (Heleen)]

Bij het installeren van het certificaat wordt dit gekoppeld aan een ip adres. Dat is bij een herinstallatie ook te koppelen aan een ander ip adres. De domeinnaam vast gekoppeld aan het certificaat; dat moet je bij aanschaf van het certificaat opgeven.

[Erik-]

Ik kan je niet concreet helpen met de vergelijking, maar ken wel de details van hoe HTTPS/SSL werkt en waarom.

 

Het doel van HTTPS

Met HTTPS (dat is HTTP met SSL er omheen) proberen we meestal twee zaken te bereiken: encryptie van de verbinding, zodat een derde die niet kan afluisteren, en verificatie van de website, zodat we zeker weten dat dat de legitieme website van LittleBit is. Als je die laatste stap overslaat, zou het veel minder effectief zijn: je weet dan wel dat de verbinding encryptie gebruikt, maar je weet alsnog niet zeker of jouw gegevens beveiligd naar LittleBit verstuurd, of naar iemand anders (zoals voor kan komen bij een zgn. man in the middle-attack).

 

Er is daarnaast ook nog een mogelijkheid om de gebruiker te authenticeren met zgn. client-certificaten, maar dat wordt maar heel weinig gebruikt.

 

De rol van het certificaat en CAs

Het encryptiedeel is, voor onze vragen, relatief eenvoudig. Lastiger is het verifieren van de identiteit van de website. Hoe weet ik immers zeker of een bepaald certificaat echt van LittleBit is, of dat het van iemand anders is die zich voordoet als LittleBit.

 

Daarvoor worden Certificate Authorities (CAs) gebruikt. Dit zijn organisaties die beloven de identiteit van anderen goed te controleren. Browsers en andere SSL-software heeft vaak een lange lijst van certificaten van CAs ingebouwd. Een CA kan vervolgens andere certificaten tekenen om aan te geven dat deze door die CA vertrouwd worden. Stel dat LittleBit een certificaat heeft dat geverifieerd is door Verisign, dan ziet mijn browser dat het certificaat dat de webserver van LittleBit stuurt, via een aantal tussenstappen, getekend is door Verisign. Omdat mijn browser gelooft dat Verisign dat vast goed gecontroleerd heeft, vertrouwt die vervolgens dat die website echt van LittleBit is.

 

In de praktijk doen we deze verificatie op domeinnaam. Als ik de eigenaar ben van littlebit.nl, kan ik naar Verisign gaan en zeggen "ik ben de eigenaar van littlebit.nl, doe mij een certificaat". Verisign zal vervolgens controleren of ik inderdaad de eigenaar ben, en dan mijn certificaat tekenen. De verificatie gebeurt dus op domeinnaam, en niet op IP-adres. Voor sommige certificaten controleert de CA ook mijn identiteit.

 

Er zijn een hondertal CA-certificaten bekend in een gemiddelde browser. Er zijn ook nog talloze resellers - dat is wat hosting providers doen die zelf certificaten aanbieden.

 

Koppeling aan IP-adres

Vroeger was het simpel: 1 website had 1 IP-adres. Als je een andere website wilde bouwen, deed je dat op een ander IP-adres.

 

Sinds een lange tijd hebben we de mogelijkheid om meerdere (niet-SSL) websites te hosten op 1 IP-adres. Dat gebeurt met de host-header. Als ik naar littlebit.nl ga, verbindt mijn browser met dat IP-adres. Vervolgens stuurt hij het verzoek voor de juiste URL, en stuurt daarbij in de host-header mee dat ik naar littlebit.nl wilde gaan. Op die manier, ook wel virtual hosting genoemd, kan de webserver dus onderscheiden welke website ik wil zien, ook al draaien er veel websites achter hetzelfde IP-adres.

 

Met SSL is dit echter een probleem. De opzet van de SSL-communicatie gebeurt voordat de browser de kans krijgt om de host-header te sturen, omdat alle HTTP-communicatie binnen de encryptielaag moet vallen. Dus totdat we de SSL-opzet hebben gedaan weten we niet welke website de gebruiker wilde zien, maar we kunnen pas de SSL-opzet doen met het juiste certificaat, als we weten welke website de gebruiker wil zien.

 

Hiervoor zijn een aantal oplossingen. Soms kan je dit oplossen met wildcard-certificaten, als alle websites onder hetzelfde domein vallen. Een andere oplossing is om elke SSL-website op een eigen IP te plaatsen: dan kunnen we immers aan de hand van het IP-adres waarop verbonden wordt, gokken welk certificaat er gebruikt moet worden.

 

Dan zijn er SSL-certificaten waar meerdere domeinnamen in opgenomen kunnen worden. Dit werkt in principe prima, maar heeft als nadeel dat je in één keer een certificaat aan moet vragen met alle namen. Later wijzigen is veel gedoe. Leuk voor twee websites in eigen beheer, maar complete chaos met honderden klanten.

 

De mooiste optie is Server Name Indication (SNI) waarmee de browser toch nog voor de SSL-opzet aan kan geven welke website hij graag wil zien. Dat is hele mooi, want het werkt eenvoudig en goed. Helaas ondersteunen niet alle browsers dit: het werkt niet op IE of Safari op Windows XP, het werkt niet op IE6, Blackberry, of Android 2.x.

 

Korte samenvatting: als je oudere browsers wil ondersteunen, is de enige optie een eigen IP-adres, omdat anders niet "op tijd" te achterhalen is welk certificaat er gebruikt moet worden, omdat de webserver niet weet welke website je probeert te bezoeken. Maar het certificaat is niet permanent gekoppeld aan dat IP.

 

Extended validation

Nu ik toch uitgebreid aan het schrijven ben, laten we dan ook even in gaan op extended validation (EV). EV is een vrij nieuw type certificaat. Het wil eigenlijk zeggen dat de CA extra veel moeite heeft gedaan om te bepalen dat jij de eigenaar bent, en wie jij dan precies bent. En daar extra veel voor betaald heeft gekregen.

 

In de meeste browsers verschijnt de naam van de organisatie in een groen balkje, of wordt op een andere manier aangeduid dat het EV is. Of dat de moeite waard is hangt van de gebruikers af, en hoeveel extra vertrouwen die daar aan geven.

 

Er wordt voor niet-EV soms ook onderscheid gemaakt tussen domeinvalidatie en organisatievalidatie, in het eerste geval staan er geen bedrijfsgegevens in het certificaat. In het tweede geval wel, maar dat is zo verstopt dat ik betwijfel of iemand het ooit ziet. Ik zie er geen meerwaarde in.

 

Veiligheid en vervalsen van certificaten

Een veel voorkomend misverstand is dat duurdere certificaten de website beter beveiligen. Dat is helaas niet waar. De browser vertrouwt namelijk elk certificaat waarbij de domeinnaam klopt en dat getekend is door een bekende CA.

 

Vorig jaar hebben, door een berg beveiligingsblunders, mensen ongeauthoriseerde SSL-certificaten voor o.a. gmail.com weten te maken door toegang te krijgen tot de CA van Diginotar. Dat is vermoedelijk op kleine schaal gebruikt om SSL-verkeer naar gmail af te luisteren: in plaats van naar de echte gmail wordt je naar een andere geleidt, die alles doorstuurd naar de echte gmail, maar intussen wel af kan luisteren. De neppe heeft gewoon een geldig SSL-certificaat voor gmail.com, getekend door Diginotar, een bekende CA, dus de browser vindt het allemaal prima.

 

Andere websites met een Diginotar-certificaat zijn dan ook helemaal niet onveiliger geworden. Wel is het verstandig om die certificaten niet meer te gebruiken, want na een dergelijk incident verdwijnt het Diginotar-certificaat heel snel uit allerlei browsers.

 

Kortom, het maakt niet per sé uit hoe hip jouw certificaat is: als er één CA in het lijstje van de browsers overtuigd kan worden om een onterecht certificaat uit te geven voor jouw domein, ben je alsnog het haasje. Daarna is het overigens alsnog verre van eenvoudig om verkeer af te luisteren of om te leiden, maar het is wel makkelijker geworden. EV kan je dan wel helpen als klanten oplettend genoeg zijn om te zien dat het nu "gewoon https" is in plaats van EV, maar ik betwijfel of ze dat zien.

 

In gevallen waarbij dit mis gaat wordt soms de hele CA verwijderd, vooral in bijzondere blunders als Diginotar. Soms wordt ook een sub-CA verwijderd, waardoor een specifiek soort certificaat van een CA niet meer vertrouwd wordt. Ook is het mogelijk om individuele certificaten als ongeldig te markeren door ze op een Certificate Revocation List (CRL) te plaatsen, maar ik weet niet hoe effectief dat tegenwoordig is.

 

Self-signed

Soms kom je self-signed certificaten tegen. Dat wil zeggen dat het op zich een prima certificaat is, maar dat het niet ondertekend is door een CA. Browsers zullen het dan ook, tenzij jij dat vraagt, niet vertrouwen. Voor de browser is dat niet anders dan een certificaat getekend door een CA die niet bekend is.

 

Andere toepassingen van SSL

SSL wordt lang niet alleen bij HTTPS toegepast: ook bij communicatie met mailservers wordt het vaak gebruikt (imaps, pop3s). Daar geldt in principe precies hetzelfde qua certificaten.

 

Wat voor certificaat moet ik nu kopen?

In principe voldoet elk certificaat waarvan de CA bekend is in alle browsers. Dat kan vanaf € 12 per jaar, en dat is dan alleen domeinvalidatie: is dit domein echt van jou. Ik zie niet zoveel waarde in organisatievalidatie, EV kan wel meerwaarde bieden door er betrouwbaarder uit te zien. Maar dat gaat dan ook snel naar € 250 per jaar.

 

Die € 12 gaat overigens puur om het laten tekenen van het certificaat door de CA: verwacht niet dat een hosting provider het voor die prijs aanbiedt. Er zit ook wat werk aan vast om de validatie te voltooien, en het moet ingesteld worden op de webserver. En ook aan extra IP-adressen zijn in principe gewoon kosten verbonden voor de hosting provider.

[Jerry van de Beek]

Compliment voor je uitleg Erik!

 

 

Die € 12 gaat overigens puur om het laten tekenen van het certificaat door de CA: verwacht niet dat een hosting provider het voor die prijs aanbiedt. Er zit ook wat werk aan vast om de validatie te voltooien, en het moet ingesteld worden op de webserver. En ook aan extra IP-adressen zijn in principe gewoon kosten verbonden voor de hosting provider.

 

Mag je dan zeggen dat het (prijstechnisch) handig is als je een flink aantal domeinen hebt (stel een stuk of 50) en je wilt die allemaal van een juist Certificaat voorzien, dat je de hostingproviders overslaat en rechtstreeks bij CA de certificaten afneemt ?