Certificate Chaining Engine — как это работает – PKI Extensions

Certificate Chaining Engine — как это работает - PKI Extensions Сертификаты

Введение

На самом деле эта тема тесно переплетается с фундаментальными основами PKI, как доверие сертификатов, защита от подделки цифровых подписей сертификатов, отзыв сертификатов и т.д. Иными словами, сама модель PKI лежит на Certificate Chaining Engine (механизм построения цепочек сертификатов).

Одной из основ PKI является модель доверия центрам сертификации (Certification Authority или просто CA). Прежде чем мы начнём доверять сертификату мы должны явно доверять корневому сертификату CA и так же явно или косвенно (по правилу одностороннего транзитивного доверия) доверять всем промежуточным CA в цепочке.

Корневые сертификаты устанавливаются в систему вручную путём добавляения сертификата CA в секцию Trusted Root CAs. Если корневой сертификат CA есть в этом списке, то мы доверяем всем сертификатам, которые выдал этот CA и любые подчинённые CA (Intermediate CA).

Comodo

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

EV SSL

  • Root: AddTrustExternalCARoot.crt
  • Intermediate 1: COMODOAddTrustServerCA.crt
  • Intermediate 2: COMODOExtendedValidationSecureServerCA.crt
  • End-Entity/Domain Certificate

InstantSSL

  • Root: AddTrustExternalCARoot.crt
  • Intermediate: ComodoHigh-AssuranceSecureServerCA.crt
  • End-Entity/Domain Certificate

EssentialSSL

  • Root: AddTrustExternalCARoot.crt
  • Intermediate 1: UTNAddTrustSGCCA.crt
  • Intermediate 2: ComodoUTNSGCCA.crt
  • Intermediate 3: EssentialSSLCA_2.crt
  • End-Entity/Domain Certificate

PositiveSSL

  • Root: AddTrustExternalCARoot.crt
  • Intermediate: PositiveSSLCA2.crt
  • End-Entity/Domain Certificate

Дёргаем цепочку сертификатов

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

На 4-м сертификате дёргать их вручную стало лень (а я ленив по натуре), поэтому набросал «самокат» выцепляющий издателя и формирующий chain-файл для скармливания nginx’у.
Наверняка он не идеален и проверен лишь на полуторадесятках сертификатов, но чем богаты.

Об устройстве x.509 много сказано (в том числе на хабре), поэтому повторяться не буду.

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

Всё нижесказанное актуально для:

Скрытый текст
$ uname -or
FreeBSD 10.3-STABLE
$ openssl version
OpenSSL 1.0.2h  3 May 2021
$ `echo $SHELL` --version
tcsh 6.18.01 (Astron) 2021-02-14 (x86_64-amd-FreeBSD) options wide,nls,dl,al,kan,sm,rh,color,filec
$ /usr/local/bin/bash --version
GNU bash, version 4.3.25(1)-release (amd64-portbld-freebsd10.0)

Итак, предположим, что у нас есть PEM-сертификат сайта. Для примера мы возьмём сертфикат ya.ru (не только ж пинговать его).

$ echo | openssl s_client -connect ya.ru:443 | openssl x509 -certopt ca_default -out ya.pem -outform PEM

Помимо самого кодированного запроса, версии, подписи и т.п. в нём имеется ряд расширений. Одно из которых

Authority Information Access

нас и интересует:

$ openssl x509 -in ./ya.pem -noout -text | grep 'Authority Information Access' -A 2
            Authority Information Access:
                OCSP - URI:http://yandex.ocsp-responder.com
                CA Issuers - URI:http://repository.certum.pl/ycasha2.cer

Параметр

CA Issuers

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

PEM

, либо в

DER

(как в нашем случае) форматах.

$ fetch http://repository.certum.pl/ycasha2.cer

На деле

PEM

формат не более чем

base64

представление

DER

и получить

PEM

из

DER

можно сделав

base64 ./ycasha2.cer ./ycasha2.pem

и обрамив кодированный текст

“—–BEGIN CERTIFICATE—–“,”—–END CERTIFICATE—–“

. Однако, логичнее и проще сделать это преобразование средствами

openssl

:

$ openssl x509 -inform der -in ./ycasha2.cer -out ./ycasha2.pem

Едем дальше и смотрим следующий сертификат в цепочке:

$ openssl x509 -in ./ycasha2.pem -noout -text | grep 'Authority Information Access' -A 2
            Authority Information Access:
                OCSP - URI:http://subca.ocsp-certum.com
                CA Issuers - URI:http://repository.certum.pl/ctnca.cer
$ fetch http://repository.certum.pl/ctnca.cer

Преобразовываем и его:

$ openssl x509 -inform der -in ./ctnca.cer -out ./ctnca.pem

В данном сертификате (т.к. он корневой) отсутствует расширение

Authority Information Access

:

$ openssl x509 -in ./ctnca.pem -noout -text | grep 'X509v3 extensions' -A 6
        X509v3 extensions:
            X509v3 Basic Constraints: critical
                CA:TRUE
            X509v3 Subject Key Identifier:
                08:76:CD:CB:07:FF:24:F6:C5:CD:ED:BB:90:BC:E2:84:37:46:75:F7
            X509v3 Key Usage: critical
                Certificate Sign, CRL Sign

То есть на нём и закончим вытягивание цепочки. Осталось собрать это всё в chain-файл:

$ cat ya.pem ycasha2.pem ctnca.pem > chain0.pem

Вроде бы теперь можно ставить (если есть Private Key), но остановлюсь ещё на паре нюансов.

