Vi har gitt ut en ny bok, "Content Marketing on Social Media: How to Get Into the Heads of Subscribers and Fall in Love with Your Brand".

Verden er besatt av internettsikkerhet. Hvis du er i trenden og utelukkende korresponderer i Telegram, så les om hvordan du oppretter en sikker tilkobling på en nettside. Det kommer i alle fall godt med, og er du en nettbutikk, så klarer du deg ikke uten i det hele tatt. La oss underveis snakke om sertifikater: hva de er og hva de er til for.

Hva er HTTPS

Det er en sikker tilkoblingsprotokoll. Den krypterer informasjon som utveksles mellom serveren og brukerens nettleser – dette bidrar til å beskytte data om passord, kredittkortnumre og e-postadresser. Bruken av HTTPS er kraftig og gjør den litt mer attraktiv i søkemotorenes øyne – Google rangerer sikre sider høyere enn ikke-sikre sider. For å aktivere HTTPS på nettstedet ditt, må du først installere et SSL-sertifikat på serveren.

Hva er et SSL-sertifikat for?

Det genererer en unik digital signatur på siden, som bidrar til å sikre forbindelsen. Uten et SSL-sertifikat vil du ikke kunne få HTTPS, uansett hvor hardt du prøver. Det inneholder:

• nettsted domene;
• fullt juridisk navn på eierselskapet;
• den fysiske adressen til selskapet;
• gyldighetsperiode for sertifikatet;
• SSL-utviklerdetaljer.

Du trenger også et sertifikat for å koble til et hvilket som helst betalingssystem, for eksempel Yandex.Money. Logikken er enkel - ingen vil tillate deg å risikere andres penger.

Hvordan velge et SSL-sertifikat

De er delt inn i to typer, avhengig av beskyttelsesgrad og.

Domenevalidering SSL

Det enkleste alternativet. Det vil fungere etter at du har bekreftet eierskapet til domenet. Dette kan gjøres på tre måter:

• Via e-post. Du vil motta en e-post med bekreftelsesinstruksjoner. Enten e-post fra Whois-domenet eller postboksene til administratoren eller webmasteren er valgt som avsenderadresse.

• Gjennom en DNS-oppføring. Hvis du har konfigurert en e-postserver, oppretter du en egendefinert DNS-post. Systemet vil bruke det til å bekrefte at du virkelig er eieren av nettstedet. Metoden er automatisert og passer for de som har sin Whois-post skjult i innstillingene.

• Gjennom en hash-fil. Plasser den spesielle .txt-filen på serveren din slik at sertifiseringsmyndigheten kan fastslå dens tilstedeværelse.

En slik verifisering er egnet hvis du har en personlig blogg eller en liten frakoblet virksomhet, fordi den ikke tillater deg å beskytte underdomener og utføre økonomiske transaksjoner. I tillegg, for å bekrefte renheten til domenet og tankene dine, trenger du ikke å gjøre noe komplisert, og det ferdiglagde sertifikatet gjøres raskt.

Virksomhetsvalidering

Denne typen SSL-sertifikat er mer pålitelig fordi du bekrefter at selskapet er koblet til nettstedet. For å gjøre dette må du sende flere dokumenter til bekreftelsessenteret og ringe bedriftsnummeret. Bedriftsvalideringssertifikater er delt inn i 3 typer:

• Utvidet validering SSL. Dette er utvidede valideringssertifikater. De trengs av alle som jobber med store pengebeløp: banker, store nettbutikker, finansselskaper, betalingssystemer.

• Jokertegn SSL. Et slikt sertifikat beskytter både selve nettstedet og dets underdomener. Dessuten kan det være et hvilket som helst antall av dem, og de kan være plassert på forskjellige servere. Obligatorisk hvis du bruker underdomener med annen regional binding eller forskjellige prosjekter.

• SAN SSl. Den største fordelen med denne typen sertifikater er støtten for alternative domenenavn: både eksterne og interne.

• SSL for kodesignering. Validerer koden og programvareproduktene fra nettstedet. Egnet for utviklere av alle applikasjoner.

Kan jeg installere et gratis SSL-sertifikat på nettstedet mitt?

Ja. De fleste av disse produktene er betalt, men det finnes også alternativer som du ikke trenger å betale penger for. Dette er domenevaliderte grunnleggende sertifikater. De vil ikke tillate deg å legge ved et online kasseapparat til ressursen, men de vil kunne beskytte forbindelsen mellom brukeren og serveren. Disse SSL-ene er egnet for små informasjonsnettsteder eller offline-bedrifter. Et eksempel er StartSSL-basesertifikatet.

Installer SSL-sertifikat

Først må du generere en CSR-forespørsel om et sertifikat. Den inneholder all informasjon om domeneeieren og den offentlige nøkkelen. De fleste SSL-leverandører lar deg gjøre dette under bestillingsprosessen, men du kan også generere en forespørsel på nettserversiden.

I prosessen med å generere en CSR-nøkkel, må du spesifisere:

• Servernavn: "site.com" eller "* .site.com" hvis du mottar et WIldcard-sertifikat. En stjerne betyr et hvilket som helst antall tegn før punktet.
• Landskode: RU, UA, KZ og så videre.
• Region, for eksempel Saratov-regionen.
• By.
• Det fulle navnet på organisasjonen eller navnet på nettstedets eier.

CSR-forespørselen sendes til verifiseringssenteret. Som et resultat mottar du et SSL-sertifikat og en fil med en privat nøkkel, som ikke kan tapes og gjøres offentlig tilgjengelig.

Etter det må du installere sertifikatet på webserveren. La oss vurdere tilfellene med Apache og nginx.

Apache

For å gjøre dette må du laste opp alle sertifikater til serveren: både grunnleggende og middels. Først av alt trenger du sistnevnte i katalogen / usr / local / ssl / crt (brukt som standard, i ditt tilfelle kan det være annerledes). Alle sertifikater vil bli lagret i den.

Etter det laster du ned hovedsertifikatet, åpner det i et hvilket som helst tekstredigeringsprogram og kopierer innholdet fullstendig sammen med linjene "BEGIN" og "END".

I katalogen / ssl / crt / oppretter du en vashsite.crt-fil og limer inn innholdet av sertifikatet i den.

