We hebben een nieuw boek uitgebracht, "Social Media Content Marketing: Hoe kom je in het hoofd van abonnees en laat ze verliefd worden op je merk."

De wereld is geobsedeerd door internetbeveiliging. Als u in de mode bent en uitsluitend correspondeert in Telegram, lees dan hoe u een beveiligde verbinding op de site tot stand brengt. Het komt in ieder geval goed van pas, en als je een webwinkel bent, dan kun je niet meer zonder. Laten we het onderweg hebben over certificaten: wat ze zijn en waarom ze nodig zijn.

Wat is HTTPS

Dit is een beveiligd verbindingsprotocol. Het versleutelt de informatie die wordt uitgewisseld tussen de server en de browser van de gebruiker - dit helpt wachtwoorden, creditcardnummers en e-mailadressen te beschermen. Het gebruik van HTTPS is sterk en maakt het een beetje aantrekkelijker in de ogen van zoekmachines - Google rangschikt veilige sites hoger dan onveilige. Om HTTPS op uw site in te schakelen, moet u eerst een SSL-certificaat op de server installeren.

Waarom je een SSL-certificaat nodig hebt

Het vormt een unieke digitale handtekening van de site, wat helpt om de verbinding te beveiligen. Zonder een SSL-certificaat kunt u het HTTPS-protocol niet krijgen, hoe hard u ook probeert. Het bevat:

• site domein;
• de volledige wettelijke naam van het eigenaarsbedrijf;
• het fysieke adres van het bedrijf;
• geldigheidsduur van het certificaat;
• Details van SSL-ontwikkelaars.

Je hebt ook een certificaat nodig om verbinding te maken met een betalingssysteem, zoals Yandex.Money. De logica is simpel: niemand zal je het geld van andere mensen laten riskeren.

Hoe kies je een SSL-certificaat

Ze zijn onderverdeeld in twee typen, afhankelijk van de mate van bescherming en.

Domeinvalidatie SSL

De gemakkelijkste optie. Het werkt nadat u het eigendom van het domein heeft geverifieerd. U kunt dit op drie manieren doen:

• Via e-mail. U ontvangt een e-mail met verificatie-instructies. Ofwel e-mail van het Whois-domein, ofwel mailboxen van de beheerder of webmaster worden als verzendadres geselecteerd.

• Via een DNS-entry. Als u een e-mailserver hebt ingesteld, maakt u een aangepast DNS-item. Volgens het systeem zal het systeem bevestigen dat u echt de eigenaar van de site bent. De methode is geautomatiseerd en geschikt voor degenen die Whois-mail in de instellingen hebben verborgen.

• Via het hashbestand. Plaats een speciaal .txt-bestand op uw server zodat de certificeringsinstantie het bestaan ​​ervan kan vaststellen.

Een dergelijke verificatie is geschikt als u een persoonlijke blog of een klein offline bedrijf heeft, omdat u hiermee geen subdomeinen kunt beschermen en geen financiële transacties kunt uitvoeren. Bovendien, om de zuiverheid van het domein en uw gedachten te bevestigen, hoeft u niets ingewikkelds te doen en is het voltooide certificaat snel klaar.

Zakelijke validatie

Dit type SSL-certificaat is veiliger omdat u bevestigt dat het bedrijf is verbonden met de site. Om dit te doen, moet u verschillende documenten naar het verificatiecentrum sturen en een oproep ontvangen naar het bedrijfsnummer. Bedrijfsvalidatiecertificaten zijn onderverdeeld in 3 soorten:

• Uitgebreide validatie SSL. Dit zijn uitgebreide validatiecertificaten. Ze zijn nodig voor iedereen die met veel geld werkt: banken, grote webwinkels, financiële bedrijven, betalingssystemen.

• SSL met jokertekens. Een dergelijk certificaat beschermt zowel de site zelf als de subdomeinen. Bovendien kunnen er een willekeurig aantal zijn en ze kunnen zich op verschillende servers bevinden. Vereist als u subdomeinen gebruikt met verschillende regionale bindingen of verschillende projecten.

• SAN-SSL. Het grote voordeel van dit type certificaat is de ondersteuning van alternatieve domeinnamen: zowel extern als intern.

• Code-ondertekening SSL. Bevestigt de code en softwareproducten van de site. Geschikt voor ontwikkelaars van alle toepassingen.

Kan ik een gratis SSL-certificaat op mijn website installeren?

Ja. De meeste van deze producten zijn betaald, maar er zijn opties waarvoor je geen geld hoeft te betalen. Dit zijn basis-domeingevalideerde certificaten. Ze zullen je niet toestaan ​​om een ​​online kassa aan de bron te koppelen, maar ze zullen in staat zijn om de verbinding van de gebruiker met de server te beschermen. Dergelijke SSL's zijn geschikt voor kleine informatiesites of offline bedrijven. Een voorbeeld is het basis StartSSL-certificaat.

Een SSL-certificaat installeren

Eerst moet u een CSR-aanvraag voor een certificaat genereren. Het bevat alle informatie over de domeineigenaar en de publieke sleutel. Bij de meeste SSL-providers kunt u dit doen als onderdeel van het bestelproces voor certificaten, maar u kunt ook een verzoek aan de webserver-zijde genereren.

Bij het genereren van een CSR-sleutel moet u het volgende specificeren:

• Servernaam: "site.com" of "*.site.com" als u een WIldcard-certificaat krijgt. De asterisk betekent een willekeurig aantal tekens vóór de punt.
• Landcode: RU, UA, KZ enzovoort.
• Regio, bijvoorbeeld Saratov Region.
• Dorp.
• De volledige naam van de organisatie of de naam van de site-eigenaar.

Het CSR-verzoek wordt naar het verificatiecentrum gestuurd. Als resultaat krijg je een SSL-certificaat en een bestand met een privésleutel die niet verloren kan gaan en in het publieke domein kan worden geplaatst.

Daarna moet u het certificaat op de webserver installeren. Overweeg de gevallen met Apache en nginx.

Apache

Om dit te doen, moet u alle certificaten uploaden naar de server: zowel primair als intermediair. Allereerst heb je de laatste nodig in de /usr/local/ssl/crt directory (standaard gebruikt, in jouw geval kan het verschillen). Alle certificaten worden erin opgeslagen.

Download daarna het hoofdcertificaat, open het in een teksteditor en kopieer de volledige inhoud samen met de regels "BEGIN" en "END".

Maak in de /ssl/crt/ map een bestand met de naam vashsite.crt en plak de inhoud van het certificaat erin.

Verplaats het privésleutelbestand naar de /usr/local/ssl/private/ directory

