Pem, der, crt и cer: кодировки и преобразования x.509

А можно обмениваться сканами через мессенджеры?

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

Если все же решили обмениваться документами и обсуждать сделку в мессенджерах, пропишите это в договоре. Напишите так:

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

Суд не принял переписку, которую не заверил нотариус, и отказал компании в иске

В деле № А56-55043/2015 компания «АЛЬКОР ГЕОПРОДЖЕКТС Лимитед» требовала у ООО «Севморгео» 614 320 долларов. Договоренности с партнером «АЛЬКОР» подтверждала распечаткой переписки. Суд ее не принял, потому что она не была заверена нотариусом, и отказал в иске.

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

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

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

В деле № А19-1050/2012 арбитражный суд обязал ИП Мартынову выплатить ООО «Домик» 300 000 ₽ долга и 9000 ₽ за просрочку. ИП Мартынова пыталась доказать, что договор не заключала. Но контрагент показал платежку, которая подтверждала, что ИП Мартынова внесла аванс по этому договору. Суд счел это одобрением сделки.

Можно подтвердить законность сделки, даже если скан договора пришел с несогласованного адреса. Достаточно переписки с почты, которая размещена на домене компании.

Письмо со сканом пришло не с согласованного адреса, но его все равно признали законным

В деле № Ф06-1047/2015 ООО «Стройдом» пытались признать сделку с ООО «Химсталькон-Инжиниринг» недействительной. Скан договора отправили не с почты ivanov@himstalcon.ru, которая была прописана в договоре, а с почты kosova@himstalkon.ru. В остальном же договор был оформлен верно. «Химсталькон-Инжиниринг» предоставил документы на домен, и суд признал сделку законной.

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

Главное

По сканам договоров можно безопасно работать, если:

В договоре прописаны адреса электронной почты, с которой ведется официальная переписка. Идеально, если почта находится на домене компании.
У человека, который подписывает договор, есть на это право. Например, доверенность.
Электронные копии документов хранятся на жестком диске или сервере.

По сканам нельзя:

Закрытые ключи

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

Чтобы создать закрытый 2048-битный ключ, защищённый паролем, введите:

По запросу введите пароль, чтобы продолжить.

Проверка закрытого ключа

Эта команда подтвердит валидность закрытого ключа:

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

Совпадение ключа с сертификатом и запросом

Эта команда позволяет узнать, относится ли закрытый ключ (domain.key) к тому или иному сертификату (domain.crt) и запросу (domain.csr):

Если команды вернули одинаковый вывод, то, скорее всего, этот ключ, запрос и сертификат связаны.

Шифрование закрытого ключа