Установив свой сертификат на свой Яндекс проверяем его:

$ echo | openssl s_client -connect ya.ru:443 | grep Verify
    Verify return code: 0 (ok)

Всё хорошо, но это лишь потому, что в дефолтных путях

-CApath, -CAfile

моего

openssl

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

openssl

с багом, в которой не «цеплялись» default CApath (если не ошибаюсь с 1.0.1с по 1.0.1e), то получим неприятность в виде:

$ echo | openssl s_client -connect ya.ru:443 -CApath . | grep Verify
    Verify return code: 20 (unable to get local issuer certificate)

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

openssl

пытается отыскать его по хешу сертификата.

$ openssl x509 -noout -hash -in ./ctnca.pem
48bec511
$ ln -s `pwd`/ctnca.pem `pwd`/48bec511.0

И теперь наша система доверяет ya.ru:

$ echo | openssl s_client -connect ya.ru:443 -CApath . | grep Verify
DONE
    Verify return code: 0 (ok)

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

Выполняем:

$ ./issuers.sh ./ya.pem
0
http://repository.certum.pl/ycasha2.cer
tmp.der                                       100% of 1196  B   16 MBps 00m00s
IS PEM: [0]
DER(tmp.der) -> PEM(./ya.pem0.pem)
/usr/bin/openssl  x509 -inform der -in tmp.der -out ./ya.pem0.pem
1
http://repository.certum.pl/ctnca.cer
tmp.der                                       100% of  959  B   13 MBps 00m00s
IS PEM: [0]
DER(tmp.der) -> PEM(./ya.pem1.pem)
/usr/bin/openssl  x509 -inform der -in tmp.der -out ./ya.pem1.pem
cat ././ya.pem* > chain.pem
Certificate chain:
-rw-r--r--  1 root  wheel  5842 Jun 30 15:46 chain.pem

Сверяем показания:

$ md5 chain0.pem ; md5 chain.pem
MD5 (chain0.pem) = 6d32b0798d48d14764cd26cc4f730444
MD5 (chain.pem) = 6d32b0798d48d14764cd26cc4f730444

Как-то так… Разумеется скрипт не универсален, всё на скорую руку в предверии грандиозного шухера. Комментарии/пожелания приветствуются, но отвечать вряд ли смогу — у нас тут (в Беларуси)

дурдом

деноминация.

Другие виды сертификатов

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

сертификаты (типа Subject Alternative Name, Unified Communications Certificate, Multi Domain Certificate) будут действовать уже для большего числа доменных имен и серверов, но за каждое наименование, включаемое в список сверх обозначенного количества, придется доплачивать отдельно.

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

В таких случаях стоит приобретать сертификаты типа Comodo PositiveSSL Multi-Domain Wildcard и Comodo Multi-Domain Wildcard SSL. Отметим, что в этом случае можно также приобрести обычный мультидоменный сертификат, в котором просто указать необходимые поддомены.

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

P.S. Несколько материалов по теме из нашего блога:

Запускаем рекурсию

Описанную выше процедуру можно выполнять в цикле, пока из сертификата извлекается путь к «родительскому». Но есть один нюанс. Подписывающие сертификаты удостоверяющих центров обычно хранятся в бинарном формате, поэтому нам нужно будет проверить формат сертификата и преобразовать его к текстовому (чтобы корректно включить в финальную цепочку сертификатов, которая будет записана в PEM формате).

Для проверки формата сертификата воспользуемся verify от openssl:

openssl verify /tmp/stapling.crt 2>&1 | grep "unable to load")

В случае возникновения ошибки чтения загруженного сертификата нам нужно будет его преобразовать из бинарного формата в base64:

openssl x509 -inform der -in /tmp/stapling.crt -out /tmp/stapling.crt

или из pkcs7

openssl pkcs7 -inform der -print_certs -in /tmp/stapling.crt -out /tmp/stapling.crt

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

Инфраструктура открытых ключей. цепочка корневых сертификатов x509 v.3

Certificate Chaining Engine — как это работает - PKI ExtensionsНеумолимо приближается час «Ч»: «использование схемы подписи ГОСТ Р 34.10-2001 для формирования подписи после 31 декабря 2021 года не допускается!».

Однако потом что-то пошло не так, кто-то оказался не готов, и использование ГОСТ Р 34.10-2001 продлили на 2021 год. Но вдруг все бросились переводить УЦ на ГОСТ Р 34.10-2021, а простых граждан переводить на новые сертификаты. У людей на руках стало по нескольку сертификатов. При проверки сертификатов или электронной подписи стали возникать вопросы, а где взять корневые сертификаты, чтобы установить в хранилища доверенных корневых сертификатов.

Это касается как хранилища сертификатов в Windows, так и хранилища сертификатов в браузерах Firefox и Google Chrome, GnuPG, LibreOffice, почтовых клиентах и даже OpenSSL. Конечно, надо было озаботиться этим при получении сертификата в УЦ и записать цепочку сертификатов на флешку. А с другой стороны у нас же цифровое общество и в любой момент должна быть возможность получить эту цепочку из сети. Как это сделать на страницах Хабра показалsimpleadmin. Однако для рядового гражданина это все же сложновато (особенно, если иметь ввиду, что абсолютное их большинство сидит на Windows): нужно иметь «какой-то» openssl, утилиту fetch, которой и у меня не оказалось на компьютере, и далеко не каждый знает, что вместо нее можно использовать wget. А сколько действий нужно выполнить. Выход конечно есть, написать скрипт, но не просто скрипт поверх openssl и иже с ним, а упакованный в самодостаточный выполняемый модуль для различных платформ.