Voeg in het VirtualHost-bestand de regels toe:

SSL-engine aan

SSLCertificateKeyFile /usr/local/ssl/private/private.key

SSLCertificateFile /usr/local/ssl/crt/uwsite.crt

SSLCertificateChainFile /usr/local/ssl/crt/intermediate.crt

U moet geldige paden naar bestanden opgeven. Sla uw wijzigingen op en start de server opnieuw op.

nginx

Hier is het proces van het installeren van een SSL-certificaat iets anders. Eerst moet u de root-, intermediate- en SSL-certificaten combineren tot één. Maak hiervoor een bestand aan met de naam vashsite.crt en plak de inhoud van de certificaten daar samen met de regels "BEGIN" en "END" (volgorde: SSL, intermediate, root). Er mogen geen lege regels zijn.

Bijna hetzelfde moet worden gedaan met de privésleutel - maak een vashsite.key-bestand en breng de inhoud van de sleutel over die is gedownload van de website van de provider.

Plaats beide bestanden (uwsite.crt en uwsite.key) in de /etc/ssl/ directory (dit is de standaard maar kan variëren).

Bewerk VirtualHost in het configuratiebestand. Toevoegen:

server(
luister 443;
ssl aan;

ssl_certificaat /etc/ssl/uwsite.crt
ssl_certificate_key /etc/ssl/uwsite.key;
servernaam uwsite.com;

Als de map met het certificaat en de sleutel verschilt van de standaardmap, wijzigt u deze.

Sla nu uw wijzigingen op en start nginx opnieuw.

Een werkende HTTPS-verbinding krijgen

Na het installeren van SSL-certificaten is de site beschikbaar op twee adressen: http://yoursite.com en https://yoursite.com. Je hoeft alleen de laatste te bewaren. Om dit te doen, stelt u een robots.txt-bestand in en maakt u een 301-omleiding vanaf de oude site.

In "robots" moet je host updaten. Voorbeeld: Host: https://uwsite.com. Om een ​​omleiding in te stellen, moet je de regels toevoegen aan het .htacsess-bestand:

Herschrijfvoorwaarde %(SERVER_PORT) !^443$

RewriteRule ^(.*)$ https://uwsite.com/$1 .

Nu rest het nog om de zoekmachines te informeren over de wijzigingen. Voeg in de "Webmaster" van "Yandex" een pagina toe met https en specificeer deze als de hoofdpagina voor de oude site.

Resultaten

We hebben uitgezocht wat https is, hoe je het op je site installeert en hoe je alles correct instelt. Dit protocol is al de verbindingsstandaard geworden en na verloop van tijd zullen alle live-sites hierop overschakelen. Dit proces wordt aangemoedigd door zoekmachines - de aanwezigheid van een gevestigd protocol voor beveiligde HTTPS-verbindingen is een van de rangschikkingsfactoren geworden. Daarom, als je de top wilt bereiken, moet je het installeren.

Goed nieuws in november 2016 voor onze lieve klanten en sitegebruikers. Onze online winkel staat niet stil en actualiseert regelmatig niet alleen het assortiment productaanbiedingen, maar breidt ook de functionaliteit van de site, de veiligheid voor gebruikers en de betekenis ervan in het wereldwijde internetsysteem uit. Dus op 26 september 2016 ontving de online winkelsite een SSL-certificaat met uitgebreide verificatie, en vanaf 1 november 2016, na het testen en verbeteren van de algoritmen van het werk, hebben we betalingssystemen op de site aangesloten!

Laten we nu eens nader kijken naar de noodzaak van deze acties en welke voordelen hebben onze dierbare klanten hiervan?

Het belangrijkste visuele voordeel dat elke klant kan opmerken, is de mogelijkheid om ONLINE met een bankkaart te betalen voor elke bestelling in onze online winkel en deze naar een handig adres te brengen. Wat betreft het interne, verborgen voordeel van site-updates: een SSL-certificaat is een speciale manier om een ​​site te versleutelen tussen het wereldwijde internet, een browser en een sitegebruiker, met andere woorden, de site is nu beschermd tegen de mogelijkheid van aanvallen en nemen uw betalings- (en zelfs contactgegevens) van derden. Om een ​​SSL-certificaat te verkrijgen, moest onze site een controle doorstaan ​​van het echte bestaan ​​van de organisatie, een bevestiging van ontvangst en binding van het certificaat aan het domein, en integratie van het nieuwe beveiligde sitesysteem in de site die bekend is bij iedereen op de online winkel. Vanaf nu kunnen gebruikers van onze site volledig vertrouwen op de veiligheid van het gebruik van onze handige en moderne site, aankopen doen en niet bang zijn om hun gegevens naar derden te lekken.

Trouwens, we staan ​​ook niet stil bij het uitbreiden van de mogelijkheden om onze bestellingen te ontvangen, en sinds het najaar van 2016 bieden we onze klanten de mogelijkheid om bestellingen te ontvangen met nieuwe bezorgmethoden - door de koeriersdienst SDEK en via inPost pakket terminals. Beide diensten zijn aanwezig in veel grote steden van Rusland, de kosten van hun diensten zijn zeer democratisch en de snelheid van het werk verbaast soms zelfs liefhebbers van dure en hoogwaardige koeriersdiensten! We raden je aan om nieuwe verzendmethoden te proberen, het zal je tijd en geld besparen en je een prettige ervaring geven bij het ontvangen van goederen.

Onze online winkelsite is een modern, zich dynamisch ontwikkelend bedrijf en biedt onze klanten de modernste en veiligste methodes om te betalen en om onze bestellingen te ontvangen. Blijf op de hoogte voor updates die groots en wereldwijd zullen worden, zowel om het assortiment uit te breiden als om meer kansen te bieden aan onze dierbare klanten !!

U kunt een bedrijf klein beginnen. Organiseer bijvoorbeeld de doorverkoop van domeinen en SSL-certificaten. U vindt klanten voor bestaande verkopers en wordt beloond in de vorm van kortingen en marges - met andere woorden, wordt wederverkoper. Met behulp van de ISPsystem-software kunt u snel doorverkoopdomeinen en SSL-certificaten instellen.

Belangrijk! We raden aan om niet met de technische implementatie te beginnen, maar met het businessmodel en de juridische kant van de zaak. Bepaal de doelgroep en manieren om deze aan te trekken, ontwikkel een prijsbeleid dat gunstig is voor u en uw klanten. Leer het juridische en boekhoudkundige kader. Pas daarna gaat u over tot de technische uitvoering van het plan.

Wat je nodig hebt om te beginnen

Om reseller van domeinen en SSL-certificaten te worden, heeft u het volgende nodig:

1. virtuele server (VPS/VDS),
2. overeenkomst met verkopers van domeinen en SSL-certificaten,
3. overeenkomst met het betalingssysteem,
4. factureringsplatform voor het ontvangen van betalingen,
5. site voor de verkoop van diensten.

Software installeren en configureren

Om domeinen en SSL-certificaten door te verkopen, moet u BILLmanager installeren op een gehuurde virtuele server.

Integratie met domein- en SSL-leveranciers

Gebruik voor het opzetten van de integratie de gegevens van het domein en SSL-leveranciers waarmee u een overeenkomst heeft. Meestal vereist de integratie een API-toegangs-URL, een resellercode en een API-autorisatiesleutel. Gegevens kunnen per bedrijf verschillen.

Daarna in BILLmanager in het menu integratie - Serviceverwerkers u kunt een wederverkoop opzetten.

U kunt ook beginnen met het doorverkopen van SSL-certificaten via ISPsystem. U hoeft niet rechtstreeks met de registrar te onderhandelen. Om dit te doen, selecteert u in het gedeelte "Serviceprocessors" BILLmanager 5 en voert u uw persoonlijke accountgegevens in mijn.ispsystem.com.

Koppeling van betalingssystemen

Stel betaalmethoden in om klanten voor services te laten betalen. BILLmanager bevat meer dan 30 modules betaling: Yandex.Money, WebMoney, PayMaster, Qiwi, PayPal, Bankoverschrijving en anderen.

Om met een bepaald betalingssysteem te kunnen werken, moeten u en uw klanten een rekening of een rekening in dit systeem hebben. Dus kies het meest populair Diensten. Om de integratie op te zetten heb je gegevens van het betalingssysteem nodig: portemonneenummer en geheime sleutel.

Klanten zullen geld van hun rekening naar de uwe overmaken. De ontvangst van het geld wordt weergegeven in uw account en klantaccount in BILLmanager.

Om betalingen van particulieren te accepteren, kunt u eenvoudige elektronische systemen zoals Yandex.Checkout of WebMoney aansluiten. Rechtspersonen betalen voor diensten via bankoverschrijving volgens de factuur, dus om met hen te werken, sluit u de betalingsmethode aan Bankoverschrijving (Russische bank). Voer de bankgegevens van uw organisatie in. Koppeling met betalingssystemen.

Documentsjablonen instellen

BILLmanager heeft vooraf geïnstalleerde documentsjablonen: facturen, certificaten van voltooiing van het werk, afstemmingscertificaten, servicecontracten, bijlagen bij het contract. Bewerk ze volgens uw servicevoorwaarden.

Om te voldoen aan de wettelijke vereisten, maakt en publiceert u op uw site Privacybeleid en Gebruiksvoorwaarden. Voeg een link naar deze documenten toe in het menu Instellingen - Merkinstellingen - auteursrechten. Volg bij het opstellen van een beleid voor de verwerking van persoonsgegevens de aanbevelingen van Roskomnadzor. Document- en berichtsjablonen instellen

E-mail- en berichtsjablonen instellen

BILLmanager bevat meer dan 60 e-mailsjablonen. Klanten krijgen brieven bij inschrijving, bestelling van diensten, facturatie. Facturering laat u weten wanneer de service verloopt. U kunt ook sjablonen instellen voor sms-berichten en massamailings. In het paneel kunt u het type berichten wijzigen.

Integratie met de site instellen

Website-integratie

Om diensten te verkopen, moet informatie over hen openbaar worden gemaakt. Als u een website heeft, stelt u de weergave van services daarop in. Maak tariefafbeeldingen en -beschrijvingen en genereer in BILLmanager een link naar een specifiek tariefplan met de gewenste betalingstermijn. Bij het klikken op de link wordt de gebruiker onmiddellijk naar de aankooppagina van het geselecteerde product geleid. BILLmanager-integratie configureren met de site

Kaarten van goederen en diensten

Met de tool Showcase plaatst u snel tarieven op de site. Met de tool kunt u een kaart van een of meer services aan de site toevoegen, zodat de gebruiker die kan selecteren en bestellen. De prijzen in de kaarten worden automatisch bijgewerkt.

Om een ​​kaart toe te voegen, moet u een speciaal script plaatsen op de plaats waar u deze wilt weergeven. U vindt het script in de documentatie: Een etalage integreren in een bestaande site.

branding

Als klanten van uw site naar hun persoonlijke account in BILLmanager gaan, kunnen ze een discrepantie voelen: de site en de facturering zijn anders ontworpen, het factuuradres bevat het IP-adres van de server en verschilt van het siteadres.

Om de stijlen te 'levelen', voltooit u de merkinstellingen: voeg uw logo toe aan de facturering, wijzig de kleur van de interface, publiceer links naar de site. Om ervoor te zorgen dat de facturerings-URL niet verschilt van de website, configureert u het adres voor BILLmanager . CloudLite heeft bijvoorbeeld een websiteadres cloudlite.com, factuur adres - mijnvdc.cloudlite.ru.

Sinds kort hebben we met benijdenswaardige regelmaat te maken met HTTPS/SSL. Maar elke keer dat een project als dit opduikt, slaag ik erin om te vergeten hoe het is gedaan. Om het gemakkelijker te maken om kennis in het geheugen te herstellen, besloot ik materiaal van hieruit te vertalen. Geleidelijk aan verwijderde de vertaling zich echter van het origineel.

SSL is een reeks protocollen voor het tot stand brengen van een versleutelde verbinding tussen twee partijen die gegevens willen uitwisselen. Dit is een uitwisseling waarbij de verbindende partijen overeenkomen welke versleutelingsmechanismen elk van hen ondersteunt, welke sleutellengte te gebruiken, versleutelingsmodi, certificaten worden uitgewisseld, een asymmetrisch versleutelingsalgoritme wordt gebruikt om een ​​symmetrische versleutelingsprotocolsleutel uit te wisselen, die vervolgens wordt gebruikt in verdere interactie. Deze initiële gegevensuitwisseling wordt een handshake genoemd.

De symmetrische sleutel wordt gegenereerd tijdens de handshake en is slechts geldig voor één SSL-sessie. Als de sessie niet actief blijft, wordt de sleutel verouderd (verlopen). De maximale tijd waarna een SSL-sessie verloopt, kan worden ingesteld. Nadat een sessie is verlopen, moet de handdruk vanaf het begin opnieuw worden geprobeerd. Het resultaat van de sessie-setup is een nieuwe symmetrische sleutel.

Certificaten en sleutels

Voordat we ingaan op de details van SSL, moeten we het concept van sleutels en certificaten introduceren. SSL/TLS gebruikt asymmetrische codering voor authenticatie en voor het uitwisselen van een symmetrische sleutel die zal worden gebruikt om gegevens te coderen tijdens een sessie.

Gebruik van asymmetrische encryptie paar sleutels voor codering, een privésleutel en de bijbehorende openbare sleutel. Gegevens die met één sleutel zijn versleuteld, kunnen worden ontsleuteld met een gekoppelde sleutel. Evenzo kunnen gegevens die met één sleutel zijn ondertekend, worden geverifieerd met een tweede sleutel. De privésleutel moet, zoals de naam al doet vermoeden, geheim worden gehouden.

Certificaten.

Een certificaat bestaat uit een openbare sleutel, samen met enkele informatie die de eigenaar identificeert, en een vervaldatum voor de sleutel. Het certificaat bevat ook een digitale handtekening van de organisatie die het certificaat heeft uitgegeven (certificeringsinstantie CA). De digitale handtekening zorgt ervoor dat er niet met het certificaat is geknoeid. Het certificaat wordt meestal uitgegeven aan een webserver, applicatie of gebruiker. Een certificaat is een manier om een ​​openbare coderingssleutel te verspreiden.

Als de client het bericht versleutelt met de openbare sleutel van de server (van het servercertificaat), kan de client er zeker van zijn dat alleen een legitieme server het bericht kan ontcijferen. Tijdens het opzetten van een SSL/TLS-sessie genereert de client een deel van de sessiesleutel, versleutelt het bericht met de openbare sleutel van de server en stuurt het naar de server. Als de server is wie hij beweert te zijn, kan hij het bericht ontsleutelen met behulp van de privésleutel en de sessiesleutel uit het bericht halen.

Er zijn twee soorten certificaten.

• Officieel uitgegeven certificaten ondertekend door de certificeringsinstantie
• Zelfondertekende certificaten

Zelfondertekende certificaten zijn certificaten die zijn geïntroduceerd om te testen, zodat ontwikkelaars hun software kunnen testen zonder te wachten op een officieel ondertekend certificaat. Een zelfondertekend certificaat is anders omdat de authenticiteit ervan niet kan worden geverifieerd, tenzij u het persoonlijk hebt gemaakt of op digitale media hebt ontvangen van een vertrouwde bron. Anders zijn zelfondertekende certificaten precies hetzelfde als officiële. Programmatisch kunnen ze op precies dezelfde manier worden gebruikt.

Vertrouwen

Het sleutelconcept van een SSL-verbinding is het concept van vertrouwen in een certificaat. Van belang is de manier waarop het voor de verbinding gebruikte certificaat wordt verkregen. Als u een certificaat krijgt van een vertrouwde bron, zoals de eigenaar van de site, kunt u er zeker van zijn dat het certificaat echt is en dat u daadwerkelijk verbinding maakt met de echte site. Wanneer u echter een verbinding tot stand brengt vanuit bijvoorbeeld een webbrowser, kan het servercertificaat worden verkregen van de server waarmee u verbinding maakt. Er is een kwestie van echtheid van het certificaat. Wat als de hacker zijn eigen asymmetrische sleutelpaar heeft gemaakt en vervolgens zijn eigen certificaat heeft gemaakt om de server van de bank te vervalsen?

Vertrouwensmodel, eenvoudig. Elke client of server besluit dat hij bepaalde organisaties (certificaatautoriteiten (CA)) die certificaten uitgeven, vertrouwt. Een CA vertrouwen is erop vertrouwen dat alle door de CA uitgegeven certificaten legitiem zijn en dat de identificerende informatie in het certificaat correct en betrouwbaar is. Verisign is een voorbeeld van een CA die veel certificaten ondertekent voor grote internetbedrijven. Alle browsers vertrouwen standaard op Verisign. De identiteitsgegevens van het certificaat bevatten een door de CA gegenereerde digitale handtekening. De client of server vertrouwt de CA door het certificaat toe te voegen aan een opslagbestand met de naam 'truststore'. Door het CA-certificaat in de truststore op te slaan, kan java de digitale handtekening van het door de CA gegenereerde certificaat controleren en beslissen of het certificaat al dan niet wordt vertrouwd.

Als een hacker een nepcertificaat voor Barclay's Bank plaatst, zal uw browser proberen de digitale handtekening van het certificaat te verifiëren. Deze controle mislukt omdat er geen certificaat in de truststore is waarmee het certificaat van de aanvaller is ondertekend.

Certificaatketen

In de praktijk is het formaat van certificaten zodanig dat meerdere handtekeningen in een certificaat kunnen worden opgenomen. Het certificaat slaat niet één handtekening op, maar een bepaalde “Certificaatketen”

Wanneer privé- en openbare sleutels worden gegenereerd, wordt automatisch een zelfondertekend certificaat gegenereerd voor de openbare sleutel. Die. in eerste instantie krijg je een privésleutelpaar en een certificaat met een ondertekende openbare sleutel. Een zelfondertekend certificaat is een certificaat waarin de maker van de sleutel en de ondertekenaar dezelfde persoon zijn.

Later, na het genereren van een Certificate Signing Request (CSR) en het ontvangen van een reactie van de Certification Authority (CA), wordt het zelfondertekende (zelfondertekende) certificaat vervangen door een certificaatketen (Сertificate Chain). Een certificaat van de CA wordt aan de keten toegevoegd, waarmee de authenticiteit van de openbare sleutel wordt bevestigd, gevolgd door een certificaat dat de authenticiteit van de openbare sleutel van de CA bevestigt.

In veel gevallen is het laatste certificaat in de keten (waarbij de openbare sleutel van de CA wordt geverifieerd) zelf ondertekend. In andere gevallen kan de CA op haar beurt niet één maar een keten van certificaten retourneren. In dit geval is de eerste in de keten de openbare sleutel die is ondertekend door de CA die het certificaat heeft uitgegeven, en het tweede certificaat kan het certificaat van een andere CA zijn ter authenticatie van de openbare sleutel van de eerste CA waarnaar het ondertekeningsverzoek is verzonden. Dit wordt gevolgd door een certificaat dat de authenticiteit van de openbare sleutel van de tweede CA bevestigt, enzovoort. totdat de keten eindigt met een zelfondertekend rootcertificaat. Elk certificaat in de keten verifieert de openbare sleutel van het vorige certificaat in de keten.

Laten we SSL eens nader bekijken. Er zijn twee soorten SSL-verbindingen.

Eenvoudige authenticatie (1 manier SSL-authenticatie)

Verificatie moet worden uitgevoerd voordat een versleutelde SSL/TLS-verbinding tot stand kan worden gebracht. Om een ​​eenvoudige verbinding tot stand te brengen, moet een private key-server worden geïnstalleerd waarvoor een certificaat is verkregen. De klant moet ook een lijst bijhouden van CA's die hij vertrouwt.

De client verifieert de server voordat een versleutelde verbinding tot stand wordt gebracht.

2-weg SSL-authenticatie

Met dit type authenticatie leveren zowel de server als de client certificaten om elkaar te authenticeren voordat een versleutelde verbinding tot stand wordt gebracht.

Certificaatverificatie

Bij eenrichtingsauthenticatie (het eerste type) heeft de server een certificaat met een gekoppelde privésleutel. Gegevens die zijn versleuteld met de openbare sleutel van de server kunnen worden ontsleuteld met de privésleutel van de server. Een client die een verbinding met een server tot stand wil brengen, verifieert het certificaat van de server voordat hij verder gaat met het tot stand brengen van een versleutelde verbinding. De klant dient het volgende te controleren:

• Is het certificaat nog geldig (of het certificaat is verlopen (vervaldatum verstreken))
• Het door de server verstrekte certificaat komt inderdaad overeen met de hostnaam.
• Staat de uitgever van het CA-certificaat op de lijst die de client vertrouwt?
• Controleer de digitale handtekening op het certificaat

Andere kleine details worden ook gecontroleerd, zoals het coderingsalgoritme voor digitale handtekeningen, sleutellengtes, enz.

Bij 2-way authenticatie zijn zowel de client als de server eigenaar van de private sleutels en certificaten. Beiden controleren elkaars certificaten voordat ze een versleutelde verbinding tot stand brengen. De client doet de hierboven beschreven controles en de server doet hetzelfde met het clientcertificaat.

Handtekeningverzoek en certificaatondertekening

Het aanmaken van sleutels en certificaten wordt gereguleerd door standaarden.

Sleutels worden gegenereerd volgens PKCS….

Wanneer een openbaar/privé-sleutelpaar wordt gegenereerd, wordt een certificaataanvraagobject genaamd Certificate Signing Request (CSR) gemaakt, zoals gedefinieerd door de PKCS#10-standaard. De vertrouwde CA (certificeringsinstantie) moet dan beslissen of ze de CSR wil ondertekenen, of ze de klant die de registratie aanvraagt ​​vertrouwt en de informatie die ze in haar certificaat verstrekt.

Als de CA (certificeringsinstantie) ervoor kiest om de Certificate Signing Request (CSR) te vertrouwen, is het resultaat de uitgifte van een ondertekend certificaat met de identiteit die in de CSR wordt vermeld. Het certificaat valt onder de X.509-standaard.

DIGITALE CERTIFICERING VAN DE VEILIGE SSL-VERBINDING

Voor een veilige gegevensoverdracht tussen de browser en de webserver wordt het https-protocol voor gegevensoverdracht gebruikt, dat is gebaseerd op een veilige SSL-verbinding.

Dit artikel geeft een overzicht van public key-encryptie, digitale certificaten, public key infrastructure (PKI - Public Key Infrastructure), het creëren van een certificeringsinstantie, het configureren van Apache Tomcat- en JBoss-servletcontainers voor het opzetten van eenrichtings- en tweerichtingsverkeer, het genereren van een certificaatarchief en hoe u een SSL-certificaat maakt met behulp van het hulpprogramma keytool. Je leert ook hoe je ingetrokken certificaten in Java kunt controleren (CRL-lijsten, OCSP-protocol) en de browser configureert om met certificaten te werken.

Een moderne manier om berichten veilig over een netwerk te verzenden, is de versleutelingsmethode met openbare sleutels. De essentie van de methode is de aanwezigheid van een paar sleutels: openbaar en privé. De openbare en privésleutels zijn algoritmen voor het converteren van het oorspronkelijke bericht naar het versleutelde bericht en het versleutelde bericht naar het originele.

De openbare sleutel is vrij beschikbaar en beschikbaar voor iedereen die een versleuteld bericht wil verzenden. De afzender, die het bericht versleuteld heeft, kan het met vertrouwen verzenden via een onveilig communicatiekanaal en er zeker van zijn dat alleen de geadresseerde dit bericht kan lezen.

De privésleutel wordt strikt geheim gehouden door de eigenaar van het sleutelpaar. Bij ontvangst van een bericht dat is versleuteld met de openbare sleutel, gebruikt de ontvanger de privésleutel om het te ontsleutelen. Aangezien de privésleutel alleen bekend is bij de geadresseerde van het bericht, kan niemand anders deze lezen, wat de geheimhouding van het bericht garandeert.

Een bericht dat met de privésleutel is versleuteld, kan door iedereen met de openbare sleutel worden ontsleuteld.

Op basis van dit encryptie-algoritme wordt een beveiligde SSL-verbinding tot stand gebracht.

Digitaal certificaat

Een digitaal certificaat is een elektronisch document dat de eigenaar identificeert. Het bevat basisinformatie over de eigenaar, de openbare sleutel van de eigenaar, vervaldatums, digitale handtekening van de uitgever (uitgever) en andere noodzakelijke informatie. Het digitale certificaat heeft een extensiesectie (optioneel) die distributiepunten voor intrekkingslijsten, uitgeversinformatie, enz. bevat. Met het digitale certificaat kunt u een beveiligde SSL-verbinding opzetten. Hoe u een SSL-certificaat aanmaakt, wordt verderop in dit artikel beschreven.

De belangrijkste kenmerken van bovenstaande certificaten zijn:

Het SSL-certificaat van de certificeringsinstantie moet het CA-veld bevatten dat is ingesteld op TRUE, zodat andere certificaten kunnen worden uitgegeven, d.w.z. dit certificaat is niet definitief in de keten.

Server SSL-certificaten in het veld CN (algemene naam) moeten de domeinnaam of het ip-adres bevatten waarmee de server wordt benaderd, anders wordt het certificaat ongeldig;

Client SSL-certificaten bevatten het e-mailadres, de voor- en achternaam van de klant. In tegenstelling tot het servercertificaat is het CN-veld niet essentieel voor de inhoud en kan het zowel een voornaam als een achternaam bevatten, evenals een e-mailadres.

Een digitaal SSL-certificaat wordt als geldig beschouwd binnen de geldigheidsperiode die in de velden is aangegeven. Het certificaat kan dus niet worden gebruikt vóór de startdatum en na de vervaldatum, omdat. systemen die met hem in contact komen, zullen wantrouwen jegens hem melden.

Er zijn situaties waarin de gebruiker of uitgever van een certificaat het certificaat moet opschorten of volledig moet stoppen. Laten we zeggen dat de privésleutel, die veilig moet worden bewaard, verloren is gegaan of dat indringers er toegang toe hebben gekregen. In een dergelijke situatie moet de gebruiker contact opnemen met de uitgever (uitgever) van het certificaat zodat deze de geldigheid ervan opzegt. Ook kan de uitgever het certificaat intrekken als blijkt dat de opdrachtgever valse informatie over zichzelf heeft verstrekt. Voor deze doeleinden wordt een speciale lijst gemaakt, de certificaatintrekkingslijst (CRL) genoemd. Deze lijst bevat het serienummer van het certificaat, de vervaldatum en de reden voor de intrekking. Vanaf het moment dat het certificaat de CRL binnenkomt, wordt het als ongeldig beschouwd en is de uitgever niet verantwoordelijk voor de inhoud van een dergelijk certificaat. Een van de methoden voor het controleren van de CRL-lijst is het OCSP-protocol, maar hiervoor is de aanwezigheid van een OCSP-responder bij de certificeringsinstantie vereist.

Publieke Sleutel Infrastructuur (PKI)

De hoofdtaak van de Public Key Infrastructure (PKI) is het bepalen van het beleid voor de uitgifte van digitale certificaten.

Voor het uitgeven en intrekken van SSL-certificaten, het genereren van intrekkingslijsten (CRL's), heeft u speciale software (software) nodig. Een voorbeeld van dergelijke software is Microsoft CA (onderdeel van MS Windows Server 2000/2003/2008), OpenSSL (gedistribueerd naar Unix-achtige besturingssystemen). Deze software wordt gehost op de apparatuur van het certificeringscentrum.

Certificatieautoriteit (CA) is een organisatie die digitale SSL-certificaten uitgeeft op basis van de gegevens die door de klant worden verstrekt. De certificeringsinstantie is volledig verantwoordelijk voor de authenticiteit van de gegevens die in het SSL-certificaat worden gepresenteerd, wat betekent dat de eigenaar van het certificaat precies is wie hij beweert te zijn.

De meest voorkomende CA's ter wereld zijn Verisign en Comodo. Deze CA-certificaten worden vertrouwd door 99% van de browsers en de meeste serversoftware. De oprichting van een certificeringsinstantie wordt hieronder beschreven.

Veilige SSL-verbinding met tweerichtingsverificatie

De beveiligde SSL-verbinding wordt het meest gebruikt in e-commerce. Denk bijvoorbeeld aan de aankoop van goederen via een elektronische winkel. De koper, die de nummers en codes van creditcards aangeeft, wil er zeker van zijn dat deze niet in verkeerde handen vallen. Daarom authenticeert de server zichzelf door een certificaat aan de client te verstrekken. De certificeringsinstantie staat garant voor deze authenticiteit. Clientgegevens worden versleuteld met de openbare sleutel van de server. Deze gegevens kunnen alleen worden ontsleuteld met de privésleutel die op de server staat. Daarom mag de klant niet bang zijn dat een aanvaller zijn gegevens zal onderscheppen, hij zal deze nog steeds niet kunnen ontsleutelen.

Een client SSL-certificaat wordt gebruikt in gevallen waarin de server bevestiging nodig heeft dat de client is wie hij beweert te zijn. Een bank biedt bijvoorbeeld netwerktoegang om een ​​persoonlijke rekening te beheren. Hij wil zichzelf beschermen en er zeker van zijn dat er contact met hem wordt opgenomen door de eigenaar van dit account, en niet door een aanvaller die een login en wachtwoord heeft gekregen. In deze situatie levert de client zijn openbare sleutel aan de server en kunnen alle gegevens die van de server worden ontvangen alleen door de client worden gedecodeerd en door niemand anders, omdat hij is de eigenaar van de privésleutel.

De afbeelding is een diagram dat de stappen toont om een ​​veilige SSL-verbinding tot stand te brengen.

Fig 1 - Schema voor het creëren van een veilige SSL-verbinding met tweerichtingsauthenticatie

Wanneer een client toegang probeert te krijgen tot een beschermde bron, verzendt de server zijn digitale certificaat. Na ontvangst van het certificaat controleert de klant het. De verificatie is als volgt: de begin- en einddatum van de geldigheid mogen niet zijn verlopen, de uitgever van het certificaat moet worden vertrouwd, het certificaat mag niet in de CRL staan. Als de controle mislukt, wordt het proces voor het tot stand brengen van de verbinding afgebroken. Als aan de validatievoorwaarden is voldaan, stuurt de client zijn certificaat naar de server. De server voert een soortgelijke controle uit. Als de controle mislukt, zal de server de toegang tot zijn bronnen weigeren. Na succesvolle verificatie wordt een beveiligde verbinding tot stand gebracht en worden de gegevens versleuteld verzonden.

In dit schema zijn de verzonden gegevens dubbel versleuteld. De client versleutelt het bericht met de openbare sleutel van de server en vervolgens met zijn eigen privésleutel. Na ontvangst van het bericht decodeert de server het bericht met de openbare sleutel van de client en vervolgens met zijn privésleutel. Zo authenticeren de server en de client zichzelf bij elkaar, omdat: alleen zij kunnen de ontvangen gegevens decoderen.

Opgemerkt moet worden dat het gebruik van deze techniek de snelheid van gegevensuitwisseling vermindert, omdat: coderings-/decoderingsbewerkingen vereisen extra tijd en de snelheid van hun uitvoering hangt af van de kracht van de computerbronnen.

Oprichting van een certificeringsinstantie

Voor testdoeleinden of wanneer het niet praktisch is om een ​​digitaal certificaat te kopen, dient u uw eigen CA aan te maken.

Een root-CA is een CA die iedereen vertrouwt. Het heeft een SSL-certificaat, dat is ondertekend met zijn eigen privésleutel. Dergelijke SSL-certificaten worden zelfondertekend genoemd.

De privésleutel van de root-CA moet zeer veilig worden bewaard, omdat: bij verlies of diefstal is het vertrouwen in alle ondergeschikte SSL-certificaten verloren.

Ondergeschikte CA is een CA die SSL-certificaten uitgeeft aan klanten. Het certificaat van de ondergeschikte certificeringsinstantie wordt ondertekend met de persoonlijke sleutel van de hogere certificeringsinstantie. Certificatiecentra, webservers, webbrowsers, mailclients waarvoor certificaten van het vereiste type worden gegenereerd, kunnen optreden als klanten van een ondergeschikt certificatiecentrum. De soorten certificaten worden bepaald door het beleid van de certificeringsinstantie.

Uit het bovenstaande volgt dat er een keten van certificaten wordt gemaakt van de root-CA tot het uiteindelijke clientcertificaat.

Fig 2 - Certificaatketen

Om een ​​certificeringsinstantie te creëren, gebruiken we een schema met twee niveaus zoals weergegeven in figuur 3. Dit schema heeft een basiscertificeringsinstantie (Root CA) en een ondergeschikte certificeringsinstantie (Issuing CA). De root-CA ondertekent zijn eigen SSL-certificaat en de SSL-certificaten van ondergeschikte CA's. Opgemerkt moet worden dat hoe meer niveaus worden gebruikt, hoe veiliger de regeling is.

In de certificaten van de root en ondergeschikte certificeringsinstantie worden de CRL-distributiepunten geregistreerd in de extensie. Het CRL-distributiepunt is een netwerkadres. Op dit adres moet met een bepaalde frequentie een door speciale software gegenereerd CRL-bestand worden geüpload.

Fig 3 - Schema met twee niveaus van het certificeringscentrum

Een voorbeeld van het organiseren van een certificeringsinstantie op basis van Microsoft CA vindt u in het artikel Een keten van certificeringsinstanties implementeren op basis van Microsoft CA.

Een SSL-servercertificaat verkrijgen van een CA en een servletcontainer configureren

Met een digitaal SSL-servercertificaat kunt u een veilige SSL-verbinding maken waarmee u gegevens in versleutelde vorm kunt overdragen.

Om een ​​certificaat te verkrijgen dat door de servletcontainer wordt gebruikt, moet u een (CSR) aan de CA genereren. De aanvraag bevat basisinformatie over de organisatie en de publieke sleutel.

Het hoofdveld dat correct moet worden ingevuld heet de Common Name (CN). In dit veld moet u de domeinnaam of het IP-adres opgeven van de host waar de servletcontainer zich bevindt.

Om een ​​privé- en openbare sleutel te genereren en een SSL-certificaat aan te vragen, kunt u het hulpprogramma keytool gebruiken dat is opgenomen in de JDK (Java-ontwikkelingskit).

Voer op de opdrachtregel de volgende opdracht in:

$JAVA_HOME\bin> keytool -genkey -alias -keyalg -keystore

Fig 4 - Een SSL-certificaatarchief maken met het hulpprogramma keytool

Deze keytool-opdracht maakt een certificaatarchief met de naam , die de privésleutel en het zelfondertekende SSL-certificaat opslaat, versleuteld met behulp van het RSA-algoritme. U hebt toegang tot het SSL-certificaat op naam .

Tijdens het aanmaken van de repository, zal het keytool-hulpprogramma u vragen om een ​​wachtwoord in te voeren om toegang te krijgen tot de repository, informatie over de organisatie en een wachtwoord voor de geheime (private) sleutel. Bij het beantwoorden van de sleutelhulpvraag "Wat is uw voor- en achternaam?" je moet de domeinnaam of het ip-adres van de host invullen, want de antwoordwaarde wordt gebruikt als het CN-veld van het SSL-certificaat.

Nadat de keystore is gegenereerd door het hulpprogramma keytool, moet een verzoek worden gedaan aan de certificeringsinstantie om een ​​SSL-certificaat te ondertekenen. Dit doe je met het commando:

$JAVA_HOME\bin> keytool -certreq -keyalg RSA -alias -het dossier -keystore

In bestand de certificaataanvraag wordt opgeslagen. Daarna wordt een speciaal formulier ingevuld op de website van het certificatiecentrum en wordt de inhoud van dit bestand gekopieerd naar een van de velden.

Om een ​​SSL-certificaat aan een organisatie af te geven, kan het certificeringscentrum documenten, een registratiecertificaat, enz. nodig hebben. Na ontvangst van een aanvraag voor een SSL-certificaat voert het certificeringscentrum een ​​verificatie uit door de gegevens in de certificaataanvraag te vergelijken met de verzonden documenten en ondertekent vervolgens het verzoek. De ondertekende aanvraag is een certificaat.

Fig 5 - Schema voor het verkrijgen van een servercertificaat

Na ontvangst van een certificaat van een certificeringsinstantie, moet deze in de winkel worden geplaatst, na toevoeging van de SSL-certificaten van de root- en tussenliggende certificeringsinstanties. Gebruik de volgende opdrachten van het hulpprogramma keytool om SSL-certificaten aan de opslag toe te voegen:

1) het certificaat van de root-CA toevoegen met het hulpprogramma keytool: $JAVA_HOME\bin> keytool -import -trustcacerts -alias rootca -file -keystore

2) een tussenliggend CA-certificaat toevoegen met het hulpprogramma keytool: $JAVA_HOME\bin> keytool -import -trustcacerts -alias subca -file -keystore

