Что проверяет корневой сертификат

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

Для корректной работы механизма автоматической проверки электронной подписи установите на компьютер корневой сертификат ГУЦ Минкомсвязи.

• по ГОСТ Р 34.10-2001 — в разделе «ПАК Головной удостоверяющий центр», Идентификатор ключа: 8B983B891851E8EF9C0278B8EAC8D420B255C95D
• по ГОСТ Р 34.10-2012 — в разделе «ПАК Минкомсвязь России», Идентификатор ключа:

Откройте скачанный файл и нажмите Установить сертификат:

Откроется мастер импорта сертификатов. Нажмите Далее:

Нашли неточность? Выделите текст с ошибкой и нажмите ctrl + enter.

У сертификата отображается статус «Последний сертификат цепи не является доверенным корневым сертификатом».

Причина

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

Решение

Запустите мастер настройки рабочего места. Он сам установит все действующие корневые сертификаты УЦ Тензор. Сделать это можно и вручную:

• Кликните файл правой кнопкой мыши и выберите «Запуск от имени администратора».
• Установите корневые сертификаты, следуя подсказкам мастера установки.

Чтобы установить сертификаты других УЦ, сначала узнайте, какого именно корневого не хватает:

• Сохраните сертификат в файл. Укажите любое имя, система присвоит ему расширение *.cer.
• Запустите файл как программу.
• В открывшемся окне перейдите на вкладку «Путь сертификации».
• Найдите сертификат, у которого отображается ошибка, и дважды кликните его левой кнопкой мыши.
• Установите сертификат в хранилище «Доверенные корневые центры сертификации».

Права и роли

Сегодня мы продолжаем разбираться, как устроен TLS и чем он может быть полезен Патрику и его друзьям. Первую часть истории можно прочитать тут.

Мы остановились на том, что сервер отправил свою часть TLS-handshake клиенту. Теперь клиент должен прежде всего проверить сертификаты – и это самая тяжелая из вещей, которые ему обязательно надо сделать.

Certificate verification

Возможно, вы обратили внимание на формулировку: посылается не сертификат, а сертификаты – сейчас станет понятно, почему (в общем-то, догадаться нетрудно).

Сертификат подписывается ишьюером – тем человеком, который этот сертификат выписал. Для того, чтобы считать этот сертификат правильным и все данные в нем верными, мы должны доверять этому ишьюеру – то есть верить, что он всякую фигню не подписывает. Чтобы вся эта система работала, придумали такую концепцию как корневой сертификат (root certificate).

Root certificate

В принципе, это даже не обязательно должен был быть сертификат – вполне хватило бы просто пары ключей. Потому что единственное, что нам от него надо – это знать, что такому-то центру сертификации (Certificate Authority, CA) соответствует такой-то публичный ключ. Тогда мы можем проверить все сертификаты, которые он выписал, и если мы считаем, что CA не врет, значит, и в сертификатах всё верно. Так что на самом деле Root CA Certificate это такой же сертификат, как и все, просто самоподписанный.

Откуда появляется вера в центры сертификации как в «хороших парней»? Все просто договорились, что вот таким-то организациям можно доверять. У каждого клиента есть список соответствия CA и публичного ключа. Таким образом, каждый клиент знает, что есть вот такой чувак и ключ для него такой. И так это всё и проверяется. То есть – просто записано, просто договорились, что верим.

Intermediate certificate

Следующий в цепочке – Intermediate Certificate. Зачем он нужен? Дело в том, что в случае, если с Root CA Certificate что-то пошло не так, очень сложно его поменять. Центру сертификации нужно сделать новый приватный ключ, новый публичный ключ, всем это всё нужно обновить и так далее, это утомительно и это ломает всю секьюрити. И вообще, чем меньше мы работаем с машиной, на которой находится этот CA, тем меньше шансов, что этот приватный ключ украдут. Поэтому CA выписывают промежуточные сертификаты и уже с их помощью подписывают конечные (end-entity) сертификаты для вашего домена. Такая цепочка происходит очень часто и сертификат для нашего Патрика может быть подписан Губкой Бобом, а сертификат Губки Боба – Мистером Крабсом (а Губка Боб работает на мистера Крабса, как мы знаем из мультика). То есть это, в принципе, может быть вообще одна организация. Для того, чтобы всё это провалидировать, клиенту нужно всю эту цепочку составить и проверить: взять ключик рутового сертификата, проверить, что промежуточный правильный и подпись валидна, потом взять ключик промежуточного сертификата и проверить конечный сертификат.

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

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

Поэтому если вы видите сертификат, в котором этих полей нет, можно возбудиться и что-нибудь покопать – возможно, там всё не очень хорошо.

Basic Constraints

Еще одна штука, которая улучшает секьюрити (и с этим были серьезные баги до 2003 года в Internet Explorer): в промежуточных сертификатах в поле Basic Constraints должно быть написано CA: true, что означает, что этим сертификатам разрешено подписывать конечные сертификаты. Если этой штуки нет, то клиент при проверке цепочки должен сказать: «я не могу принять этот промежуточный сертификат» – несмотря на то, что все подписи совпадают, в субъекте всё совпадает и т.д. Этой штуки нет – до свидания. Internet Explorer не делал этой проверки и люди страдали из-за этого. Казалось бы, мелочь! Но тем не менее.