На чем писать никаких сомнений не было – на Tcl и Python. И начинаем с Tcl и вот почему:

* охренительной вики, где есть даже игрушки (там можно подсмотреть интересное 🙂
* шпаргалки
* нормальные сборки tclkit (1.5 — 2 Мб как плата за реальную кросс-платформенность)
* и моя любимая сборка eTcl от Evolane (бережно сохранённая с умершего сайта 🙁
сохраняют высокий рейтинг Tcl/Tk в моём личном списке инструментария
и, да, wiki.tcl.tk/16867 (мелкий web-сервер с cgi на Tcl, периодически используется с завидным постоянством под tclkit)
а ещё — это просто красиво и красиво 🙂

Про сертификаты:  Сертификация сейсмостойкости в Москве

К этому бы я добавил наличии утилиты

freewrap

, которая нам и поможет собрать автономные (standalone) утилиты для Linux и MS Windows. В результате мы будем иметь утилиту chainfromcert:

bash-4.3$ ./chainfromcert_linux64  
Copyright(C)2021 
Usage: 
chainfromcert <file with certificate> <directory for chain certificate> 
Bad usage! 
bash-4.3$

В качестве параметров утилите задаются файл с пользовательским сертификатом (как в формате PEM, так и формате DER) и каталог, в котором будут сохранены сертификаты УЦ, входящие в цепочку:

bash-4.3$ ./chainfromcert_linux64  ./cert_test.der /tmp
Loading file: cert_test.der 
Directory for chain: . 
cert 1 from http://ca.ekey.ru/cdp/ekeyUC2021.cer 
cert 2 from http://reestr-pki.ru/cdp/guc_gost12.crt 
Goodby! 
Length chain=2 
Copyright(C) 2021
bash-4.3$

А теперь рассмотрим как работает утилита.

Информация о центре сертификации, выдавшем сертификат пользователю, хранится в расширении с oid-ом 1.3.6.1.5.5.7.1.1. В этом расширении может хранится как о местонахождении сертификата УЦ (oid 1.3.6.1.5.5.7.48.2), так и информация о службе OCSP УЦ (oid 1.3.6.1.5.5.7.48.1):

Certificate Chaining Engine — как это работает - PKI Extensions

А информация, например, о периоде использования ключа электронной подписи хранится в расширении с oid-ом 2.5.29.16.

Для разбора сертификата и доступа к расширениям сертификата воспользуемся пакетом pki:

#!/usr/bin/tclsh -f
package require pki

Нам также потребуются пакет base64:

package require base64

Пакет pki, а также подгружаемые им пакет asn, и пакет base64 и помогут нам преобразовывать сертификаты из PEM-кодировки в DER-кодировку, разобрать ASN-структуры и собственно получить доступ к информации о местонахождении сертификатов УЦ.

Работа утилиты начинается с проверки параметров и загрузки файла с сертификатом:

proc usage {use } {
    puts "Copyright(C)  2021-2021"
    if {$use == 1} {
	puts "Usage:nchainfromcert <file with certificate> <directory for chain certificate>n"
    }
}
if {[llength $argv] != 2 } {
    usage 1
    puts "Bad usage!"
    exit
}
set file [lindex $argv 0]
if {![file exists $file]} {
    puts "File $file not exist"
    usage 1
    exit
}
puts "Loading file: $file"
set dir [lindex $argv 1]
if {![file exists $dir]} {
    puts "Dir $dir not exist"
    usage 1
    exit
}
puts "Directory for chain: $dir"
set fd [open $file]
chan configure $fd -translation binary
set data [read $fd]
close $fd
if {$data == "" } {
    puts "Bad file with certificate=$file"
    usage 1
    exit
}

Здесь все понятно и отметим только одно – файл с сертификатом рассматривается как бинарный файл:

chan configure $fd -translation binary

Это связано с тем, что сертификат может хранится как в формате DER (двоичный код), так и в формате PEM (base64 — кодировка).

После того как файл загружен вызывается процедура chainfromcert:

set depth [chainfromcert $data $dir]

которая собственно и загружает корневые сертификаты:

proc chainfromcert {cert dir} {
    if {$cert == "" } {
	exit
    }
    set asndata [cert_to_der $cert]
    if {$asndata == "" } {
#Файл содержит все что угодно, только не сертификат
	return -1
    }
    array set cert_parse [::pki::x509::parse_cert $asndata]
    array set extcert $cert_parse(extensions)
    if {![info exists extcert(1.3.6.1.5.5.7.1.1)]} {
#В сертификате нет расширений
	return 0
    }
    set a [lindex $extcert(1.3.6.1.5.5.7.1.1) 0]
#    if {$a == "false"} {
#	puts $a
#    }
#Читаем ASN1-последовательность расширения в Hex-кодировке
    set b [lindex $extcert(1.3.6.1.5.5.7.1.1) 1]
#Переводим в двоичную кодировку
    set c [binary format H* $b]
#Sequence 1.3.6.1.5.5.7.1.1
    ::asn::asnGetSequence c c_par_first
#Цикл перебора значений в засширении 1.3.6.1.5.5.7.1.1
    while {[string length $c_par_first] > 0 } {
#Выбираем очередную последовательность (sequence)
	::asn::asnGetSequence c_par_first c_par
#Выбираем oid из последовательности
	::asn::asnGetObjectIdentifier c_par c_type
	set tas1 [::pki::_oid_number_to_name $c_type]
#Выбираем установленное значение
	::asn::asnGetContext c_par c_par_two
#Ищем oid с адресом корневого сертификата
	if {$tas1 == "1.3.6.1.5.5.7.48.2" } {
#Читаем очередной корневой сертификат
	    set certca [readca $c_par $dir]
	    if {$certca == ""} {
#Прочитать сертификат не удалось. Ищем следующую точку с сертификатом
		continue
	    } else {
		global count
#Сохраняем корневой сертификат в указанном каталоге
		set f [file join $dir [file tail $c_par]]
		set fd [open $f w]
		chan configure $fd -translation binary
		puts -nonewline $fd $certca 
		close $fd
		incr count
		puts "cert $count from $c_par"
#ПОДЫМАЕМСЯ по ЦЕПОЧКЕ СЕРТИФИКАТОВ ВВЕРХ
		chainfromcert $certca $dir
		continue
	    }
	} elseif {$tas1 == "1.3.6.1.5.5.7.48.1" } {
#	    puts "OCSP server (oid=$tas1)=$c_par"
	}
    }
# Цепочка закончилась
    return $count
}

К комментариям добавить нечего, но у нас осталась не рассмотренной процедура readca:

proc readca {url dir} {
    set cer ""
#Читаем сертификат в бинарном виде
    if {[catch {set token [http::geturl $url -binary 1]
#получаем статус выполнения функции
	set ere [http::status $token]
	if {$ere == "ok"} {
#Получаем код возврата с которым был прочитан сертификат
	    set code [http::ncode $token]
	    if {$code == 200} {
#Сертификат успешно прочитан и будет созвращен
                set cer [http::data $token]
    	    } elseif {$code == 301 || $code == 302} {
#Сертификат перемещен в другое место, получаем его 
         		set newURL [dict get [http::meta $token] Location]
#Читаем сертификат с другого сервера
          		set cer [readca $newURL $dir]
    	    } else {
#Сертификат не удалось прочитать
        	set cer ""
    	    }
        } 
    } error]} {
#Сертификат не удалось прочитать, нет узла в сети
	set cer ""
    }
    return $cer
}

Это процедура построена на использовании пакета http:

package require http

Для чтения сертификата мы используем следующую функцию:

set token [http::geturl $url -binary 1]

Назначение остальных используемых функции понятно из комментариев. Дадим только расшифровку кодов возврата для функции http::ncodel:

200 Запрос успешно выполнен
206 Запрос успешно выполнен, но удалось скачать только часть файла
301 Файл перемещен в другое место
302 Файл временно перемещен в другое место
401 Требуется аутентификация на сервере
403 Доступ к этому ресурсу запрещен
404 Указанный ресурс не может быть найден
500 Внутренняя ошибка

Осталось не рассмотренной одна процедура, а именно cert_to_der:

proc cert_to_der {data} {
    set lines [split $data n]
    set hlines 0
    set total 0
    set first 0
#Ищем PEM-сертификат в файле
    foreach line $lines {
        incr total
        if {[regexp {^-----BEGIN CERTIFICATE-----$} $line]} {
            if {$first} {
                incr total -1
                break
            } else {
                set first 1
                incr hlines
            }
        }        
        if {[regexp {^(.*):(.*)$} $line ]} {
            incr hlines
        } 
    }
    if { $first == 0 && [string range $data 0 0 ] == "0" } {
#Очень похоже на DER-кодировку "0" == 0x30 
	return $data
    }
    if {$first == 0} {return ""}
    set block [join [lrange $lines $hlines [expr {$total-1}]]]
#from PEM to DER
    set asnblock [base64::decode $block]
    return $asnblock
}

Схема процедуры очень простая. Если это PEM-файл с сертификатом («—–BEGIN CERTIFICATE—– »), то выбирается тело этого файла и преобразуется в бинаоный код:

set asnblock [base64::decode $block]

Если это не PEM-файл, то проверяется это «похожесть» на asn-кодировку (нулевой бит должен быть равен 0x30).

Вот собственно и все, осталось добавить завершающие строки:

if {$depth == -1} {
    puts "Bad file with certificate=$file"
    usage 1
    exit
}
puts "Goodby!nLength chain=$depth"
usage 0
exit

Теперь все собираем в один файл с именем

Проверить работу этого файла можно с помощью интерпретарора tclsh:

$ tclsh ./chainfromcert.tcl cert_orlov.der /tmp 
Loading file: cert_test.der 
Directory for chain: /tmp 
cert 1 from http://ca.ekey.ru/cdp/ekeyUC2021.cer 
cert 2 from http://reestr-pki.ru/cdp/guc_gost12.crt 
Goodby! 
Length chain=2 
Copyright(C) 2021 
$

В результате работы мы получили цепочку из двух сертификатов в каталоге /tmp.

Но мы хотели получить выполняемые модули для платформ Linux и Windowsи и чтобы пользователи не задумывались о каких-то интерпретаторах.

Для этой цели мы воспользуемся утилитой freewrapTCLSH. С помощью этой утилиты мы сделаем выполняемые модули нашей утилиты для платформ Linux и Windows как 32-х разрядных так и 64-х. Сборку утилит можно проводить для всех платформ на любой из платформ. Извините за тавтологию. Я буду собирать на linux_x86_64 (Mageia).

Для сборки потребуется:

1. Утилита freewrapTCLSH для платформы linux_x86_64;
2. Файл freewrapTCLSH с этой утилитой для каждой платформы:
— freewrapTCLSH_linux32
— freewrapTCLSH_linux64
— freewrapTCLSH_win32
— freewrapTCLSH_win64
3. Исходный файл нашей утилиты: chainfromcert.tcl

Итак, собираемый выполняемый файл chainfromcerty_linuxx86 для платформы Linux x86:

$freewrapTCLSH chainfromcert.tcl –w freewrapTCLSH_linux32 –o chainfromcerty_linuxx86
$

Сборка утилиты для платформы Windows 64-х битного выглядит так:

$freewrapTCLSH chainfromcert.tcl –w freewrapTCLSH_win64 –o chainfromcerty_win64.exe
$

И т.д. Утилиты готовы к использованию. Все необходимое для их работы они вобрали в себя.

Аналогичным образом пишется код и на Python-е.

В ближайшие дни я думаю дополнить пакет fsb795 (а он написан на Python-е) функцией получения цепочки корневых сертификатов.

Корневые сертификаты

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

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

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

В данном примере сертификаты «Б» и «В» называются промежуточными.

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

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

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

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

Посмотреть локальные списки корневых сертификатов можно в настройках браузеров или операционной системы.

Не забываем про подписи

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

Если вы ещё не знаете, что такое цифровая подпись, то пора бы и узнать. Когда CA составляет сертификат, то он высчитывает конечный хеш (с использованием алгоритма указанного в поле Signature algorithm) этого сертификата и шифрует его своим закрытым ключом и пристыковывает подпись к сертификату.

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

На картинке слева вы видите, что chaining engine построил цепочку до доверенного корня, поскольку мой сертификат содержал нужные поля для работы метода Name match. Но сертификат был выдан не тем CA, который виден в цепочке, а поддельным CA. Хоть мой поддельный CA внешне не отличим от легитимного CA, но у него нету самого важного — правильного закрытого ключа, чтобы подписать сертификат. Ведь при проверке подписи используется открытый ключ легитимного CA и, следовательно, подпись не может быть проверена.

Про сертификаты:  Помощь в оформлении сертификата на резистор– услуги сертификации

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

Откуда берутся сертификаты?

Еще совсем недавно было всего 2 способа заполучить X.509 сертификат, но времена меняются и с недавнего времени есть и третий путь.

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

    not trusted

  2. Приобрести сертификат в УЦ. Это будет стоить денег в зависимости от различных его характеристик и возможностей, указанных выше.
  3. Получить бесплатный сертификат LetsEncrypt, доступны только самые простые DV сертификаты.

Для первого сценария достаточно пары команд и чтобы 2 раза не вставать создадим сертификат с алгоритмом эллиптических кривых. Первым шагом нужно создать закрытый ключ. Считается, что шифрование с алгоритмом эллиптических кривых дает больший выхлоп, если измерять в тактах CPU, либо байтах длины ключа. Поддержка ECC не определена однозначно в TLS < 1.2.

openssl ecparam -name secp521r1 -genkey -param_enc explicit -out private-key.pem

Далее, создает CSR — запрос на подписание сертификата.

openssl req -new -sha256 -key private.key -out server.csr -days 730

И подписываем.

openssl x509 -req -sha256 -days 365 -in server.csr -signkey private.key -out public.crt

Результат можно посмотреть командой:

openssl x509 -text -noout -in public.crt

Openssl имеет огромное количество опций и команд. Man страница не очень полезна, справочник удобнее использовать так:

openssl -help
openssl x509 -help
openssl s_client -help

Ровно то же самое можно сделать с помощью java утилиты keytool.

keytool -genkey -keyalg RSA -alias selfsigned -keystore keystore.jks -storepass password -validity 360 -keysize 2048

Следует серия вопросов, чтобы было чем запомнить поля owner и issuer

What is your first and last name?
What is the name of your organizational unit?
What is the name of your organization?
What is the name of your City or Locality?
What is the name of your State or Province?
What is the two-letter country code for this unit?
Is CN=Johnnie Walker, OU=Unknown, O=Unknown, L=Moscow, ST=Moscow, C=RU correct?

Конвертируем связку ключей из проприетарного формата в PKCS12.

keytool -importkeystore -srckeystore keystore.jks -destkeystore keystore.jks -deststoretype pkcs12

Смотрим на результат:

keytool -list -v -alias selfsigned -storepass password -keystore keystore.jks
Alias name: selfsigned
Creation date: 20.01.2021
Entry type: PrivateKeyEntry
Certificate chain length: 1
Certificate[1]:
Owner: CN=Johnnie Walker, OU=Unknown, O=Unknown, L=Moscow, ST=Moscow, C=RU
Issuer: CN=Johnnie Walker, OU=Unknown, O=Unknown, L=Moscow, ST=Moscow, C=RU
Serial number: 1f170cb9
Valid from: Sat Jan 20 18:33:42 MSK 2021 until: Tue Jan 15 18:33:42 MSK 2021
Certificate fingerprints:
     MD5:  B3:E9:92:87:13:71:2D:36:60:AD:B5:1F:24:16:51:05
     SHA1: 26:08:39:19:31:53:C5:43:1E:ED:2E:78:36:43:54:9B:EA:D4:EF:9A
     SHA256: FD:42:C9:6D:F6:2A:F1:A3:BC:24:EA:34:DC:12:02:69:86:39:F1:FC:1B:64:07:FD:E1:02:57:64:D1:55:02:3D

Signature algorithm name: SHA256withRSA
Subject Public Key Algorithm: 2048-bit RSA key
Version: 3

Extensions:

#1: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: 30 95 58 E3 9E 76 1D FB   92 44 9D 95 47 94 E4 97  0.X..v...D..G...
0010: C8 1E F1 92                                        ....
]
]

