Использование Let’s Encrypt для внутренних серверов / Хабр

О сертификате: что это такое

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

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

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

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

Информация о сертификатах хранится в базах Единого реестра ЕСИА. Вносить данные имеют право удостоверяющие центры, прошедшие сертификацию. Все УЦ делятся на аккредитованные и неаккредитованные.

Основные поля сертификата

Сертификат Х.509 v3 определяется следующим образом. Для вычисления подписи данные, которые должны быть подписаны, представляются с использованием ASN.1 однозначных правил представления (DER).

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,
    -- если присутствует, версия должна 
    -- быть v2 или v3
    subjectUniqueID [2] IMPLICIT 
        UniqueIdentifier OPTIONAL,
    -- если присутствует, версия должна быть
    -- v2 или v3 
    extensions [3] EXPLICIT Extensions OPTIONAL
    -- если присутствует, версия должна быть v3      
}
Version ::= INTEGER { v1(0), v2(1), v3(2) }
CertificateSerialNumber ::= INTEGER
Validity ::= SEQUENCE {
    notBefore Time,
    notAfter  Time 
}
Time ::= CHOICE {
    utcTime     UTCTime,
    generalTime GeneralizedTime 
}
UniqueIdentifier ::= BIT STRING
SubjectPublicKeyInfo ::= SEQUENCE {
    algorithm        AlgorithmIdentifier,
    subjectPublicKey BIT STRING  
}
Extensions ::= SEQUENCE SIZE (1..MAX) OF Extension
Extension ::= SEQUENCE  {
      extnID    OBJECT IDENTIFIER,
      critical  BOOLEAN DEFAULT FALSE,
      extnValue OCTET STRING  
}

Issuer

Поле issuer идентифицирует того, кто подписал и выпустил сертификат. Поле issuer должно содержать непустое уникальное имя (DN). Имя определяется в соответствии со следующей ASN.1 структурой:

Имя описывает иерархическое имя, состоящее из атрибутов, таких, например, как название страны, и соответствующих значений, таких как RU. Тип компонента AttributeValue определяется значением AttributeType.

Стандарт Х.509 не ограничивает набор типов атрибутов, которые могут появиться в имени. Тем не менее, стандартом рекомендуется поддерживать следующие типы атрибутов в именах выпускающего и субъекта:

Дополнительно могут присутствовать некоторые другие типы атрибутов в именах выпускающего и субъекта, например:

Также может присутствовать атрибут domainComponent. DNS предоставляет собой иерархическую систему обозначения ресурсов. Данный атрибут предоставляет удобный механизм для организаций, которые хотят использовать уникальные DN имена параллельно со своими DNS-именами.

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

Subject

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

Если субъект является СА (т.е. основное обязательное расширение сА есть TRUE ), то поле subject должно содержать непустое уникальное имя, соответствующее содержимому поля issuer во всех сертификатах, выпущенных данным СА.

Если субъект является выпускающим CRL (т.е. присутствует расширение использования ключа keyUsage, и значение cRLSign есть TRUE ), то поле субъекта должно содержать непустое уникальное имя, соответствующее содержимому поля issue во всех CRLs, выпущенных данным субъектом.

Если информация именования субъекта представлена только расширением subjectAltName (т.е. ключ
связан только с e-mail адресом или URI ), то имя субъекта должно быть пустой последовательностью, и расширение subjectAltName должно быть обязательным.

Поле subject, если оно не пусто, должно содержать уникальное имя в форме DN. СА может выпустить более одного сертификата с одним и тем же DN для одного и того же участника, определенного в subject.

Поле subject определено как тип Name в терминологии стандарта Х.501.

Альтернативное имя субъекта

Расширение альтернативных имен субъекта допускает дополнительные идентификации, связанные с субъектом сертификата. Данная опция включает e-mail адрес, DNS-имя, IP-адрес и URI. Существуют и другие формы имени, в том числе полностью локальные определения.

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

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

Более того, если идентификация субъекта, включенная в сертификат, является только формой альтернативного имени (например, адрес электронной почты), то расширение subjectAltName должно быть помечено как критичное.

Когда расширение subjectAltName содержит электронный адрес, он должен иметь вид, определенный в RFC 822, т.е. иметь форму local-part@domain.

