Англоязычная кроссплатформенная утилита для просмотра российских квалифицированных сертификатов x509

image Сегодня использование цифровых сертификатов X509 v.3 стало обыденным делом. Все больше людей используют их для доступа на сайт Госуслуги, ФНС, электронные торги и т.д. И все больше людей хотят знать, что же находится в этом «сундуке» под названием сертификат. И если сертификат является аналогом паспорта, то как его можно прочитать/просмотреть. Да, в операционных системах присутствуют различные утилиты для просмотра. Но рядовому гражданину они мало что дадут. Возьмем для примера утилиту gcr-viewer, которая, по сути, является стандартным средством для просмотра в Linux-системах, а значит и в отечественных ОС:



Стандартный просмотрщик


Утилита хорошо сделана, удобная. И вообще задумана как универсальная утилита для просмотра файлов, содержащих данные в различных криптографических форматах (сертификаты, запросы, электронные подписи/PKCS#7, защищенные контейнеры PKCS#12 и т.д.). Но, к сожалению, она рассчитана на западную криптографию и не учитывает oid-ы, которые вводятся в вашей стране. И если взглянуть на скриншот, то уже при выводе сведений о владельце сертификата появляются непонятные символы. Слева это сами oid-ы, а справа в 16-ом виде asn1-структура с их значениями. В данном случае это ОГРН (1.2.643.100.1), СНИЛС (1.2.643.100.3) и ИНН (1.2.643.3.131.1.1). И вот как рядовой гражданин должен убедиться, что это его данные. Не надо думать, что так только в Linux, это общая черта любого просмотрщика сертификатов. А если посмотреть дальше, то становится вообще все непонятно:



Появляются какие-то расширения, идентификаторы и значения. В данном случае под oid-ом 1.2.643.100.111 скрывается наименование СКЗИ, которое использовалось пользователем для генерации ключевой пары, закрытый ключ из которой использовался для подписания запроса на сертификат, а открытый ключ из которой лежит в сертификате:



И здесь мало что понятно владельцу сертификата. Он даже не понимает, какой алгоритм использовался при генерации ключа, то ли ГОСТ Р 34.10-2001, то ли ГОСТ Р 34.10-2012 и с какой длиной ключа.

Можно продолжать приводить примеры. Например, если со сроком действия сертификата понятно, то где срок действия ключа?

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

И последнее, хотелось бы иметь универсальную утилиту, учитывающую по максимуму особенности российской ИОК/PKI, по настоящему кроссплатформенной и работающей на отечественных и неотечественных ОС. На чем разрабатывать? Конечно на скриптовом языке, хотя бы в силу их кроссплатформенности.

Тут вспомнилось, что совсем недавно отпраздновал свое 30-летие прекрасный скриптовый язык Tcl (Tool Command Language). Программировать на нем одно удовольствие. У него огромное количество расширений (package), которые позволяют практически все. Так, для работы с ASN-структурами имеется пакет asn. Более того, для работы с сертификатами (нас в данном случае интересует их разбор) имеется пакет pki. А для разработки графического интерфейса имеется пакет Tk.

Все то же самое можно сказать и про Pyton с Tkinter, и про perl, и про ruby. Каждый может выбрать по своему вкусу. Мы останавливаемся на связке Tcl/Tk.

Графический дизайн для утилиты позаимствуем у утилиты gcr-viewer. И еще одно требование.

Поскольку у Хабра появилась англоязычная версия, то хотелось, чтобы и утилита имела различные интерфейсы (русский/английский). Но это не главная причина. Важнее то, что все больше граждан западного мира становятся гражданами Российской Федерации, например, всемирно известный актер Депардье. Могут возразить: он француз. Но я тоже военный переводчик с французского языка:



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



Приглашаем переводчика


Итак, начнем с «переводчика». На скриншоте он скрывается под национальным флагом. Основное требование к переводчику – это синхронность перевода, т.е. возможность перейти на другой язык в любой момент. Функции переводчика в Tcl/Tk выполняет пакет msgcat:

package require msgcat

Для установки текущего языка используется команда следующего вида:

msgcat::mclocale ru

Словарный запас «переводчика» сохраняется в файле ru.msg в следующем виде:

#Импортируем процедуру msgcat::mcset и в дальнейшем к ней 
# обращаемся по короткому имени mcset 
namespace import -force msgcat::mcset 
#         На английском  Русский перевод
mcset ru "Language" 	"Язык"
…

Ниже приводится текст тестового
скрипта с переводчиком:
#!/usr/bin/wish -f 
#Загружаем пакет msgcat 
package require msgcat 
#Устанавливаем локальный язык ru 
msgcat::mclocale ru 
#Импортируем процедуру ::msgcat::mc и в дальнейшем к ней 
# обращаемся по короткому имени mc 
namespace import msgcat::mc 
#Загружаем словарь из файла [msgcat::mclocale].msg. 
#В данном случае из каталога с данным скриптом. 
msgcat::mcload [file join [file dirname [info script]]] 
#Языковые иконки
image create photo rf_32x21_f -file rf_32x21.png 
image create photo gb_32x21_f -file gb_32x21.png 
#Метка, текст в которой подлежит переводу
label .lab -text "[mc Language]: " -relief flat -bd 0 –bg snow -anchor sw -width 10 
button .but_lang -image rf_32x21_f -command ::changelang -relief flat -bd 0 
pack .lab  -side left -pady {2 0} 
pack .but_lang -side left 
#Процедура смены языка и синхронный перевод 
proc ::changelang {} { 
#Смена языка и синхронный перевод 
#Смена иконки на кнопке 
   if  {[msgcat::mclocale] == "ru"} { 
       msgcat::mclocale en 
       .but_lang configure -image gb_32x21_f 
   } else { 
       msgcat::mclocale ru 
       .but_lang configure -image rf_32x21_f 
   } 
#Перевод текста 
   .lab configure -text "[mc Language]: " 
} 


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

Если запустить этот скрипт, то наглядно будет видно, как работает переводчик:



Получаем публичный ключ


Теперь, когда с переводчиком определились, приступим к разбору сертификата. Для этого нам потребуется пакет pki:

package require pki). 

