{"id":30214,"date":"2019-10-31T21:34:16","date_gmt":"2019-10-31T18:34:16","guid":{"rendered":"https:\/\/prohoster.info\/blog\/ietf-odobrili-acme-eto-standart-dlya-raboty-s-ssl-sertifikatami\/"},"modified":"2019-10-31T21:34:16","modified_gmt":"2019-10-31T18:34:16","slug":"ietf-odobrili-acme-eto-standart-dlya-raboty-s-ssl-sertifikatami","status":"publish","type":"post","link":"https:\/\/prohoster.info\/et\/blog\/ietf-odobrili-acme-eto-standart-dlya-raboty-s-ssl-sertifikatami","title":{"rendered":"IETF kiitis heaks ACME \u2014 see on standard SSL-sertifikaatidega t\u00f6\u00f6tamiseks","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

IETF on kinnitanud standard<\/a><\/noindex> Automaatne Sertifikaadi Halduse Keskkond (ACME), mis aitab automatiseerida SSL-sertifikaatide saamist. Selgitame, kuidas see t\u00f6\u00f6tab.<\/p>\n

\"IETF<\/a><\/noindex><\/a><\/noindex>
\n\/ Flickr \/ Cliff Johnson<\/a><\/noindex> \/ CC BY-SA<\/a><\/noindex><\/i><\/p>\n

Miks on standard vajalik<\/h2>\n

\nKeskmiselt kulub domeeni seadistamiseks administraatoril \u00fche kuni kolme tunni vahel. Kui tehakse viga, tuleb oodata, kuni taotlus tagasil\u00fckatakse, p\u00e4rast seda saab selle uuesti esitada. See raskendab ulatuslike s\u00fcsteemide juurutamist. SSL-sertifikaati<\/a><\/noindex> Domeeni valideerimise protseduur v\u00f5ib iga sertifitseerimiskeskuse juures erineda. Standardisatsiooni puudumine toob m\u00f5nikord kaasa turvaprobleeme. On teada<\/p>\n

juhtum , kus \u00fche CA s\u00fcsteemi vea t\u00f5ttu verifitseeriti k\u00f5ik esitatud domeenid. Sellistes olukordades v\u00f5ivad SSL-sertifikaadid minna petturlikele ressurssidele.<\/a><\/noindex>Heakskiidetud IETF protokoll ACME (spetsifikatsioon<\/p>\n

RFC8555 ) peaks automatiseerima ja standardiseerima sertifikaadi saamise protsessi. Inimfaktori v\u00e4listamine aitab suurendada domeeninime valideerimise usaldusv\u00e4\u00e4rsust ja turvalisust.<\/a><\/noindex>Standard on avatud ja k\u00f5ik huvilised saavad selle arendusse panustada. Vastavad juhised on<\/p>\n

avaldatud. GitHubi hoidlast<\/a><\/noindex> ACME-s toimub p\u00e4ringute vahetus HTTPS-i kaudu JSON-s\u00f5numite abil. Protokolliga t\u00f6\u00f6tamiseks tuleb sihtpunkti installeerida ACME-klient, mis genereerib esimese p\u00f6\u00f6rdumise korral unikaalse v\u00f5tmepaari. Edaspidi kasutatakse neid k\u00f5igi kliendi ja serveri s\u00f5numite allkirjastamiseks.<\/p>\n

Kuidas see t\u00f6\u00f6tab<\/h2>\n

\nEsimene s\u00f5num sisaldab domeeni omaniku kontaktandmeid. See allkirjastatakse privaatv\u00f5tmega ja koos avaliku v\u00f5tmega saadetakse serverile. Server kontrollib allkirja ehtsust ja kui k\u00f5ik on korras, alustatakse SSL-sertifikaadi v\u00e4ljastamisprotsessi.<\/p>\n

Sertifikaadi saamiseks peab klient t\u00f5estama serverile, et tal on domeeni omandi\u00f5igus. Selleks peab ta sooritama teatud toimingud, mis on vabadele maaomanikele kergesti k\u00e4tte saada. N\u00e4iteks v\u00f5ib sertifitseerimiskeskus genereerida unikaalse tokkeni ja paluda kliendil see oma saidile paigutada. Edasi, CA koostab veeb-p\u00e4ringu v\u00f5i DNS-p\u00e4ringu, et tuvastada v\u00f5tme selle tokeni seest.<\/p>\n

\u0427\u0442\u043e\u0431\u044b \u043f\u043e\u043b\u0443\u0447\u0438\u0442\u044c \u0441\u0435\u0440\u0442\u0438\u0444\u0438\u043a\u0430\u0442 \u043a\u043b\u0438\u0435\u043d\u0442 \u0434\u043e\u043b\u0436\u0435\u043d \u0434\u043e\u043a\u0430\u0437\u0430\u0442\u044c \u0441\u0435\u0440\u0432\u0435\u0440\u0443 \u0444\u0430\u043a\u0442 \u0432\u043b\u0430\u0434\u0435\u043d\u0438\u044f \u0434\u043e\u043c\u0435\u043d\u043e\u043c. \u0414\u043b\u044f \u044d\u0442\u043e\u0433\u043e \u043e\u043d \u0441\u043e\u0432\u0435\u0440\u0448\u0430\u0435\u0442 \u043e\u043f\u0440\u0435\u0434\u0435\u043b\u0451\u043d\u043d\u044b\u0435 \u0434\u0435\u0439\u0441\u0442\u0432\u0438\u044f, \u0434\u043e\u0441\u0442\u0443\u043f\u043d\u044b\u0435 \u0442\u043e\u043b\u044c\u043a\u043e \u0441\u043e\u0431\u0441\u0442\u0432\u0435\u043d\u043d\u0438\u043a\u0443. \u041d\u0430\u043f\u0440\u0438\u043c\u0435\u0440, \u0446\u0435\u043d\u0442\u0440 \u0441\u0435\u0440\u0442\u0438\u0444\u0438\u043a\u0430\u0446\u0438\u0438 \u043c\u043e\u0436\u0435\u0442 \u0441\u0433\u0435\u043d\u0435\u0440\u0438\u0440\u043e\u0432\u0430\u0442\u044c \u0443\u043d\u0438\u043a\u0430\u043b\u044c\u043d\u044b\u0439 \u0442\u043e\u043a\u0435\u043d \u0438 \u043f\u043e\u043f\u0440\u043e\u0441\u0438\u0442\u044c \u043a\u043b\u0438\u0435\u043d\u0442\u0430 \u0440\u0430\u0437\u043c\u0435\u0441\u0442\u0438\u0442\u044c \u0435\u0433\u043e \u043d\u0430 \u0441\u0430\u0439\u0442\u0435. \u0414\u0430\u043b\u0435\u0435, CA \u0444\u043e\u0440\u043c\u0438\u0440\u0443\u0435\u0442 \u0432\u0435\u0431- \u0438\u043b\u0438 DNS- \u0437\u0430\u043f\u0440\u043e\u0441 \u0434\u043b\u044f \u0438\u0437\u0432\u043b\u0435\u0447\u0435\u043d\u0438\u044f \u043a\u043b\u044e\u0447\u0430 \u0438\u0437 \u044d\u0442\u043e\u0433\u043e \u0442\u043e\u043a\u0435\u043d\u0430.<\/p>\n

N\u00e4iteks, HTTP puhul on vajalik paigutada v\u00f5tme v\u00e4\u00e4rtus tokenist faili, mida haldab veebiserver. DNS-i valideerimise k\u00e4igus otsib sertifikaadi keskus unikaalset v\u00f5tit DNS-kirje tekstidokumendis. Kui k\u00f5ik on korras, kinnitab server, et klient on l\u00e4binud valideerimise ja CA v\u00e4ljastab sertifikaadi.<\/p>\n

\"IETF
\n\/ Flickr \/ Blondinrikard Fr\u00f6berg<\/a><\/noindex> \/ Kommertstoodete s\u00fcnd<\/a><\/noindex><\/i><\/p>\n

Uuringud<\/h2>\n

\nAjal s\u00f5nadele<\/a><\/noindex> IETF, ACME on kasulik halduritele, kes peavad t\u00f6\u00f6tama mitu domeeninime. Standard aitab siduda iga domeeni vajalike SSL-idega.<\/p>\n

Ekspertide seas tuuakse standardi eeliste seas esile ka mitmeid turvameetodeid.<\/a><\/noindex>Need peavad tagama, et SSL-sertifikaate antakse ainult t\u00f5eliste domeenide omanikele. Eelk\u00f5ige kasutatakse DNS-r\u00fcnnakute eest kaitsmiseks hulka laiendusi DNSSEC<\/a><\/noindex>, ning DoS-r\u00fcnnakute kaitsmiseks piirab standard \u00fcksikute p\u00e4ringute t\u00e4itmise kiirus \u2014 n\u00e4iteks HTTP meetodile POST<\/a><\/noindex>. ACME arendajad \u201e (mida me eelnevalt mainisime) ja \u201e<\/a><\/noindex> peavad turvalisuse t\u00f5stmiseks lisama DNS-p\u00e4ringutele entropiat ja t\u00e4itma neid mitmest v\u00f5rgupunktist.<\/p>\n

Sarnased lahendused<\/h2>\n

\nSertifikaatide saamiseks kasutatakse ka protokolle SCEP<\/a><\/noindex> ja EST<\/a><\/noindex>.<\/p>\n

Esimene neist t\u00f6\u00f6tati v\u00e4lja Cisco Systemsis. Selle eesm\u00e4rk oli lihtsustada digitaalsete sertifikaatide X.509 v\u00e4ljastamise protseduuri ja teha see maksimaalselt skaleeritavaks. Enne SCEP-i tulekut n\u00f5udis see protsess aktiivset osalemist s\u00fcsteemiadministraatoritelt ja ei skaleerunud h\u00e4sti. T\u00e4nap\u00e4eval on see protokoll \u00fcks levinumaid.<\/p>\n

Mis puudutab EST-i, siis see v\u00f5imaldab PKI-klientidel sertifikaate saada turvaliste kanalite kaudu. See rakendab TLS-i s\u00f5numite edastamiseks ja SSL-i v\u00e4ljastamiseks, samuti CSR-i seotuks saatjaga. Lisaks toetab EST elliptilise kr\u00fcptograafia meetodeid, mis loob t\u00e4iendava kaitse taseme.<\/p>\n

Ajal ekspertide arvates<\/a><\/noindex>, lahendused nagu ACME peaksid saama laiemat levikut. Need pakuvad lihtsustatud ja turvalist SSL-i seadistamise mudelit ning kiirendavad protsessi.<\/p>\n

Lisaartiklid meie ettev\u00f5tte blogist:<\/h5>\n

<\/p>\n