3) vervanging van een zelfondertekend certificaat door een certificaat ondertekend door een certificeringsinstantie (de waarde van de aliasparameter is opgegeven, die werd gebruikt bij het maken van de repository): $JAVA_HOME\bin> keytool -import -trustcacerts -alias -het dossier -keystore

Om ervoor te zorgen dat applicaties een beveiligde SSL-verbinding kunnen gebruiken, moet de servletcontainer worden geconfigureerd. Voeg voor Apache Tomcat en JBoss de volgende inhoud toe aan het bestand server.xml:

clientAuth="false" sslProtocol="TLS"

keystoreFile=" "

keystorePass=" "

keystoreType="JKS"

keyAlias=" "

Met dit item kan de servlet-container een beveiligde verbinding tot stand brengen met behulp van een digitaal SSL-certificaat, dat zich in de winkel bevindt Met wachtwoord door alias .

De bovenstaande configuratie maakt gebruik van eenrichtingsauthenticatie, d.w.z. het verstrekken van een digitaal SSL-certificaat is alleen vereist van de server. Om een ​​tweerichtingsauthenticatie te creëren, d.w.z. wanneer de client ook een digitaal SSL-certificaat levert, moet u de configuratie van de servletcontainer als volgt wijzigen:

maxThreads="150" scheme="https" secure="true"

