SSL сертификат в Linux | Блог злобного админа

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

Сертификат Х.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  
}

Internet explorer

Issuer

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

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

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

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

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

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

Mozilla firefox

Serial number

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

Signature

Данное поле содержит идентификатор алгоритма, используемого СА для подписывания сертификата.

Данное поле должно содержать тот же самый идентификатор алгоритма, что и поле signatureAlgorithm в Certificate. Содержание необязательного поля параметров зависит от конкретного алгоритма.

Signaturealgorithm

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

Идентификатор алгоритма определяется следующей ASN.1-структурой:

Идентификатор алгоритма используется для определения криптографического алгоритма. Компонент OBJECT IDENTIFIER идентифицирует алгоритм (такой как DSA с SHA-1). Компоненты поля параметров изменяются в соответствии с указанным алгоритмом.

Поле должно содержать тот же самый идентификатор алгоритма, что и поле подписи в tbsCertificate.

Signaturevalue

Поле signatureValue содержит цифровую подпись, вычисленную для поля tbsCertificate, записанном в DER-представлении ASN.1. Это означает, что поле tbsCertificate, представленное как ASN.

1 DER, используется в качестве входа в функцию подписи. Полученное значение подписи представлено как BIT STRING и включено в поле подписи. Детали данного процесса могут отличаться для каждого конкретного алгоритма подписи.

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

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.

Tbscertificate

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

Version

Данное поле описывает версию представления сертификата. Если используются расширения, то версия должна быть 3 (значение – 2). Если расширения не указаны, но UniqueIdentifier представлен, версия может быть 2 (значение – 1); но версия может быть и 3.

Реализации должны быть готовы принимать любую версию сертификата. Как минимум конформные реализации должны распознавать версию 3 сертификатов.

X509: what’s the difference between digital signature and non-repudiation

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

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

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

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

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

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

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

Альтернативные имена выпускающего

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

Когда данное расширение присутствует, оно не должно быть помечено как критичное.

Атрибуты директории субъекта

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

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

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

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

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

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

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

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

Вариант второй

Редактируем файл /etc/ssl/openssl.cnf, в котором находим блок [req], в котором указываются настрйоки для создания CSR:

...
[ req ]
default_bits            = 1024
default_keyfile         = privkey.pem
distinguished_name      = req_distinguished_name
attributes              = req_attributes
x509_extensions = v3_ca # The extentions to add to the self signed cert
...

В конце блока добавляем строку:

req_extensions = v3_req

Так мы указали OpenSSL включать блок [v3_req] при создании CSR.

Находим его:

[ v3_req ]
# Extensions to add to a certificate request
basicConstraints = CA:FALSE
keyUsage = nonRepudiation, digitalSignature, keyEncipherment

Добавляем:

subjectAltName = @alt_names

И в блоке [alt_names] перечисляем SAN-ы:

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

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

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

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

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

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

Расширение доступа к информации уполномоченного органа определяет, как получить доступ к информации и сервисам СА для сертификата, в котором расширение присутствует. Информация и сервисы могут включать on-line сервисы проверки действительности и данные политики СА.

Расположение CRLs в данном расширении не указывается; эта информация предоставляется расширением cRLDistributionPoints. Данное расширение может включаться в сертификаты конечного участника или СА и не должно быть критичным.

Каждая запись в последовательности AuthorityInfoAccessSyntax описывает формат и размещение дополнительной информации, предоставляемой СА, который выпустил сертификат с данным расширением. Тип и формат информации определяется полем accessMethod ; в поле accessLocation указывается место размещения информации.

В настоящий момент определено два accessMethod OIDs:

Другие полезные команды openssl

Создание закрытого ключа:

openssl genrsa -des3 -out domain.key 2048

Создание запроса на основе имеющегося ключа:

openssl req -key domain.key -new -out domain.csr

Просмотр сертификата:

openssl req -text -noout -verify -in domain.csr

Генерация паролей с помощью openssl:

openssl rand -base64 9

Запрос ssl сертификата в linux

После того как отредактировали файл создаем ключ и запрос в одной команде:

openssl req -newkey rsa:2048 -nodes -keyout domain.key -out domain.csr

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

Обратите внимание на поле Common Name такое же имя стоит прописать в конфиге выше в качестве одного из полей в alt_names.

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

openssl x509 -in domain.crt -signkey domain.key -x509toreq -out domain.csr

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Информационный доступ субъекта

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

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

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

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

Информация открытого ключа субъекта

Данное поле используется для указания использования открытого ключа, в частности для идентификации алгоритма данного ключа (например, RSA, DSA или Diffie-Hellman). Алгоритм идентифицируется использованием AlgorithmIdentifier структуры.

Использование ключа

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

Например, когда ключ RSA должен использоваться только для проверки подписей для объектов, отличных от сертификатов открытого ключа и CRLs, биты digitalSignature и/или nonRepudiation должны присутствовать.

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

Биты в keyUsage типе используются следующим образом:

Бит digitalSignature установлен, когда открытый ключ субъекта используется с механизмом цифровой подписи для поддержки сервисов безопасности, отличных от подписывания сертификата (бит 5) или подписывания CRL (бит 6). Например, если механизмы цифровых подписей используются для аутентификации участника или аутентификации и целостности исходных данных.

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

Более тонкое различие между битами digitalSignature и nonRepudiation может определяться конкретными политиками сертификации.

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

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

Бит keyAgreement установлен, когда открытый ключ субъекта используется для согласования ключа. Например, когда ключ Диффи-Хеллмана используется для управления ключом, этот бит установлен.

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

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

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

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

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

Используем сертификаты

Для начала полезные команды, позволяющие «посмотреть» сертификаты и csr:

Теперь нужно положить сгенерированные сертификаты (server.crt и server.key) в нужное место на сервере. Конкретные детали уже выходят за рамки заметки.

Чтобы браузер не ругался на сертификат, нужно добавить в его репозиторий CA только что созданный CA, а именно файл ca.crt, импортируем, смотрим, что в списке он появился. Также можно сертификат положить в общесистемный репозиторий CA-сертификатов.

Конфигурирование nginx

Ниже приведен мой конфигурационный файл Web-сервера Nginx. Следует обратить внимание на дублирующиеся директивы

ssl_certificatessl_certificate_key

Коротко о главном

Удостоверяющий центр (по-английски Certification authority, сокращённо CA) — это единый центр генерации цифровых сертификатов. У конечных клиентов (например, веб-браузеров) имеется база публичных ключей разных CA и они проверяют ими приходящие, например, от сайтов сертификаты. Нас интересуют сертификаты, используемые в сеансах, защищённых протоколом SSL/TLS.

Собственно, всю процедуру можно разбить на такие шаги:

1. генерим приватный ключ (сильно случайный набор байтов);
2. генерим на основе приватного ключа пару сертификатов для CA (публичный и приватный);
3. генерим пару сертификатов для домена, подписанных созданным на прошлом шаге CA.

Настройка дополнительных полей ssl сертификата в linux

Первым делом необходимо настроить список и значения дополнительных полей в сертификате, а именно Subject Alternative Names. Указывать их необходимо, чтобы избежать ошибки [missing_subjectAltName] и NET::ERR_CERT_COMMON_NAME_INVALID в Google Chrome и других браузерах. В данных полях необходимо перечислить все dns имена и ip адреса, по которым может быть открыт сайт.

Задаются параметры через файл /etc/ssl/openssl.cnf. Если у вас данный конфигурационный файл не изменялся то необходимо внести следующие изменения:

1. В разделе [req] добавить строку: req_extensions = v3_req
2. В разделе [v3_req] добавить строку: subjectAltName = @alt_names
3. Создать раздел [ alt_names ] и добавить в него все альтернативные имена в формате:

Ограничения имени

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

Ограничения имени не применяются к сертификатам, чьи выпускающие и субъекты одинаковы, т.е. для самоподписанных сертификатов.

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

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

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

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

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

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

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

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

Отображения политик