Следующая команда возьмёт незашифрованный ключ (unencrypted.key) и зашифрует его (encrypted.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.

EasyRSA

Вместе с OpenVPN поставляется набор скриптов (есть под Linux и Windows), которые вызывают openssl для выполнения основных манипуляций с сертификатами. В набор скриптов входят:

build-ca — создать приватный ключ удостоверяющего центра (CA)
build-key-server — создать серверный приватный ключ и сертификат, подписанный ключом CA
build-dh — создать серверный ключ Диффи-Хелмана
build-key — создать клиентский приватный ключ и сертификат, подписанный ключом CA
build-key-pkcs12 — создать приватный ключ, сертификат и упаковать их вместе сертификатом CA

Версии с добавлением -pass потребуют ввода пароля для шифрования приватного ключа.

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

vars.sh (фрагмент)

Сохранить сертификаты и личные ключи в файлы

Вы можете экспортировать сертификаты и закрытый ключ из файла PKCS # 12 и сохранить их в формате PEM в новый файл, указав выходное имя файла:

openssl pkcs12 -in INFILE.p12 -out OUTFILE.crt -nodes

Вам снова будет предложено ввести пароль файла PKCS # 12. Как и раньше, вы можете зашифровать закрытый ключ, удалив пометка из команды и / или добавление or выводить только закрытый ключ или сертификаты. Итак, для генерации файла закрытого ключа мы можем использовать эту команду:

openssl pkcs12 -in INFILE.p12 -out OUTFILE.key -nodes -nocerts

И чтобы создать файл, включающий только сертификаты, используйте это:

openssl pkcs12 -in INFILE.p12 -out OUTFILE.crt -nokeys

Включенный экспериментальный протокол QUIC

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

Показываем как отключить QUIC на примере браузера Google Chrome:

Откройте браузер и введите команду chrome://flags/#enable-quic;
В появившемся окне будет выделен параметр: Experimental QUIC protocol (Экспериментальный протокол QUIC). Под названием этого параметра вы увидите выпадающее меню, в котором нужно выбрать опцию: Disable.

Этот способ работает и в Windows и в Mac OS.

Отзыв сертификата

Утилита OpenSSL ocsp может выступать в качестве ответчика OCSP, но она предназначена только для тестирования. Для производственной среды OCSP ответчики тоже существуют, но они выходят за рамки данной статьи.

Создадим серверный сертификат для тестирования.

Запустим ответчик OCSP на локальной машине. Вместо того, чтобы хранить статус отзыва в отдельном CRL файле ответчик OCSP напрямую читает файл index.txt. Ответ подписывается криптографической парой OCSP (используя опции –rkey и –rsigner).

В другом терминале пошлем запрос к OCSP ответчику. Опция указывает сертификат для запроса.

Начало вывода показывает следующее:

был ли получен положительный ответ (OCSP Response Status)
идентичность ответчика (Responder Id)
статус отзыва сертификата (Cert Status)

Отзыв сертификата.

Как и раньше, запускаем ответчик OCSP в другом терминале и шлем запрос. В этот раз вывод показывает и .

Подготовка

Генерация ключей SSH и сохранение их в пару файлов (mykey,mykey.pub)

Приватные ключи по умолчанию сохраняются в формате PEM PKCS#1. Ключи, созданные в «новом» формате OpenSSH (опция ) не совместимы с другими криптографическими системами.

Формат PEM можно отличить по строкам

в файле приватного ключа. В новом формате они заменены на строки

Публичный ключ так же нужно сконвертировать в формат PEM PKCS#8 (Можно это будет сделать на лету в момент шифрования):

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

Создание ключа

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

Хотя 4096 бит немного больше безопаснее, чем 2048 бит, он замедляет TLS хэндшейки и значительно увеличивает нагрузку на процессор во время хэндшейков. По этой причине, большинство веб-сайтов используют 2048-битные пары ключей.

Если вы создаете криптографическую пару для использования веб-сервером (к примеру, Apache), вам потребуется вводить пароль каждый раз, когда вы перезапускаете веб-сервер. Вы можете указать опцию –aes256 для создания ключа без пароля.

Генерация CSR запроса на сертификат

CSR (Certificate Signing Request) – это зашифрованный запрос на получение сертификата, включает в себя информацию о домене и организации.

CSR может быть сгенерирован одним из способов:

Автоматически в процессе заказа SSL-сертификата.
Онлайн, через CSR генератор, например у или .
Самостоятельно на собственном веб-сервере.

В независимости от способа, в результате вы должны получить 2 файла (или их текстовое содержание) — файл запроса (domain.csr) и файл приватного ключа (private.key). Файл запроса потребуется для генерации сертификата. А приватный ключ понадобится в дальнейшем, его вместе с сертификатом нужно будет установить на хостинг или сервер.

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

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

При заказе сертификатов типа WildCard доменное имя необходимо указывать со знаком звездочка (Пример: *.domain.com).

У домена, для которого заказывается SSL-сертификат (за исключением зон .ru и .рф), должно быть отключено сокрытие персональных данных.

В некоторых случаях, для того, чтобы сертификат защищал домены с префиксом www и без него, необходимо указать домен с префиксом, например: www.domain.ru. В противном случае сертификат не будет защищать домен с www даже если он поддерживает его.

Далее при генерации запроса CSR вам потребуется указать адрес электронной почты. Рекомендуется заранее создать почтовый ящик вида admin@domain, administrator@domain, hostmaster@domain, postmaster@domain или webmaster@domain и указать в контактных данных его. Этот же адрес пригодится позже для подтверждения владения доменом.

Генерация CSR запроса на собственном сервере

Потребуется криптографический пакет с открытым исходным кодом – . Он входит в состав большинства UNIX-подобных операционных систем.

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

Подключитесь к серверу по SSH и перейдите в домашнюю директорию.

Сгенерируйте закрытый ключ.

В команде выше:

private.key – выходной файл, который будет содержать ключ;
4096 – размер ключа, резже 2048.

На запрос «Enter pass phrase for private.key» укажите пароль для защиты закрытого ключа, а затем «Verifying – Enter pass phrase for private.key» – подтвердите его, повторив ввод пароля еще раз.

Закрытый ключ будет создан и сохранен в файл под именем private.key.

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

Далее сгенерируйте CSR запрос.

В команде выше:

private.key – созданный на предыдущем этапе закрытый ключ;
domaine.csr – выходной файл с CSR запросом.

На запрос «Enter pass phrase for private.key» введите пароль от закрытого ключа.

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

Country Name – двухсимвольный код страны согласно ISO-3166, например RU для России;
State or Province Name: область или регион без сокращений;
Locality Name: название города или населенного пункта;
Organization Name: название организации, для физ. лиц укажите «Private Person»;
Organizational Unit Name: подразделение (необязательно), для которого заказывается сертификат, например для IT-отдела можно указать IT;
Common Name: доменное имя (полностью) для которого заказывается сертификат;
Email Address: контактный e-mail адрес, вида admin@domain, administrator@domain, hostmaster@domain, postmaster@domain или webmaster@domain;
A challenge password: не заполняется;
An optional company name: альтернативное имя компании (необязательно).

CSR запрос на сертификат будет сохранен в файле domain.csr в виде закодированного текста.

Проверить корректность введенных данных можно, выполнив следующую команду.

Файлы закрытого ключа и CSR запроса или их содержимое потребуются далее. Вывести (чтобы затем скопировать) содержимое файла можно командой cat.

или

Для выхода нажмите клавишу Q.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ответ 2

PEM — сам по себе не является сертификатом, это просто способ кодирования данных. Сертификаты X.509 — это один из типов данных, которые обычно кодируются с помощью PEM.

PEM — это сертификат X.509 (структура которого определена с помощью ASN.1), закодированный с помощью ASN.1 DER (distinguished encoding rules), затем закодированный Base64 кодировкой и вставленный между заголовками текста (BEGIN CERTIFICATE и END CERTIFICATE).

Вы можете представить те же данные, используя представления PKCS#7 или PKCS#12, и для этого можно использовать утилиту командной строки OpenSSL.

Очевидным преимуществом PEM является то, что его безопасно вставлять в тело электронного сообщения, поскольку он имеет заголовки и 7-битную кодировку.

RFC1422 содержит более подробную информацию о стандарте PEM в части, касающейся ключей и сертификатов.