• Digitální certifikace zabezpečeného ssl připojení. Nastavení platebních systémů Obousměrné ssl propojení s platebním systémem

    Můžete začít podnikat v malém. Například organizovat přeprodej domén a SSL certifikátů. Najdete zákazníky pro stávající prodejce a získáte odměnu ve formě slev a marží – jinými slovy, staňte se prodejcem. Pomocí softwaru ISPsystem můžete rychle nastavit prodejní domény a SSL certifikáty.

    Důležité! Doporučujeme začít nikoli technickou implementací, ale obchodním modelem a právní stránkou problému. Určete cílovou skupinu a způsoby, jak ji přilákat, vypracujte cenovou politiku, která je výhodná pro vás i vaše zákazníky. Naučte se právní a účetní rámec. Teprve poté přejděte k technické realizaci plánu.

    Co potřebujete, abyste mohli začít

    Chcete-li se stát prodejcem domén a certifikátů SSL, budete potřebovat:

    1. virtuální server (VPS/VDS),
    2. dohoda s prodejci domén a SSL certifikátů,
    3. souhlas s platebním systémem,
    4. fakturační platforma pro příjem plateb,
    5. stránky pro prodej služeb.

    Instalace a konfigurace softwaru

    Chcete-li prodávat domény a certifikáty SSL, budete muset nainstalovat BILLmanager na pronajatý virtuální server.

    Integrace s dodavateli domény a SSL

    Chcete-li nastavit integraci, použijte data od dodavatelů domény a SSL, se kterými máte smlouvu. Integrace obvykle vyžaduje adresu URL pro přístup k rozhraní API, kód prodejce a autorizační klíč rozhraní API. Údaje se mohou lišit v závislosti na společnosti.

    Poté v BILLmanageru v menu Integrace - Servisní procesory budete moci nastavit další prodej.

    Můžete také začít prodávat SSL certifikáty prostřednictvím ISPsystem. Nebudete muset jednat přímo s registrátorem. Chcete-li to provést, v části „Servisní procesory“ vyberte BILLmanager 5 a zadejte údaje o svém osobním účtu my.ispsystem.com.

    Propojení platebních systémů

    Chcete-li zákazníkům umožnit platit za služby, nastavte platební metody. BILLmanager obsahuje více než 30 modulů platba: Yandex.Money, WebMoney, PayMaster, Qiwi, PayPal, Bankovní převod a další.

    Chcete-li pracovat s určitým platebním systémem, musíte vy a vaši zákazníci mít účet nebo účet v tomto systému. Vyberte si tedy co nejvíce oblíbený Služby. Pro nastavení integrace budete potřebovat údaje z platebního systému: číslo peněženky a tajný klíč.

    Klienti převedou prostředky ze svého účtu na váš. Příjem finančních prostředků se projeví na vašem účtu a zákaznickém účtu v BILLmanager.

    Chcete-li přijímat platby od jednotlivců, můžete připojit jednoduché elektronické systémy, jako je Yandex.Checkout nebo WebMoney. Právnické osoby platí za služby bankovním převodem dle faktury, pro práci s nimi tedy připojte platební metodu Bankovní převod (ruská banka). Zadejte bankovní údaje vaší organizace. Napojení na platební systémy.

    Nastavení šablon dokumentů

    BILLmanager má předinstalované šablony dokumentů: faktury, potvrzení o provedení práce, potvrzení o odsouhlasení, servisní smlouvy, přílohy ke smlouvě. Upravte je podle svých smluvních podmínek.

    Pro splnění zákonných požadavků vytvořte a publikujte na svém webu Zásady ochrany osobních údajů A Podmínky použití. Přidejte odkaz na tyto dokumenty v nabídce Nastavení - Nastavení značky - autorská práva. Při sestavování zásad zpracování osobních údajů se řiďte doporučeními Roskomnadzoru. Nastavení šablon dokumentů a zpráv

    Nastavení šablon pošty a zpráv

    BILLmanager obsahuje více než 60 e-mailových šablon. Klienti obdrží dopisy při registraci, objednávce služeb, fakturaci. Vyúčtování vás upozorní, až služba vyprší. Můžete také nastavit šablony pro SMS zprávy a hromadné rozesílání. Na panelu můžete změnit typ zpráv.

    Nastavení integrace s webem

    Integrace webových stránek

    Aby bylo možné prodávat služby, musí být informace o nich veřejně dostupné. Pokud máte web, nastavte si na něm zobrazování služeb. Připravte si obrázky a popisy tarifů a v BILLmanageru vygenerujte odkaz na konkrétní tarif s požadovanou dobou splatnosti. Po kliknutí na odkaz bude uživatel okamžitě přesměrován na nákupní stránku vybraného produktu. Konfigurace integrace BILLmanager s webem

    Karty zboží a služeb

    Tarify můžete na stránky rychle umístit pomocí nástroje Showcase. Nástroj umožňuje přidat na stránku kartu jedné nebo více služeb, takže si uživatel může vybrat a objednat. Ceny na kartách se aktualizují automaticky.

    Chcete-li přidat kartu, musíte na místo, kde ji chcete zobrazit, umístit speciální skript. Skript najdete v dokumentaci: Integrace výlohy do existujícího webu.

    Branding

    Při přechodu z vaší stránky na svůj osobní účet v BILLmanageru mohou zákazníci pocítit nesrovnalosti: stránka a fakturace jsou navrženy jinak, fakturační adresa obsahuje IP adresu serveru a liší se od adresy webu.

    Chcete-li styly „o úroveň výš“, dokončete nastavení značky: přidejte své logo do fakturace, změňte barvu rozhraní, publikujte odkazy na web. Abyste zajistili, že se fakturační adresa URL nebude lišit od webové stránky, nakonfigurujte adresu pro BILLmanager . CloudLite má například webovou adresu cloudlite.ru, fakturační adresa - myvdc.cloudlite.ru.

    Webová stránka společnosti CloudLiteDokumentace pro nastavení Aihor showcase" nebo "FirstVDS". Poté si můžete spustit vlastní virtuální hosting a VDS hosting.

    DIGITÁLNÍ CERTIFIKACE ZABEZPEČENÉHO SSL PŘIPOJENÍ

    Pro bezpečný přenos dat mezi prohlížečem a webovým serverem se používá protokol přenosu dat https, který je založen na zabezpečeném připojení SSL.

    Tento článek poskytuje přehled o šifrování veřejného klíče, digitálních certifikátech, infrastruktuře veřejných klíčů (PKI - Public Key Infrastructure), vytvoření certifikační autority, konfiguraci kontejnerů servletů Apache Tomcat a JBoss pro navázání jednosměrné a obousměrné zabezpečené komunikace, generování úložiště certifikátů a jak vytvořit certifikát SSL pomocí obslužného programu keytool. Dozvíte se také o způsobech kontroly odvolaných certifikátů v Javě (seznamy CRL, protokol OCSP) a konfiguraci prohlížeče pro práci s certifikáty.

    Moderním způsobem bezpečného přenosu zpráv po síti je metoda šifrování veřejným klíčem. Podstatou metody je přítomnost dvojice klíčů: veřejného a soukromého. Veřejný a soukromý klíč jsou algoritmy pro převod původní zprávy na zašifrovanou zprávu a zašifrovanou zprávu na původní.

    Veřejný klíč je volně dostupný a dostupný každému, kdo chce poslat šifrovanou zprávu. Odesílatel, který zprávu zašifroval, ji může s jistotou přenést přes nezabezpečený komunikační kanál a mít jistotu, že tuto zprávu bude moci přečíst pouze adresát.

    Soukromý klíč je přísně tajný vlastníkem páru klíčů. Po obdržení zprávy zašifrované veřejným klíčem příjemce použije soukromý klíč k jejímu dešifrování. Vzhledem k tomu, že soukromý klíč zná pouze adresát zprávy, nemůže jej přečíst nikdo jiný, což zaručuje utajení zprávy.

    Zprávu zašifrovanou soukromým klíčem může dešifrovat kdokoli, kdo má veřejný klíč.

    Na základě tohoto šifrovacího algoritmu je vytvořeno zabezpečené připojení SSL.

    Digitální certifikát

    Digitální certifikát je elektronický dokument, který identifikuje vlastníka. Obsahuje základní údaje o vlastníkovi, veřejný klíč vlastníka, data expirace, digitální podpis vydavatele (vydavatele) a další potřebné informace. Digitální certifikát má sekci rozšíření (volitelné), která obsahuje distribuční body seznamu odvolání, informace o vydavateli atd. Digitální certifikát umožňuje nastavit zabezpečené připojení SSL. Jak vytvořit certifikát SSL je popsáno dále v tomto článku.

    Hlavní vlastnosti výše uvedených certifikátů jsou:

    Certifikát SSL certifikační autority musí obsahovat pole CA nastavené na hodnotu TRUE, což umožňuje vydávání dalších certifikátů, tzn. tento certifikát není v řetězci konečný.

    SSL certifikáty serveru v poli CN (common name) musí obsahovat název domény nebo ip-adresu, na které je server přistupován, jinak bude certifikát zneplatněn;

    Klientské SSL certifikáty obsahují e-mailovou adresu klienta, jméno a příjmení. Na rozdíl od certifikátu serveru není pole CN pro obsah kritické a může obsahovat křestní jméno a příjmení a také e-mailovou adresu.

    Digitální certifikát SSL je považován za platný v době platnosti uvedené v jeho polích. Certifikát tedy nelze použít před datem zahájení a po datu vypršení platnosti, protože. systémy, které s ním přijdou do kontaktu, budou hlásit nedůvěru k němu.

    Existují situace, kdy uživatel nebo vydavatel certifikátu potřebuje certifikát pozastavit nebo úplně zastavit. Řekněme, že soukromý klíč, který by měl být bezpečně uložen, byl ztracen nebo k němu získali přístup vetřelci. V takové situaci musí uživatel kontaktovat vydavatele (vydavatele) certifikátu, aby ten zrušil jeho platnost. Vydavatel také může certifikát zrušit, pokud se zjistí, že klient o sobě uvedl falešné údaje. Pro tyto účely je vytvořen speciální seznam, nazývaný seznam odvolaných certifikátů (CRL). Tento seznam obsahuje sériové číslo certifikátu, datum vypršení jeho platnosti a důvod zrušení. Od okamžiku, kdy certifikát vstoupí do CRL, je považován za neplatný a vydavatel nenese odpovědnost za obsah takového certifikátu. Jednou z metod kontroly seznamu CRL je protokol OCSP, ten však vyžaduje přítomnost OCSP respondéru u certifikační autority.

    Infrastruktura veřejného klíče (PKI)

    Hlavním úkolem infrastruktury veřejného klíče (PKI) je definovat politiku pro vydávání digitálních certifikátů.

    Chcete-li vydávat a odvolávat certifikáty SSL, generovat seznamy odvolání (CRL), potřebujete speciální software (software). Příkladem takového softwaru je Microsoft CA (součást MS Windows Server 2000/2003/2008), OpenSSL (distribuovaný do unixových operačních systémů). Tento software je umístěn na zařízení certifikačního centra.

    Certifikační autorita (CA) je organizace, která vydává digitální certifikáty SSL na základě údajů poskytnutých zákazníkem. Za pravost údajů uvedených v SSL certifikátu je odpovědná výhradně certifikační autorita, což znamená, že vlastníkem certifikátu je přesně ten, za koho se vydává.

    Nejběžnější CA na světě jsou Verisign a Comodo. Těmto certifikátům CA důvěřuje 99 % prohlížečů a většina serverového softwaru. Vytvoření certifikační autority je popsáno níže.

    Zabezpečené připojení SSL s obousměrnou autentizací

    Zabezpečené připojení SSL se nejčastěji používá v elektronickém obchodování. Jako příklad uveďme nákup zboží prostřednictvím elektronického obchodu. Kupující s uvedením čísel a kódů kreditních karet chce mít jistotu, že se nedostanou do nesprávných rukou. Proto se server ověřuje poskytnutím certifikátu klientovi. Garantem této pravosti je certifikační autorita. Klientská data budou zašifrována veřejným klíčem serveru. Tato data lze dešifrovat pouze pomocí soukromého klíče, který je na serveru. Klient se tedy nemusí bát, že jeho data zachytí útočník, stejně je nebude schopen dešifrovat.

    Klientský SSL certifikát se používá v případech, kdy server potřebuje potvrzení, že klient je tím, za koho se vydává. Například banka poskytuje síťový přístup pro správu osobního účtu. Chce se chránit a mít jistotu, že ho kontaktuje majitel tohoto účtu, a ne útočník, který získal přihlašovací jméno a heslo. V této situaci klient poskytne svůj veřejný klíč serveru a všechna data přijatá ze serveru může dešifrovat pouze klient a nikdo jiný, protože. je vlastníkem soukromého klíče.

    Obrázek je schéma, které ukazuje kroky k vytvoření zabezpečeného připojení SSL.

    Obr 1 - Schéma pro vytvoření zabezpečeného SSL spojení s obousměrnou autentizací

    Když se klient pokusí o přístup k chráněnému prostředku, server odešle svůj digitální certifikát. Po obdržení certifikátu jej klient zkontroluje. Ověření je následující: datum začátku a konce platnosti nesmí vypršet, vydavatel certifikátu musí být důvěryhodný, certifikát nesmí být v CRL. Pokud kontrola selže, proces navázání spojení se přeruší. Pokud jsou splněny podmínky ověření, klient odešle svůj certifikát na server. Server provede podobnou kontrolu. Pokud se kontrola nezdaří, server odepře přístup ke svým prostředkům. Po úspěšném ověření je navázáno zabezpečené spojení a data jsou přenášena v šifrované podobě.

    V tomto schématu jsou přenášená data dvojitě zašifrována. Klient zašifruje zprávu veřejným klíčem serveru a poté svým vlastním soukromým klíčem. Po přijetí zprávy server dešifruje zprávu pomocí veřejného klíče klienta a poté pomocí jeho soukromého klíče. Server a klient se tedy vzájemně ověřují, protože pouze oni mohou dešifrovat přijatá data.

    Je třeba poznamenat, že použití této techniky snižuje rychlost výměny dat, protože operace šifrování/dešifrování vyžadují další čas a rychlost jejich provádění závisí na výkonu výpočetních zdrojů.

    Vytvoření certifikační autority

    Pro účely testování nebo v případech, kdy není praktické kupovat digitální certifikát, byste si měli vytvořit vlastní CA.

    Kořenová CA je CA, které všichni důvěřují. Má SSL certifikát, který je podepsán vlastním soukromým klíčem. Takové certifikáty SSL se nazývají self-signed.

    Soukromý klíč kořenové CA musí být velmi zabezpečený, protože pokud dojde ke ztrátě nebo odcizení, dojde ke ztrátě důvěry ve všechny podřízené certifikáty SSL.

    Podřízená CA je CA, která vydává certifikáty SSL klientům. Certifikát podřízené certifikační autority je podepsán privátním klíčem nadřízené certifikační autority. Jako klienti podřízeného certifikačního centra mohou vystupovat certifikační centra, webové servery, webové prohlížeče, poštovní klienti, pro které jsou generovány certifikáty požadovaného typu. Typy certifikátů jsou určeny politikou certifikační autority.

    Z výše uvedeného vyplývá, že je vytvořen řetězec certifikátů od kořenové CA až po finální klientský certifikát.

    Obr. 2 - Řetězec certifikátů

    Pro vytvoření certifikační autority použijeme dvouúrovňové schéma znázorněné na obrázku 3. Toto schéma má kořenovou certifikační autoritu (Root CA) a podřízenou certifikační autoritu (Issuing CA). Kořenová CA podepisuje svůj vlastní certifikát SSL a certifikáty SSL podřízených CA. Je třeba poznamenat, že čím více úrovní je použito, tím je schéma bezpečnější.

    V certifikátech kořenové a podřízené certifikační autority jsou distribuční místa CRL registrována v rozšíření. Distribuční bod CRL je síťová adresa. Na tuto adresu by měl být s danou frekvencí nahrán soubor CRL vygenerovaný speciálním softwarem.

    Obr. 3 - Dvouúrovňové schéma certifikačního centra

    Příklad organizace certifikační autority na základě Microsoft CA naleznete v článku Nasazení řetězce certifikačních autorit založených na Microsoft CA.

    Získání certifikátu SSL serveru od CA a konfigurace kontejneru Servlet

    Digitální certifikát serveru SSL vám umožňuje vytvořit zabezpečené připojení SSL, které vám umožní přenášet data v šifrované podobě.

    Chcete-li získat certifikát, který bude kontejner servletu používat, musíte CA vygenerovat žádost o podepsání certifikátu (CSR). Požadavek obsahuje základní informace o organizaci a veřejný klíč.

    Hlavní pole, které musí být správně vyplněno, se nazývá Common Name (CN). V tomto poli musíte zadat název domény nebo IP adresu hostitele, kde je umístěn kontejner servletu.

    Chcete-li vygenerovat soukromý a veřejný klíč a požádat o certifikát SSL, můžete použít nástroj keytool, který je součástí sady JDK (Java development kit).

    Na příkazovém řádku zadejte následující příkaz:

    $JAVA_HOME\bin> keytool -genkey -alias -keyalg -úložiště klíčů

    Obr. 4 - Vytvoření úložiště certifikátů SSL pomocí nástroje keytool

    Tento příkaz keytool vytvoří paměť certifikátů s názvem , který uchovává soukromý klíč a certifikát SSL s vlastním podpisem, zašifrovaný pomocí algoritmu RSA. K certifikátu SSL můžete přistupovat podle jména .

    Během vytváření úložiště vás nástroj keytool vyzve k zadání hesla pro přístup do úložiště, informací o organizaci a hesla pro tajný (soukromý) klíč. Když odpovídáte na klíčovou otázku "Jaké je vaše jméno a příjmení?" musíte zadat název domény nebo ip-adresu hostitele, protože hodnota odpovědi bude použita jako pole CN certifikátu SSL.

    Po vygenerování úložiště klíčů obslužným programem keytool by měla být certifikační autoritě zaslána žádost o podepsání certifikátu SSL. To se provádí příkazem:

    $JAVA_HOME\bin> keytool -certreq -keyalg RSA -alias -soubor -úložiště klíčů

    V souboru žádost o certifikát se uloží. Poté se na webu certifikačního centra vyplní speciální formulář a obsah tohoto souboru se zkopíruje do jednoho z polí.

    K vydání SSL certifikátu organizaci může certifikační centrum vyžadovat ustavující dokumenty, registrační certifikát atd. Po obdržení žádosti o SSL certifikát certifikační centrum provede ověření porovnáním údajů v žádosti o certifikát a zaslaných dokumentů a poté žádost podepíše. Podepsaná žádost je certifikát.

    Obr. 5 - Schéma pro získání certifikátu serveru

    Po obdržení certifikátu od certifikační autority je nutné jej po přidání SSL certifikátů kořenové a zprostředkující certifikační autority umístit do úložiště. Chcete-li do úložiště přidat certifikáty SSL, použijte následující příkazy nástroje keytool:

    1) přidání certifikátu kořenové CA pomocí nástroje keytool: $JAVA_HOME\bin> keytool -import -trustcacerts -alias rootca -file -úložiště klíčů

    2) přidání zprostředkujícího certifikátu CA pomocí nástroje keytool: $JAVA_HOME\bin> keytool -import -trustcacerts -alias subca -file -úložiště klíčů

    3) nahrazení self-signed certifikátu certifikátem podepsaným v certifikační autoritě (je uvedena hodnota parametru alias, který byl použit při vytváření úložiště): $JAVA_HOME\bin> keytool -import -trustcacerts -alias -soubor -úložiště klíčů

    Aby aplikace mohly používat zabezpečené připojení SSL, musí být nakonfigurován kontejner servletu. Pro Apache Tomcat a JBoss přidejte do souboru server.xml následující obsah:

    clientAuth="false" sslProtocol="TLS"

    keystoreFile=" "

    keystorePass=" "

    keystoreType="JKS"

    keyAlias=" "

    Tato položka umožňuje kontejneru servletu vytvořit zabezpečené připojení pomocí digitálního certifikátu SSL, který je umístěn v úložišti S heslem podle aliasu .

    Výše uvedená konfigurace využívá jednosměrnou autentizaci, tzn. poskytnutí digitálního certifikátu SSL je vyžadováno pouze ze serveru. Pro vytvoření obousměrné autentizace, tzn. když klient poskytuje také digitální certifikát SSL, musíte změnit konfiguraci kontejneru servletu následovně:

    maxThreads="150" schéma="https" secure="true"

    clientAuth="true" sslProtocol="TLS"

    keystoreFile="

    keystorePass=" "

    keystoreType="JKS"

    keyAlias=" "

    truststoreFile="

    truststorePass=" "truststoreType="JKS"

    V této konfiguraci je nastaven parametr clientAuth=”true” a je připojeno důvěryhodné úložiště. Vytvoření úložiště důvěryhodných certifikátů SSL se provádí pomocí nástroje keytool stejným způsobem jako běžné úložiště. Musíte k němu přidat certifikáty certifikačních autorit, které vydávají digitální certifikáty, kterým by měl kontejner servletu důvěřovat. Jinak budou certifikáty poskytované SSL kontejnerem servletu během ověřování odmítnuty. nebude se jim věřit.

    Kontrola odvolaných certifikátů na serveru

    Existují 3 způsoby, jak ověřit certifikát pro odvolání: statické ověření CRL, dynamické ověření CRL a ověření OCSP. Zvažme tyto metody podrobněji.

    1) Statická kontrola CRL

    Při použití tohoto typu ověření musí administrátor serveru zadat v konfiguraci název souboru na lokálním disku, kde se nachází seznam odvolaných certifikátů. Tento seznam je stažen ze síťového prostředku certifikačního úřadu.

    Chcete-li připojit CRL v kontejnerech servletů Apache Tomcat a Jboss, přidejte do konektoru ssl následující atribut:

    crlFile=”

    Nevýhodou tohoto způsobu je nutnost neustálého sledování aktualizace souboru CRL ze strany správce.

    2) Dynamická kontrola CRL

    Tato metoda umožňuje provádět kontrolu CRL automaticky. To vyžaduje, aby byl atribut CRLDistributionPoint zadán v části rozšíření certifikátu SSL poskytnutého klientem, který určuje adresu URL, kde se nachází seznam odvolaných certifikátů (CRL).

    Aby mohl být klientský certifikát SSL ověřen v CRL, musí být pro Java Virtual Machine nakonfigurovány dva parametry. Tyto volby lze zadat ve spouštěcím skriptu kontejneru servletu. Pro Apache Tomcat a Jboss ve Windows to vypadá takto:

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

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

    Volba java.security.debug=certpath vám umožňuje sledovat ověřování certifikátů v konzole běžícího kontejneru.

    Mezi nevýhody této metody patří zpoždění v přístupu k chráněnému zdroji spojené se stahováním velkého souboru CRL.

    3) Ověření pomocí protokolu OCSP

    OCSP (Online Certificate Status Protocol) byl vyvinut jako alternativa k CRL. Tato kontrola je podporována technologií JSSE (Java Secure Socket Extension) od verze JDK 5. OCSP funguje ve spojení s CRL. K CRL se přistupuje, když během komunikace OCSP dojde k chybě. Pokud OCSP určil stav certifikátu SSL, kontrola CRL se neprovádí. Certifikát může mít jeden ze tří stavů: odvolaný, normální, neznámý.

    Pro ověření OCSP musí certifikát obsahovat atribut AuthorityInfoAccess v sekci rozšíření s hodnotou adresy URL OCSP respondéru.

    OCSP Responder je software umístěný na síťovém prostředku certifikační autority, který zpracovává požadavky na zjištění stavu certifikátu a vydává výsledky ověření.

    Aby mohl virtuální stroj Java kontrolovat OCSP, musíte nastavit vlastnost ocsp.enable=true. Tato vlastnost je nakonfigurována v souboru JAVA_HOME\jre\lib\security\java.security. V tomto souboru můžete zadat adresu OCSP respondéru ve vlastnosti ocsp.responderURL. Tato vlastnost se použije, pokud v certifikátu SSL není žádná adresa URL odpovídače.

    Získání klientského SSL certifikátu od certifikační autority a konfigurace webového prohlížeče

    Existují situace, kdy server nejen potřebuje prokázat, že je tím, za koho se vydává, ale také když server vyžaduje, aby klient prokázal svou identitu digitálním certifikátem.

    Klientský SSL certifikát můžete získat, aniž byste sami generovali žádost, a to pomocí certifikační autority. K tomu je třeba na stránkách CA vyplnit formulář se jménem, ​​příjmením, e-mailovou adresou apod. Na základě těchto údajů bude vygenerována žádost. V této situaci je generování tajného klíče přiřazeno certifikační autoritě. Po ověření dat a podepsání požadavku je klientovi zaslán soubor obsahující tajný klíč a certifikát a také soubory kořenové a zprostředkující certifikační autority.

    Po obdržení souborů certifikátu je třeba nakonfigurovat software, který vytvoří zabezpečená připojení.

    Obr. 6 - Schéma pro získání SSL klientského certifikátu

    Jako příklad si nainstalujme klientský SSL certifikát do webového prohlížeče Microsoft Internet Explorer. Chcete-li to provést, vyberte z nabídky Nástroje > Možnosti Internetu. Na záložce "Obsah" vyberte "Certifikáty ...".

    Obr. 7 - Správa SSL certifikátů v MS Internet Explorer

    Spusťte Průvodce importem certifikátu kliknutím na tlačítko "Importovat...". V tomto průvodci zadejte cestu ke kořenovému certifikátu CA. Dále vyberte úložiště důvěryhodných kořenových certifikačních úřadů a přidejte do něj certifikát.

    Podobně jsou certifikáty zprostředkujících CA přidány do úložiště "Zprostředkující CA" a klientský certifikát do úložiště "Osobní".

    Obr. 8 - Certifikační řetězec

    Pro zobrazení obsahu certifikátu vyberte požadovaný SSL certifikát a klikněte na tlačítko "Zobrazit".

    Pokud je klientský certifikát získán od známé certifikační autority, pak jsou její SSL certifikáty zpravidla již obsaženy v úložištích webového prohlížeče a není třeba je přidávat. Stačí přidat klientský certifikát.

    Pokud server, se kterým bude interakce provedena, obdržel certifikát, který není od běžné certifikační autority, pak by měl být serverový certifikát přidán mezi důvěryhodné, aby webový prohlížeč nezobrazoval hlášení o nedůvěře k takovému certifikátu.

    Kontrola odvolaných certifikátů na klientovi

    Pokud klient používá webový prohlížeč MS Internet Explorer, pak jej lze nakonfigurovat tak, aby kontroloval odeslané certifikáty v CRL. Chcete-li to provést, přejděte na kartu "Upřesnit" v Možnostech Internetu a zaškrtněte dva atributy "Kontrola odvolání certifikátů vydavatele" a "Kontrola odvolání certifikátů serveru".

    Nastavení přístupu na web

    Další nastavení serveru pro webový přístup

    Nastavení zabezpečeného připojení (založené na Secure Socket Layers, SSL)

    V případě potřeby můžete nakonfigurovat ochranu připojenís webovým přístupovým serverem DIRECTUM : Informace přenášené komunikačními kanály budou šifrovány. Abyste mohli pracovat se zabezpečenými připojeními, proveďte následující:

    1. Proveďte změny v konfiguračním souboru serveru pro webový přístup:

    · Krok 1: Spusťte konfigurační nástroj Web Access Server C:\Program Files\DIRECTUM Company\WebAccessConfig\DirWebConfigurator.exe.

    · Krok 2. Okno "Select the Web Site of the Web Access Server". DIRECTUM":

    A) v rozevíracím seznamu vyberte webovou stránku serveru pro webový přístup DIRECTUM . Ve výchozím nastavení se nazývá "Web Access Server". DIRECTUM";

    b) klikněte na tlačítko OK ;

    · Krok 3. Okno "Web Access Server Settings". DIRECTUM “, záložka „Obecné“:

    A) v rozevíracím seznamu "Zabezpečené připojení" vyberte hodnotu "Pro vzdálené". Pokud je nutné vytvořit zabezpečené připojení pro uživatele místní sítě, vyberte hodnotu „Pro vzdálené a místní“;

    b) klikněte na tlačítko OK .

    2. Nakonfigurujte službu IIS pro práci s protokolem SSL -připojení instalací ověřovacího certifikátu serveru. K tomu je vygenerován certifikát s účelem „Poskytuje získání identifikace ze vzdáleného počítače“ s možností exportu do služby podnikového certifikátu, v důsledku čehož musíte získat *. pfx -soubor soukromého klíče.

    3. Pokud používáte Certificate Web Service Okna pak proveďte následující:

    A) Při generování certifikátu uveďte možnost případného exportu certifikátu. Jakmile je certifikát nainstalován v místním systému, lze jej zobrazit pomocí internet Explorer – Položka nabídky „Možnosti Internetu“, karta „Obsah“, tlačítko Certifikáty . Pro export použijte tlačítko Vývozní , upřesněte Ano, exportovat soukromý klíč a zadejte heslo.

    b) Importujte certifikát. Chcete-li to provést, na kartě „Zabezpečení adresáře“ na kartě vlastností webu klikněte na tlačítko Certifikáty a podle pokynů na obrazovce importujte certifikát pomocí hesla, které bylo nastaveno v předchozím kroku. Po obdržení certifikátu bude navázán a zprovozněn port zabezpečeného připojení 443 SSL bude možné.

    4. Chcete-li podporovat otevřená (nezabezpečená) připojení, musíte tuto možnost nastavit Povolit podporu pro otevřená připojení HTTP na kartě Web ve vlastnostech webu.

    5. Abyste mohli nainstalovat certifikát certifikační autority pomocí odkazu z přihlašovací stránky, potřebujete uživatele, který spouští aplikační skupinu " DIRECTUM “, povolte „Číst“ a „Vyžadovat certifikáty“ v modulu snap-in „Certifikační autorita“ ve vlastnostech požadované certifikační autority na záložce „Zabezpečení“.

    Viz také:

    Tabulka 10.1. Místo SSL v modelu OSI
    Číslo úrovně Název úrovně
    7 Aplikovaný
    6 Reprezentace
    5 zasedání
    SSL
    4 Doprava
    3 síť
    2 odvedeny
    1 Fyzický

    SSL verze 3.0 byl základem pro protokol Transport Layer Security (TLS), který se od SSL liší v drobných detailech. V následujícím textu bude termín SSL označovat oba protokoly.

    10.1. Výměna dat v SSL

    Proces výměny dat pomocí protokolu SSL je znázorněn na Obr. 10.1.

    Kdykoli se klient připojí k serveru, spustí se relace SSL. V rámci každé relace je možné více připojení. Pokud se klient připojí k jinému serveru, zahájí se nová relace, aniž by byla přerušena ta aktuální. Při návratu k prvnímu serveru může uživatel buď obnovit připojení pomocí dříve nastavených parametrů, nebo vytvořit nové připojení. Aby se zabránilo útokům, SSL zahrnuje časový limit relace (obvykle 24 hodin), po kterém je relace ukončena a musí být vytvořena nová relace, aby mohla pokračovat komunikace se serverem.

    Relace SSL je charakterizována následujícími hodnotami.

    • ID relace (Session_ID) – náhodné číslo vygenerované na straně klienta, které vám umožní vrátit se k již navázané relaci.
    • Host certifikáty (Client_Certificate a Server_Certificate) - certifikát účastníka výměny informací podle normy ISO/IEC 9594-8.
    • Metoda komprese - algoritmus pro kompresi přenášených dat. Podporované algoritmy jsou specifikovány v RFC 3749.
    • Specifikace šifry - definuje parametry krypto algoritmů:
      • pro výměnu klíčů a ověřování: kryptosystém veřejného klíče RSA, protokol generování sdíleného tajného klíče Diffie-Hellman, DSA (Digital Signature Algorithm), Fortezza.
      • pro symetrické šifrování: RC2, RC4, DES, 3DES, IDEA, AES;
      • pro hashování: SHA, MD5.
    • Tajný klíč relace (Master_Secret) je tajný klíč sdílený mezi klientem a serverem.
    • Příznak obnovení – parametr, který určuje, zda lze vybrané parametry uložit pro nové připojení v rámci aktuální relace.
    • Spojení SSL je charakterizováno následujícími hodnotami.
    • Náhodná čísla (Client_Random a Server_Random) použitá ke generování sdíleného tajného klíče.
    • Klíče pro šifrování/dešifrování informací (Client_Write_Secret = Server_Read_Secret a Server_Write_Secret = Client_Read_Secret).
    • Klíče pro podepisování zpráv (secret Server_MAC_Write_Secret a Client_MAC_Write_Secret).
    • Inicializační vektory (Server_IV a Client_IV) - synchronizují zprávy pro blokové šifrovací algoritmy.
    • Dvě po sobě jdoucí čísla pro server a klienta, aby se zabránilo zachycení a přehrání útoků.

    10.2. SSL protokoly

    SSL zahrnuje čtyři protokoly, které jsou znázorněny na Obr. 10.2:

    • podání ruky;
    • záznam;
    • upozornění;
    • CCS (Change Cipher Specification).


    Rýže. 10.2.

    podání ruky. Tento protokol je určen pro vzájemnou autentizaci klienta a serveru, navázání relace nebo spojení.

    Nastavení relace, schematicky znázorněné na Obr. 10.3 je obvykle inicializován klientem zprávou ClientHello (někdy se server inicializuje odesláním zprávy HelloRequest indikující, že server je připraven na Handshake), ve které klient předává následující parametry:

    • verze SSL podporovaná klientem;
    • identifikátor relace - hodnota, pomocí které lze později obnovit relaci;
    • náhodné číslo Client_Random;
    • seznam algoritmů pro kompresi, šifrování a hašování informací podporovaných klientem.


    Rýže. 10.3.

    Jako odpověď na tuto zprávu server odešle zprávu ServerHello obsahující následující parametry:

    • verze SSL podporovaná serverem;
    • náhodné číslo Server_Random;
    • seznam algoritmů pro kompresi, šifrování a hašování informací, které budou použity při implementaci relace nebo připojení.

    Kromě této zprávy server odešle svůj vlastní certifikát. V případě, že použité algoritmy vyžadují klientský certifikát, server odešle klientovi žádost o certifikát - CertificateRequest. Server poté odešle zprávu ServerHelloDone klientovi, která označuje konec zprávy ServerHello.

    Pokud klient nepodporuje algoritmy navržené serverem nebo neposlal svůj certifikát jako odpověď na příslušný požadavek, pak se navázání relace přeruší. V opačném případě klient ověří certifikát serveru, vygeneruje Pre_Master_Secret, zašifruje jej veřejným klíčem serveru odvozeným z certifikátu serveru a odešle výslednou hodnotu ve zprávě ClientKeyExchange. Server dešifruje přijatou zprávu pomocí svého soukromého klíče a extrahuje Pre_Master_Secret. Obě strany (klient a server) tedy mají tři hodnoty - Server_Random, Client_Random a Pre_Master_Secret a mohou vypracovat Master_Secret podle schématu znázorněného na obr. 10.4.


    Rýže. 10.4.

    Poté obě strany pošlou zprávu Finished, což jsou parametry relace zašifrované na tajném klíči Master_Secret a symbolizuje dokončení procesu navázání nové relace.

    Spojení je dokončeno odesláním zpráv ChangeCipherSpec klienta a serveru, které potvrzují přijetí obou stran algoritmů pro kompresi, šifrování a hashování informací a Dokončené zprávy, symbolizující dokončení procesu navazování nového spojení.

    záznam. Tento protokol je navržen pro převod dat přenášených relační vrstvou do transportní vrstvy a naopak. Konverze dat probíhá podle schématu na obr. 10.7.

    Informace přenášené odesílatelem jsou rozděleny do bloků ne větších než 2^14 + 2048 bajtů. Každý blok je poté komprimován pomocí zvoleného kompresního algoritmu. Poté se vypočítá MAC každého bloku a připojí se k poslednímu bloku. Přijaté fragmenty jsou postupně očíslovány, aby se zabránilo útokům, zašifrovány pomocí zvoleného algoritmu a přeneseny do transportní vrstva. Příjemce dešifruje přijaté fragmenty, zkontroluje pořadí jejich čísel a integritu zpráv. Fragmenty jsou poté rozbaleny a spojeny do jediné zprávy.

    CSS. Protokol CSS se skládá z jediné zprávy umožňující provedení protokolu Record transformace dat pomocí vybraných algoritmů.

    Upozornění. Tento protokol generuje chybové zprávy, které se vyskytují během přenosu dat nebo navazování relace nebo připojení. V závislosti na povaze chyb bude vydáno varování nebo bude připojení/relace ukončeno. Příklady chyb jsou uvedeny v tabulce. 10.2.

    Tabulka 10.2. Chyby generované protokolem Alert
    název Popis
    přístup odepřen certifikát odvolán během platnosti relace/připojení
    špatný_certifikát chyba certifikátu
    bad_record_mac špatný MAC
    platnost certifikátu vypršela vypršela platnost certifikátu
    certifikát_odvolán zneplatněný certifikát
    certifikát_neznámý neznámý certifikát
    close_notify dobrovolné ukončení relace ze strany odesílatele
    decode_error chyba rozdělení/sloučení bloku
    dekompresní_selhání chyba dekomprese komprimovaného bloku
    decrypt_error chyba dešifrování související se selháním ověření podpisu
    dešifrování se nezdařilo chyba dešifrování způsobená nesprávným nastavením parametrů při šifrování zprávy
    export_restriction chyba způsobená exportními omezeními
    handshake_failure nelze nastavit obecné parametry připojení
    nelegální_parametr nesprávné parametry relace/připojení
    nedostatečné_zabezpečení nedostatečná míra utajení algoritmů na straně klienta
    interní chyba Interní chyba
    no_renegociation chyba způsobená nemožností dokončit protokol Handshake
    Protocol_version verze klientského protokolu není podporována serverem
    záznam_přetečení délka bloku zpráv přesahuje 2^14+2048 bajtů
    neočekávaná_zpráva předčasně přijatá zpráva
    neznámý_ca nesprávný podpis certifikační autority
    nepodporovaný_certifikát nepodporovaný certifikát
    uživatel_zrušeno přerušení protokolu Handshake klientem

    10.3. Použití SSL v platebních systémech

    Většina elektronických platebních systémů, zejména internetových obchodů, využívá při své práci webové prohlížeče. Vzhledem k tomu, že SSL je zabudováno do téměř všech známých webových prohlížečů, je na něm v 99 % případů založena bezpečnost přenášených dat [ 3GPP TR 21.905: Vocabulary for 3GPP Specifications.]. Je však třeba vzít v úvahu následující negativní aspekty SSL, které je třeba vzít v úvahu při rozhodování, zda použít tento protokol při organizování zabezpečeného kanálu pro interakci mezi účastníky elektronických platebních transakcí.

    • Nedostatek ověření kupujícího. Navzdory skutečnosti, že protokol SSL má možnost vyžádat si certifikát kupujícího, je ověření kupujícího nepovinné a zpravidla se neprovádí, což znemožňuje použití SSL při transakcích s bankovním účtem.
    • Autentizace prodejce pomocí URL. Certifikát poskytnutý prodejcem pouze indikuje jeho spojení se zadanou URL, přičemž neexistují žádné informace o interakci mezi prodejcem a bankou obsluhující zadaný platební systém.
    • Otevřenost údajů o kupujícím. Navzdory skutečnosti, že všechny informace přenášené v rámci SSL jsou šifrované, jsou bankovní údaje kupujícího zaslány prodávajícímu v čisté podobě.
    • Exportní omezení protokolu. Navzdory skutečnosti, že v roce 1999 se ministerstvo zahraničí USA rozhodlo odstranit omezení exportu, některé prohlížeče podporují protokol SSL s omezením exportu na délku klíčů pro algoritmy šifrování informací, což výrazně snižuje bezpečnost přenášených dat.

    Vydali jsme novou knihu „Marketing obsahu sociálních médií: Jak se dostat do hlavy předplatitelů a přimět je, aby si vaši značku zamilovali.“

    Svět je posedlý internetovou bezpečností. Pokud jste v trendu a odpovídáte výhradně v telegramu, přečtěte si o tom, jak vytvořit zabezpečené připojení na webu. V každém případě se bude hodit a pokud jste internetový obchod, tak se bez něj vůbec neobejdete. Po cestě si promluvme o certifikátech: co to je a proč jsou potřeba.

    Co je HTTPS

    Toto je protokol zabezpečeného připojení. Šifruje informace vyměňované mezi serverem a prohlížečem uživatele – to pomáhá chránit hesla, čísla kreditních karet a e-mailové adresy. Využití HTTPS je silné a dělá ho v očích vyhledávačů o něco atraktivnějším – Google řadí zabezpečené stránky výše než ty nezabezpečené. Chcete-li na svém webu povolit protokol HTTPS, musíte nejprve na server nainstalovat certifikát SSL.

    Proč potřebujete certifikát SSL

    Tvoří jedinečný digitální podpis webu, který pomáhá zabezpečit spojení. Bez SSL certifikátu se k protokolu HTTPS nedostanete, ať se budete snažit sebevíc. Obsahuje:

    • doména webu;
    • úplný právní název společnosti vlastníka;
    • fyzická adresa společnosti;
    • doba platnosti certifikátu;
    • Podrobnosti o vývojáři SSL.

    Budete také potřebovat certifikát pro připojení k jakémukoli platebnímu systému, jako je Yandex.Money. Logika je jednoduchá – nikdo vás nenechá riskovat cizí peníze.

    Jak vybrat SSL certifikát

    Jsou rozděleny do dvou typů, v závislosti na stupni ochrany a.

    Ověření domény SSL

    Nejjednodušší varianta. Bude fungovat, až ověříte vlastnictví domény. Můžete to udělat třemi způsoby:

    • Prostřednictvím e-mailu. Obdržíte e-mail s pokyny pro ověření. Jako odesílací adresa je vybrána buď pošta z domény Whois, nebo poštovní schránky správce nebo webmastera.
    • Prostřednictvím záznamu DNS. Pokud máte nastavený e-mailový server, vytvořte vlastní záznam DNS. Podle ní systém potvrdí, že jste skutečně vlastníkem stránky. Metoda je automatizovaná a vhodná pro ty, kteří mají v nastavení skrytý Whois mail.
    • Prostřednictvím hash souboru. Umístěte na server speciální soubor TXT, aby certifikační úřad mohl určit jeho existenci.

    Takové ověření je vhodné, pokud máte osobní blog nebo malou offline firmu, protože vám neumožňuje chránit subdomény a provádět finanční transakce. Navíc pro potvrzení čistoty domény a vašich myšlenek nemusíte dělat nic složitého a hotový certifikát je rychle hotový.

    Ověření podnikání

    Tento typ certifikátu SSL je bezpečnější, protože potvrzujete, že je společnost připojena k webu. Chcete-li to provést, musíte do ověřovacího centra odeslat několik dokumentů a přijmout hovor na firemní číslo. Certifikáty Business Validation se dělí na 3 typy:

    • Rozšířené ověření SSL. Jedná se o rozšířené ověřovací certifikáty. Potřebuje je každý, kdo pracuje s velkým množstvím peněz: banky, velké internetové obchody, finanční společnosti, platební systémy.
    • Zástupný znak SSL. Takový certifikát chrání jak samotný web, tak jeho subdomény. Navíc jich může být libovolný počet a mohou být umístěny na různých serverech. Povinné, pokud používáte subdomény s různými regionálními vazbami nebo různými projekty.
    • SAN SSL. Hlavní výhodou tohoto typu certifikátu je podpora alternativních doménových jmen: externích i interních.
    • Podepisování kódu SSL. Potvrzuje kód a softwarové produkty z webu. Vhodné pro vývojáře jakýchkoli aplikací.

    Mohu si na svůj web nainstalovat bezplatný certifikát SSL?

    Ano. Většina těchto produktů je placená, ale existují možnosti, za které nemusíte platit peníze. Jedná se o základní doménově ověřené certifikáty. Neumožní vám připojit online pokladnu ke zdroji, ale budou moci chránit připojení uživatele k serveru. Takové SSL jsou vhodné pro malé informační weby nebo offline podniky. Příkladem je základní StartSSL certifikát.

    Instalace certifikátu SSL

    Nejprve je potřeba vygenerovat CSR žádost o certifikát. Obsahuje všechny informace o vlastníkovi domény a veřejném klíči. Většina poskytovatelů SSL vám to umožňuje jako součást procesu objednávky certifikátu, ale můžete také vygenerovat požadavek na straně webového serveru.

    Při generování klíče CSR musíte zadat:

    • Název serveru: „site.com“ nebo „*.site.com“, pokud získáváte certifikát WIldcard. Hvězdička znamená libovolný počet libovolných znaků před tečkou.
    • Kód země: RU, UA, KZ atd.
    • Region, například Saratov Region.
    • Město.
    • Úplný název organizace nebo jméno vlastníka webu.

    Požadavek CSR je odeslán do ověřovacího centra. V důsledku toho získáte certifikát SSL a soubor se soukromým klíčem, který nelze ztratit a zveřejnit ve veřejné doméně.

    Poté je třeba certifikát nainstalovat na webový server. Zvažte případy s Apache a nginx.

    Apache

    Chcete-li to provést, musíte na server nahrát všechny certifikáty: primární i prostřední. Nejprve potřebujete poslední v adresáři /usr/local/ssl/crt (ve výchozím nastavení, ve vašem případě se může lišit). Budou v něm uloženy všechny certifikáty.

    Poté si stáhněte hlavní certifikát, otevřete jej v libovolném textovém editoru a zkopírujte celý obsah spolu s řádky „ZAČÁTEK“ a „KONEC“.

    V adresáři /ssl/crt/ vytvořte soubor s názvem vashsite.crt a vložte do něj obsah certifikátu.

    Přesuňte soubor soukromého klíče do adresáře /usr/local/ssl/private/

    Do souboru VirtualHost přidejte řádky:

    SSL Engine zapnutý

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

    SSLCertificateFile /usr/local/ssl/crt/yoursite.crt

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

    Musíte zadat platné cesty k souborům. Uložte změny a restartujte server.

    nginx

    Zde je proces instalace SSL certifikátu mírně odlišný. Nejprve musíte zkombinovat kořenový, mezilehlý a SSL certifikát do jednoho. Chcete-li to provést, vytvořte soubor s názvem vashsite.crt a vložte do něj obsah certifikátů spolu s řádky "BEGIN" a "END" (pořadí: SSL, střední, root). Neměly by tam být prázdné řádky.

    Téměř totéž je potřeba udělat se soukromým klíčem – vytvořit soubor vashsite.key a přenést obsah klíče staženého z webu poskytovatele.

    Umístěte oba soubory (yoursite.crt a yoursite.key) do adresáře /etc/ssl/ (toto je výchozí nastavení, ale může se lišit).

    V konfiguračním souboru upravte VirtualHost. Přidat:

    server(
    poslouchat 443;
    ssl zapnuto;

    ssl_certificate /etc/ssl/yoursite.crt
    ssl_certificate_key /etc/ssl/yoursite.key;
    server_name yoursite.com;

    Pokud se adresář s certifikátem a klíčem liší od výchozího, změňte jej.

    Nyní uložte změny a restartujte nginx.

    Jak získat funkční připojení HTTPS

    Po instalaci certifikátů SSL bude stránka dostupná na dvou adresách: http://yoursite.com a https://yoursite.com. Musíte si nechat jen to poslední. Chcete-li to provést, nastavte soubor robots.txt a proveďte přesměrování 301 ze starého webu.

    V "robotech" musíte aktualizovat hostitele. Příklad: Host: https://yoursite.com. Chcete-li nastavit přesměrování, musíte do souboru .htacsess přidat řádky:

    RewriteCond %(SERVER_PORT) !^443$

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

    Nyní zbývá o změnách informovat vyhledávače. V "Webmaster" "Yandex" přidejte stránku s https a zadejte ji jako hlavní pro starý web.

    Výsledek

    Přišli jsme na to, co je to https, jak jej nainstalovat na váš web a jak vše správně nastavit. Tento protokol se již stal standardem připojení a časem na něj přejdou všechny živé weby. Tento proces podporují vyhledávače – přítomnost zavedeného protokolu zabezpečeného připojení HTTPS se stala jedním z hodnotících faktorů. Proto, pokud se chcete dostat nahoru, musíte si jej nainstalovat.