clientAuth="true" sslProtocol="TLS"

keystoreFile="

keystorePass=" "

keystoreType="JKS"

keyAlias=" "

truststoreFile="

truststorePass=" "truststoreType="JKS"

In deze configuratie is de parameter clientAuth=”true” ingesteld en is de trust store verbonden. Het maken van een winkel met vertrouwde SSL-certificaten wordt gedaan door het hulpprogramma keytool op dezelfde manier als een gewone winkel. U moet er certificaten aan toevoegen van certificeringsinstanties die digitale certificaten uitgeven, die de servletcontainer moet vertrouwen. Anders worden de door SSL geleverde certificaten tijdens de authenticatie afgewezen door de servletcontainer. ze zullen niet worden vertrouwd.

Ingetrokken certificaten op de server controleren

Er zijn 3 manieren om een ​​certificaat te valideren voor intrekking: statische CRL-validatie, dynamische CRL-validatie en OCSP-validatie. Laten we deze methoden in meer detail bekijken.

1) Statische CRL-controle

Bij gebruik van dit type verificatie moet de serverbeheerder in de configuratie de naam opgeven van het bestand op de lokale schijf waar de lijst met ingetrokken certificaten zich bevindt. Deze lijst wordt gedownload van de netwerkbron van de certificeringsinstantie.