Еще раз, если кто не понял: если эту штуку не проверять, я могу получить сертификат от Let’s Encrypt и потом этим сертификатом подписывать что угодно. И цепочка будет валидная.

CAPI и SCVP

Еще про верификацию и про цепочку. Есть маленькая особенность – похвалим здесь Windows. Если сервер не отдал сертификат, в обычном (традиционном) подходе сертификат нам взять неоткуда, цепочки нет, всё сломалось. Так вот, в Windows есть такая штука как Certificate API, и она может достроить цепочку, взяв промежуточные сертификаты из своего хранилища. То есть, даже если сервер не передал, но у тебя в хранилище они есть, то цепочка построится и всё будет работать. Достаточно удобная штука, можно пересылать меньше информации, не уменьшая секьюрити.

Как эти сертификаты туда попадают? Либо залиты в хранилище, либо из сертификата, установленного на сервере. Например, в Plesk, если получить сертификат от Comodo и поставить его на домен – в хранилище попадет промежуточный сертификат от Comodo.

Ну и еще люди, которым Windows нравится, придумали SCVP (Server-based Certificate Validation Protocol). В действительности не работает почти ни у кого и нигде – в смысле глобально и массово, — но как концепция есть. Более того, есть продукты, которые это делают, и даже в каких-то сетях это может быть настроено. Это сервис, который за тебя эту цепочку строит и частично даже проверяет, что удобно. Если там заявлена поддержка DPV (Delegated Path Validation), то он цепочку еще и провалидирует. То есть, клиенту надо этому сервису отправить сертификат и получить ответ – продолжать сессию или рвать.

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

Итак, вот у нас получается такая вот цепочка.

Прежде всего мы проверяем, что с подписями у нас всё нормально: выстраиваем цепочку, проверяем подписи – и считаем, что содержимое сертификатов верно. Дальше нам надо проверить конечный сертификат. Промежуточный нам проверять не надо, потому что мы идем к Патрику и проверить нам надо только самый последний сертификат.

Про подпись уже упоминалось. Это вот пример, как это может выглядеть структурно: вот есть подпись, вот алгоритм этой подписи, мы берем какую-нибудь библиотечку, которая умеет с этим работать и проверяем, что тело сертификата подписано вот этой подписью и что всё действительно хорошо.

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

Не протух ли сертификат?

После этого нам надо проверить, что сертификат не протух – это логично, ведь сертификаты выдаются на какое-то время.

Сейчас все certificate Authority договорились, что максимальный срок – 2 года (раньше было 3). Еще дальше они хотят сделать 1 год, а некоторые радикалы хотят, чтобы был месяц. Let’s Encrypt сейчас на 3 месяца выдает. А совсем радикальные радикалы хотят на каждое соединение новый сертификат выписывать. Почему некоторые люди так этим озабочены, станет понятно попозже, когда дойдем до пункта «Не отозван ли сертификат?». Еще из интересного – сертификат может быть выписан на будущее, так что надо проверять дату старта (по-хорошему).

Тот ли домен?

Тут всё понятно: если домен Wikipedia, а сертификат выписан на домен Plesk, то что происходит вообще? Кажется очевидным и капитанистым, но было несколько багов, когда клиенты это не проверяли. Сейчас, по счастью, такого бардака уже нет и стараются проверять все. Но опять-таки есть нюанс. Это SAN – Subject Alternative Name.

Subject Alternative Name

В subject у нас может быть только один домен — в нашем случае там, кстати, есть звездочка, про это попозже, это так называемый wildcard-сертификат. Итак, в субъекте доменное имя одно, но если хочется много (например, у нас есть сабдомены и/или разные имена типа plesk.ru, plesk.com и т.д., и хочется один сертификат на это всё иметь) – тогда есть возможность всё это запихать в это поле SAN. Но нужно, чтобы это работало, во-первых, на сервере, во-вторых, на клиенте. Потому что, чтобы сервер отдал правильный сертификат, клиент должен ему как-то передать, куда конкретно он пришел. Это важно. И когда сервер выбирает сертификат, он должен знать Subject Alternative Name, потому что, может быть, имя домена – там. За всё это отвечает такое расширение TLS, как SNI (Server Name Indication), на эту тему есть 4 RFC, – короче, возможность есть, но не все это поддерживают. Например, у продуктов на GNU TLS с поддержкой SNI всё неплохо, а вот на OpenSSL многие не поддерживают. Кажется, это потому, что в GNU TLS это проще.

Ладно, мы, допустим, всё это умеем. Всё хорошо, всё проверили, пришли сюда.

Как мы должны проверять wild-card? Отдельный момент. Можно просто запомнить: звёздочка это не вообще звёздочка, а только один сегмент.

• Если хотим на domain.com – нам нужно без звездочки.
• Если хотим на foo.bar.domain.com – нам нужно *.bar.domain.com.

Поэтому wild card сертификат без SAN используется довольно редко. Хочется защитить не только сабдомены, но и сам домен – а поле у тебя одно. С этим связаны интересные штуки, как определить, насколько сертификат хорош – есть разные рекомендации. Например, Google Chrome форсит людей на то, чтобы даже если в субъекте у тебя прописан domain.com, то чтобы в SAN он тоже был, потому что они хотят проверять только поле SAN, а субъект не проверять. Но пока еще проверяют.