Пакет pki заточен на работу с ключами и сертификатами алгоритма RSA. Если сертификат (proc ::pki::x509::parse_cert) создан с другим типом ключа, то информацию об этом ключе мы не получим:

# Handle RSA public keys by extracting N and E
switch -- $ret(pubkey_algo) {
	"rsaEncryption" {
		set pubkey [binary format B* $pubkey]
		binary scan $pubkey H* ret(pubkey)
			::asn::asnGetSequence pubkey pubkey_parts
			::asn::asnGetBigInteger pubkey_parts ret(n)
			::asn::asnGetBigInteger pubkey_parts ret(e)
			set ret(n) [::math::bignum::tostr $ret(n)]
			set ret(e) [::math::bignum::tostr $ret(e)]
			set ret(l) [expr {int([::pki::_bits $ret(n)] / 8.0000 + 0.5) * 8}]
			set ret(type) rsa
	}
 }

Удивительно то, что алгоритм публичного ключа все же возвращается (ret(pubkey_algo))
Аналогичным образом обстоит дело и с разбором запроса на сертификат (proc ::pki::pkcs::parse_csr):

# Parse public key, based on type
switch -- $pubkey_type {
	"rsaEncryption" {
		set pubkey [binary format B* $pubkey]
		::asn::asnGetSequence pubkey pubkey_parts
		::asn::asnGetBigInteger pubkey_parts key(n)
		::asn::asnGetBigInteger pubkey_parts key(e)
		set key(n) [::math::bignum::tostr $key(n)]
		set key(e) [::math::bignum::tostr $key(e)]
		set key(l) [expr {2**int(ceil(log([::pki::_bits $key(n)])/log(2)))}]
		set key(type) rsa
	}
	default {
		return -code error "Unsupported key type: $pubkey_type"
	}
}

Но здесь он хоть возвращает информацию об ошибке. Но сегодня помимо RSA в ходу, например, ключи на эллиптических кривых ЕС, в том числе и ГОСТ Р 34.10-2012 (ГОСТ Р 34.10-2001 тоже пока ходит).

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

proc ::pki::x509::parse_cert {cert} {
	. . . 
	::asn::asnGetSequence cert subject
	::asn::asnGetSequence cert pubkeyinfo
#Добавляем в возвращаемый массив ASN-структуру публичного ключа.
       binary scan $pubkeyinfo H* ret(pubkey_pubkeyinfo)
	. . .
}

Все, больше ничего делать не надо. Именно таким образом процедура ::pki::x509::parse_cert возвращает большинство расширений сертификата по той простой причине, что не знает как их разобрать (например, subjectSignTool у наших квалифицированных сертификатов), т.е. отдает на усмотрения пользователя.

С другой стороны, процедура ::pki::x509::parse_cert возвращает одним из результатов tbs-сертификат, который содержит всю информацию из сертификата, кроме его подписи (signature) и типа подписи (signature_algo):

#Читаем сертификат из файла
set fd [open «cert.pem» r]
chan configure –translation binary
set datacert [read $fd]
close $fd 
#разбираем сертификат
array set cert_parse [::pki::x509::parse_cert  $datacert]
#Сохряняем tbs-сертификат
set cert_tbs_hex $cert_parse(cert)

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

proc ::pki::x509::parse_cert_pubkeyinfo {cert_tbs_hex} {
	array set ret [list]
	set wholething [binary format H* $cert_tbs_hex]
	::asn::asnGetSequence wholething cert

	::asn::asnPeekByte cert peek_tag
	if {$peek_tag != 0x02} {
		# Version number is optional, if missing assumed to be value of 0
		::asn::asnGetContext cert - asn_version
		::asn::asnGetInteger asn_version ret(version)
	}
	::asn::asnGetBigInteger cert ret(serial_number)
	::asn::asnGetSequence cert data_signature_algo_seq
		::asn::asnGetObjectIdentifier data_signature_algo_seq ret(data_signature_algo)
	::asn::asnGetSequence cert issuer
	::asn::asnGetSequence cert validity
		::asn::asnGetUTCTime validity ret(notBefore)
		::asn::asnGetUTCTime validity ret(notAfter)
	::asn::asnGetSequence cert subject
	::asn::asnGetSequence cert pubkeyinfo
#Сохраняем и возвращаем в hex asn-структуру публичного ключа
	binary scan $pubkeyinfo H* ret(pubkeyinfo)
	return $ret(pubkeyinfo)
}

А поскольку нас интересует российская криптография, то сразу напишем и процедуру разбора ГОСТ-ового публичного ключа:

proc parse_key_gost {pubkeyinfo_hex} {
    array set ret [list]
    set pubkeyinfo [binary format H* $pubkeyinfo_hex]
    ::asn::asnGetSequence pubkeyinfo pubkey_algoid
	::asn::asnGetObjectIdentifier pubkey_algoid ret(pubkey_algo)
#Убеждаемся, что это ГОСТ-ключ
    if {[string first "1 2 643 " $ret(pubkey_algo)] == -1} {
	return [array get ret]
    }
    ::asn::asnGetBitString pubkeyinfo pubkey
    set pubkey [binary format B* $pubkey]
#Значение публичного ключа
    binary scan $pubkey H* ret(pubkey)
    ::asn::asnGetSequence pubkey_algoid pubalgost
#OID - параметра
    ::asn::asnGetObjectIdentifier pubalgost ret(paramkey)
#OID - Функция хэша
    ::asn::asnGetObjectIdentifier pubalgost ret(hashkey)
#puts "ret(paramkey)=$ret(paramkey)\n"
#puts "ret(hashkey)=$ret(hashkey)\n"
#parray ret
#Возвращаем разобранный ключ: алгоритм ключа, значение ключа и параметры
    return [array get ret]
}

Да, чуть не упустил: после загрузки пакета pki, необходимо добавить в массив ::pki::oids oid-ы, характеризующие ГОСТ и квалифицированный сертификат или просто отсутствующих в этом массиве:

package require pki
#Добавляемые oid-ы
set ::pki::oids(1.2.643.100.1)  "OGRN"
set ::pki::oids(1.2.643.100.5)  "OGRNIP"
set ::pki::oids(1.2.643.3.131.1.1) "INN"
set ::pki::oids(1.2.643.100.3) "SNILS"
 set ::pki::oids(1.2.643.2.2.19) "GOST R 34.10-2001"
 set ::pki::oids(1.2.643.7.1.1.1.1) "GOST R 34.10-2012-256"
 set ::pki::oids(1.2.643.7.1.1.1.2) "GOST R 34.10-2012-512"
set ::pki::oids(1.2.643.2.2.3) "GOST R 34.10-2001 with GOST R 34.11-94"
 set ::pki::oids(1.2.643.7.1.1.3.2) "GOST R 34.10-2012-256 with GOSTR 34.11-2012-256"
 set ::pki::oids(1.2.643.7.1.1.3.3) "GOST R 34.10-2012-512 with GOSTR 34.11-2012-512"
 set ::pki::oids(1.2.643.100.113.1) "KC1 Class Sign Tool"
 set ::pki::oids(1.2.643.100.113.2) "KC2 Class Sign Tool"
. . . 

Можно также пополнить словарный запас переводчика, пополнив файл ru.msg:

mcset ru "GOST R 34.10-2001" "ГОСТ Р 34.10-2001"
mcset ru "GOST R 34.10-2012-256" "ГОСТ Р 34.10-2012-256"
mcset ru "GOST R 34.10-2012-512" "ГОСТ Р 34.10-2012-512"
mcset ru "GOST R 34.10-2001 with GOST R 34.11-94" "ГОСТ Р 34.10-2001 с ГОСТ Р 34.11-94"
mcset ru "GOST R 34.10-2012-256 with GOSTR 34.11-2012-256" "ГОСТ Р 34.10-2012-256 с ГОСТ Р 34.11-2012-256"
mcset ru "GOST R 34.10-2012-512 with GOSTR 34.11-2012-512" "ГОСТ Р 34.10-2012-512 с ГОСТ Р 34.11-2012-512"
. . .
:


Цепочка корневых сертификатов и список отозванных сертификатов


Как получить цепочку корневых сертификатов, уже было рассмотрено. По аналогии пишется процедура получения списка отозванных сертификатов СОС/CRL. Исходный код утилиты и ее дистрибутивы для платформ Linux, OS X (macOS) и MS Windows можно найти


В исходном коде можно найти все процедуры для разбора расширений сертификата.
Противникам Tk (Tcl/Tk, Python/Tkinter и т.д.) предлагаю найти, как говорят, 10 (десять) различий между двумя утилитами: утилитой gcr-viewer, написанной на gtk, и утилитой certViewer, разработанной на Tk:



Сертификаты на токенах/смарткартах PKCS#11


Выше мы говорили о работе с сертификатами (просмотреть, получить цепочку корневых сертификатов, списки отозванных сертификатов, отпечатки по sha1 и sha256 и т.д.), хранящимися в файлах. Но есть еще сертификаты, хранящиеся на токенах/смаркартах PKCS#11. И естественное желание не только их посмотреть, то и экспортировать в файл. Как это сделать, мы расскажем в следующей статье:

Поделиться публикацией

Комментарии 39

    +1
    Надо ведь было так старательно замазывать названия компании и ФИО Павла Анатольевича и при этом оставить закодированные ОГРН/СНИЛС…
      0

      Сертификат содеожит публичные данные. Мы сами подтверждаете это, заявляю что по ОГРН/СНИЛС можно многое получить. Так это было или нет "старательно" замазывать? А где по ОГРН/СНИЛС выдают данные владельца?

        +2
        Я не понял, что вы написали %)

        Мое недопонимание вызвало то, что вы замазали данные о компании и директоре, но оставили ОГРН и проч., по которым эти данные установить — секундное дело.
          –2
          по которым эти данные установить — секундное дело.

          Получить сертификат тоже секундное делою Замазал чтобы не мозолить глаза. Но на будущее учту — спасибо. Будем использовать сертификаты аля Остап Бендер.

      +2

      Как я понял, тут только парсинг сертификата без построения цепочки и PKI-валидации? Насколько возможно это сделать без привлечения всяких богомерзких КриптоПро и тому подобных прослоек? Хотя бы для сертификатов на токенах с неизвлекаемым ключём, которые сами умеют всё считать.

        0

        Цепочку сертификатов вы получаете — нажмите кнопку Дополнительно или правую кнопку мышки, когда курсор на основном окне. Укажите каалог, где сохранить цепочку и все:



        Я уже писал, что следующая статья будет о работе с сертификатами на токенах PKCS#11 с российской криптографией. А насчет КриптоПро. Зачем его привлекать, есть OpenSSL c ГОСТ-ами, есть NSS с ГОСТ-ами, и даже GnuPG/SMIME с ГОСТ-ами. Они успешно справляются с проверкой валидности.

          +1

          Здорово, мне статья понравилась

            0
            0

            На счёт крипто-про ремарка: не все токены PKCS#11, например любимый всякими ЭДО Рутокен Лайт с проприетарным контейнером ключа.

              0

              Ну если быть совсем точнем, то не знаю кем любимый Рутокен Лайт это не токен PKCS#11, там нет никакой российской криптографии, а значит не может быть неизвлекаемого ключа. По сути обычная флэшка с паролем. Так что это не PKCS#11. А программно-аппаратный токен на нем делается легко.

                0

                Рутокен Лайт используется подавляющим большинством поставщиков ЭДО и электронной отчётности совместно с Крипто-Про. Честные токены с неизвлекаемыми ключами используют только банки и в ЕГАИС.

                  0
                  Рутокен Лайт используется подавляющим большинством поставщиков ЭДО и электронной отчётности совместно с Крипто-Про.

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


                  Честные токены с неизвлекаемыми ключами используют только банки и в ЕГАИС.

                  Я в качестве положительного примера привел бы ГОСУСЛУГИ.

          0
          >> А насчет КриптоПро. Зачем его привлекать…

          Потому что, установил и работает. А OpenSSL c ГОСТ-ами настроить нетривиально
            0

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

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

                В Крипто-Про CSP мало чего нормального, особенно не под Windows. Начиная с работы с закрытым ключём в ОЗУ и кончая принудительной данью какой-то конторе для работы с КЭП в России.

                  0
                  кончая принудительной данью какой-то конторе для работы с КЭП в России.

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


                  В Крипто-Про CSP мало чего нормального, особенно не под Windows. Начиная с работы с закрытым ключём в ОЗУ

                  Несколько лет назад я было поверил еще немного еще чуть-чуть и мы перейдет на нас тоящие токены/смарткарты PKCS#11. Нет остались с CSP.

            0
            del
              0

              Переключать язык иконкой в GUI приложении совершенно неправильно. Приложение должно использовать язык, который указан в локали пользователя (LC_MESSAGES для Unix/Linux).


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


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


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


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


              Язык, на котором выводятся сообщения в приложении, и в Windows и в Linux переключается иначе, и вы тут изобрели велосипед с квадратными колесами, и зачем-то его еще защищаете.

                0

                Так-то оно так, но если переменная среды не установлена? А если у меня с десяток языков? Но и самое главное — утилита не зависит от прихоти локальной машины, она полностью автономна и в этом ее прелесть.
                И еще на рабочем столе (а это тоже приложение) хоть Windows хоть Linux переключать иконкой язык совершенно правильно, а в других приложениях неправильно — это как-то неправильно.

                  0
                  Так-то оно так, но если переменная среды не установлена?

                  Делать как сейчас. Но при этом если переменная установлена, выбирать локаль окружения.
                  А если у меня с десяток языков?

                  Перебирать их «флагом» будет крайне неудобно, поэтому выбранный из их числа будет удобнее, чем совершенно незнакомый.
                  Но и самое главное — утилита не зависит от прихоти локальной машины, она полностью автономна и в этом ее прелесть.

                  Что не мешает хотя бы определять локаль стандартным для ОС образом, раз уж бинарники под каждую платформу разные.
                  И еще на рабочем столе (а это тоже приложение) хоть Windows хоть Linux переключать иконкой язык совершенно правильно, а в других приложениях неправильно — это как-то неправильно.

                  На рабочем столе такое поведение ожидаемо пользователем. В приложении переключение языка ожидается либо в настройках, либо в выпадающем меню с кодом, тут же флаг максимально неинтуитвен.
                  Кроме этого в системе у пользователя редко бывает больше 2-3 языков ввода, приложение может (и в некоторых случаях должно) поддерживать десятки локалей, перебор между которыми подобным образом неудобен
                    0
                    Делать как сейчас. Но при этом если переменная установлена, выбирать локаль окружения.

                    Это из серии если бы да кабы. Мне нужен мой язык, а не язык из локали.


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

                    Зачем флагом-то! Для этого combox есть.


                    Что не мешает хотя бы определять локаль стандартным для ОС образом, раз уж бинарники под каждую платформу разные.

                    Зачем? Мне нужно показать на чувашском языке, а локаль татарская. И что? И как бинарники связаны с локалью?


                    А вообще-то есходники есть, поправьте как вам удобно.

                      0

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

                        0
                        Я говорю больше о выборе а исходной локали из окружения.

                        Выбирайте, ваше право.

                        0
                        Начнем с того, что сейчас де-факто стандарт когда мультиязычное приложение по-умолчанию использует локаль системы (или английскую, если системная локаль приложением не поддерживается, либо какую-то еще локаль, которую приложение считает близкой к нужной — например вместо неподдерживаемого белорусского языка использовать русский, вместо британского английского американский и т.п.). И обычно это отдельный пункт в выборе локали (т.е. например в двуязычной программе будет выбор из трех языков — «Русский», «Английский», «Использовать язык системы»).

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

                        К тому же все современные системы (Win, Linux, Mac, Android, etc.) предоставляют API для получения текущей локали, а так же других региональных настроек. Например формата даты, времени, десятичного разделителя, первого дня недели и т.п. которые программа тоже должна соблюдать. Опять же они не обязанны совпадать с таковыми «по-умолчанию» для данной локали, например на том же английском может быть минимум 4 разных варианта даты — DD.MM.YYYY, MM-DD-YYYY, DD-MM-YYYY, DD/MM/YYYY.
                          0
                          Соответственно вы просто прете против устоявшегося пользовательского опыта и сложившихся практик.

                          Я не пру! Боже упаси! Но у меня другой опыт и что мне делать? Ну поправьте как вам удобно. Это же инструмент.
                          А дата чем не угодила, она же из одного из ваших вариантов.


                          И обычно это отдельный пункт в выборе локали (т.е. например в двуязычной программе будет выбор из трех языков — «Русский», «Английский», «Использовать язык системы»).

                          Вы это хотите:


                            0
                            А дата чем не угодила, она же из одного из ваших вариантов.

                            Я имею ввиду, что приложению хорошо, по возможности, использовать именно тот вариант, который настроен в текущих настройках локали (в системе). Это лишь пример что на условно «английской» локали могут быть разные настройки локали.

                            Вы это хотите:

                            Да, во многих программах именно так и делают и мне кажется это правильно.
                              0

                              Хорошо, договорились. Буду добавлять чувашский язык — подправлю.

                          0

                          Ещё бы исходники были на гитхабе/битбакете/гитлабе. А то в архиве… как-то несерьёзно в 21 веке...

                            0

                            Да, насчет гитхаба на правы. Руки дайдут — сделаю.

                    0
                    Прошу прощения за возможно дурацкий вопрос, но сертификаты в контейнерах Crypto Pro оно видеть будет? Там вроде не совсем стандартный контейнер… И By the way — утилиты командной строки для работы с ними никто посоветовать не может? очень хочется срок годности в zabbix мониторить…
                      0
                      сертификаты в контейнерах Crypto Pro оно видеть будет?

                      Первое, что такое контейнер КриптоПро? Где он лежит? Особенно мне нравится когда говорят, что КриптоПро работает с токенами/смарткартами PKCS#11. Нет, они кладут туда, как правильно вы заметили, свой контейнер. А при необходимости вытаскивают закрытый ключ потом с память и работают с ним. Напрямую, нет не посмотрите, хотя дописать нет проблем. Мы уже это много раз делали. Обратите внимание на это.
                      И все же я вам подскажу выход, который стал дюже популярным. когда я начинал писать утилиту экспорта из хранилищ MS CSP с ГОСТ-ами личных сертификатов в защищенный контейнер PKCS#12, я не думал что так будет востребовано. Итак, берете утилиту p12fromgostcsp и экспортируете сертификат. А затем можете посмотреть на него и через утилиту. Кстати, она имеет и интерфейс командной строки:


                      $certView_linux64  <имя файла с сертификатом>
                        +1
                        ЭЭЭЭ. Я не сотрудник CryptoPro… Мне его только мониторить надо, а то что там контейнеры через одно место — я в курсе, но наверное это не моя вина?
                        PS
                        за ссылочку на p12fromgostcsp большое спасибо
                          0

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

                            0
                            Нужно за 1-2 недели до прекращения действия поднимать warning в zabbix и отправлять письмо в бизнес-подразделения о необходимости обновить сертификат. У меня на обслуживании пол-сотни юрлиц и бизнеса постоянно про 1-2 сертификата забывают. А потом начинается цирк с конями, т.к. протухший сертификат стандартным способом уже не обновить :-(
                      0

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

                        +1
                        Важнее то, что все больше граждан западного мира становятся гражданами Российской Федерации

                        Вот оно как, Михалыч.
                          0

                          А то как!

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

                        Самое читаемое