Когда расширение subjectAltName содержит iPAddress, адрес должен храниться в строке октетов в “сетевом порядке байтов”, как определено в RFC 791. Для IP версии 4 строка октетов должна содержать строго четыре октета. Для IP версии 6 строка октетов должна содержать строго 16 октетов.

Базовые ограничения

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

Булевское значение сА указывает, принадлежит ли сертифицированный открытый ключ СА. Если булевское значение сА не установлено, то бит keyCertSign в расширении использования ключа не должен быть установлен.

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

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

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

САs не должны включать поле pathLenConstraint, если булевское значение сА не установлено и расширение использования ключа не имеет бит keyCertSign.

Действительность сертификата

Период действительности сертификата является интервалом времени, в течение которого СА гарантирует, что он поддерживает информацию о статусе сертификата. Поле представлено как SEQUENCE двух дат: дата, с которой начинается период действительности сертификата ( notBefore ), и дата, которой заканчивается период действительности сертификата ( notAfter ).

САs должны всегда указывать даты действительности сертификата до 2049 года как UTCTime ; даты действительности сертификатов, начиная с 2050 года и далее, должны быть представлены как GeneralizedTime.

Основная разница между представлениями времени в UTCTime и в GeneralizedTime заключается в том, что в UTCTime для значения года отводится две цифры, а в GeneralizedTime – четыре.

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

Идентификатор ключа сертификационного центра

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

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

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

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

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

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

Данное расширение не должно помечаться как критичное.

Идентификатор ключа субъекта

Расширение идентификатора ключа субъекта предоставляет способ идентификации сертификата, содержащего конкретный открытый ключ.

Для упрощения создания сертификационного пути данное расширение должно появляться во всех сертификатах СА, т.е. во всех сертификатах, в которых значение сА есть TRUE.

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

1. keyIdentifier получается из 160-битного хэша SHA-1 значения битовой строки subjectPublicKey (исключая тег, длину и неиспользуемые биты).
2. keyIdentifier получается из четырех битов поля типа со значением 0100, следующим за младшими 60 битами хэша SHA-1 значения битовой строки subjectPublicKey (исключая тег, длину и неиспользуемые биты).

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

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

Данное расширение не должно быть помечено как критичное.

Использование let’s encrypt для внутренних серверов

$ dig  short NS example.com
ddns1.mycompany.com.

$ dig  short xi8qz.example.com
10.1.1.4

{
  "identifier": {
    "type": "dns",
    "value": "xi8qz.example.com"
  },
  "status": "pending",
  "expires": "2021-04-15T21:26:29Z",
  "challenges": [
    {
      "type": "dns-01",
      "status": "pending",
      "uri": "https://acme-staging.api.letsencrypt.org/acme/challenge/VtjihR4X8nLAj4MDwI...",
      "token": "aLptEKAeUOajkiGrx-kkbjUX4b1MC..."
    },
    // ...
  ],
  // ...
}

-----BEGIN CERTIFICATE-----
MIIGEjCCBPqgAwIBAgISAyk2izMz7OXSqHeZhg rUR5uMA0GCSqGSIb3DQEBCwUA
MEoxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MSMwIQYDVQQD
...

$ openssl x509 -in www.crt -text -noout
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            03:29:36:8b:33:33:ec:e5:d2:a8:77:99:86:0f:ab:51:1e:6e
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: C=US, O=Let's Encrypt, CN=Let's Encrypt Authority X3
        Validity
            Not Before: Jul 18 23:37:35 2021 GMT
            Not After : Oct 16 23:37:35 2021 GMT
        Subject: CN=xi8qz.example.com
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:be:69:df:28:04:9c:2b:e9:94:72:c3:de:a6:fd:
                    a4:38:93:be:43:a7:81:8b:dc:9a:be:19:0d:c0:d1:
...