Еще интересный момент, что www.domain.com – это отдельное имя, и если мы хотим по нему ходить, его надо защитить отдельно. Не у всех это в голове есть.

Ну и да, как уже говорилось, серверу надо найти сертификат для домена. Как работает SNI – клиент в определенном заголовке передает, какой домен нужен. Поэтому это доступно даже на уровне TCP, где доменных имен нет – в TLS есть, а в TCP (и в FTP) нет. Поэтому если мы делаем TLS, мы можем передать имя, но мало передать имя – надо же серверу найти этот сертификат, и здесь есть разные нюансы с разными продуктами. Продукты на Windows нередко находят этот сертификат в хранилище сертификатов, а для продуктов на Linux нужно указывать конфиги, где брать эти сертификаты. И здесь тоже есть разные проблемы. Мы недавно чинили SAN в Postfix – там может быть очень простая вещь — мы, например, указываем, что для domain.com сертификат такой, а человек приходит c mail.domain.com. А mail.domain.com – это не domain.com. Всё, сервер не может найти сертификат, всё развалилось. То есть кому-то надо указывать, кто-то сам находит. Для тестирования и разработки это важная вещь в аспекте SAN.

Ок, пойдём дальше.

Тот ли тип использования?

Кроме проверки, тот ли это домен, не истёк ли срок годности и валидна ли подпись, из таких вещей, которые достаточно просто делаются, у нас еще есть пункт «тот ли тип использования».

Сертификаты бывают разные. То есть, если в Key Usage не указаны вот эти вот два параметра, то это – по идее! – должно влиять на то, как клиент с этим работает.

Key agreement – это как раз когда мы выписываем сеансовые ключи и договариваемся о них. Обычно вся эта коммуникация подписывается или шифруется вот этим вот публичным ключом, который чуть выше. Но если в key usage не прописан key agreement, то это означает, что ишьюер этого сертификата запрещает использовать этот сертификат для вот этого назначения. Сейчас на практике это почти не встречается, то есть эти вещи у большинства сертификатов одинаковые, но тем не менее — в принципе могут быть и другие. И бывает, что сертификат НЕ подходит для чего-то. Для чего он подходит – написано здесь. Клиент должен это проверять. Кстати, нередко бывает, что в extended key usage вот это вот ‘TLS Web Server Authentication’ у промежуточных сертификатов отсутствует.

Не отозван ли сертификат?

Самая интересная вещь – мы дошли до нее, ура! Самая прикольная, самая неработающая 🙂

Если говорить кратко, то сейчас здесь во всей инфраструктуре TLS очень большие проблемы, потому что: не работает ничего. И эту проблему как раз и хотят решать тем, чтобы срок действия сертификата сделать очень маленьким. Когда нужно отзывать сертификат? Чаще всего – когда ваш приватный ключ утек. Ваш приватный ключ утек – вы попали. Надо сертификат отозвать, потому что если не отозвать, тот кто украл ваш ключ, сможет подсовывать клиентам ваш сертификат и представляться вами. Надо сказать: чуваки, я поменял свой ключ – тот сертификат не действителен!

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

Как же проверить, отозван сертификат или нет?

Certificate Revocation List

Поэтому этот механизм считается устаревшим, но в стандартах всё еще есть и по-хорошему надо бы его использовать. Google Chrome на него забил уже давно, Mozilla тоже.

OCSP

Есть другая штука – OCSP. Это примерно то же самое, только вместо того, чтобы качать файлик, делается специальный запрос на то, чтобы та сторона сказала тебе – отозван сертификат или нет. То есть, клиенту стало проще, а вот чуваку на той стороне проще не стало, потому что вместо того, чтобы просто отдавать список, надо по этому списку проверять запрос и говорить «да» или «нет». Если основываться на CRL, другого варианта, кроме этого, особо-то и нет – и это действительно лучше, чем чистый CRL. Тем не менее, Chrome забил и на это, остальные пока используют.

OCSP stapling

Это примерно в ту же степь, но тут мы уже начинаем уходить от структуры Certificate Authority. То есть возлагаем эту проверку на сервер. Как это работает: сервер периодически ходит по этому OSCP URL-у и говорит: «OCSP-resolver, посмотри-ка, вот этот мой сертификат – в отозванных или нет?». OCSP-resolver отвечает подписанным ответом, наш сервер его запоминает, и когда клиент приходит, ему отдаётся этот ответ. То есть у клиента есть подписанный ответ и в нём написано, что всё хорошо. Из-за того, что серверов меньше, чем клиентов и сервер может на какое-то время это кэшировать, нагрузка на всех становится меньше.

Тут есть тоже некоторые проблемы: текущий механизм — это только на один сертификат, а у нас цепочка (и это важно). А еще, из-за того, что мой сервер отвечать на это не обязан, клиент не может рассчитывать на то, что OSCP-stapling точно будет. И поэтому отказаться ни от CRL, ни от OCSP не получается – просто потому, что серверы не обязаны опрашивать и отвечать. Ну и еще один аспект: если в вебе с этим нормально, то в почте всё плохо, а в FTP даже слов таких не знают.

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