Flytt den private nøkkelfilen til katalogen / usr / local / ssl / private /

Legg til linjene i VirtualHost-filen din:

SSLengine på

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

SSLCertificateFile /usr/local/ssl/crt/vashsite.crt

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

Du må spesifisere gyldige stier til filer. Lagre endringer og start serveren på nytt.

nginx

Her er prosessen for å installere et SSL-sertifikat litt annerledes. Først må du kombinere rot-, mellom- og SSL-sertifikatene til ett. For å gjøre dette, lag en fil vashsite.crt og lim inn innholdet i sertifikatene der sammen med linjene "BEGIN" og "END" (rekkefølge: SSL, intermediate, root). Det skal ikke være tomme linjer.

Du må gjøre nesten det samme med den private nøkkelen - opprette en fil vashsite.key og overføre innholdet i nøkkelen som er lastet ned fra leverandørens nettsted.

Plasser begge filene (vashsite.crt og vashsite.key) i katalogen / etc / ssl / (den brukes som standard, men kan variere).

Rediger VirtualHost i konfigurasjonsfilen. Legge til:

server (
hør 443;
ssl på;

ssl_sertifikat /etc/ssl/vashsite.crt;
ssl_certificate_key /etc/ssl/vashsite.key;
servernavn vashsite.com;

Hvis katalogen med sertifikatet og nøkkelen er forskjellig fra standarden, endre den.

Lagre nå endringene og start nginx på nytt.

Hvordan få en fungerende HTTPS-tilkobling

Etter å ha installert SSL-sertifikater, vil siden være tilgjengelig på to adresser: http://vashsite.com og https://vashsite.com. Du trenger bare å forlate den siste. For å gjøre dette, sett opp en robots.txt-fil og foreta en 301-omdirigering fra det gamle nettstedet.

I "roboter" må du oppdatere verten. Eksempel: Vert: https://vashsite.com. For å sette opp en omdirigering, legg til følgende linjer i .htacsess-filen:

RewriteCond% (SERVER_PORT)! ^ 443 $

RewriteRule ^ (. *) $ Https://vashsite.com/$1.

Nå gjenstår det å informere søkemotorene om endringene. I "Webmaster" til "Yandex" legg til en side med https og spesifiser den som hovedsiden for det gamle nettstedet.

Utfall

Vi fant ut hva https er, hvordan du installerer det på nettstedet ditt og hvordan du konfigurerer alt riktig. Denne protokollen har allerede blitt en tilkoblingsstandard og over tid vil alle live-nettsteder bytte til den. Denne prosessen oppmuntres av søkemotorer - å ha en etablert sikker HTTPS-tilkoblingsprotokoll har blitt en av rangeringsfaktorene. Derfor, hvis du vil komme til toppen, må du installere den.

Hyggelige nyheter fra november 2016 for våre kjære kunder og brukere av nettstedet. Nettbutikken vår står ikke stille, og oppdaterer regelmessig ikke bare utvalget av produkttilbud, men utvider også funksjonaliteten til nettstedet, dets sikkerhet for brukerne og dets betydning i det globale Internett-systemet. Så 26. september 2016 mottok nettbutikksiden et SSL-sertifikat med utvidet verifisering, og fra 1. november 2016, etter å ha testet og forbedret algoritmene, koblet vi betalingssystemer til siden!

La oss nå se nærmere på behovet for disse handlingene og hvilke fordeler får våre dyrebare kunder av dette?

Den største visuelle fordelen som hver klient kan legge merke til er muligheten til å betale ONLINE med et bankkort for enhver bestilling fra nettbutikken vår og ta den til en praktisk adresse. Når det gjelder den interne, skjulte verdigheten til nettstedsoppdateringer - et SSL-sertifikat er en spesiell måte å kryptere et nettsted mellom det globale Internett, en nettleser og en bruker av nettstedet, med andre ord, dette er at nettstedet nå er beskyttet mot muligheten for et angrep og beslagleggelse av betalings- (og til og med kontaktinformasjon) tredjeparter. For å få et SSL-sertifikat måtte nettstedet vårt gjennom en sjekk av organisasjonens reelle eksistens, bekreftelse på mottak og binding av sertifikatet til domenet, og integreringen av det nye sikre nettstedssystemet på nettstedet kjent for alle. Fra nå av kan brukere av nettstedet vårt være helt trygge på sikkerheten ved å bruke vår praktiske og moderne side, foreta kjøp og ikke være redd for å lekke dataene sine til tredjeparter.

Vi står forresten heller ikke stille i å utvide mulighetene for å motta våre bestillinger, og høsten 2016 begynte vi å tilby våre kunder muligheten til å motta bestillinger med nye leveringsmetoder - CDEK budtjeneste og gjennom inPost pakketerminaler . Begge tjenestene er til stede i mange store byer i Russland, kostnadene for tjenestene deres er veldig demokratiske, og arbeidshastigheten overrasker noen ganger til og med fans av dyre og høykvalitets budtjenester! Vi anbefaler deg å prøve nye leveringsmetoder, dette vil spare deg for tid og penger, og vil gi deg en hyggelig opplevelse av å motta varene.

Nettbutikksiden vår er et moderne selskap i dynamisk utvikling, og tilbyr våre kunder de mest moderne og sikre måtene å betale og motta våre bestillinger på. Følg med for oppdateringer som kommer til å bli grandiose og globale, både for å utvide utvalget og gi flere muligheter for våre dyrebare kunder !!

Du kan starte en liten bedrift. Organiser for eksempel videresalg av domener og SSL-sertifikater. Du finner kunder for eksisterende selgere og blir belønnet i form av rabatter og marginer – du blir med andre ord en forhandler. Du kan raskt sette opp forhandlerdomener og SSL-sertifikater ved å bruke ISPsystem-programvare.

Viktig! Vi anbefaler ikke å starte med den tekniske implementeringen, men med forretningsmodellen og den juridiske siden av saken. Bestem målgruppen og måter å tiltrekke seg den på, utvikle en prispolitikk som er fordelaktig for deg selv og kundene dine. Studer det juridiske og regnskapsmessige rammeverket. Bare deretter fortsett til den tekniske implementeringen av planen.

Hva du trenger for å komme i gang

For å bli forhandler av domene og SSL-sertifikater trenger du:

1. virtuell server (VPS / VDS),
2. en avtale med selgere av domener og SSL-sertifikater,
3. avtale med betalingssystemet,
4. faktureringsplattform for å godta betalinger,
5. nettsted for salg av tjenester.

Installere og konfigurere programvare

For å videreselge domener og SSL-sertifikater, må du installere BILLmanager på en leid virtuell server.

Integrasjon med domene- og SSL-selgere

For å sette opp integrasjonen, bruk data fra domene- og SSL-forhandlerne du har inngått avtale med. Vanligvis krever integrasjon en API-tilgangs-URL, en forhandlerkode og en API-autorisasjonsnøkkel. Data kan variere avhengig av selskapet.

Etter det, i BILLmanager i menyen Integrering - Tjenestebehandlere vil du kunne sette opp et videresalg.

Du kan også begynne å videreselge SSL-sertifikater gjennom ISPsystem. Du trenger ikke å forhandle direkte med registraren. For å gjøre dette, i delen "Tjenestebehandlere", velg BILLmanager 5 og skriv inn dine personlige kontodata my.ispsystem.com.

Tilkobling av betalingssystemer

For å gjøre det mulig for kunder å betale for tjenester, konfigurer betalingsmåter. BILLmanager inneholder mer 30 moduler betaling: Yandex.Money, WebMoney, PayMaster, Qiwi, PayPal, bankoverføring og andre.

For å jobbe med et bestemt betalingssystem må du og dine kunder ha en konto eller konto i dette systemet. Velg derfor mest populær Tjenester. For å sette opp integrasjonen trenger du data fra betalingssystemet: lommeboknummer og hemmelig nøkkel.

Kunder vil overføre penger fra kontoen sin til din. Mottak av midler vil reflekteres på kontoen din og på klientkontoen i BILLmanager.

For å motta betalinger fra enkeltpersoner kan du koble til enkle elektroniske systemer som Yandex.Checkout eller WebMoney. Juridiske enheter betaler for tjenester ved bankoverføring i henhold til fakturaen, derfor, for å jobbe med dem, koble til betalingsmetoden for bankoverføring (Russian Bank). Fyll inn organisasjonens bankdetaljer. Tilkobling til betalingssystemer.

Sette opp dokumentmaler

BILLmanager har forhåndsdefinerte dokumentmaler: fakturaer, ferdigattest, avstemmingsattest, serviceavtale, vedlegg til avtalen. Vennligst rediger dem i henhold til vilkårene for bruk.

For å overholde juridiske krav må du opprette og publisere på nettstedet ditt Personvernerklæring og Vilkår for bruk... Legg til en lenke til disse dokumentene i menyen Innstillinger - Merkeinnstillinger - opphavsrett... Når du utarbeider en policy for behandling av personopplysninger, følg anbefalingene fra Roskomnadzor. Tilpasse dokument- og meldingsmaler

Tilpasse e-post- og meldingsmaler

BILLmanager inneholder over 60 maler for å lage nyhetsbrev. Kunder vil motta brev ved registrering, bestilling av tjenester, fakturering. Fakturering vil varsle deg om slutten av tjenesten. Du kan også tilpasse maler for SMS-meldinger og masseutsendelser. I panelet kan du endre type meldinger.

Sette opp nettstedsintegrasjon

Integrasjon med nettstedet

For å selge tjenester må informasjon om dem være offentlig tilgjengelig. Hvis du har en nettside, tilpass visningen av tjenester på den. Utarbeid bilder og beskrivelser av tariffer og generer en lenke til en spesifikk tariffplan med nødvendig betalingsperiode i BILLmanager. Når du klikker på lenken, vil brukeren umiddelbart bli ført til kjøpssiden for det valgte produktet. Sette opp BILLmanager-integrasjon med en nettside

Produkt- og servicekort

Du kan raskt plassere priser på nettstedet ved å bruke Showcase-verktøyet. Verktøyet lar deg legge til et kort med en eller flere tjenester til nettstedet slik at brukeren kan velge den han trenger og bestille. Prisene i kortene oppdateres automatisk.

For å legge til et kort, må du plassere et spesielt skript på stedet der du vil vise det. Skriptet finner du i dokumentasjonen: Integrasjon av butikkfronten i en eksisterende side.

Merkevarebygging

Når du går fra nettstedet ditt til sin personlige konto i BILLmanager, kan klienter føle et avvik: nettstedet og faktureringen er utformet annerledes, faktureringsadressen inneholder serverens IP-adresse og er forskjellig fra nettsideadressen.

For å "jevne" stilene, konfigurer merkevaren: legg til logoen din på faktureringen, endre grensesnittfargen, publiser lenker til nettstedet. For å gjøre fakturerings-URLen den samme som på nettsiden, konfigurer adressen for BILLmanager. For eksempel har CloudLite en nettsideadresse cloudlite.ru, fakturaadresse - myvdc.cloudlite.ru.

Nylig må vi håndtere HTTPS / SSL med misunnelsesverdig regelmessighet. Men hver gang et slikt prosjekt kommer, klarer jeg å glemme hvordan det gjøres. For å gjøre det lettere å gjenopprette kunnskap i minnet, bestemte jeg meg for å oversette materialer herfra. Imidlertid beveget oversettelsen seg gradvis bort fra originalen.

SSL er en familie av protokoller for å etablere en kryptert forbindelse mellom to parter som ønsker å utveksle data. Dette er en utveksling der de koblende partene blir enige om hvilke krypteringsmekanismer hver av dem støtter, hvilken nøkkellengde som skal brukes, krypteringsmoduser, sertifikater utveksles, en asymmetrisk krypteringsalgoritme brukes til å utveksle en symmetrisk krypteringsprotokollnøkkel, som deretter brukes i videre kommunikasjon. Denne første kommunikasjonen kalles et håndtrykk.

Den symmetriske nøkkelen genereres under håndtrykket og er kun gyldig for én SSL-økt. Hvis økten ikke forblir aktiv, utløper nøkkelen (utløper). Den maksimale tiden etter at SSL-økten utløper (utløper) kan spesifiseres. Etter at økten utløper, må håndtrykket gjentas fra begynnelsen. Sesjonsoppsettet resulterer i en ny symmetrisk nøkkel.

Sertifikater og nøkler

Før vi dykker ned i detaljene i SSL, må vi introdusere konseptet med nøkler og sertifikater. SSL / TLS bruker asymmetrisk kryptering for autentisering og symmetrisk nøkkelutveksling, som vil bli brukt til å kryptere data under en økt.

Asymmetrisk kryptering bruker nøkkelpar for kryptering - en privat nøkkel og en tilsvarende offentlig nøkkel. Data kryptert med én nøkkel kan dekrypteres med en parnøkkel. På samme måte kan data signert med én nøkkel verifiseres med en annen nøkkel. Den private nøkkelen, som navnet antyder, må holdes hemmelig.

Sertifikater.

Et sertifikat består av en offentlig nøkkel, sammen med noe informasjon som identifiserer eieren, og nøkkelens utløpsdato. Sertifikatet inneholder også den digitale signaturen til sertifiseringsinstansens CA. En digital signatur sikrer at sertifikatet ikke tukles med. Et sertifikat utstedes vanligvis til en webserver, applikasjon eller bruker. Et sertifikat er en måte å distribuere en offentlig krypteringsnøkkel på.

Hvis klienten krypterer meldingen med serverens offentlige nøkkel (fra serverens sertifikat), kan klienten være sikker på at kun en legitim server kan dekryptere meldingen. I prosessen med å etablere en SSL / TLS-sesjon, oppretter klienten en del av sesjonsnøkkelen, krypterer meldingen ved hjelp av serverens offentlige nøkkel og overfører den til serveren. Hvis serveren er den den utgir seg for å være, vil den kunne dekryptere meldingen ved hjelp av den private nøkkelen og trekke ut øktnøkkelen fra meldingen.

Det finnes to typer sertifikater.

• Offisielt utstedte sertifikater signert av en sertifiseringsinstans
• Selvsignerte sertifikater

Selvsignerte sertifikater - sertifikater lagt inn for testing slik at utviklere kan teste programvaren deres uten å vente på et offisielt signert sertifikat. Et selvsignert sertifikat er annerledes ved at dets autentisitet ikke kan bekreftes med mindre du personlig har laget det eller mottatt det på et digitalt medium fra en pålitelig kilde. Ellers er selvsignerte sertifikater nøyaktig de samme som offisielle. De kan brukes programmatisk på samme måte.

Tillit

Nøkkelbegrepet for en SSL-tilkobling er konseptet med å stole på et sertifikat. Metoden for å få sertifikatet som brukes for tilkoblingen er viktig. Hvis du får et sertifikat fra en pålitelig kilde, for eksempel personlig fra eieren av nettstedet, kan du være sikker på at sertifikatet er ekte og at du faktisk kobler til dette nettstedet. Men når du oppretter en tilkobling fra en nettleser, for eksempel, kan serversertifikatet hentes fra selve serveren du kobler til. Spørsmålet om sertifikatets ekthet oppstår. Hva om en hacker opprettet sitt eget asymmetriske nøkkelpar og deretter laget sitt eget sertifikat for å forfalske bankens server?

Tillitsmodellen er enkel. Hver klient eller server bestemmer at den stoler på visse sertifikatmyndigheter (CAer) for å utstede sertifikater. Å stole på en CA betyr å stole på at alle sertifikater utstedt av CA er lovlige og at den identifiserende informasjonen i sertifikatet er korrekt og pålitelig. Verisign er et eksempel på en CA som signerer mange sertifikater for store Internett-selskaper. Alle nettlesere stoler på Verisign som standard. Identiteten til sertifikatet inneholder en digital signatur generert av CA. Klienten eller serveren stoler på CA ved å legge sertifikatet til en butikkfil kalt 'truststore'. Ved å lagre CA-sertifikatet i truststore kan java verifisere den digitale signaturen til sertifikatet generert av CA og bestemme om sertifikatet skal stole på eller ikke.

Hvis en hacker legger inn et falskt sertifikat for Barclays bank, vil nettleseren din prøve å bekrefte den digitale signaturen til sertifikatet. Denne kontrollen vil mislykkes fordi det ikke er noe sertifikat i truststore som signerte angriperens sertifikat.

Sertifikatkjede

I praksis er formatet på sertifikater slik at flere signaturer kan inkluderes i et sertifikat. Sertifikatet inneholder ikke én signatur, men en viss "sertifikatkjede"

Når private og offentlige nøkler genereres, genereres det automatisk et selvsignert sertifikat for den offentlige nøkkelen. De. til å begynne med får du et par av en privat nøkkel og et sertifikat som inneholder den signerte offentlige nøkkelen. Et selvsignert sertifikat er et sertifikat der skaperen av nøkkelen og underskriveren er samme person.

Senere, etter generering av en forespørsel om sertifikatsignering (CSR) og mottatt svar fra sertifiseringsmyndigheten (CA), erstattes det selvsignerte sertifikatet med en sertifikatkjede. Et sertifikat fra CA legges til kjeden, som bekrefter autentisiteten til den offentlige nøkkelen, etterfulgt av et sertifikat som bekrefter autentisiteten til den offentlige nøkkelen til CA.

I mange tilfeller er det siste sertifikatet i kjeden (som bekrefter autentisiteten til CAs offentlige nøkkel) selvsignert. I andre tilfeller kan CA på sin side returnere ikke én, men en kjede av sertifikater. I dette tilfellet er den første i kjeden den offentlige nøkkelen signert av CA som utstedte sertifikatet, og det andre sertifikatet kan være et sertifikat fra en annen CA, som bekrefter autentisiteten til den offentlige nøkkelen til den første CAen som signeringsforespørselen til ble sendt. Dette vil bli fulgt av et sertifikat som bekrefter autentisiteten til den offentlige nøkkelen til den andre CA, etc. til kjeden avsluttes med et selvsignert rotsertifikat. Hvert sertifikat i kjeden validerer den offentlige nøkkelen til det forrige sertifikatet i kjeden.

La oss ta en dypere titt på SSL. Det finnes to typer SSL-tilkoblinger.

Enkel autentisering (enveis SSL-autentisering)

Autentisering må utføres før en kryptert SSL/TLS-forbindelse etableres. For at en enkel tilkobling skal etableres, må det installeres en server med privat nøkkel som det er innhentet sertifikat for. Klienten må også opprettholde en liste over CA-organisasjoner som den stoler på.

Klienten verifiserer identiteten til serveren før den etablerer en kryptert tilkobling.

2-veis SSL-autentisering

Med denne typen autentisering gir både serveren og klienten sertifikater for å autentisere hverandre før de etablerer en kryptert tilkobling.

Sertifikatbekreftelse

Med enveisautentisering (den første typen) har serveren et sertifikat med en sammenkoblet privat nøkkel. Data kryptert med serverens offentlige nøkkel kan dekrypteres ved hjelp av serverens private nøkkel. En klient som ønsker å opprette en tilkobling til en server, bekrefter serverens sertifikat før han fortsetter med å etablere en kryptert tilkobling. Kunden bør sjekke følgende:

• Er sertifikatet fortsatt gyldig (utløpsdato passert)
• Sertifikatet levert av serveren samsvarer faktisk med vertsnavnet.
• Er det en organisasjon som har utstedt CA-sertifikatet på listen som klienten stoler på?
• Sjekk den digitale signaturen på sertifikatet

Andre små detaljer blir også sjekket, som krypteringsalgoritmen til den digitale signaturen, nøkkellengder osv.

Med 2-veis autentisering eier både klienten og serveren de private nøklene og sertifikatene. Begge sjekker hverandres sertifikater før de etablerer en kryptert forbindelse. Klienten utfører kontrollene beskrevet ovenfor og serveren utfører de samme handlingene på klientsertifikatet.

Signeringsforespørsel og signering av sertifikater

Oppretting av nøkler og sertifikater er regulert av standarder.

Nøkler genereres i henhold til PKCS….

Når et par offentlige og private nøkler genereres, opprettes et sertifikatforespørselsobjekt kalt Certificate Signing Request (CSR), regulert av PKCS # 10-standarden. Den betrodde CA (sertifikatmyndigheten) må da avgjøre om den vil signere CSR, om den stoler på klienten som ber om registrering og informasjonen den gir i sertifikatet.

Hvis CA (sertifikatmyndighet) bestemmer seg for å stole på Certificate Signing Request (CSR), er resultatet utstedelse av et signert sertifikat med identiteten oppgitt i CSR. Sertifikatet er regulert av X.509-standarden.

SSL-SIKRET DIGITAL SERTIFISERING

For sikker dataoverføring mellom nettleseren og webserveren brukes https-dataoverføringsprotokollen, som er basert på en sikker SSL-tilkobling.

Denne artikkelen gir en oversikt over offentlig nøkkelkryptering, digitale sertifikater, Public Key Infrastructure (PKI), opprettelse av en CA, konfigurering av Apache Tomcat og JBoss servletbeholdere for å etablere enveis og toveis sikre tilkoblinger, generere et sertifikatlager og hvordan for å lage et SSL-sertifikat ved å bruke nøkkelverktøyet. Du vil også lære om måter å sjekke tilbakekalte sertifikater i Java (CRL-lister, OCSP-protokoll) og konfigurere nettleseren til å fungere med sertifikater.

Offentlig nøkkelkryptering er en moderne måte å sikkert overføre meldinger over nettverket. Essensen av metoden ligger i tilstedeværelsen av et par nøkler: offentlige og private. Den offentlige og private nøkkelen er algoritmer for å konvertere den opprinnelige meldingen til den krypterte og den krypterte meldingen i den originale.

Den offentlige nøkkelen er fritt tilgjengelig og gis til alle som ønsker å sende en kryptert melding. Avsenderen, etter å ha kryptert meldingen, kan trygt overføre den over en usikker kommunikasjonskanal og være sikker på at bare adressaten vil kunne lese meldingen.

Den private nøkkelen holdes strengt hemmelig av eieren av nøkkelparet. Ved mottak av en melding kryptert med en offentlig nøkkel, bruker mottakeren den private nøkkelen til å dekryptere den. Siden den private nøkkelen kun er kjent for mottakeren av meldingen, kan ingen andre lese den, noe som garanterer hemmelighold av meldingen.

En melding kryptert med en privat nøkkel kan dekrypteres av alle innehavere av den offentlige nøkkelen.

En sikker SSL-tilkobling opprettes basert på denne krypteringsalgoritmen.

Digitalt sertifikat

Et digitalt sertifikat er et elektronisk dokument som identifiserer eieren. Den inneholder grunnleggende informasjon om eieren, eierens offentlige nøkkel, utløpsdatoer, digital signatur fra utsteder (utgiver) og annen nødvendig informasjon. Et digitalt sertifikat har en utvidelsesseksjon (valgfritt) som inneholder distribusjonspunkter for opphevelseslister, utgiverinformasjon mm Et digitalt sertifikat lar deg etablere en sikker SSL-tilkobling. Hvordan lage et SSL-sertifikat er beskrevet nedenfor i denne artikkelen.

Hovedtrekk ved sertifiseringene ovenfor:

SSL-sertifikatet til sertifiseringsmyndigheten må inneholde CA-feltet med TRUE-verdien, som tillater utstedelse av andre sertifikater, dvs. dette sertifikatet er ikke endelig i kjeden.

Server SSL-sertifikater i CN (fellesnavn)-feltet må inneholde domenenavnet eller ip-adressen som serveren er adressert til, ellers vil sertifikatet bli ugyldig;

Klients SSL-sertifikater inneholder klientens e-postadresse, for- og etternavn. I motsetning til et serversertifikat er ikke CN-feltet innholdskritisk og kan inneholde både et for- og etternavn og en e-postadresse.

Et digitalt SSL-sertifikat anses som gyldig innenfor gyldighetsperioden som er spesifisert i feltene. Dermed kan sertifikatet ikke brukes før startdatoen for gyldigheten, og etter utløpsdatoen, fordi systemer som kommer i kontakt med ham vil rapportere mistillit til ham.

Det er situasjoner når en bruker eller utsteder av et sertifikat må suspendere eller fullstendig stoppe gyldigheten. La oss si at en privat nøkkel som må lagres sikkert går tapt eller får tilgang til av hackere. I en slik situasjon må brukeren kontakte utstederen (utgiveren) av sertifikatet for at sistnevnte skal kansellere handlingen. Utgiveren kan også tilbakekalle sertifikatet dersom det viser seg at klienten har gitt forfalskede opplysninger om seg selv. For disse formålene opprettes en spesiell liste, kalt listen over tilbakekalte (tilbakekallede) sertifikater (English Certificate revocation list, CRL). Denne listen inneholder serienummeret til sertifikatet, utløpsdatoen og årsaken til tilbakekall. Fra det øyeblikket sertifikatet kommer inn i CRL, anses det som ugyldig og utgiveren er ikke ansvarlig for innholdet i et slikt sertifikat. En av metodene for å sjekke CRL-listen er OCSP-protokollen, men dette krever tilstedeværelse av OCSP-responderens CA.

Public Key Infrastructure (PKI)

Hovedmålet med en Public Key Infrastructure (PKI) er å definere en policy for utstedelse av digitale sertifikater.

For å utstede og tilbakekalle SSL-sertifikater, generer tilbakekallingslister (CRL), du trenger spesiell programvare (programvare). Eksempler på slik programvare er Microsoft CA (inkludert i MS Windows Server 2000/2003/2008), OpenSSL (distribuert på unix-lignende operativsystemer). Denne programvaren er plassert på utstyret til sertifiseringssenteret.

Sertifiseringsinstans (CA) er en organisasjon som utsteder digitale SSL-sertifikater basert på dataene kunden har oppgitt. Sertifiseringsmyndigheten er fullt ansvarlig for nøyaktigheten av dataene som presenteres i SSL-sertifikatet, noe som betyr at eieren av sertifikatet er nøyaktig den han utgir seg for å være.

De vanligste CA-ene i verden er Verisign og Comodo. Disse CA-ene er klarert av 99 % av nettlesere og de fleste serverprogramvare. Opprettelsen av en sertifiseringsinstans er beskrevet nedenfor.

SSL sikret tilkobling med toveis autentisering

SSL sikret tilkobling er mest brukt i e-handel. Vurder for eksempel å kjøpe varer gjennom en nettbutikk. Kjøperen, ved å spesifisere numrene og kodene til kredittkort, ønsker å være sikker på at de ikke faller inn i en inntrenger. Derfor autentiserer serveren seg selv ved å gi et sertifikat til klienten. Garanten for denne autentisiteten er sertifiseringssenteret. Klientdata vil bli kryptert med serverens offentlige nøkkel. Disse dataene kan kun dekrypteres med en privat nøkkel som er plassert på serveren. Derfor trenger ikke klienten å frykte at en angriper vil avskjære dataene hans, han vil fortsatt ikke være i stand til å dekryptere dem.

Client SSL-sertifikat brukes i tilfeller der serveren trenger bekreftelse på at klienten er nøyaktig den han utgir seg for å være. For eksempel gir en bank nettverkstilgang for å administrere en personlig konto. Han ønsker å beskytte seg selv og være sikker på at eieren av denne kontoen kontakter ham, og ikke en angriper som har fått brukernavn og passord. I denne situasjonen gir klienten sin offentlige nøkkel til serveren, og alle mottatte data fra serveren kan bare dekrypteres av klienten og ingen andre, fordi han er eieren av den private nøkkelen.

Figuren er et diagram som viser trinnene for å opprette en sikker SSL-tilkobling.

Figur 1 - Opplegg for å opprette en sikker SSL-forbindelse med toveis autentisering

Når en klient prøver å få tilgang til en beskyttet ressurs, sender serveren sitt digitale sertifikat. Etter å ha mottatt sertifikatet, bekrefter klienten det. Verifikasjonen er som følger: start- og sluttdatoene må ikke utløpe, utstederen av sertifikatet må være klarert, sertifikatet må ikke være i CRL. Hvis kontrollen mislykkes, avbrytes tilkoblingsprosessen. Hvis bekreftelsesbetingelsene er oppfylt, sender klienten sitt sertifikat til serveren. Serveren utfører en lignende sjekk. Hvis kontrollen mislykkes, vil serveren nekte tilgang til ressursene sine. Hvis kontrollen er vellykket, opprettes en sikker forbindelse og dataene overføres i kryptert form.

I dette opplegget er de overførte dataene dobbeltkryptert. Klienten krypterer meldingen med serverens offentlige nøkkel og deretter med sin egen private nøkkel. Etter å ha mottatt meldingen, dekrypterer serveren meldingen med klientens offentlige nøkkel og deretter med sin egen private nøkkel. Dermed autentiserer serveren og klienten seg for hverandre, siden bare de kan dekryptere de mottatte dataene.

Det skal bemerkes at bruken av denne teknikken reduserer datautvekslingshastigheten, siden krypterings-/dekrypteringsoperasjoner krever ekstra tid og hastigheten på utførelse av dem avhenger av kraften til dataressursene.

Opprettelse av et sertifiseringssenter

For testformål eller når det er upraktisk å kjøpe et digitalt sertifikat, bør du opprette din egen CA.

Root CA er en CA som alle stoler på. Han har et SSL-sertifikat, som er signert med hans egen private nøkkel. Slike SSL-sertifikater kalles selvsignerte.

Den private nøkkelen til rot-CA må lagres veldig sikkert fordi hvis det blir tapt eller stjålet, mister tilliten til alle underordnede SSL-sertifikater.

Underordnet CA - en CA som utsteder SSL-sertifikater til klienter. Sertifikatet til den underordnede CA er signert med den private nøkkelen til den overordnede CA. Sertifiseringsmyndigheter, webservere, nettlesere, e-postklienter som det genereres sertifikater av påkrevd type for, kan fungere som klienter til den underordnede sertifiseringsmyndigheten. Sertifikattypene bestemmes av retningslinjene til sertifiseringsmyndigheten.

Av ovenstående følger det at en kjede av sertifikater opprettes fra rot-CA til det endelige klientsertifikatet.

Fig 2 - Sertifikatkjede

For å lage en CA, vil vi bruke to-lags-skjemaet vist i figur 3. I dette opplegget er det en rot-CA og en underordnet CA (utstedende CA). Rot-CA signerer sitt eget SSL-sertifikat og SSL-sertifikater fra underordnede CAer. Det skal bemerkes at jo flere lag som brukes, desto sikrere er ordningen.

CRL-distribusjonspunkter er skrevet i sertifikatene til rot- og underordnede CA-er i utvidelsen. CRL-distribusjonspunktet er en nettverksadresse. En CRL-fil generert av spesiell programvare bør lastes opp til denne adressen med en spesifisert frekvens.

Figur 3 - To-lags ordning for sertifiseringssenteret

Et eksempel på organisering av en sertifiseringsinstans basert på Microsoft CA finner du i artikkelen "Deploying a chain of Certification Authorities based on Microsoft CA".

Skaffe et server SSL-sertifikat fra en sertifiseringsinstans og konfigurere servletbeholderen

Et digitalt SSL-serversertifikat lar deg opprette en sikker SSL-tilkobling, som vil tillate kryptert dataoverføring.

For å få et sertifikat som skal brukes av servletbeholderen, må du generere en sertifikatsigneringsforespørsel (CSR) til sertifiseringsmyndigheten. Forespørselen inneholder grunnleggende informasjon om organisasjonen og den offentlige nøkkelen.

Hovedfeltet som skal fylles ut riktig kalles Common Name (CN). I dette feltet må du spesifisere domenenavnet eller IP-adressen til verten der servletbeholderen er plassert.

Du kan bruke nøkkelverktøyet fra JDK (Java Development Kit) til å generere private og offentlige nøkler og be om et SSL-sertifikat.

Ved ledeteksten skriver du inn følgende kommando:

$ JAVA_HOME \ bin> nøkkelverktøy -genkey -alias -keyalg -nøkkellager

Figur 4 - Opprette et SSL-sertifikatlager ved å bruke nøkkelverktøyet

Denne nøkkelverktøykommandoen oppretter et sertifikatlager med navnet , som lagrer den private nøkkelen og det selvsignerte SSL-sertifikatet, kryptert med RSA-algoritmen. Du kan referere til SSL-sertifikatet ved navn .

Under opprettelsen av hvelvet vil nøkkelverktøyet be deg om å angi et passord for tilgang til hvelvet, informasjon om organisasjonen og et passord for den hemmelige (private) nøkkelen. Når du svarer på spørsmålet "Hva er ditt for- og etternavn?" du må skrive inn domenenavnet eller ip-adressen til verten, fordi svarverdien vil bli brukt som CN-feltet til SSL-sertifikatet.

Etter at nøkkelverktøy-verktøyet har generert en lagring med nøkler, bør du generere en forespørsel til sertifiseringsmyndigheten om å signere et SSL-sertifikat. Dette gjøres med kommandoen:

$ JAVA_HOME \ bin> nøkkelverktøy -certreq -keyalg RSA -alias -fil -nøkkellager

I fil sertifikatforespørselen er lagret. Etter det fylles et spesielt skjema ut på nettstedet til sertifiseringssenteret, i et av feltene som innholdet i denne filen er kopiert til.

For å utstede et SSL-sertifikat til en organisasjon, kan et sertifiseringssenter kreve inngående dokumenter, et registreringsbevis osv. Ved mottak av en søknad om et SSL-sertifikat kontrollerer sertifiseringssenteret dataene i sertifikatforespørselen og de sendte dokumentene. , og signerer deretter forespørselen. Den signerte forespørselen er et sertifikat.

Figur 5 - Opplegg for å få et serversertifikat

Etter å ha mottatt et sertifikat fra en sertifiseringsmyndighet, må det legges i lagringen etter å ha lagt til SSL-sertifikater fra rot- og. For å legge til SSL-sertifikater til depotet, bruk følgende kommandoer fra nøkkelverktøyet:

1) legge til sertifikatet til rotsertifiseringsmyndigheten ved å bruke nøkkelverktøyet: $ JAVA_HOME \ bin> nøkkelverktøy -import -trustcacerts -alias rootca -fil -nøkkellager

2) legge til sertifikatet til den mellomliggende sertifiseringsmyndigheten ved å bruke nøkkelverktøyet: $ JAVA_HOME \ bin> nøkkelverktøy -import -trustcacerts -alias subca -fil -nøkkellager

3) erstatte det selvsignerte sertifikatet med et sertifikat som er signert i sertifiseringsinstansen (verdien av aliasparameteren som ble brukt ved opprettelsen av lagringen er angitt): $ JAVA_HOME \ bin> keytool -import -trustcacerts -alias -fil -nøkkellager

For at applikasjoner skal bruke en sikker SSL-tilkobling, må servletbeholderen konfigureres. For Apache Tomcat og JBoss, legg til følgende innhold i server.xml-filen:

clientAuth = "false" sslProtocol = "TLS"

keystoreFile = " "

keystorePass = " "

keystoreType = "JKS"

keyAlias ​​= " "

Denne oppføringen lar servletbeholderen etablere en sikker tilkobling ved hjelp av et digitalt SSL-sertifikat som ligger i depotet Med passord ved alias .

Denne konfigurasjonen bruker enveisautentisering, dvs. levering av et digitalt SSL-sertifikat er kun nødvendig fra serveren. For å lage toveis autentisering, dvs. når klienten også leverer et digitalt SSL-sertifikat, må du endre konfigurasjonen av servletbeholderen som følger:

maxThreads = "150" scheme = "https" secure = "sant"

clientAuth = "true" sslProtocol = "TLS"

keystoreFile = "

keystorePass = " "

keystoreType = "JKS"

keyAlias ​​= " "

truststoreFile = "

truststorePass = " "truststoreType =" JKS "

I denne konfigurasjonen er parameteren clientAuth = "true" satt og trust-lageret tilkoblet. Keytool-verktøyet oppretter et arkiv med klarerte SSL-sertifikater på samme måte som et vanlig arkiv. Den må legge til sertifikater for CAer som utsteder digitale sertifikater som servletbeholderen må stole på. Ellers vil de oppgitte SSL-sertifikatene bli avvist av servletbeholderen under autentisering. det vil ikke være noen tillit til dem.

Kontrollerer tilbakekalte sertifikater på serveren

Det er tre måter å sjekke et sertifikat for tilbakekalling: statisk CRL-sjekk, dynamisk CRL-sjekk, OCSP-sjekk. La oss vurdere disse metodene mer detaljert.

1) Statisk CRL-sjekk

Når du bruker denne typen verifisering, må serveradministratoren spesifisere i konfigurasjonen navnet på filen på den lokale disken hvor listen over tilbakekalte sertifikater er plassert. Denne listen er lastet ned fra nettverksressursen til sertifiseringssenteret.

For å koble til CRL-er i Apache Tomcat- og Jboss-servletbeholdere, legg til et attributt til ssl-koblingen:

crlFile = ”

Ulempen med denne metoden er behovet for at administratoren konstant overvåker oppdateringen av CRL-filen.

2) Dynamisk CRL-sjekk

Denne metoden tillater automatisk CRL-kontroll. Dette krever at CRLDistributionPoint-attributtet spesifiseres i utvidelsesdelen levert av SSL-klienten, som spesifiserer URL-en der Certificate Revocation List (CRL) er plassert.

For at klientens SSL-sertifikat skal valideres i CRL, må to parametere konfigureres for den virtuelle Java-maskinen. Disse parameterne kan spesifiseres i oppstartsskriptet til servletbeholderen. For Apache Tomcat og Jboss på Windows ser det slik ut:

sett JAVA_OPTS =% JAVA_OPTS% -Dcom.sun.net.ssl.checkRevocation = sant

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

Parameteren java.security.debug = certpath lar deg observere sertifikatets autentisering i konsollen til beholderen som kjører.

Ulempene med denne metoden inkluderer forsinkelsen i å få tilgang til en beskyttet ressurs knyttet til lasting av en stor CRL-fil.

3) Verifikasjon ved hjelp av OCSP-protokollen