Om CRL in Apache Tomcat- en Jboss-servletcontainers te verbinden, voegt u het volgende kenmerk toe aan de ssl-connector:

crlFile="

Het nadeel van deze methode is dat de beheerder voortdurend moet toezien op het bijwerken van het CRL-bestand.

2) Dynamische CRL-controle

Met deze methode kunt u automatisch CRL-controles uitvoeren. Dit vereist dat het CRLDistributionPoint-kenmerk in het gedeelte extensies van het SSL-certificaat dat door de client wordt geleverd, dat de URL specificeert waar de certificaatintrekkingslijst (CRL) zich bevindt.

Om het SSL-certificaat van de client in de CRL te valideren, moeten twee parameters worden geconfigureerd voor de Java Virtual Machine. Deze opties kunnen worden gespecificeerd in het opstartscript van de servletcontainer. Voor Apache Tomcat en Jboss op Windows ziet het er als volgt uit:

set JAVA_OPTS=%JAVA_OPTS% -Dcom.sun.net.ssl.checkRevocation=true

Dcom.sun.security.enableCRLDP=true -Djava.security.debug=certpath

Met de optie java.security.debug=certpath kunt u certificaatverificatie observeren in de console van de actieve container.

De nadelen van deze methode zijn onder meer de vertraging in toegang tot een beschermde bron die gepaard gaat met het downloaden van een groot CRL-bestand.