Вот это всё вместе теоретически может начать работать, но пока еще мало распространено.

Google и Mozilla, так как им всё это не нравится, сделали свой CRL. И зашили его в браузер. Огонь вообще! Это работает быстро, ну и на этом все плюсы заканчиваются. Для того чтобы не помереть, они не запихивают в него DV-сертификаты. То есть если DV-сертификат отозван, они считают – ну и ладно. Так что если DV-сертификат отозван и при этом нет OSCP-степлинга, Chrome об этом не скажет – он посчитает этот сертификат нормальным. На самом деле, правильно пользоваться OSCP-степлингом и OCSP Must Staple флагом в сертификате. С ним тоже не всё просто — большинство генераторов CSR сейчас не умеют его указывать, а большинство Сertificate Authority не умеют его выписывать.

Сertificate Transparency

Итак, всё хорошо, но Google не был бы Google, если бы не придумал еще одну технологию конкретно для себя. Она называется Сertificate Transparency. Откуда что идет: Google очень беспокоится о том, чтобы кто-нибудь не выписал плохой сертификат на него самого – чтобы именно Google не пострадал от того, что кто-то там выписывает какие-то нехорошие сертификаты. И вот с помощью Сertificate Transparency каждый владелец домена (и вообще кто угодно) может посмотреть, какие сертификаты на этот домен были выписаны. Дальше он может этот сертификат взять и с ним что-нибудь сделать. Например, проверить, хороший он или нет. Ну и возбудиться (или не возбудиться).

Это не только технология, но и набор процессов. То есть Google говорит: ребята, вот у нас есть Сertificate Transparency, мы в него записываем только нормальные сертификаты – такие, где цепочка есть, цепочка правильная и всё нормально. Мы можем время записи Сertificate Transparency Log запихать в сертификат, чтобы клиент мог четче посмотреть, что вот этот сертификат в Transparency Log должен быть тогда-то. Мы гарантируем, что это вот эта штука не редактируема обратно (из-за того, что блокчейн) – ну то есть нельзя взять и подменить старые записи, можно только добавлять новые. И давайте, ребята, кто-нибудь из вас будет периодически ходить по этому логу, и проверять, что там всё нормально, а если что-то не так, говорить нам и мы будем это править. А другие ребята пусть держат у себя всё это, потому что надо, чтобы было много мощностей на вот эту вот штуку.

Сейчас Сertificate Transparency поддерживает DigiCert, недавно начал поддерживать Let’s Encrypt, а вот из валидаторов практически никого нет, Google сам всё это делает. Когда всё это заработает в полную силу и валидаторов станет больше, то плохих сертификатов должно стать меньше, потому что кто-нибудь будет возбуждаться. На картинке показан HTTP-заголовок Excpect-CT, его можно отдать и клиент будет обязан сходить в Сertificate Transparency и проверить, что вот этот сертификат в нем указан. А из-за того, что там еще есть timestamp, сложнее становится запихать плохую запись в Сertificate Transparency. Но, опять-таки — это не очень помогает с Revocation, можно сказать, вообще не помогает. Это только про то, что все сертификаты, выписанные на домен, владелец домена может посмотреть и возбудиться.

Вот такая вот штука. По большому счету – хайпа много, но ничего она не решает. А что решает (каким-то образом), но не используется – это DANE.

Дополнительная защита

Вся структура TLS является уязвимой в одной точке – точке доверия, то есть вот эти вот сертификационные центры, рутовые сертификаты — если с ними что-то не то, всё разлетелось. Есть по сути две попытки с этим как-то бороться.

DANE

Первая попытка, собственно, DANE – хранить информацию о сертификатах в DNS.

Давайте посмотрим на запись детальнее. Здесь есть разные поля: можно указать, что сертификат должен быть выписан именно этим Authority – это уже немного помогает. Принцип тот же, что и у САА, только уже после выписки. Это не зависит от того, смотрит ли ишьюер в САА запись или нет. В DANE написано: клиент обязан посмотреть, что сертификат, который он получил, выписан определенным Certificate Authority, и если это не так – ничего не выйдет. Всё зависит только от клиента и не зависит от CA. Это плюс.

Из остального остановимся на Domain issued certificate. В принципе, если бы всё хорошо работало (здесь ключевая проблема с DNSSEC), то мы бы могли указывать в своей DNS-записи свой сертификат и не зависеть ни от кого. То есть, если я владею доменом, сгенерировал хотя бы самоподписанный сертификат, указал его вот сюда, и DNSSEC работает нормально, то клиент доверяет моей DNS-записи и сертификат берет оттуда. Всё, CA не нужны. Бизнес на сертификатах рушится, денег никаких нет 🙂

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

В общем, спорная вещь, одно меняем на другое, из-за этого теряем EV-сертификаты. Возможно, поэтому это не слишком распространилось.

HPKP

Дальше еще есть одна интересная вещь, называется HPKP.

Идея на картинке: мы в HTTP-заголовке отдаем собственно хэши сертификатов, которые клиент должен проверить, и если публичный ключ сертификата имеет другой хэш (то есть его нет среди перечисленных) — до свидания. Google в HPKP разочаровался и Chrome это не поддерживает. На этом можно закончить, хотя вообще выглядит интересно — если я знаю, какие у меня есть сертификаты, мне очень легко этот заголовок отдать, и это должно повышать секьюрити по идее.