Данное расширение используется в сертификатах СА. Оно перечисляет одну или более пар OIDs; каждая пара включает issuerDomainPolicy и subjectDomainPolicy. Пара определяет, что выпустивший СА считает свою issuerDomainPolicy эквивалентной subjectDomainPolicy субъекта СА.

Отображение политик определяет список политик, связанных с субъектом СА, которые могут приниматься как эквивалентные issuerDomainPolicy.

Каждая issuerDomainPolicy, перечисленная в расширении отображения политик, должна также быть установлена в расширении политик сертификата в том же самом сертификате. Политики не должны отображаться в специальное значение anyPolicy.

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

Период использования закрытого ключа

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

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

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

Если расширение используется, notBefore и notAfter представлены как GeneralizedTime.

Подпись ssl сертификата linux в доменном центре сертификации

Копируем содержимое csr файла в буфер, затем идем на веб сайт доменного центра сертификации.

В поле шаблон сертификата выбираем Веб-сервер и кликаем по кнопке «Выдать».

Кликаем по ссылке «Загрузить сертификат» и сохраняем файл сертификата. После этого его можно загрузить на сервер и настроить на использование вебсервером.

Поскольку доменный центр сертификации по умолчанию распространяет свой корневой сертификат на все машины в домене Active Directory, либо вы сделали это с помощью GPO, то все подписанные им сертификаты на машинах в домене будут валидными. Таким образом и SSL сертификат в Linux подписанный доменным центром сертификации прикрученный к внутрикорпоративному веб-серверу тоже не вызовет ошибок в браузере на рабочей машине пользователя.

Данная инструкция пригодится при выпуске сертификата например для установки на Proxmox Mail Gateway или любой другой веб-сервер.

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

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

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

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

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

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

Сертификат есть последовательность трех обязательных полей: tbsCertificate, signatureAlgorithm и signatureValue.

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

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

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

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

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

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

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

Расширения

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

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

Расширения, определенные для сертификатов Х.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

Собираем nginx

Я собирал nginx со статической библиотекой OpenSSL 1.0.2h

Создаём ca

Для начала сгенерим приватный ключ (файл ca.key), если хотите зашифровать приватный ключ с паролем, добавьте аргумент -des3:

Теперь сгенерим пару сертификатов для нашего CA (вместо 365 можно подставить любое другое значение, это срок годности пары сертификатов в днях):

Вводим пароль к ключу (если ключ был зашифрован) и затем аккуратно заполняем поля субъекта (subject). По этим данным можно будет потом идентифицировать публичный сертификат среди списка других, например. На выходе получаем файл ca.crt — это публичный сертификат нашего CA.

Можно создать ключ и сертификат одной командой, причём в эту же команду можно включить параметры субъекта:

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

Содержимое параметра -subj состоит из сегментов вида /$KEY=$VALUE, где $KEY может принимать такие значения:

• L — locality, обычно это город
• ST — state, обычно это регион, область, район и т.д.
• C — country, двухбуквенный код страны, например, RU или US
• O — organization, название организации
• OU — organization unit, отдел в организации
• CN — common name, обычно это адрес веб-сайта
• emailAddress — email

Стандартные расширения

Рассмотрим стандартные расширения сертификата, определенные в стандарте X.509. Каждое расширение имеет определенный OID. Эти OIDs являются элементами id-ce множества, которое определено следующим образом:

Точки распространения 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, предполагается следующая семантика:

Уникальные идентификаторы

Данные поля должны присутствовать только в том случае, если версия сертификата есть 2 или 3. Эти поля не должны присутствовать, если версия равна 1. Уникальные идентификаторы субъекта и выпускающего представлены в сертификате для получения возможности повторного использования имен субъекта и/или выпускающего в более позднее время. САs не должны создавать сертификаты с одинаковыми идентификаторами.

Частные расширения internet

На сегодня определено два расширения для использования в PKI Internet. Эти расширения могут применяться для предоставления приложениям on-line информации о выпускающем СА или о субъекте. Так как информация может быть доступна в нескольких формах, каждое расширение является последовательностью IA5String значений, представляющих собой URI. URI неявно определяют размещение и формат информации, а также метод ее получения.