Online sertifikatstatusprotokoll (OCSP) ble utviklet som et alternativ til CRL. Denne sjekken støttes av JSSE (Java Secure Socket Extension)-teknologi siden JDK 5. OCSP fungerer sammen med CRL. CRL-en åpnes når det oppstår en feil under kommunikasjon over OCSP. Hvis OCSP har bestemt statusen til et SSL-sertifikat, utføres ikke CRL-kontrollen. Et sertifikat kan ha en av tre statuser: kansellert, normal, ukjent.

For OCSP-validering må sertifikatet ha et AuthorityInfoAccess-attributt i utvidelsesdelen med verdien av OCSP-svar-URLen.

OCSP-responder - programvare plassert på en nettverksressurs til en sertifiseringsmyndighet som behandler forespørsler for å fastslå statusen til et sertifikat og gir verifiseringsresultater.

For at den virtuelle Java-maskinen skal utføre OCSP-kontroll, må egenskapen ocsp.enable settes til true. Denne egenskapen er konfigurert i filen JAVA_HOME \ jre \ lib \ security \ java.security. I denne filen kan du registrere adressen til OCSP-responderen i egenskapen ocsp.responderURL. Denne egenskapen vil bli brukt hvis det ikke er noen svar-URL i SSL-sertifikatet.

Skaffe et klient-SSL-sertifikat fra sertifiseringssenteret og konfigurere nettleseren

Det er situasjoner hvor ikke bare serveren trenger å bekrefte at den er den den utgir seg for å være, men også når serveren krever at klienten bekrefter sin identitet med et digitalt sertifikat.

Du kan få et klient-SSL-sertifikat uten å generere en forespørsel selv ved å bruke en sertifiseringsinstans. For å gjøre dette, på CA-nettstedet, må du fylle ut et skjema som angir navn, etternavn, e-postadresse osv. Basert på disse dataene vil en forespørsel bli generert. I denne situasjonen er genereringen av den hemmelige nøkkelen sertifiseringsmyndighetens ansvar. Etter å ha kontrollert dataene og signert forespørselen, får klienten tilsendt en fil som inneholder den hemmelige nøkkelen og sertifikatet, samt filene til rot- og mellomsertifiseringssentrene.

Etter å ha mottatt sertifikatfilene, må du konfigurere programvaren som skal etablere sikre tilkoblinger.

Fig 6 - Opplegg for å få et SSL-klientsertifikat

Som et eksempel vil vi installere klientens SSL-sertifikat i nettleseren Microsoft Internet Explorer. For å gjøre dette, velg Verktøy > Alternativer for Internett fra menyen. På "Innhold"-fanen, velg "Sertifikater ...".

Fig 7 - Administrere SSL-sertifikater i MS Internet Explorer

Start sertifikatimportveiviseren ved å klikke på "Importer ..."-knappen. I denne veiviseren angir vi banen til sertifikatet til rotsertifiseringsmyndigheten. Deretter velger du "Trusted Root Certification Authorities"-butikken for å legge til et sertifikat til den.

På samme måte legges mellomliggende CA-sertifikater til lageret for mellomliggende sertifiseringsinstanser og klientsertifikatet til det personlige lagret.

Figur 8 - Sertifiseringskjede

For å se innholdet i sertifikatet, velg det nødvendige SSL-sertifikatet og klikk på "Vis"-knappen.

Hvis et klientsertifikat er hentet fra en kjent sertifiseringsinstans, er SSL-sertifikatene som regel allerede i butikkene til nettleseren, og det er ikke nødvendig å legge dem til. Du trenger bare å legge til klientsertifikatet.

Hvis serveren som kommunikasjonen skal utføres med mottok et sertifikat fra en ikke-vanlig sertifiseringsinstans, bør serversertifikatet legges til de klarerte, slik at nettleseren ikke viser en melding om å ikke stole på et slikt sertifikat.

Bekrefter tilbakekalte sertifikater på klienten

Hvis klienten bruker MS Internet Explorer-nettleseren, kan den konfigureres til å sjekke de sendte sertifikatene i CRL. For å gjøre dette, gå til fanen "Avansert" i nettleseregenskapene og sjekk de to attributtene "Sjekk for tilbakekall av utgiversertifikater" og "Sjekk for tilbakekall av serversertifikater".