Хранилище сертификатов в офисном пакете LibreOffice

    image LibreOffice — мощный офисный пакет. LibreOffice бесплатен и имеет открытый исходный код.

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

    image

    Более того, проводимая политика импортозамещения, когда на столах чиновников вместо MS Windows все чаще появляются отечественные форки Linux, способствует широкому распространению пакета LibreOffice и в органах государственного управления.

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

    image

    Глядя на картинку, у неискушенного пользователя (а тем более у чиновника) возникает глубокое чувство непонимания: что за файл собирается открываться, что за пароль должен вводиться!

    Следует отметить, что это не очень удачный перевод разработчиков LibreOffice. Речь идет не о файле, а о токене/смарткарте PKCS#11, и не о пароле, а о пользовательском PIN-коде для токена. Должно быть что-то следующего вида:

    image

    Тут мы подошли к главному вопросу: где и как хранятся сертификаты, которые LibreOffice использует для формирования электронной подписи документов?

    В качестве хранилища сертификатов LibreOffice использует, как правило, хранилища сертификатов, создаваемых и поддерживаемых продуктами Mozilla (Firefox, Thunderbird, SeaMonkey). По умолчанию это хранилище сертификатов почтового клиента Thunderbird (Сервис → Параметры… → Безопасность → Сертификат…):

    image

    Хранилища сертификатов для продуктов Mozilla создаются средствами пакета NSS (Network Security Services). С помощью утилит командной строки можно создать и свое хранилище сертификатов, например:

    bash-4.3$ cd /home/a513/tmp 
    bash-4.3$ mkdir db_for_libre 
    bash-4.3$ modutil -create -dbdir /home/a513/tmp/db_for_libre 
    WARNING: Performing this operation while the browser is running could cause 
    corruption of your security databases. If the browser is currently running, 
    you should exit browser before continuing this operation. Type  
    'q <enter>' to abort, or <enter> to continue:  
    bash-4.3$ ls -l db_for_libre 
    итого 60 
    -rw------- 1 a513 a513 65536 авг 31 16:49 cert8.db 
    -rw------- 1 a513 a513 16384 авг 31 16:49 key3.db 
    -rw------- 1 a513 a513 16384 авг 31 16:49 secmod.db 
    bash-4.3$

    Созданное хранилище сертификатов в каталоге /home/a513/tmp/db_for_libre содержит три базы данных, а именно cert8.db, key3.db и secmod.db. Для их создания используется старая версия базы данных Berkeley (обычно она описывается в документах NSS как« DBM ») в отличие от хранилища сертификатов, скажем, в google-chrome, для создания и поддержки которого также используется пакет NSS, но для поддержки баз данных (cert9.db, key4.db и pkcs11.txt) в хранилище используется механизм SQLite3. Для работы и с тем и другим хранилищем используются одни и те же утилиты NSS, просто в параметре –d (каталог хранилища) перед путем к хранилищу, если вы собираетесь работать с новым форматом (SQLite3) хранилища, достаточно указать префикс: -d sql:<путь к хранилищу>.

    Более того, также просто из хранилища сертификатов старого формата (cert8.db, key3.db и secmod.db) создается и хранилище в новом формате (cert9.db, key4.db и pkcs11.txt). Для этого достаточно выполнить утилиту работы с сертификатами certutil в режиме просмотра ключей (-K) или сертификатов (-L) с параметром –X:

    bash-4.3$ ls -l /home/a513/tmp/db_for_libre/ 
    итого 60 
    -rw------- 1 a513 a513 65536 авг 31 17:56 cert8.db 
    -rw------- 1 a513 a513 16384 авг 31 17:56 key3.db 
    -rw------- 1 a513 a513 16384 авг 31 16:49 secmod.db 
    bash-4.3$ certutil -L -d sql:/home/a513/tmp/db_for_libre -X  
    Certificate Nickname             Trust Attributes   SSL,S/MIME, JAR/XPI 
    bash-4.3$ ls -l /home/a513/tmp/db_for_libre/                
    итого 120 
    -rw------- 1 a513 a513 65536 авг 31 17:56 cert8.db 
    -rw------- 1 a513 a513 28672 авг 31 17:56 cert9.db 
    -rw------- 1 a513 a513 16384 авг 31 17:56 key3.db 
    -rw------- 1 a513 a513 28672 авг 31 17:56 key4.db 
    -rw------- 1 a513 a513   440 авг 31 17:56 pkcs11.txt 
    -rw------- 1 a513 a513 16384 авг 31 16:49 secmod.db 
    bash-4.3$

    Как видим, теперь в хранилище есть базы данных как в старом, так и новом форматах.
    К сожалению, обратное преобразование мне неизвестно и поэтому новые хранилища сертификатов, например, google-chrome (~/.pki) в LibreOffice недоступны.

    Пакет NSS поддерживает работу с токенами/смарткартами PKCS#11, на которых, как правило, и хранят свои личные сертификаты с закрытыми ключами пользователи. Отметим, что личные сертификаты сегодня получают в удостоверяющих центрах .

    Итак, мы остановились на том, что у нас был запрошен PIN-код к токену. Подключить токены/смарткарты PKCS#11 можно как через Firefox, Thunderbir, Seamonkey, так и утилитой modutil. Например, для подключения облачного токена достаточно выполнить команду:

    $modutil –add LS11CLOUD2016 –libfile libls11cloud.so –dbdir /home/a513/tmp/db_for_libre 
    $

    Именно к этому токену LibreOffice и запросил пароль:

    image

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

    image

    Как только будет выбран сертификат, произойдет формирование электронной подписи:

    image

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

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

    Данная утилита позволяет подключать токены/смарткарты, импортировать корневые сертификаты и сертификаты из защищенного контейнераPKCS#12. Позволяет также создавать запросы (CSR) на сертификаты в формате PKCS#10:

    image

    Сформированный запрос на сертификат может быть отправлен в УЦ для получения сертификата:

    image

    Созданное хранилище может найти применение и за рамками LibreOffice.
    Поделиться публикацией
    Похожие публикации
    Никаких подозрительных скриптов, только релевантные баннеры. Не релевантные? Пиши на: adv@tmtm.ru с темой «Полундра»

    Зачем оно вам?
    Реклама
    Комментарии 16
    • +3

      GUI для NSS выглядит омерзительно.

      • +1
        Комментарий так себе. А что лучше?
        • 0
          Раз уж в конце статьи дается ненавязчивая реклама одного удостоверяющего центра, то она должна быть красивой, а не вырвиглазной.
          Достаточно было сделать два выпадающих меню — функции и типы сертификатов, а также не использовать набор цветов как для слабовидящих.
          • 0
            Реклама УЦ? Где вы ее увидели. Это скриншот с ТЕСТОВОГО УЦ, куда можно отправить CSR в формате PKCS#10. Его рекламируй не рекламируй толку нет. А вот для тестовых целей кто-нибудь и сможет использовать абсолютно свободно!!! Какие типы сертификатов, — он один x509 v.3. А если вы имеете ввиду для физических лиц, юридических лиц, индивидульных предпринимателей, да еще квалифицированный, то это все расписано и Законе и требованиях ФСБ. Может вы имели ввиду этот УЦ? Но про него нет ни слова
            • +1
              Что там рекламировать? CodeSign нету, для сайтов и серверов где сертификаты купить, я тоже не вижу. Ну только S/MIME, наверное, есть, то, что на скриншотах.

              У любого нормального УЦ всё забито сертификатами на сайт, с вайлдкардами, с мультидоменами или без; DV, OV или EV. Чуть пониже болтаются Authenticode (CodeSign), опять же, разные, вот EV, например, вроде как даже запрос не выдаёт на повышение прав до админских, и не с любым можно сделать x64 драйвер. И в самом низу S/MIME, но при этом понятно, что это S/MIME, эти слова фигурируют в тексте.

              А тут заходишь, и ничего не понятно. Думаешь, куда я вообще попал.
              • 0
                А это вы про что?
                • 0
                  Ну вот захожу я, допустим, сюда, и тут всё по полочкам: где поддерживаются поддомены, где — нет, где подтверждается существование компании (OV/EV), а где — нет (DV, только проверка домена). Вот тут, например, можно пролистать до самого подвала, и там ссылки с абсолютно понятными текстами: Тип SSL: DV SSL, OV SSL, EV SSL, Code Signing, Wildcard. S/MIME, правда, там нету прямым текстом, зато наверху: Для чего Вам сертификат? для сайта или интернет магазина, для почты, для программного обеспечения. И в «для почты» можно обнаружить S/MIME.

                  УЦ здорового человека и УЦ российский
                  А ещё у них на сайте можно узнать интересные факты о сертификатах, вроде того, что, оказывается, сертификат для подписи ПО сгодится для подписи PDF, но нет гарантий, что так это и останется в будущем. Вот ещё пример для сертификатов для подписи ПО. И ещё пример для защиты серверов. И ещё пример, где всё свалено в кучу, но справа есть ссылки вроде «Разработчикам ПО», чтоб отфильтровать лишнее.

                  И я таких ссылок могу накидать много, объединяет их одно: на самом деле удостоверяющие центры учреждены зарубежными дядями. Вот у них руки из правильного места, они сделали всё как надо, а русским доверили только роль субподрядчиков и иногда даже только продавцов (это когда проверяет не та организация, где куплено, а непосредственно Comodo, по D-U-N-S и пр.).

                  Если же русские пытаются не продавать от чужих УЦ, а сделать свой независимый, получается:

                  Выпуск сертификата электронной подписи для предоставления документов в Федеральную службу по финансам и рынкам (ФСФР РФ)


                  Ого! Ой, а можно что-нибудь попроще? Мне бы с сайта начать, а то без сайта не видать ни финансов, ни рынка.

                  Предназначен для использования на порталах:
                  gosuslugi.ru;
                  nalog.ru;


                  Это всё, конечно, замечательно, но надо сначала заработать, чтобы тратить на госуслуги и налоги.

                  Выпуск сертификата электронной подписи для организации системы межведомственного электронного взаимодействия (СМЭВ)


                  Все ведомства важны, все ведомства нужны, ну а для простого регионального ИП что-нибудь можно подыскать?

                  Выпуск сертификата электронной подписи для электронной торговой площадки uTender.ru


                  А можно что-нибудь для тех, кто хочет через свой сайт работать, а не через чужой? Мы уж там сами дальше в Яндекс рекламу дадим, чтоб нас нашли.

                  Выпуск сертификата электронной подписи для использования системе электронных торгов B2B-Center


                  Алё, меня слышно вообще?

                  Выпуск сертификата электронной подписи для ЕГАИС


                  Алёшенькииии?!

                  Конец страницы


                  Блин, да как так-то? У нас разве не импортозамещение? Ну, я понимаю, что иностранные ОС не будут сразу понимать российскую криптографию и доверять нашему ГУЦ, но а с российскими ОС как дела? Вот соберу я программу под российские дистрибутивы, как распространяемый пакет подписать, чтоб сертификат был для ПО и чтоб цепочка с ГУЦ Минкомсвязи начиналась? Напишу я расширение для Редфокса, его тоже надо подписать. Как? Сайт сделать с российской криптографией, чтоб от ГУЦ доверие начиналось. Как?

                  И даже для иностранных ОС можно сделать подписанный (иностранным УЦ) сертификатом типа EV CodeSign установщик, чтоб добавлял поддержку ГОСТ и добавлял доверие к ГУЦ Минкомсвязи. Я у одного производителя видел такое для Authenticode, но для меня так и осталось загадкой, зачем это нужно, если никто из российских УЦ не в состоянии выдать такой сертификат. Сложно там что-то, вот не получается, и всё тут.

                  И чтоб решить свои внутрироссийские проблемы, надо идти на поклон к иностранному дяде, сами-то, по всему выходит, ничего не можем.
          • +1
            GUI для NSS выглядит омерзительно.

            Вам никто не мешает сделать его лучше.

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

                  Это как? Это поля для юридического лица, еще есть физическое лицо и индивидульный предприниматель. Под владельца сертификата и создаются поля
              • 0
                image
                А как вам этот GUI для NSS?
                • 0

                  Заставка лишняя!

                  • +1
                    Намного лучше!
                    Осталось заменить зеленый цвет на более спокойный.
                    • 0
                      Спасибо. Учтем!
                • 0
                  А по мне так миленько

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