Policy

Как мы уже знаем, если браузер смотрит в это поле и находит там определенные сочетания циферок и буковок, то он должен понять, что это EV-сертификат и, возможно надо сделать дополнительные вещи. Вот тут у нас указан Global Sign Repository – и иногда браузер должен сходить по указанному там адресу и получить ответ, что всё хорошо. Это в основном работает для EV-сертификатов, для OV браузеры это часто просто игнорируют, ну и в DV этих полиси-то и нет собственно. Для чего это надо вам – просто для информации.

Ответ клиента

Итак, Патрик проверил сертификаты и начинает отвечать Губке Бобу.

Если у клиента просили сертификаты, он их отдает. Дальше он отдает информацию для того, чтобы сделать ключики – так же, как сервер, clientKeyExchange. Поле CertificateVerify – неинтересная инфа на тему «как валидировать сертификат», в TLS 1.3 она и выглядит-то уже по-другому, потому что не сильно нужна.

После этого клиент переходит на шифрованный канал и посылает сообщение Finished – «я готов к шифрованному каналу». Сервер проверяет это сообщение – что там всё нормально, как договорились, что оно расшифровывается, что не успели на данном этапе ничего подменить и это всё еще Патрик, — тоже переходит на шифрованный канал и отдает свое Finished-сообщение, которое в свою очередь проверяет клиент. И после этого идет общение уже данными приложений по шифрованному каналу.

TLS-handshake full vs resumed

В этой статье мы не стали подробно останавливаться на том, как выбираются сессионные ключи. Там тоже много работы на процессоре, много вычислительных действий – и следующая проблема после безопасности это производительность. Всё это происходит медленно, особенно, если ходить в CRL списки и делать прочие дополнительные проверки. А если еще цепочка сертификатов огромная, то всё может быть прям совсем медленно, и с этим надо что-то делать.

Session ID

До TLS 1.3 для решения этой проблемы использовались укороченные сессии. Когда сервер отвечает клиенту, он отдает ему Session ID. Если у клиента этот Session ID тоже есть, он отсылает его серверу и вот эта часть, которая в рамочке, пропускается. Потому что сервер запоминает контекст всей этой штуки и продолжает так, как будто это уже произошло. Сессионный ключ выбран, и клиенту не надо проверять сертификат, потому что он есть в этом сессионном ключе. Если окажется, что сертификат там какой-то другой, то выбранный сессионный ключ не будет работать и клиент просто не сможет расшифровать сообщение сервера.

Так это всё работает. Это побыстрее, но тоже есть проблемы, — возрастает нагрузка на сервер, ну и есть атаки с перехватом Session ID. Потому что этот Session ID идет по открытому каналу.

Session ticket

Еще для ускорения можно использовать Session Ticket — это в принципе то же самое, что и Session ID, только передается зашифрованный контекст, а не циферка, которую можно украсть. Бывает, что сессию установить не удалось, тогда придет алерт. С ними тоже связаны атаки на TLS, потому что алерты имеют определенную структуру и определенный размер. Если алерт произошел на этапе, когда уже трафик идет зашифрованным, то из-за того, что алерт понятной структуры и злоумышленник может знать, что ему в этом алерте отвечают – задача расшифровывания становится сильно проще. Поэтому в TLS 1.3 это уже не используется.

Reinit

Что еще бывает в TLS-handshake в принципе? Иногда серверу бывает нужно инициализировать сессию повторно – чаще всего тогда, когда сертификат клиента был не нужен и вдруг стал нужен. Тогда сервер говорит: давай перезапустим. Ну и клиент может сказать еще раз Client Hello. В TLS 1.3 это тоже убрали, потому что тоже были атаки – атаки были везде!

Что в TLS 1

Все упомянутые трудности решаются использованием TLS 1.3. Половины проблем вообще нет, всё проще, красивее, всё прям отличненько. Но TLS 1.3 еще распространен маловато. Самые важные отличия TLS 1.3 (их очень много, они везде, поэтому только самые важные):

• Плохие шифры удалены, остались только хорошие. Инициализировать сессию TLS 1.3 на плохих шифрах не получится. Всё дело в новых cipher suites: тут и другие алгоритмы обмена сеансовых ключей, и так называемый HMAC – не будем углубляться в подробности, потому что Патрик устал. Вкратце: раньше подпись каждого TLS-пакета шла отдельно. На это были атаки, потому что было известно, какой там контент находится. Сейчас ее запихали вовнутрь (режим AEAD), и в TLS 1.3 по-другому быть не может, соответственно, мы избавились от таких атак.
• Handshake стал короче – нет старых сообщений, нет старых расширений, нет возможности по каким-то странным штукам обменяться ключиками. То есть, он тупо короче количественно – даже самый полный TLS 1.3 handshake короче, чем в TLS 1.2.
• Переход на шифрованный канал происходит почти что сразу. Для этого используются разные ключики: да, пока не договорились о хороших ключиках, оптимальных, мы используем какие попало, но канал уже шифрованный. То есть hello – hello и пошло всё зашифрованное. Из-за этого сложнее всё это ломать.
• Всё регламентировано, больше не надо пытаться менять размеры пакетов, забивая их ноликами, чтобы сложнее было расшифровывать.
• Своя пара ключей на каждую сеансовую фазу. Сеансовые ключи меняются: пока мы ни о чем не договорились – они такие, договорились о более крутых – они более крутые, сертификаты проверили и всё хорошо – еще другие ключи. В итоге их много, они усложняются и очень трудно это всё поломать. Еще одна важная вещь, почему это быстрее: Early Data (она же 0-RTT, Zero Round Trip Time) – это когда у тебя в TLS-handshake посылается полезная инфа – ну например GET-запрос. То есть нет такого, что поговорили-поговорили и только потом посылаем что-то отдельным потоком. Сразу же в handshake идет запрос. Как только сервер его получил, он начинает его обрабатывать, отдает клиенту свои данные, сертификат и пока клиент проверяет, сервер уже готов отдать. И может даже в TLS-handshake и отдать иногда.

Основная проблема, что поддержка TLS 1.3 – она во всех браузерах, которые актуальны, есть, но не во всех по дефолту включена. Например, в Safari нет (но там очень легко включить), Google Chrome и Mozilla Firefox уже по дефолту поддерживают TLS 1.3. Ngnix с TLS 1.3 – без проблем, в Apache есть нюансы, а вот с почтовыми клиентами хуже — там только Exim молодец, а остальные не очень.

В общем, это наше будущее, там всё получше и попроще, самое главное. Но пока оно еще не везде наступило.

Как всё это тестить?

Инструментов для тестирования много, большинство из них не очень, вот эти плюс-минус ничего:

Маленький бонус

То, что не влезло.

На картинку тоже не всё влезло – тема очень большая, но на практике можно фокусироваться таким образом, чтобы на любом уровне понимать идею в целом и смочь разгрести что происходит, понять, что вам нужно доучить, что сейчас конкретно нужно узнать и всё вот это. Эта картинка — про ключевые слова. Из литературы можно рекомендовать очень крутую статью на русском языке «Ключи, шифры, сообщения: как работает TLS» – прочитать целиком вряд ли удастся, но в качестве справочника пригодится. Открыл, нашел что надо, почитал, ключевые слова узнал, пошел в википедию и на английском прочитал (на русском почему-то плохо написано). На английском написано отлично: идея, зачем, почему, ссылочки. Не знаешь, что такое HSTS – иди в википедию, там будет ссылочки на статьи для Патриков, то есть чайников. Еще на RFC, но это читать невозможно. Общий смысл станет понятен даже из самой статьи в Википедии.

Вот и всё! Вы молодцы 🙂

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

Проверка сертификата Минкомсвязи России

• Зайдите в приложение «Сертификаты», которое было установлено вместе с КриптоПро CSP, или в приложение «Сертификаты пользователя» certmgr.mscЗапустите приложение «Выполнить» (зажмите клавиши на клавиатуре: кнопку с логотипом Windows + R)Введите certmgr.msc
• Запустите приложение «Выполнить» (зажмите клавиши на клавиатуре: кнопку с логотипом Windows + R)
• Введите certmgr.msc
• Убедитесь, что в подпапке «Сертификаты» папки «Доверенные корневые центры сертификаты» установлен действующий сертификат Минкомсвязи России.

На скриншоте видно, что сертификат Минкомсвязи России установлен в папку «Доверенные корневые центры сертификации», и срок его действия не истёк.

Как установить сертификат Минкомсвязи России? Инструкция.

Если сертификат не установлен, или срок действия сертификата истёк.

Проверка сертификата удостоверяющего центра

На скриншоте видно, что сертификат удостоверяющего центра установлен в папку «Промежуточные центры сертификации», и срок его действия не истёк.

Как установить сертификат вашего удостоверяющего центра? Инструкция.

Если сертификат не установлен, или срок действия сертификата УЦ истёк.

Проверка личного сертификата электронной подписи

На скриншоте видно, что сертификат электронной подписи установлен в папку «Личное», и срок его действия не истёк.

Как установить сертификат электронной подписи? Инструкция.

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

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

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

Для меня эта история началась при заключении договора со страховой компанией ООО СК “Сбербанк страхование”. После оформления мне показались подозрительными некоторые факты (небольшой спойлер: всё оказалось хорошо) и я стал разбираться, как же мне проверить, что полученный документ действительно выдан страховой компанией, а не некими третьими лицами.

Что же меня насторожило?

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

Через полчаса ожидания я стал волноваться, быстрый поиск показал, что у страховой компании есть аж 3 разных активных домена: www.sberbank-insurance.ru, www.sberins.ru и sberbankins.ru, что не добавляло мне уверенности в компании.

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

Глава первая

Все манипуляции с PDF документом приведены в чистой версии ОС Windows 10, русская домашняя редакция, как наиболее вероятной среде работы простого пользователя. Набор софта, используемый в статье, также является непрофессиональным и доступным для всех.

Для начала я открыл документ в просмотрщике Foxit Reader, который использую как основной:

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

Кроме имени организации, которой выдан сертификат, видно наименование выдавшей его организации, ООО “ИТК”. Поиск по запросу “ООО ИТК сертификат” вывел меня на страницу Установка корневого сертификата Удостоверяющего центра ООО «ИТК». Это официальный сайт ООО «Интернет Технологии и Коммуникации», который является одним из удостоверяющих центров, выдающих сертификаты ЭП.

Снова открываем сертификат из документа. И чуда не произошло, цепочка доверия от корневого до конечного не строится!

Изучаем ЭП подробнее: в Foxit Reader есть дополнительная информация о свойствах подписи:

Ага, алгоритм хеширования ГОСТовский, ЭП создана в КриптоПро PDF. Возможно, Windows не знает про ГОСТ шифрование и поэтому ему нужен дополнительный криптопровайдер.

Идём на сайт КриптоПро, регистрируемся, скачиваем пробную версию КриптоПро CSP 5.0 на 3 месяца. Что будет дальше — не совсем понятно, возможно всё превратится в тыкву, посмотрим.

Снова открываем просмотр сертификата ЭП:

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

Сообщение о проверке немного улучшилось, но всё равно Foxit Reader не может проверить сертификат (вероятно дело в ГОСТовском алгоритме):

В Adobe Acrobat Reader DC проверка тоже не успешна:

И на этом вроде бы можно остановиться: Foxit Reader подтверждает, что документ не был изменен после подписания, руками можно проверить, что сертификат подтверждается системой и действителен. Но всё же хочется довести дело до конца, чтобы хотя бы одна программа сказала: да, документ действителен, всё хорошо.

Вспоминаем, что полис подписан в программе КриптоПро PDF. Вероятно, что раз она может создавать такие подписи, то уж наверняка должна их и проверять. Ставим.

+1 триал версия на 90 дней, хотя вроде бы надпись при установке успокаивает, что при использовании продукта в Adobe Acrobat Reader DC лицензия не нужна.

Ура, долгожданное сообщение о том, что всё хорошо.

Подведем промежуточный итог. Для проверки действительности ЭП на документе нужно:

• Узнать, какой удостоверяющий центр выдал сертификат, которым подписан документ, установить его промежуточный и, если такого еще нет, корневой сертификат (в нашем случае из rar архива с Google Drive);
• Установить в систему криптопровайдер (вероятно, существуют другие криптопровайдеры, которые обучат Windows ГОСТовским криптоалгоритмам) КриптоПро CSP с триалом на 3 месяца и неизвестностью после;
• Для проверки подписи из Adobe Acrobat Reader DC установить КриптоПро PDF (без CSP он не ставится).

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

• Нужно понять, какого софта не хватает в системе и где его взять, из коробки ничего не работает. В данной статье приведены примеры на основе продуктов КриптоПро только потому, что это название встретилось в информации о создании ЭП. Нужно изучать тему в поиске аналогов;
• Проверка полноценно заработала только в Adobe Acrobat Reader DC, в Foxit Reader проверка ЭП неполная, нет долгожданной зелёной галочки. Нужно копать дальше, вероятно есть решения.

Глава вторая

Порывшись в почте, я нашел еще один электронный договор. По счастливой случайности, им тоже оказался страховой полис, но на этот раз еОСАГО от АО “Тинькофф Страхование”. Открываем сертификат, смотрим выпустившую сертификат организацию. Ей оказывается АО “Тинькофф банк”. Да, оказывается у них есть свой УЦ, который выдает сертификаты дочерним организациям (у Сбербанка тоже есть свой УЦ, но в дочерних структурах он не используется).

По отработанному алгоритму идём в поисковую систему с запросом “тинькофф сертификат”, находим официальный сайт УЦ АО Тинькофф Банк. Тут нас встречает изобилие ссылок на корневые сертификаты, списки отозванных сертификатов и даже видеоинструкция по их установке. Скачиваем “Цепочка корневых сертификатов УЦ АО Тинькофф Банк ГОСТ Р 34.10.2012”, на этот раз ссылка ведёт не на сторонний сервис, а на сайт банка. Формат файла P7B не очень известный, но открывается Windows без установки стороннего софта и показывает находящиеся в нём сертификаты. Здесь уже привычный корневой сертификат от Минкомсвязи (другой, не тот, что в первом случае) и промежуточный сертификат УЦ банка.

Ставим оба, проверяем сертификат в полисе. Но нет, сертификат не является доверенным, т.к. система не может подтвердить поставщика сертификата. На сайте УЦ было 2 ссылки на 2 цепочки сертификатов, один для ГОСТ Р 34.10.2001, другой для ГОСТ Р 34.10.2012. Полис был выпущен в этом году, логичнее бы его подписать уже более современным криптоалгоритмом (тем более уже есть версия ГОСТ от 2018 года, алгоритмы обновляются довольно часто), но давайте проверим старый.

В новом файле формата P7B оказывается уже 3 файла сертификатов. Можно поставить все 3, однако стоит заметить, что сертификат “Головного удостоверяющего центра” мы поставили в первой главе из RAR архива ООО “ИТК”, они идентичны. А сертификат с не очень говорящим названием “УЦ 1 ИС ГУЦ” поставил КриптоПро CSP, т.к. галочка об установке корневых сертификатов была установлена по-умолчанию в его инсталляторе. Единственным новым является сертификат АО “Тинькофф Банк”, который мы и ставим.

После установки сертификатов из “Цепочка корневых сертификатов УЦ АО Тинькофф Банк ГОСТ Р 34.10.2001” путь в сертификате прорисовался и система радостно сообщила, что он является доверенным. Adobe Acrobat Reader DC также подтвердил, что подпись действительна.

На этом приключения с проверкой ЭП на полисе еОСАГО завершаются. Заметно, что после того, как в системе уже установлен необходимый софт, а пользователь понимает принципы работы и поиска промежуточных сертификатов, то проверка подписи занимает уже меньше времени.

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

Немного про корневые и промежуточные сертификаты

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

Однако просто списка недостаточно, нужны хотя бы ссылки на сайты этих УЦ, а также надо найти корневые сертификаты непосредственно от первоисточника, Минкомсвязи. Следующий точкой в поиске этой информации стал портал pravo.gov.ru, где перечислены ссылки на некоторые корневые сертификаты. Страница доступна только по http протоколу, контрольных сумм опять нет.

Приглядевшись, можно заметить, что первые 4 ссылки ведут на портал https://e-trust.gosuslugi.ru. Не совсем понятно, почему именно поддомен сайта госуслуг стал центральным в системе корневых сертификатов, но, кажется, тут приведена вся актуальная информация по корневым и промежуточным сертификатам.

На странице головного УЦ https://e-trust.gosuslugi.ru/MainCA приведены 10 корневых сертификатов от Минкомсвязи, для разных ГОСТ алгоритмов и с разными сроками действия. Тут же доступны слепки ключей, можно проверить, что скачанный сертификат никто не подменил. Сам сайт имеет сертификат от Thawte.

У сертификатов есть поле точки распространения списка отзывов (CRL), в котором прописан путь получения списка отозванных сертификатов. При проверке ЭП на каком-то документе кроме установки промежуточного и корневых сертификатов нужно также установить и последний список отозванных и обновлять его перед каждой проверкой (данная процедура автоматизируется специализированным софтом, но штатные средства вроде бы так не умеют). На портале e-trust у каждого сертификата указан путь к такому списку и он может отличаться от того, что написано в самом сертификате. Чему верить? Не совсем понятно.

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

После написания статьи осталось несколько открытых вопросов, которые хотелось бы обсудить с сообществом:

• аналоги КриптоПро, особенно opensource инструменты для создания и проверки ЭП;
• добавление валидации ЭП не только в Adobe Acrobat Reader DC, но и в Foxit Reader и другие;
• оставшиеся за пределами данной статьи проблемы, которые также важны и требуют внимания, но не проявились в моём случае.

UPD 0: В комментариях подсказали онлайн сервис на портале госуслуг для проверки ЭП документов: https://www.gosuslugi.ru/pgu/eds. К сожалению, не заработало в моём случае, но может быть полезно.

UPD 1: После написания статьи мне подсказали, что есть ещё один криптопровайдер, ViPNet CSP, который тоже может помочь с ГОСТовскими криптоалгоритмами в системе. Одновременная установка его с КриптоПро CSP под вопросом.

КДПВ: edar, Pixabay

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

Всегда-ли вы проверяете ЭЦП в полученных электронных документах?

Проголосовали 72 пользователя.

Воздержались 28 пользователей.

Всем привет на  fst-wolker.ru! Тема сегодняшнего выпуска — установка доверенных корневых сертификатов на компьютер Windows если возникает ошибка при подписи электронных документов.

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

Ошибка проверки установленного сертификата

При попытке подписать документ система сначала проверяет — можно ли установленному сертификату доверять? Электронную подпись изготавливают различные уполномоченные организации. Каждая из них использует свой корневой сертификат который выдан вышестоящим удостоверяющим центром.

Которому в свою очередь сертификаты выдает головной удостоверяющий центр РФ.

Таким образом, при создании электронно — цифровой подписи создается так называемая цепочка доверия. В этой цепочке (в порядке подчинения) сначала идут доверенные корневые сертификаты УЦ, промежуточные сертификаты,  затем личные сертификаты. Если у вас не установлен хотя бы один сертификат из цепочки -возникаеют ошибки  проверки:

У всех сертификатов имеется срок действия. Возможно, доверенный корневой сертификат УЦ просрочен и необходимо установить свежий.

Перехожу к исправлению ситуации.

Как проверить установленные личные сертификаты в Windows?

На компьютере так же есть хранилища для установки сертификатов:

• Доверенные корневые центры сертификации;
• Промежуточные центры сертификации;
• Личные;

Просмотреть хранилища (и  находящиеся сертификаты в них) мы можем вызвав сочетанием клавиш Win+R меню «Выполнить» и введя туда команду:

Зайдя в папку «Сертификаты» нужного хранилища (слева) мы увидим установленные сертификаты (справа) кто их выдал, их сроки действия. Но как определить сертификат какого УЦ нам нужен конкретно для нашей подписи?  Для этого нужно открыть личный сертификат и посмотреть там всю цепочку доверия.

Как установить личный сертификат госуслуги в хранилище?

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

Но я открою свой сертификат прямо в хранилище личные (у меня он уже был установлен через крипто про):

Если цепочка доверия нарушена наш личный сертификат выглядит так:

Указываем, что сертификат будет доступен только текущему пользователю компьютера:

Указываем автоматическую установку, на основе типа сертификата.

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