В этой статье объясняется, как использовать сертификаты, выданные сторонним центром сертификации (CA), например Let's Encrypt, Comodo, Symantec, Digicert и т. Д. В ней также будет рассмотрено, как сертификаты работают в целом.
Краткий обзор
Сертификаты служат двум основным целям: шифрование связи между двумя объектами и подтверждение подлинности объекта. Первая цель может быть достигнута с помощью так называемого самозаверенного (самоподписанного) сертификата, но для аутентификации объекта вам понадобится глобально доверенный сертификат, выданный корневым или промежуточным Центром Сертификации (ЦС ) / Certification Authority (CA). В этой статье объясняется, как сертификаты обычно обеспечивают аутентификацию, как изменить формат сертификата для работы с другими устройствами, включая наши шлюзы безопасности, как импортировать сертификат в ваш шлюз безопасности и как обращаться с сертификатами, чтобы избежать угроз безопасности.
Таблица содержания
- Как работает сертификат?
- Самоподписанные сертификаты
- Работа с сертификатами
- Импорт сертификатов в шлюзы безопасности USG / ATP / VPN / FLEX
- Сертификат безопасности
Как работает сертификат?
Каждый сертификат состоит из двух частей: сертификата (также называемого открытым ключом) и закрытого ключа. Сертификат может быть общедоступным, и он просто содержит информацию о целях, для которых был выпущен сертификат, и о том, какой организации был выдан сертификат - это может быть ваше полное доменное имя, адрес электронной почты или другое значение.
Сертификаты имеют ограниченный срок действия - это помогает в ситуациях, когда какой-то старый сертификат с закрытым ключом откопали где-то спустя десятилетия. Если срок действия был бесконечным, сертификат все равно мог быть использован в злонамеренных целях любым, кто его получил. С 2021 года рекомендуется не использовать срок действия более одного года. С появлением механизмов автоматической перевыпуска, таких как CertBot, этот период может стать намного короче для дальнейшего повышения безопасности.
Сертификаты могут быть отозваны в случае утечки закрытого ключа - и в качестве меры предосторожности любое нарушение безопасности, связанное с скомпрометированным оборудованием, содержащим закрытые ключи, должно сопровождаться отзывом сертификата и последующей повторной выдачей новых сертификатов.
Сертификаты могут быть выданы различным объектам, таким как полное доменное имя, электронная почта, даже IP-адрес или данное имя. Хотя технически возможно иметь сертификаты FQDN с подстановочным знаком "*", и они часто предпочитаются пользователями, имейте в виду, что в случае утечки закрытого ключа из определенной службы сертификат с подстановочными знаками аутентифицирует все FQDN - в результате утечка закрытого ключа на веб-сервере, который используется для простого представления компании, может также использоваться для атак MITM между сервером Exchange или системой CRM. Сохранение независимости сертификатов для каждого домена низшего уровня помогает снизить влияние утечки до тех пор, пока сертификат не будет отозван.
Хотя также можно выдавать сертификаты на IP-адрес, это не рекомендуется. Причина в том, что IP-адреса можно легко изменить по сравнению с FQDN.
Основной принцип сертификатов довольно прост. В одном примере Алиса хочет получить доступ к серверу Боба, но проблема в том, что ее там никогда не было, поэтому они никогда не смогут обменяться каким-либо общим секретом для аутентификации. Как Алиса может быть уверена, что она действительно подключается к Бобу? Здесь в игру вступает Чарли. Алиса знает Чарли и добавила его сертификат в хранилище корневых сертификатов. Поэтому Алиса считает Чарли доверенным лицом. Если у Боба есть собственный сертификат и закрытый ключ, выданный Чарли, он может пройти аутентификацию для Алисы, и не имеет значения, что Алиса никогда раньше не общалась с Бобом, потому что Бобу доверяет Чарли, а поскольку Алиса доверяет Чарли, она доверяет и Бобу. Это так называемая цепочка доверия.
Давайте посмотрим на цепочку доверия для нашего веб-сертификата портала техподдержки:
Обратите внимание, что есть еще один объект под названием "R3". Это называется промежуточным ЦС, тогда как "DST Root CA X3" является корневым ЦС. Сертификат может иметь только один корневой ЦС, но может иметь большее количество промежуточных ЦС. Промежуточный ЦС - это организация, которой предоставлено разрешение на выпуск сертификатов для своих клиентов. Пока ваш компьютер имеет сертификат "DST Root CA X3" в списке доверенных корневых сертификатов, он будет считать support.zyxel.eu доверенным.
Самоподписанные сертификаты
По умолчанию наши шлюзы безопасности (и многие другие устройства) используют самоподписанные сертификаты для установления зашифрованного TLS-соединения. О таком сертификате браузер сообщает известное сообщение об ошибке: 
Это происходит по двум причинам. Первая причина заключается в том, что сертификат в основном является сертификатом корневого ЦС, которого нет в вашей системе. Но простая установка его в качестве корневого ЦС на ваш компьютер не поможет, потому что сертификат не выдается для вашего IP-адреса или домена. Однако сертификат подходит для безопасного соединения, и его использование не несет никакой угрозы безопасности, если его закрытый ключ не просочился - единственная проблема здесь в том, что личность не может быть подтверждена.
Работа с сертификатами
За прошедшие годы было разработано множество форматов сертификатов. Однако сертификаты по-прежнему используют тот же принцип, и все форматы могут быть преобразованы из одних в другие.
Форматы сертификатов
Самым старым форматом будет PEM, который содержит ключ в кодировке ASCII. Причина этого - использование в оригинальном виде в зашифрованных письмах, где двоичный сертификат может быть искажен. PEM распространены в системах Unix, и вполне вероятно, что ваш CA отправил вам сертификат вместе с закрытым ключом в формате PEM. Обычно используется расширение файла .pem или .cer.
DER - это двоичная форма сертификата формата ASCII PEM. Все типы сертификатов и закрытых ключей можно закодировать в формате DER. Этот формат поддерживает хранение одного сертификата и не включает закрытый ключ для промежуточного / корневого ЦС. Они имеют расширение .der или .cer и чаще всего используются на платформах Java.
PKCS # 7 - это двоичный формат, который позволяет содержать сертификаты или всю цепочку доверия сертификатов в одном файле. Однако в этом формате нельзя хранить закрытый ключ. Этот формат чаще всего используется центрами сертификации для обеспечения полной цепочки доверия. Использует расширение .p7b.
PKCS # 12, также известный как PFX, - это формат, который может содержать всю цепочку доверия и закрытый ключ. Обычно этот формат предоставляется центрами сертификации, так как он может быть защищен паролем. Обычно используется расширение .p12 или .pfx.
Инструменты сертификата
В Windows есть встроенная системная служебная программа командной строки certutil, которую можно использовать для преобразования сертификатов. Плагины управления в Microsoft Management Console также позволяют управлять сертификатами.
Утилита с открытым исходным кодом под названием OpenSSL также может обрабатывать и преобразовывать сертификаты. Бинарные файлы доступны для Windows, Linux и macOS (и многих других платформ).
Полезные команды certutil:
Merging PEM into PFX:
C:\temp>certutil –MergePFX cert.cer cert.pfx
NOTE: as certutil doesn't allow to specify private key path, the key must be present
in the same directory as certificate, have the same name and .key extension.
Полезные команды OpenSSL:
Merging PEM into PFX:
C:\temp>openssl pkcs12 -export -out cert.pfx -inkey key.pem -in cert.pem
Импорт сертификата в шлюзы безопасности USG / ATP / VPN / FLEX
Текущий дизайн (по состоянию на июнь 2021 г.) ограничен импортом сертификатов без промежуточных ключей. Если сертификат содержит промежуточный ключ, файл будет проанализирован неправильно и попытка использовать такой сертификат может привести к недоступности службы (например, веб-интерфейса). Рекомендуется получить сертификат в формате .pem и экспортировать его в формат .pfx с помощью certutil или OpenSSL. Сертификат можно импортировать вместе с паролем в пункте меню:
Configuration > Objects > Certificates > My Certificates
Сертификат безопасности
У каждого сертификата есть соответствующий закрытый ключ. Хотя сертификат является общедоступной информацией, с закрытым ключом нужно обращаться как с секретом, и никто не должен его передавать. Даже у нас в Zyxel единственный верный способ работы с закрытым ключом - использовать инструменты удаленной помощи, такие как TeamViewer. При хранении закрытого ключа в формате PEM дважды проверьте разрешения на доступ к закрытому ключу, чтобы предотвратить его утечку. Всегда используйте шифрование паролей в формате PFX, чтобы обеспечить хотя бы некоторую степень безопасности при экспорте сертификатов. Любые сертификаты с утечкой закрытого ключа должны быть немедленно отозваны.