3) Validatie met behulp van OCSP-protocol

OCSP (Online Certificate Status Protocol) is ontwikkeld als alternatief voor CRL. Deze controle wordt ondersteund door JSSE-technologie (Java Secure Socket Extension) sinds JDK 5. OCSP werkt samen met CRL. De CRL wordt geopend wanneer er een fout optreedt tijdens OCSP-communicatie. Als OCSP de status van het SSL-certificaat heeft bepaald, wordt de CRL-controle niet uitgevoerd. Een certificaat kan drie statussen hebben: ingetrokken, normaal, onbekend.

Voor OCSP-validatie moet het certificaat een AuthorityInfoAccess-kenmerk in de extensiesectie bevatten met de waarde van de URL van de OCSP-responder.

OCSP Responder is software op een netwerkbron van een certificeringsinstantie die verzoeken verwerkt om de status van een certificaat te bepalen en verificatieresultaten afgeeft.

Om ervoor te zorgen dat de virtuele Java-machine kan worden vergeleken met OCSP, moet u de eigenschap ocsp.enable=true instellen. Deze eigenschap wordt geconfigureerd in het bestand JAVA_HOME\jre\lib\security\java.security. In dit bestand kunt u het adres van de OCSP-responder opgeven in de eigenschap ocsp.responderURL. Deze eigenschap wordt gebruikt als er geen responder-URL in het SSL-certificaat is.