$ curl -v https://xi8qz.example.com/login
*   Trying 10.1.1.4...
* TCP_NODELAY set
* Connected to xi8qz.example.com (10.1.1.4) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: /etc/ssl/certs
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server accepted to use http/1.1
* Server certificate:
*  subject: CN=xi8qz.example.com
*  start date: Jul 18 23:37:35 2021 GMT
*  expire date: Oct 16 23:37:35 2021 GMT
*  subjectAltName: host "xi8qz.example.com" matched cert's "xi8qz.example.com"
*  issuer: C=US; O=Let's Encrypt; CN=Let's Encrypt Authority X3
*  SSL certificate verify ok.
> GET /login HTTP/1.1
> Host: xi8qz.example.com
> User-Agent: curl/7.58.0
> Accept: */*
> 
< HTTP/1.1 200 OK
< Date: Sun, 05 Aug 2021 17:38:49 GMT
< Server: Apache/2.4.18 (Ubuntu)
...

Какие виды ssl-сертификатов есть и кто их выдаёт?

Есть специальные центры сертификации или как ещё называют — удостоверяющие центры (УЦ). Вы могли встречать названия таких УЦ: Symantec, Comodo, GlobalSign, Thawte, GeoTrust, DigiCert. Они подтверждают подлинность ключей шифрования с помощью сертификатов электронной подписи.

Кроме того, есть проекты, CloudFlare или LetsEncrypt, где можно получить сертификат бесплатно и самостоятельно. Такой сертификат выпускается на 3 месяца и далее требует продления. Однако во время их установки и дальнейшей работы есть ряд нюансов, которые стоит учитывать.

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

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

Итак, существует несколько типов SSL-сертификатов по источнику подписи и типу проверки данных.

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

• Подписанные доверенным центром сертификации (валидные). Речь о тех самых авторитетных УЦ выше. Сертификат корректно отображается во всех браузерах. Данные сертификата проверены и подтверждены в сертифицирующем центре.

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

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

• DV (Domain Validation) — базовый уровень сертификата, который обеспечивает только шифрование данных, но не подтверждает существование организации. Такие бюджетные сертификаты подойдут физическим и юридическим лицам.
• OV (Organization Validation) — обеспечивает не только шифрование данных, но и подтверждает существование организации. Такие сертификаты доступны только для юридических лиц.
• EV (Extended Validation) — это эффективное решение с самым высоким классом защиты, которое активно применяется в онлайн-бизнесе. Для оформления требуется пройти процедуру расширенной проверки, подтвердить законность организации и право собственности на домен.

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

• WildCard — защищает соединение с доменом и всеми его поддоменами.
• SAN — защищает домены по списку, указанному при получении SSL-сертификата.

Ограничения политики

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

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

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

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

Конформные САs не должны выпускать сертификаты, в которых ограничения политики являются пустой последовательностью. Это означает, что, по крайней мере, одно из полей requireExplicitPolicy или inhibitPolicyMapping должно присутствовать.

Данное расширение может быть как критичным, так и некритичным.

Политики сертификата

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

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

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

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

Предотвращение anypolicy

Расширение предотвращения anyPolicy может быть использовано в сертификатах, выпущенных САs. Предотвращение any-policy указывает, что конкретный anyPolicy OID со значениями { 2 5 29 32 0 } не считается явно соответствующим остальным политикам сертификата.

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

Данное расширение должно быть критическим.

Самый свежий CRL (точка распространения Delta CRL)

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

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

Расширения сертификата

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

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

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

Каждое расширение должно иметь соответствующий OID и определяться ASN.1-структурой. Когда расширение появляется в сертификате, OID появляется как поле extnID, и соответствующая ASN.1 структура представления является значением строки октетов extnValue.

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

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

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

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

Могут также распознаваться расширения идентификаторов ключа сертификационного центра и субъекта и расширение отображения политики.

Расширенное использование ключа

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

Цели ключа могут быть при необходимости определены любой организацией.

Данное расширение может быть как критичным, так и некритичным.

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

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

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

Определены следующие цели использования ключа:

anyExtendedKeyUsage OBJECT IDENTIFIER ::=
    { id-ce-extKeyUsage 0 }
id-kp OBJECT IDENTIFIER ::= { id-pkix 3 }
id-kp-serverAuth OBJECT IDENTIFIER ::= 
    { id-kp 1 }
-- аутентификация сервера TLS  
-- биты использования ключа, которые могут
-- быть ограничением: digitalSignature,
-- keyEncipherment или keyAgreement
id-kp-clientAuth OBJECT IDENTIFIER ::= 
    { id-kp 2 }
-- аутентификация клиента TLS 
-- биты использования ключа, которые могут
-- быть ограничением: digitalSignature 
-- и/или keyAgreement
id-kp-codeSigning OBJECT IDENTIFIER ::= 
    { id-kp 3 }
-- подписывание загруженного выполняемого кода
-- биты использования ключа, которые могут 
-- быть ограничением: digitalSignature
id-kp-emailProtection OBJECT IDENTIFIER ::= 
    { id-kp 4 }
-- защита е-mail
-- биты использования ключа, которые могут 
-- быть ограничением: digitalSignature,
-- nonRepudiation, и/или (keyEncipherment 
-- или keyAgreement)
id-kp-timeStamping OBJECT IDENTIFIER ::= 
    { id-kp 8 }
-- связывание хэша объекта со временем 
-- биты использования ключа, которые могут 
-- быть ограничением: digitalSignature 
-- и/или nonRepudiation
id-kp-OCSPSigning OBJECT IDENTIFIER ::= 
    { id-kp 9 }
-- подписывание ответов OCSP
-- биты использования ключа, которые могут 
-- быть ограничением: digitalSignature 
-- и/или nonRepudiation

Токены pkcs#11: сертификаты и закрытые ключи

Токены PKCS#11

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

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

Такое соответствие, как правило, устанавливается путем задание идентичных параметров CKA_ID и/или CKA_LABEL для тройки объектов: сертификата (CKO_CERTIFICATE), публичного ключа (CKO_PUBLIC_KEY) и приватного ключа (CKO_PRIVATE_KEY).

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

Наиболее распространенный способ задания CKA_ID – это использование значения хэш-функции от значения открытого ключа. Именно такой способ для связывания тройки объектов используется в проекте NSS (Network Security Services). При этом в качестве хэш-функции используется алгоритм SHA1. С учетом того, что на токене реально будет храниться едва ли больше десятка личных сертификатов, то с точки зрения появления коллизии этот способ является хорошим. Вместе с тем CKA_ID для этой тройки могут устанавливаться в любой момент и любое значение. Именно в этом и состоит вся проблема. Если бы RFC или Рекомендации ТК-26 требовали установки параметра CKA_ID в момент появления объекта на токене (например, при генерации ключевой пары CKM_GOSTR3410_KEY_GEN_PAIR) и его нельзя было бы изменить, то на этом данное повествование можно было бы завершить. К сожалению, это не так. Как уже было сказано, CKA_ID можно установить в любой момент с любым значением. Таким образом, всегда существует вероятность, что сертификат окажется связанным с чужим приватным ключом. Не нужно объяснять, к каким это приведет последствиям.

А вообще, существует ли строгий математический алгоритм, который позволяет связать тройку CKO_CERTIFICATE x CKO_PRIVATE_KEY x CKO_PUBLIC_KEY в единое целое?

Да, такой алгоритм на базе криптографических механизмов (CKM_) токена существует. Связка сертификата и публичного ключа проверяется легко и просто. Берутся значение открытого ключа и его параметров из сертификата и сравниваются и аналогичными значениями публичного ключа.

Что касается сертификата и приватного ключа, то до недавнего времени этот алгоритм выглядел следующим образом. С помощью приватного ключа формируется подпись под некоторым текстом (например, «поиск закрытого ключа»), а затем с помощью открытого ключа, полученного из сертификата, проверяется корректность полученной подписи. Если подпись корректна, значит, мы получили закрытый ключ для выбранного сертификата. Если нет, то выбирается следующий закрытый ключ на токене.

Все, мы теперь не зависим ни от CKA_ID, ни от CKA_LABEL.

Но вот появляется документ «МЕТОДИЧЕСКИЕ РЕКОМЕНДАЦИИ. Расширение PKCS#11 для использования российских стандартов ГОСТ Р 34.10-2021, ГОСТ Р 34.11-2021, ГОСТ Р 34.12-2021 и ГОСТ Р 34.13-2021», в котором появляется новый механизм CKM_GOSTR3410_PUBLIC_KEY_DERIVE — механизм создания открытого ключа из закрытого. Данный механизм используется в C_DeriveKey. Теперь поиск закрытого ключа для сертификата значительно упрощается. Достаточно получить список закрытых ключей на токене, затем для каждого закрытого ключа получить открытый ключ:

…
CK_OBJECT_HANDLE             priv_key   = CK_INVALID_HANDLE;
CK_OBJECT_HANDLE            pub_key    = CK_INVALID_HANDLE;
CK_MECHANISM                 mechanism_der_desc =
    { CKM_GOSTR3410_PUBLIC_KEY_DERIVE, NULL, 0 };
    CK_MECHANISM_PTR             mechanism_der          = &mechanism_der_desc;
…
   // Получаем открытый ключ по закрытому
    rc = funcs->C_DeriveKey(sess, mechanism_der, priv_key,
		NULL, 0, &pub_key);
…

А далее сравниваем значения полученного публичного ключа, со значениями публичного ключа в сертификате.

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

Использование механизма CKM_GOSTR3410_PUBLIC_KEY_DERIVE предполагает его реализацию на том или другом токене. Посмотреть список реализованных механизмов удобно с помощью утилиты p11conf:

$ /usr/local/bin64/p11conf  -h
usage:  /usr/local/bin64/p11conf [-hitsmIupPred] -A APIpath [-c slotID -U userPin -S SOPin -n newPin -L label]
        -h display usage
        -i display PKCS#11 library info
        -s display slot(s) info (-c slotID is optional)
        -t display token(s) info (-c slotID is optional)
Others must use -c slotID
        -m display mechanism list
        -I initialize token 
        -u initialize user PIN
        -p set the user PIN
        -P set the SO PIN
        -r remove all objects
        -e enumerate objects
        -d dump all object attributes
$

Список доступных механизмов можно посмотреть следующим образом:

$ /usr/local/bin64/p11conf  -A /usr/local/lib64/libls11usb2021.so -m -c 0|grep GOSTR3410
        Mechanism: CKM_GOSTR3410_KEY_PAIR_GEN (0x1200)
        Mechanism: CKM_GOSTR3410_512_KEY_PAIR_GEN (0xD4321005)
        Mechanism: CKM_GOSTR3410 (0x1201)
        Mechanism: CKM_GOSTR3410_512 (0xD4321006)
        Mechanism: CKM_GOSTR3410_WITH_GOSTR3411 (0x1202)
        Mechanism: CKM_GOSTR3410_WITH_GOSTR3411_12_256 (0xD4321008)
        Mechanism: CKM_GOSTR3410_WITH_GOSTR3411_12_512 (0xD4321009)
        Mechanism: CKM_GOSTR3410_DERIVE (0x1204)
        Mechanism: CKM_GOSTR3410_12_DERIVE (0xD4321007)
        Mechanism: CKM_GOSTR3410_KEY_WRAP (0x1203)

        Mechanism: CKM_GOSTR3410_PUBLIC_KEY_DERIVE (0xD432100A)

        Mechanism: CKM_LISSI_GOSTR3410_PUBLIC_KEY_DERIVE (0xD4321037)
$

И последнее, есть ли сегодня токены, разработанные в соответствии с документом

«МЕТОДИЧЕСКИЕ РЕКОМЕНДАЦИИ. Расширение PKCS#11 для использования российских стандартов ГОСТ Р 34.10-2021, ГОСТ Р 34.11-2021, ГОСТ Р 34.12-2021 и ГОСТ Р 34.13-2021»

?

Да, есть.

Точки распространения crl

Расширение для точек распространения CRL определяет, как может быть получена информация CRL. Расширение должно быть некритичным, но рекомендуется, чтобы оно поддерживалось как САs, так и приложениями. Далее мы подробно рассмотрим управление CRL.

Расширение cRLDistributionPoints является последовательностью DistributionPoint. DistributionPoint состоит из трех полей, каждое из которых является необязательным: distributionPoint, reasons и cRLIssuer.

Хотя каждое из этих полей является необязательным, DistributionPoint не должно состоять только из поля reasons ; либо distributionPoint, либо cRLIssuer должно присутствовать.

Если выпускающий сертификата не является выпускающим CRL, то поле cRLIssuer должно присутствовать и содержать имя выпускающего CRL. Если выпускающий сертификата является также и выпускающим CRL, то поле cRLIssuer должно быть опущено, и поле distributionPoint должно присутствовать.

Когда поле distributionPoint присутствует, оно содержит либо последовательность общих имен, либо единственное значение nameRelativeToCRLIssuer. Если расширение cRLDistributionPoints содержит общее имя типа URI, предполагается следующая семантика: