Ssl-конвертер

Formats

PGP Public Key

For OpenSSL to recognize it as a PEM format, it must be encoded in Base64, with the following header:

Also, each line must be maximum 79 characters long. Otherwise you will receive the error:

Note: the PEM standard (RFC1421) mandates lines with 64 characters long. A PEM certificate stored as a single line can be converted with the UNIX command-line utility:

PKCS#1 RSAPublicKey (PEM header: BEGIN RSA PUBLIC KEY)
PKCS#8 EncryptedPrivateKeyInfo (PEM header: BEGIN ENCRYPTED PRIVATE KEY)
PKCS#8 PrivateKeyInfo (PEM header: BEGIN PRIVATE KEY)
X.509 SubjectPublicKeyInfo (PEM header: BEGIN PUBLIC KEY)
CSR PEM header : (PEM header:—-BEGIN NEW CERTIFICATE REQUEST—–)
DSA PrivateKeyInfo (PEM header: (—–BEGIN DSA PRIVATE KEY—-)

Ответ 1

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

.csr — Это запрос на подписание сертификата. Некоторые приложения могут генерировать их для отправки в центры сертификации. Фактический формат — PKCS10, который определен в RFC 2986. Он включает некоторые/все ключевые детали запрашиваемого сертификата, такие как субъект, организация, штат и т.д., а также открытый ключ сертификата, который должен быть подписан. Сначала его необходимо подписать в центре сертификации. Возвращенный сертификат — это открытый сертификат (который включает открытый ключ, но не закрытый ключ), который сам может быть в нескольких форматах.

.pem — определенный в RFC с 1421 по 1424, это контейнерный формат, который может включать только открытый сертификат (как, например, при установке Apache и файлов сертификатов CA /etc/ssl/certs), или может включать всю цепочку сертификатов, включая открытый ключ, закрытый ключ и корневые сертификаты. Настораживает то, что он также может быть закодирован в CSR, Поскольку формат PKCS10 может быть переведен в PEM. Название происходит от Privacy Enhanced Mail (PEM), неудачного метода для безопасной электронной почты. Но формат контейнера, который он использовал, продолжает жить и является переводом x509 ASN.1 ключей в base64.

.key — Это файл в формате PEM, содержащий только закрытый ключ конкретного сертификата, и это просто условное, а не стандартизированное название. В установках Apache он часто находится в каталоге /etc/ssl/private. Права на эти файлы очень важны, и некоторые программы откажутся загружать эти сертификаты, если они установлены неправильно.

.pkcs12 .pfx .p12 — Первоначально определенный RSA в Стандартах криптографии открытых ключей (сокращенно PKCS), вариант «12» был первоначально усовершенствован Microsoft, а затем представлен как RFC 7292. Это формат контейнера с паролем, который содержит пары публичных и приватных сертификатов. В отличие от файлов .pem, этот контейнер полностью зашифрован. OpenSSL может превратить его в файл .pem с открытым и закрытым ключами:

openssl pkcs12 -in file-to-convert.p12 -out converted-file.pem –nodes

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

.der — способ кодирования синтаксиса ASN.1 в двоичном формате, файл .pem — это просто файл .der, закодированный в Base64. OpenSSL может конвертировать их в .pem (openssl x509 -inform der -in to-convert.der -out converted.pem). Windows воспринимает их как файлы сертификатов. По умолчанию Windows, экспортирует сертификаты как файлы в формате .DER с другим расширением..

.cert .cer .crt — файлы в формате .pem (или редко .der), но с другим расширением, которые распознаются проводником Windows как сертификат, а .pem таковым не является.

.p7b .keystore — Определенный в RFC 2315 как PKCS номер 7, это формат, используемый Windows для обмена сертификатами. Java воспринимает их как нативные, и часто использует .keystore в качестве расширения. В отличие от сертификатов в стиле .pem, этот формат имеет определенный способ включения сертификатов сертификационного пути.

.crl — список отзыва сертификатов. Центры сертификации выпускают их как способ деавторизации сертификатов по истечению срока действия. Иногда их можно загрузить с веб-сайтов центров сертификации.

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

PEM — регулируется RFC, используется преимущественно в программах с открытым исходным кодом. Он может иметь различные расширения (.pem, .key, .cer, .cert и т.д.).
PKCS7 — Открытый стандарт, используемый Java и поддерживаемый Windows. Не содержит закрытый ключ.
PKCS12 — закрытый стандарт Microsoft, который позже был определен в RFC и обеспечивает повышенную безопасность по сравнению с обычным текстовым форматом PEM. Он может содержать закрытый ключ. Он используется преимущественно в системах Windows и может быть свободно преобразован в формат PEM с помощью OpenSSL.
DER — родительский формат PEM. Полезно рассматривать его как двоичную версию файла PEM с кодировкой base64. Редко используется за пределами Windows.

Что такое сертификаты безопасности?

~~Фантастические твари и где они…~~ Если совсем просто: те, что нам понадобятся — PEM (с расширениями .pem .crt .cer, и .key)- самые обычные текстовые файлы с зашифрованными данными внутри, которые позволяют сторонам убедиться, что их «собеседники» на другом конце именно те, за кого себя выдают. Их можно открыть Блокнотом и увидеть что-то вроде:

Таких блоков в файле может быть один или больше, в зависимости от длины цепочки.

Каждый сертификат начинается строкой «BEGIN CERTIFICATE» и заканчивается «END CERTIFICATE» с пятью тире до и после текста. Другие форматы имеют свои заголовки; например, P7B — «BEGIN PKCS7», а блок приватного ключа (о нём ниже) — «BEGIN RSA PRIVATE KEY».

Файл будет работоспособен при любом порядке блоков, но всё же желательно его соблюдать. Неправильная последовательность снизит рейтинг SSLLabs вашего сайта (если он вам нужен; для навыков Алисы этот фактор не имеет значения).

Более важная деталь: в файле не должно быть пустых строк! Также, в зависимости от операционной системы, на которой работает веб-сервер, могут быть разные требования к символам переноса строки. И, конечно, недопустимы никакие комментарии, пометки, посторонние символы.

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

Корневые сертификаты. Выпущены специальными удостоверяющими центрами, имеют наивысшую доверительность. Могут удостоверять собой любые другие виды сертификатов.
Промежуточные сертификаты. Любые виды цепочек сертификатов. Тоже имеют право удостоверять (подписывать) другие сертификаты.
Конечные сертификаты. Самая низкая степень доверия. Ими нельзя подписывать никакие другие сертификаты.

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

Теперь легко понятны ещё два термина:

fullchain («полная цепочка») сертификат — тот, который хранит всю цепочку, включая корневой и конечный сертификаты (и все промежуточные, если они участвуют). Физически fullchain-сертификат — тот же текстовый файл, который хранит все подписи, участвующие в цепочке.
самозаверенный (чаще говорят «самоподписанный») — конечный сертификат, который удостоверяет сам себя на манер корневого. Кроме того, из-за того, что самоподписанные сертификаты невозможно отозвать, возникают различные риски («атака посредника» итд).

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

Для цифровой аутентификации, в том числе подписи к сертификатам существует два вида ключей:

Публичный (открытый)	Приватный (закрытый)
Можно и нужно открывать в доступ	Ни в коем случае никому нельзя отдавать
Используется только для проверки подписи и идентичности владельца	Используется для создания цифровых подписей

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

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

И напоследок, у сертификата есть срок действия, после истечения которого пользоваться им не получится. Он может быть отозван и досрочно по каким-то причинам (например, скомпрометирован приватный ключ издателя или владельца конечного сертификата). Сертификат, у которого всё в порядке, называют валидным (действительным) — и наоборот.

Форматы SSL сертификатов

Различные платформы и устройства требуют SSL сертификаты в различных форматах, например, сервер Windows использует PFX файлы в то время как Apache сервер использует индивидуальный PEM (.crt .cer) файлы. Ниже информация о форматах сертификатов и как преобразовать SSL сертификаты из одного формата в другой.

PEM — популярный среди сертификационных центров, имеют расширение .pem, .crt, .cer, и .key. Файлы закодированы в Base64 и обязательно начинаются со строки «—— BEGIN CERTIFICATE ——«, заканчиваются строкой «—— END CERTIFICATE ——«. Apache и аналогичные серверы используют сертификаты в PEM формате.
DER — бинарная форма сертификата в формате PEM. Иногда имеет расширение файла .der но чаще .cer. DER обычно используется в платформах Java.
PKCS # 7 / P7B — файлы PKCS # 7 или P7B закодированные Base64, начинаются со строки «—— BEGIN PKCS7 ——» и заканчиваются строкой «—— END PKCS7 ——«. P7B файлы содержат только сертификат и промежуточные сертификаты, частный ключ используется как отдельный файл. Платформы поддерживающие P7B файлы: Microsoft Windows и Java Tomcat.
PKCS # 12/PFX — бинарная форма, в одном файле хранится сертификат сервера, промежуточные сертификаты и закрытый ключ. PFX файлы обычно имеют расширения .pfx и .p12. Как правило, используется в Windows для импорта и экспорта сертификатов и закрытых ключей. При конвертации PFX-формата в PEM-формат необходимо открыть файл в текстовом редакторе и скопировать каждый сертификат и закрытый ключ (включая BEGIN / END включение) в свои отдельные текстовые файлы, сохранить их как certificate.cer, CACert.cer, и privateKey.key.

Полезная информация

Получить сертификат Active Directory можно при помощи ввода команды на контролере домена:

certutil -ca.cert cacert.bin

Генерация приватного 2048-битного ключа при помощи openssl:

openssl genrsa -out privat.key 2048

Пример config-файла утилиты OpenSSL для генерации SAN сертификата:

distinguished_name = req_distinguished_name
req_extensions = v3_req


countryName = Country Name (2 letter code)
countryName_default = UA
stateOrProvinceName = State or Province Name (full name)
stateOrProvinceName_default = Kiev
localityName = Locality Name (eg, city)
localityName_default = Kiev
organizationalUnitName = Organizational Unit Name (eg, section)
organizationalUnitName_default = IT
commonName = Common Name
commonName_max = 64


# Extensions to add to a certificate request
basicConstraints = CA:FALSE
keyUsage = nonRepudiation, digitalSignature, keyEncipherment
subjectAltName = @alt_names


DNS.1 = server.domain.com.ua
DNS.2 = server.domain2.com.ua
DNS.3 = server
IP.1 = 192.168.1.1
IP.2 = 192.168.2.2

Команда для генерации CSR запроса через OpenSSL

openssl req -new -out request.csr -key privat.key -config config.cfg

Не доверенный сертификат сайта для браузера в android

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

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

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

Например в настройках хостинга «Украина», в поле где указывается SSL-сертификат моего сайта я прописал:

——BEGIN CERTIFICATE—— Тут сертификат для elims.org.ua ——END CERTIFICATE—— ——BEGIN CERTIFICATE—— Тут сертификат промежуточного центра сертификации — Comodo RSA Domain Validation Secure Server CA ——END CERTIFICATE—— ——BEGIN CERTIFICATE—— Тут корневой сертификат центра сертификации — COMODO RSA Certification Authority ——END CERTIFICATE——

SEO и SSL

Google заявлял о том, что присутствие https на сайте является положительным фактором для ранжирования. То есть из двух абсолютно одинаковых сайтов, в поисковой выдаче выше будет тот, который с https
Если некоторые части сайта мигрировали в HTTPS, а некоторые — нет, то позитивный сигнал к ранжированию получат только страницы с https в URL-адресах.
Есть слухи что Google Chrome будет помечать сайты без https как не надежные.
Необходимо использовать 2048-разрядные ключи для всех сертификатов.
Используйте относительные URL адреса, это облегчит переход с http на https
Для перехода с http на https можно использовать редирект в файле htaccess
Убедитесь что в теге rel=»canonical» используются ссылки с http, а не https
Убедитесь что в индексе поисковиков не присутствуют одновременно и http и htpps версии одной страницы — это может восприниматься как дублированный контент
CSS, JS, изображения и прочие файлы также должны использовать https

Объединить файлы.CRT, .KEY и.CA-BUNDLE

Для того, чтобы это сделать, установите на ваш компьютер программу openssl.exe .

Откройте данную утилиту и введите команду:

pkcs12 -export -out domain.name.pfx -inkey domain.name.key -in domain.name.crt -certfile domain.name.ca-bundle

domain.key — имя файла с приватным ключом RSA;

domain.crt — имя файла сертификата;

domain.ca-bundle — имя файла цепочки сертификатов.

Если конвертация прошла успешно, вы увидите слово Verifying.

Часто используемые форматы сертификатов: PEM
— очень часто используется в Linux based системах или оборудовании, файлы такого формата сертификата используют расширение.cer, .crt, and .pem. DER
— двоичная формат сертификата. DER формат не содержит текста «BEGIN CERTIFICATE/END CERTIFICATE», формат DER чаще всего использует расширение.der PKCS#7
или P7B
— эти форматы сертификата хранятся в формате Base64 ASCII и чаще всего имеют расширения файлов.p7b или.p7c. Файл P7B, кроме самого сертификата содержит цепочку сертификатов (открытых ключей) выпускающих центров сертификации (Intermediate CAs). Этот формат поддерживается в Windows и Java Tomcat. PKCS#12
или PFX
— эти форматы представляют собой двоичный формат для хранения сертификата сервера, промежуточных сертификатов и закрытого ключа в одном зашифрованном файле. Файлы такого формата сертификата используют расширение.pfx and .p12. PFX файлы обычно используются на windows машинах для импорта/экспорта сертификатов и закрытого ключа.

Конвертирование x509 в PEM

openssl x509 -in certificate.cer -outform PEM -out certificate.pem
Конвертирование
PEM в
DER

openssl x509 -outform der -in certificate.pem -out certificate.der
Конвертирование
DER в
PEM

openssl x509 -inform der -in certificate.der -out certificate.pem
Конвертирование
PEM в
P7B

openssl crl2pkcs7 -nocrl -certfile certificate.pem -out certificate.p7b -certfile CACert.cer
Конвертирование
PKCS7 в
PEM

openssl pkcs7 -print_certs -in certificate.p7b -out certificate.pem
Конвертирование
pfx в
PEM

openssl pkcs12 -in certificate.pfx -out certificate.pem
Конвертирование
PFX в
PKCS#8

Step 1:
Конвертирование
PFX в
PEM

openssl pkcs12 -in certificate.pfx -nocerts -nodes -out certificate.pem
Step 2:
Конвертирование
PEM в
PKCS8

openSSL pkcs8 -in certificate.pem -topk8 -nocrypt -out certificate.pk8
Конвертирование
P7B в
PFX

Для этого требуется выполнение двух команд

1. Конвертирование
P7B в
CER

openssl pkcs7 -print_certs -in certificate.p7b -out certificate.cer
2. Конвертирование
CER и закрытого ключа в
PFX

openssl pkcs12 -export -in certificate.cer -inkey privateKey.key -out certificate.pfx -certfile cacert.cer

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

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

Мне было интересно, могут ли хорошие люди здесь в ServerFault дать некоторые разъяснения по этому вопросу?

Переход на HTTPS, SSL

Если у Вас WordPress, то рекомендую прочесть статью «WordPress: переход на https» — в ней этот вопрос подробно рассматривается.

Указать канонические url через https.

Изменить все внутренние ссылки с http на https: Это тоже можно сделать через запрос в базе данных

Настроить 301-ю переадресацию с http-версии на https-версию через .htaccess:

Вариантов кодов редиректа с http на https существует большое количество, для примера приведу два из них:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{SERVER_PORT} 80 
RewriteRule ^(.*)$ https://www.yoursite.com/$1 
</IfModule>

Или еще один код:

<IfModule mod_rewrite.c>
RewriteEngine on
RewriteCond %{HTTP_HOST} ^yoursite.com 
RewriteCond %{HTTP_HOST} ^www.yoursite.com 
RewriteRule ^(.*)$ https://www.yoursite.com/$1 
</IfModule>

Не всегда такая переадресация работает, у меня например выбивало ошибку «ERR_TOO_MANY_REDIRECTS», то есть происходило зацикливание.

В этом случае может помочь 301 редирект через php-код:

<?php
 if ( !$_SERVER ) {
  $host = $_SERVER;
  $request_uri = $_SERVER;
  $good_url = "https://" . $host . $request_uri;
  header( "HTTP/1.1 301 Moved Permanently" );
  header( "Location: $good_url" );
  exit;
 }
?>

Как конвертировать файл PEM

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

Преобразуйте PEM в PPK с помощью PuTTYGen. выберите нагрузка с правой стороны программы, установите тип файла как любой файл (*. *), а затем просмотрите и откройте файл PEM. выберите Сохранить закрытый ключ для создания файла PPK.

С помощью OpenSSL (получить версию Windows здесь) вы можете преобразовать файл PEM в PFX с помощью следующей команды:

Как получить такой сертификат?

Вариантов и инструкций в Интернете достаточно много. В том числе у нас на вики в статье «».

В следующих разделах — краткие инструкции по самым популярным сервисам:

Lets’ Encrypt и certbot

Потребуется установить программу certbot. Под *nix- системами это сделать проще, но под Windows тоже не потребуется сверхъестественных усилий.

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

Предположим, что certbot у вас установлен. Что дальше? Запускаем несколько консольных команд.

Зарегистрироваться:

certbot register -m emailадминистратора@вашдомен.com

Сгенерировать сертификат:

certbot certonly --webroot -w /var/www/папкасервера -d вашдомен.com -d www.вашдомен.com

Если опасаетесь, что что-то не так и хотите сначала потренироваться, добавьте опцию —dry-run (режим эмуляции для отладки ошибок)

certbot certonly --dry-run --webroot -w /var/www/папкасервера -d вашдомен.com -d www.вашдомен.com

После успешной генерации сертификата у вас появятся 4 файла (их расположение также сильно зависит от вашей операционной системы):

cert.pem (конечный сертификат),
chain.pem (цепочка доверия от корневого сертификата, не включающая конечный),
fullchain.pem (нужная нам полная цепочка, включая конечный сертификат, по сути это сложение cert.pem + chain.pem),
privkey.pem (ваш приватный ключ, который никому нельзя ни показывать, ни отсылать).

Для веб-сервера необходимы два из них: fullchain.pem и privkey.pem.

Ещё несколько полезных команд certbot

Проверка и обновление сертификатов (полезно поставить запуск этой команды по расписанию):

certbot -q renew

Для проверки и обновления также есть тестовый режим (чтобы убедиться. что ваши домены будут обновляться):

certbot renew --dry-run

Добавление новых доменов и поддоменов к сертификату:

certbot certonly --webroot -w /var/www/папкасервера --expand -d вашдомен.com -d test.вашдомен.com -d www.вашдомен.ru

Изменение адреса администратора:

certbot register --update-registration -m newemail@вашдомен.ru

SSL For Free

Получить сертификат через онлайн-сервис намного быстрее и проще, ничего устанавливать не нужно:

Выбор настроек (обычно ничего трогать не нужно, просто жмите «Next Step»)
Подтверждение прав на домен, для которого получаете сертификат, любым из способов:
- на почту его владельца (список готовый, посторонний адрес вписать не получится) — вам должен быть доступен один из перечисленных email.
- изменением полей DNS (CNAME) — для новичков этот способ самый запутанный, но не требует доступности почты и http.
- скачиванием подтверждающего файла и размещением его в подпапке сайта — к домену должен быть http-доступ из Интернета в момент проверки.
После подтверждения останется выбрать формат: предлагается список шаблонов (Default, Tomcat, AWS, cPanel, Google App, Heroku. nginx, Plesk, итд) — но во всех случаях, кажется, скачивается идентичный архив.

Сертификат готов, но… сервис SSL For Free создаёт три файла:

ca_bundle.crt (цепочка, исключая конечный сертификат)
certificate.crt (сам конечный сертификат)
private.key (ваш приватный ключ, который никому нельзя ни показывать, ни отсылать).

Поэтому fullchain мы склеим вручную из двух первых файлов (сначала certificate.crt, затем ca_bundle.crt), и назовём его fullchain.crt (имена на самом деле могут быть любыми, но принято — и нужно — использовать «говорящие» названия: fullchain.crt/fullchain.pem, или domain.ca-bundle)

Сделать это можно как консольными командами, так и в обычном Блокноте Windows. Пример консольной команды:

cat domain.crt Intermediate1.crt Intermediate2.crt <все промежуточные что есть через пробел> CARoot.crt > fullchain.crt

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

Серверу отдаём, соответственно, fullchain.crt и private.key.

Немного паранойи

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

ОБЗОР ФОРМАТОВ SSL CЕРТИФИКАТОВ

ФОРМАТ СЕРТИФИКАТА PEM

PEM – наиболее популярный формат среди сертификационных центров. PEM сертификаты могут иметь расширение .pem, .crt, .cer, и .key (файл приватного ключа). Она представляют собой ASCII файлы, закодированные по схеме Base64. Когда вы открываете файл pem формата в текстовом редакторе, вы можете увидеть, что текст кода в нем начинается с тега «—— BEGIN CERTIFICATE ——» и заканчивая тегом «—— END CERTIFICATE ——«. Apache и другие подобные серверы используют сертификаты в PEM формате

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

Как правило, для установки SSL сертификата на Apache, сертификаты и приватный ключ должны быть в разных файлах.

ФОРМАТ СЕРТИФИКАТА DER

DER формат – это бинарный тип сертификата вместо формата PEM. В PEM формате чаще всего используется расширение файла .cer, но иногда можно встретить и расширение файла .der. Поэтому чтобы отличить SSL сертификат в формате PEM от формата DER, следует открыть его в текстовом редакторе и найти теги начала и окончания сертификата (BEGIN/END). DER SSL сертификаты, как правило, используются на платформах Java.

PKCS # 7 / P7B СЕРТИФИКАТ

SSL сертификаты в формате PKCS # 7 или P7B — это файлы, которые хранятся в формате Base64 ASCII и имеют расширение файла .p7b или .p7c. P7B сертификаты содержат теги начала сертификата «—— BEGIN PKCS7 ——» и его конца «—— END PKCS7 ——«. Файлы в формате P7B включают в себя только ваш SSL сертификат и промежуточные SSL сертификаты. Приватный ключ при этом идет отдельным файлом. SSL сертификаты в формате PKCS # 7 / P7B поддерживают следующие платформы: Microsoft Windows и Java Tomcat.

PFX СЕРТИФИКАТ (ФОРМАТ PKCS # 12)

Формат SSL сертификата PKCS # 12 или, как его еще называют, PFX сертификат — бинарный формат, при использовании которого в одном зашифрованном файле хранится не только ваш личный сертификат сервера и промежуточные сертификаты центра сертификации, но и ваш закрытый ключ. PFX файлы, как правило, имеют расширение .pfx или .p12. Обычно, файлы формата PFX используются на Windows серверах для импорта и экспорта файлов сертификатов и вашего приватного ключа.

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

Со временем появились три версии сертификата. В каждой из версий добавлялись новые поля. Версия 3, которая действует в настоящий момент, содержит все поля версий 1 и 2, дополненные полями версии 3. Версия 1 определяет следующие поля:

Version (Версия) — значение 1, 2 или 3, которое указывает используемую версию сертификата.
Serial Number (Серийный номер) — уникальный идентификатор, который присваивается каждому сертификату ЦС.
CA Signature Algorithm (Алгоритм подписывания ЦС) — имя алгоритма, который ЦС использует для подписывания содержимого сертификата.
Issuer Name (Имя издателя) — различающееся имя ЦС, который выдал этот сертификат.
Validity Period (Период действия) — период времени, в течение которого сертификат считается действительным.
Subject Name (Имя субъекта) — имя сущности, которую представляет сертификат.
Subject Public Key Info (Данные открытого ключа субъекта) — открытый ключ, принадлежащий субъекту сертификата.

В версии 2 добавлены следующие поля с информацией об издателе сертификата, хотя эти поля редко используются:

Issuer Unique ID (Уникальный идентификатор издателя): уникальный идентификатор центра сертификации, который выдал сертификат. Он определяется самим центром сертификации.
Subject Unique ID (Уникальный идентификатор субъекта) — уникальный идентификатор субъекта сертификата, который определяется ЦС, выдавшим сертификат.

В сертификатах версии 3 добавлены следующие расширения:

Authority Key Identifier (Идентификатор ключа центра) — может содержать одно из двух значений:
- субъект ЦС и серийный номер сертификата ЦС, который выдал сертификат;
- хэш-код открытого ключа ЦС, который выдал этот сертификат.
Subject Key Identifier (Идентификатор ключа субъекта) — хэш-код открытого ключа сертификата.
Key Usage (Использование ключа) — определяет службу, для которой можно использовать сертификат. Здесь могут содержаться одно или несколько значений из следующего списка:
- Цифровая подпись
- Неотрекаемость
- Шифрование ключа
- Data Encipherment (Шифрование данных);
- Key Agreement (Согласование ключей);
- Key Cert Sign (Подпись сертификата с ключом);
- CRL Sign (Подпись списка отзыва сертификатов);
- Encipher Only (Только шифрование);
- Decipher Only (Только расшифровка).
Private Key Usage Period (Период использования закрытого ключа) — период действия закрытого ключа из пары ключей.
Certificate Policies (Политики сертификатов) — политики, используемые для проверки субъекта сертификата.
Policy Mappings (Сопоставления политик) — сопоставляет политику в одной организации с политикой в другой.
Subject Alternative Name (Альтернативное имя субъекта) — список альтернативных имен для субъекта.
Issuer Alternative Name (Альтернативное имя издателя) — список альтернативных имен для ЦС, выдавшего сертификат.
Subject Dir Attribute (Атрибут DIR субъекта) — атрибуты из каталога X.500 или LDAP.
Basic Constraints (Базовые ограничения) — позволяет определить в сертификате, кому он выдан: ЦС, пользователю, компьютеру, устройству или службе. Это расширение также включает ограничение длины пути, которое ограничивает допустимое количество подчиненных ЦС в цепочке.
Name Constraints (Ограничения имен) — определяет, какие пространства имен разрешены в сертификате, выданном ЦС.
Policy Constraints (Ограничения политики) — позволяет запретить сопоставления политик между ЦС.
Extended Key Usage (Расширенное использование ключа) — указывает, как можно использовать открытый ключ сертификата, кроме целей, определяемых расширением Key Usage (Использование ключа).
CRL Distribution Points (Точки распространения списков отзыва сертификатов) — содержит один или несколько URL-адресов, в которых публикуется базовый список отзыва сертификатов.
Inhibit anyPolicy (Запрет любой политики) — запрещает использование значения All Issuance Policies (Все политики выдачи) с идентификатором OID (2.5.29.32.0) в сертификатах подчиненного ЦС.
Freshest CRL (Актуальный список отзыва сертификатов) — содержит один или несколько URL-адресов, в которых публикуется разностный список отзыва сертификатов ЦС, выдавшего этот сертификат.
Authority Information Access (Доступ к информации центра) — содержит один или несколько URL-адресов, в которых публикуется сертификат ЦС, выдавшего этот сертификат.
Subject Information Access (Доступ к сведениям о субъекте) — содержит сведения о том, как можно получить дополнительные сведения о субъекте сертификата.

Current certificate best practices

Set lifetime lower than 398 days
Use SHA-256 instead of SHA-1
Use 2048 bit keys for now (4096 is still too resource intensive)

Certificate chain order

The correct order of a certificate bundle a.k.a certificate chain e.g:

is:

Web Server:

HTTP Client:

The following certificate chain issues can occur:

: When a site does not provide the necessary intermediate certificates, a trust path cannot be established. Generally speaking, one cannot distinguish that case from a certificate signed by a custom CA. However, some server certificates include the information on which intermediate certificates are required, and also where to obtain them. If the intermediate certificates are found, then it’s very likely that a trust path will be established. In such cases you should reconfigure the server to add the missing certificates.
: Sites often include more certificates in the handshake than necessary. Of those, most include one extra certificate, and that is the actual trusted root certificate (which browsers already have in their storage). This last certificate is not needed for the validation process. Having an additional certificate in the chain wastes bandwidth and decreases overal performance slightly. A small number of sites will include a very large number of certificates as a result of misconfiguration. Such sites will typically suffer significant performance issues and need to be reconfigured.
: According to the standard, certificates must be presented in the order in which they are needed. The main, server, certificate must come first, followed by the certificate that signed it, followed by the next certificate in the chain, and so on. A small number of sites does not get this order right. Most SSL clients will deal with this problem silently, but there is a small number of platforms that will give up.