Een SSL-clientcertificaat verkrijgen van een certificeringsinstantie en een webbrowser configureren

Er zijn situaties waarin de server niet alleen moet verifiëren dat hij is wie hij beweert te zijn, maar ook wanneer de server vereist dat de client zijn identiteit verifieert met een digitaal certificaat.

U kunt een client-SSL-certificaat krijgen zonder zelf een verzoek te genereren, door dit te doen met behulp van een certificeringsinstantie. Hiervoor dient u op de website van de CA een formulier in te vullen met vermelding van naam, achternaam, e-mailadres, etc. Op basis van deze gegevens wordt een verzoek gegenereerd. In deze situatie wordt het genereren van een geheime sleutel toegewezen aan de certificeringsinstantie. Na verificatie van de gegevens en ondertekening van het verzoek, ontvangt de klant een bestand met de geheime sleutel en het certificaat, evenals de bestanden van de root- en tussenliggende certificeringsinstanties.

Nadat u de certificaatbestanden hebt ontvangen, moet u de software configureren die veilige verbindingen tot stand brengt.

Fig 6 - Schema voor het verkrijgen van een SSL-clientcertificaat

Laten we als voorbeeld een SSL-certificaat van een client installeren in een webbrowser van Microsoft Internet Explorer. Selecteer hiervoor Extra > Internetopties in het menu. Selecteer op het tabblad "Inhoud" de optie "Certificaten ...".