Значению ObjectId: 2.5.29.14 соответствует определение ASN.1, согласно RFC 3280 оно всегда non-critical. Точно так же можно узнать смысл и возможные значения других ObjectId, которые присутствуют в сертификате X.509.

subjectKeyIdentifier EXTENSION ::= {
    SYNTAX SubjectKeyIdentifier
    IDENTIFIED BY id-ce-subjectKeyIdentifier
}

SubjectKeyIdentifier ::= KeyIdentifier

Ошибка создания подписи: не удается построить цепочку сертификатов 0x800b010a – как исправить

Чтобы исправить ошибку создания подписи: «Не удается построить цепочку сертификатов» (0x800B010A) необходимо правильно диагностировать проблемный сертификат. Сделать это можно с помощью специализированного ПО, либо – с помощью Internet Explorer.

  1. Следует запустить браузер Internet Explorer. В операционных системах Windows он является предустановленным;
  2. Открыть меню браузера, нажав на значок шестеренки в верхнем правом углу окна;
  3. Выбрать пункт «Свойства браузера»;
    Меню - Свойства браузера
    Альтернативный вариант – зайти в свойства браузера, воспользовавшись встроенным поиском Windows;
    Свойства браузера открыть через поиск Windows
    Альтернативный вариант – зайти в свойства браузера, воспользовавшись встроенным поиском Windows;
    Certificate Chaining Engine — как это работает - PKI Extensions
  4. Перейти во вкладку «Содержание»;
  5. Нажать кнопку «Сертификаты»;
    Сертификаты - Свойства
  6. Выбрать сертификат, которым необходимо подписать документ и нажать кнопку «Просмотр»;
  7. Перейти во вкладку «Путь сертификации»;
  8. Сертификат отмеченный красным крестиком или восклицательным знаком – и есть причина возникновения ошибки создания подписи: «Не удается построить цепочку сертификатов» (0x800B010A).
    Цепочка сертификатов (корневой, промежуточные, личный)

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

Поручители

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

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

Пусть некто «Б» удостоверил личность некоего «А».

Проблему можно считать преодолённой, если вы знаете и доверяете «Б», а что, если — нет: не знаете или не доверяете.

«Б», в свою очередь, может сообщить, что его знает «В».

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

Мишу знает Боря, Борю знает Дима, Диму знает Вова, а вот уж Вову мы знаем сами. Помните шуточную теорию о шести рукопожатиях между двумя любыми людьми, одновременно живущими на Земле?

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

Постройка цепочки сертификатов

Давайте сначала посмотрим на путь сертификатов (цепочки сертификатов) обоих веб-сайтов:

В первом случае цепочка сертификатов заканчивается на сертификате VeriSign, которому мы доверяем явно. Вы можете убедиться в этом нажав кнопку View Certificate, чтобы посмотреть его внутренности и найти этот же сертификат в оснастке certmgr.msc –>

Trusted Root CAs. Однако, вы видите, что не корневой CA выдал сертификат сайту, а подчинённый (Intermediate CA). Это доказывает то, что если мы доверяем корню, то и явно или косвенно доверяем всем сертификатам этого CA или любым его прямым или косвенным промежуточным CA.

Если говорить простым языком, то в сертификатах используется одностороннее транзитивное доверие сертификатам CA. Чуть позже будет рассказано как строится эта цепочка. Во втором случае мы видим, что корневой сертификат CA не находится у нас в Trusted Root CAs и, следовательно, мы не доверяем ни одному сертификату, который издал этот CA или любой другой его подчинённый CA.

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

Но нас теперь интересует другой вопрос — а откуда же взялись все эти сертификаты в цепочке? Chaining engine как правило использует только 3 метода построения цепочки:

  • по полю AIA (Authority Information Access) каждого сертификата
  • с использованием файла цепочки сертификатов в формате pkcs7
  • поиск подходящих сертификатов в локальном хранилище (с использованием exact, key, name matches, о которых будет рассказно ниже)

Примечание: в сертификате любое поле содержащее слово Authority будет означать какие-то сведения о сертификате вышестоящего CA. Например, Authority Key Identifier — комбинация серийного номера, поля Subject или хеша открытого ключа вышестоящего CA. А любое поле содержащее слово Subject — означает то же самое, но применительно к конкретно этому сертификату.

Давайте посмотрим поле AIA первого сертификата:

Проблема устаревших корневых сертификатов. на очереди let’s encrypt и умные телевизоры

Certificate Chaining Engine — как это работает - PKI Extensions

Чтобы браузер мог аутентифицировать веб-сайт, тот представляет себя действительной цепочкой сертификатов. Типичная цепочка показана сверху, в ней может быть больше одного промежуточного сертификата. Минимальное количество сертификатов в действительной цепочке равно трём.

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

Специалист по безопасности Скотт Хельме (Scott Helme) пишет, что основные проблемы возникнут у центра сертификации Let’s Encrypt, потому что сегодня это самый популярный ЦС в интернете, а его корневой сертификат скоро «протухнет». Смена корня Let’s Encrypt назначена на 8 июля 2020 года.

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

Проблема заключается в том, что у каждого сертификата есть срок действия, после чего он нуждается в замене. Например, с 1 сентября 2020 года в браузере Safari планируют ввести ограничение на срок действия серверных TLS-сертификатов максимум 398 дней.

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

Сертификаты CA регулируются другим набором правил, поэтому имеют разные ограничения на срок действия. Очень часто встречаются промежуточные сертификаты со сроком действия 5 лет и корневые сертификаты со сроком службы даже 25 лет!

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

Как мы уже говорили, корневой CA встроен непосредственно в само клиентское устройство, в ОС, в браузер или другое программное обеспечение. Изменение корневого CA веб-сайт не может контролировать. Здесь требуется обновление на клиенте, будь то обновление ОС или софта.

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

Такая ситуация возникла 30 мая 2020 года в 10:48:38 GMT. Это точное время, когда протух корневой сертификат AddTrust от центра сертификации Comodo (Sectigo).

Про сертификаты:  /cabinet/anketa – активировать карту по номеру телефона - NEZLOP.RU

Он использовался для перекрёстной подписи, чтобы обеспечить совместимость с устаревшими устройствами, в хранилище которых нет нового корневого сертификата USERTrust.

К сожалению, проблемы возникли не только в устаревших браузерах, но и в небраузерных клиентах на базе OpenSSL 1.0.x, LibreSSL и GnuTLS. Например, в телевизионных приставках Roku, сервисе Heroku, в приложениях Fortinet, Chargify, на платформе .NET Core 2.0 под Linux и многих других.

Предполагалось, что проблема затронет только устаревшие системы (Android 2.3, Windows XP, Mac OS X 10.11, iOS 9 и т.п.), поскольку современные браузеры могут задействовать второй корневой сертификат USERTRust. Но по факту начались сбои в сотнях веб-сервисов, которые использовали свободные библиотеки OpenSSL 1.0.x и GnuTLS. Безопасное соединение перестало устанавливаться с выводом ошибки об устаревании сертификата.

Ещё один хороший пример предстоящей смены корневого CA — центр сертификации Let’s Encrypt. Ещё

в апреле 2021 года

они планировали перейти с цепочки Identrust на собственную цепочку ISRG Root, но этого

не произошло

.

Certificate Chaining Engine — как это работает - PKI Extensions

«Из-за опасений по поводу недостаточного распространения корня ISRG на устройствах Android мы решили перенести дату перехода к собственному корню с 8 июля 2021 года на 8 июля 2020 года», — сказано в официальном сообщении Let’s Encrypt.

Дату пришлось перенести из-за проблемы, которую называют «распространением корня» (root propagation), а точнее, отсутствием распространения корня, когда корневой CA не слишком широко распространён на всех клиентах.

Сейчас Let’s Encrypt использует перекрёстно подписанный промежуточный сертификат с цепочкой до корня IdenTrust DST Root CA X3. Этот корневой сертификат был выдан ещё в сентябре 2000 года и истекает 30 сентября 2021 года. До этого времени Let’s Encrypt планирует перейти на собственный самоподписанный корень ISRG Root X1.

Certificate Chaining Engine — как это работает - PKI Extensions

Корень ISRG выпущен 4 июня 2021 года. После этого начался процесс его утверждения в качестве центра сертификации, который завершился 6 августа 2021 года. С этого момента корневой CA был доступен всем клиентам через обновление операционной системы или программного обеспечения. Всё, что нужно было сделать, — это установить обновление.

Но в этом и проблема.

Если ваш мобильный телефон, телевизор или другое устройство не обновлялось два года — как оно узнает о новом корневом сертификате ISRG Root X1? А если его не установить в системе, то все серверные сертификаты Let’s Encrypt ваше устройство признает недействительными, как только Let’s Encrypt перейдёт на новый корень. А в экосистеме Android много устаревших устройств, которые давно не обновлялись.

Certificate Chaining Engine — как это работает - PKI Extensions
Экосистема Android

Вот почему Let’s Encrypt отложил переход к собственному корню ISRG и всё ещё использует промежуточное звено, которое спускается к корню IdenTrust. Но переход в любом случае придётся сделать. И датой смены корня назначено 8 июля 2020 года.

Для проверки, что на вашем устройстве (телевизор, приставка или другой клиент) установлен корень ISRG X1, откройте тестовый сайт https://valid-isrgrootx1.letsencrypt.org/. Если не появляется предупреждение безопасности, то обычно всё в порядке.

Let’s Encrypt не единственный, кому предстоит решить проблему с переходом на новый корень. Криптографию в интернете начали использовать чуть более 20 лет назад, так что как раз сейчас наступает момент окончания действия многих корневых сертификатов.

С такой проблемой могут столкнуться владельцы умных телевизоров, которые много лет не обновляли программное обеспечение Smart TV. Например, новый корень GlobalSign R5 Root выпущен в 2021 году, и после некоторые старые Smart TV не могут построить цепочку к нему, потому что этот корневой CA у них просто отсутствует. В частности, эти клиенты не могли установить защищённое соединение с сайтом bbc.co.uk. Чтобы решить проблему, админам BBC пришлось пойти на хитрость: они построили для этих клиентов альтернативную цепочку через дополнительные промежуточные сертификаты, задействуя старые корни R3 Root и R1 Root, которые ещё не протухли.

www.bbc.co.uk (Leaf)
GlobalSign ECC OV SSL CA 2021 (Intermediate)
GlobalSign Root CA - R5 (Intermediate)
GlobalSign Root CA - R3 (Intermediate)

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

Это касается всех устройств, не только телевизоров. Если у вас любое устройство, которое подключено к интернету и которое рекламировали как «умный» девайс, то проблема с протухшими сертификатами почти наверняка касается его. Если устройство не обновляется, то корневое хранилище CA со временем устареет, и в конечном итоге проблема всплывёт на поверхность. Как скоро возникнет проблема, зависит от времени последнего обновления корневого хранилища. Это может быть за несколько лет до даты реального выпуска устройства.

Кстати, в этом проблема, почему некоторые крупные медиаплатформы не могут использовать современные автоматизированные центры сертификации типа Let’s Encrypt, пишет Скотт Хельме. Для умных ТВ они не подходят, и количество корней слишком мало, чтобы гарантировать поддержку сертификата на устаревших устройствах. В противном случае ТВ просто не сможет запустить современные стриминговые сервисы.

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

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


Certificate Chaining Engine — как это работает - PKI Extensions

Проверка соответствия сертификатов внутри построенной цепочки

Однако, это только половина дела. Мы просто построили цепочку сертификатов, но не более того. Поскольку сертификаты могут быть скачаны в pkcs7 формате, а по ссылкам AIA просто подменить сертификаты, chaining engine делает полнуюю проверку доверия каждого сертификата в цепочке, чтобы исключить возможность подмены сертификатов, а так же достраивает цепочку (если этого не удалось сделать с помощью AIA и pkcs7 используя локальное хранилище сертификатов). Соответствие сертификатов внутри цепочки может происходить по нескольким правилам (в порядке приоритета):

  • Exact Match
  • Key Match
  • Name MAtch

Для этого chaining engine использует следующие поля сертификатов:

  • Authority Key Identfier (AKI) — может содержать комбинацию поля Subject и Serial Number сертификата вышестоящего CA или хеш открытого ключа вышестоящего CA (но бывает, что это поле совсем отсутствует).
  • Issuer – данное поле используется только если AKI отсутствует в сертификате и это поле должно быть эквивалентно полю Subject вышестоящего CA. По этому полю определяется имя CA, котороый издал этот сертификат.
  • Subject в сертификате вышестоящего CA. Данное поле должно быть эквивалентно полю Issuer в издаваемых сертификатах.
  • Serial Number сертификата вышестоящего CA.
  • Subject Key Identifier (SKI) — может содержать комбинацию поля Subject и Serial Number текущего сертификата или хеш открытого ключа текущего сертификата.

Словарный запас

Определение X.509 сертификатов есть в архиве ITU-T

Certificate  ::=  SEQUENCE  {
     tbsCertificate       TBSCertificate,
     signatureAlgorithm   AlgorithmIdentifier,
     signatureValue       BIT STRING  }

TBSCertificate  ::=  SEQUENCE  {
     version         [0]  EXPLICIT Version DEFAULT v1,
     serialNumber         CertificateSerialNumber,
     signature            AlgorithmIdentifier,
     issuer               Name,
     validity             Validity,
     subject              Name,
     subjectPublicKeyInfo SubjectPublicKeyInfo,
     issuerUniqueID  [1]  IMPLICIT UniqueIdentifier OPTIONAL,
                          -- If present, version MUST be v2 or v3

Для того, чтобы досконально понять обозначения и синтаксис, придется читать спеки X.680 редакции 2008 г., где есть полное описание ASN.1. В понятиях ASN.1SEQUENCE обозначает примерно то же самое, что и struct в Си. Это может сбить с толку, ведь по семантике оно должно было соответствовать скорее массиву. И тем не менее.

Стандарт X.690 определяет следующие правила кодирования структур данных, созданных в соответствии с ASN.1: BER (Basic Encoding Rules), CER (Canonical Encoding Rules), DER (Distinguished Encoding Rules). Есть даже XER (XML Encoding Rules), который на практике мне никогда не встречался.

Да, но для чего нужны сертификаты X.509, которые доставляют столько головной боли? Первая и основная функция сертификатов X.509 — служить хранилищем открытого или публичного ключа PKI (public key infrastructure). К этой функции нареканий нет, а вот со второй не все так однозначно.

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

Установка криптопро

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

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

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

Найти программу для запуска можно будет по следующему пути: «Пуск», «Все программы», «КриптоПро», «КриптоПро CSP». В открывшемся окне нажмите кнопку «Ввод лицензии» и в последней графе введите ключ. Готово. Теперь программу необходимо настроить соответствующим образом под ваши задачи.

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

Ошибка «Не удается построить цепочку сертификатов» все еще появляется? Отправьте запрос в службу поддержки, в котором нужно разместить скриншоты ваших последовательных действий и объяснить подробно свою ситуацию.

Шаг первый. размашисто подписываем файл

Сертификат есть, теперь нужно узнать его отпечаток. Просто откроем его в оснастке «Сертификаты» и скопируем на вкладке «Состав».

Нужный нам отпечаток.

Лучше сразу его привести к должному виду — только большие буквы и без пробелов, если они есть. Это удобно сделать в консоли PowerShell командой:

("6b142d74ca7eb9f3d34a2fe16d1b949839dba8fa").ToUpper().Replace(" ","")

Получив отпечаток в нужном формате, можно смело подписывать файл rdp:

rdpsign.exe /sha256 6B142D74CA7EB9F3D34A2FE16D1B949839DBA8FA .contoso.rdp

Где .contoso.rdp — абсолютный или относительный путь к нашему файлу.

После того как файл подписан, уже не получится изменить часть параметров через графический интерфейс вроде имени сервера (действительно, иначе смысл подписывать?) А если поменять настройки текстовым редактором, то подпись «слетает».

Теперь при двойном клике по ярлыку сообщение будет другим:

Новое сообщение. Цвет менее опасный, уже прогресс.

Избавимся же и от него.

Оцените статью
Мой сертификат
Добавить комментарий