Fig 7 - SSL-certificaten beheren in MS Internet Explorer

Start de wizard Certificaat importeren door op de knop "Importeren..." te klikken. Geef in deze wizard het pad naar het root-CA-certificaat op. Selecteer vervolgens het archief met vertrouwde basiscertificeringsinstanties om het certificaat eraan toe te voegen.

Evenzo worden certificaten van intermediaire CA's toegevoegd aan het "Tussenliggende CA's"-archief en een clientcertificaat aan het "Persoonlijke"-archief.

Fig 8 - Certificatieketen

Om de inhoud van het certificaat te bekijken, selecteert u het gewenste SSL-certificaat en klikt u op de knop "Bekijken".

Als een clientcertificaat is verkregen van een bekende certificeringsinstantie, dan zijn de SSL-certificaten in de regel al in de webbrowserwinkels aanwezig en hoeft u deze niet toe te voegen. U hoeft alleen het clientcertificaat toe te voegen.

Als de server waarmee de interactie wordt uitgevoerd een certificaat heeft ontvangen dat niet van een gemeenschappelijke certificeringsinstantie is, moet het servercertificaat worden toegevoegd aan de vertrouwde, zodat de webbrowser geen bericht over wantrouwen voor een dergelijk certificaat weergeeft.

Ingetrokken certificaten controleren op de client

Als de client de webbrowser MS Internet Explorer gebruikt, kan deze worden geconfigureerd om de verzonden certificaten in de CRL te controleren. Ga hiervoor naar het tabblad "Geavanceerd" in de internetopties en vink de twee attributen "Controleren op intrekking van uitgeverscertificaten" en "Controleren op intrekking van servercertificaten" aan.