Что такое корневой сертификат SSL и зачем он нужен.

Корневой сертификат SSL – одна из частей схемы PKI (инфраструктуры публичных ключей), которая идентифицирует корневой центр сертификации. Важность SSL сертификации и преимущества оценили многие пользователи. Использование SSL гарантирует:

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

Но возникает вопрос: откуда берутся цифровые сертификаты безопасности и кто отвечает за их надежность?

Есть несколько основных доверенных центров сертификации , которые выдают сертификаты SSL и Code Signing. Они проверяют, действительно ли клиент, запросивший SSL имеет доступ к домену или является представителем запрашивающей организации. Кроме того, именно центры сертификации несут ответственность за конфиденциальность передаваемой информации. Массовое применение сертификатов SSL привело к большому количеству сертификационных центров, каждый из которых подписывает предоставляемые решения своим именем. Чтобы браузер пользователя мог отличать поставщиков SSL друг от друга, а также определить их надежность, в нем применяется список доверенных центров сертификации.

Структура SSL сертификатов

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

На примере сертификационного центра Comodo, структуру SSL сертификатов можно изобразить следующим образом:

• Корневой сертификат ЦС Comodo : AddTrustExternalCARoot
• Промежуточные сертификаты: PositiveSSL CA 2, ComodoUTNSGCCA, UTNAddTrustSGCCA, EssentialSSLCA, Comodo High-Assurance Secure Server CA
• В самом низу изображены SSL сертификаты для отдельных доменов .

Для чего нужен корневой сертификат SSL?

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

Что же касается таких доверительных центров сертификации, как Comodo, Symantec, Thawte, GeoTrust и GlobalSign, то данные об их корневых сертификатах в обязательном порядке добавляются во все современные браузеры. Их список в настройках обозревателя выглядит следующим образом:

Но для правильного распознавания SSL для Вашего личного доменного имени, необходимо создать так называемую цепочку доверия (trust chain) из доменного, промежуточного и корневого сертификатов SSL. Для этого необходимо установить корневой, а также промежуточный сертификаты на своем сервере. Процесс установки производится по разному, в зависимости от Вашего программного обеспечения. Для наиболее известного ПО на нашем сайте можно найти

• Tutorial

Привет, Хабр! Мы начинаем новую серию статей. Она будет посвящена развертыванию службы сертификатов на предприятии на базе Windows Server 2016 с практическими примерами. Сегодня обозначим вступительные моменты и поговорим о типовых схемах развёртывания иерархии PKI: двухуровневой и многоуровневой. Обо всем этом читайте под катом.

Введение

Целевая аудитория

ИТ-администраторы, ИТ-инженеры и специалисты по безопасности, имеющие основные понятия о цифровых сертификатах.

Словарь терминов

В этой части серии использованы следующие сокращения и аббревиатуры:

• PKI (Public Key Infrastructure ) - инфраструктура открытого ключа (ИОК), набор средств (технических, материальных, людских и т. д.), распределённых служб и компонентов, в совокупности используемых для поддержки криптозадач на основе закрытого и открытого ключей. Поскольку аббревиатура ИОК не является распространённой, здесь и далее будет использоваться более знакомая англоязычная аббревиатура PKI.
• X.509 - стандарт ITU-T для инфраструктуры открытого ключа и инфраструктуры управления привилегиями.
• ЦС (Центр Сертификации ) - служба, выпускающая цифровые сертификаты. Сертификат - это электронный документ, подтверждающий принадлежность открытого ключа владельцу.
• CRL (Certificate Revocation List ) - список отзыва сертификатов. Подписанный электронный документ, публикуемый ЦС и содержащий список отозванных сертификатов, действие которых прекращено по внешним причинам. Для каждого отозванного сертификата указывается его серийный номер, дата и время отзыва, а также причина отзыва (необязательно). Приложения могут использовать CRL для подтверждения того, что предъявленный сертификат является действительным и не отозван издателем.
• SSL (Secure Sockets Layer ) или TLS (Transport Layer Security ) - технология, обеспечивающая безопасность передачи данных между клиентом и сервером поверх открытых сетей.
• HTTPS (HTTP/Secure ) - защищённый HTTP, являющийся частным случаем использования SSL.
• Internet PKI - набор стандартов, соглашений, процедур и практик, которые обеспечивают единый (унифицированный) механизм защиты передачи данных на основе стандарта X.509 по открытым каналам передачи данных.

Зачем нужен частный PKI?

Шифрование, цифровые подписи и сертификаты всё плотнее входят в нашу повседневную интернет-жизнь. Если об этих терминах 10 лет назад говорили мало, и далеко не всем ИТ специалистам был известен смысл этих слов, то сейчас они у многих на слуху. И этот процесс длится не год и не два, а добрый десяток лет. Сейчас мы находимся в активной фазе развития клиент-серверных веб-сервисов (привет мейнфреймам!), и значительная доля коммуникации людей и устройств перекладывается на компьютерные сети и интернет. Как следствие, новые условия диктуют новые требования к защите данных. Крупные производители ПО активно продвигают идеологию «безопасного интернета», требуя поддержки цифровых сертификатов, начиная от серверов с конфиденциальными данными, облачных служб, вплоть до кухонного чайника или бельевого утюга (IoT).

Некоторые компании делают это весьма настойчиво. Так, начиная с 2017 года, компания Google считает все сайты без поддержки HTTPS небезопасными: Moving towards a more secure web . И это весьма ощутимо влияет на интернет-индустрию. Во-первых, предупреждение в браузере (Google Chrome) явно не будет радовать ваших потенциальных клиентов и просто посетителей. Во-вторых, сайты без поддержки HTTPS опускаются в поисковой выдаче. Mozilla и другие крупные вендоры также не отстают от Google: Deprecating Non-Secure HTTP . С одной стороны, компании давят на интернет-индустрию, толкая организации на дополнительные расходы, связанные с цифровыми сертификатами. С другой стороны, это - вынужденный шаг, и всем нужно идти в ногу со временем.

Однако текущее положение Internet PKI не позволяет решать эти вопросы достаточно гибко и удобно, требуя существенных затрат. Например, один сертификат SSL для публичного веб-сервера вам обойдётся в сумму порядка $100, а если хотите сертификат с зелёной полосой, это вам будет стоить ещё дороже. И это только за один сертификат! При этом автоматизация процессов находится в самом зачаточном состоянии.

Для решения этих проблем крупнейшие вендоры ПО объединились и совместными усилиями наводят порядок с цифровыми сертификатами в Internet PKI. Во-первых, создан единый стандартизирующий орган - CAB Forum (CA/Browser Forum), который определяет стандартные практики для коммерческих CA, производителей веб-ПО и потребителей сертификатов. Во-вторых, активное продвижение некоммерческого CA (но глобально доверенного) Let’s Encrypt для обеспечения бесплатными сертификатами с возможностью автоматического продления.

Казалось бы, это решает все проблемы безопасной коммуникации, и частные PKI (разворачиваемые в пределах организации) стали сразу ненужными. В какой-то, да, если частный PKI занимался обслуживанием внешних серверов (веб, VPN и т.д.). Но сервисы наподобие Let’s Encrypt в настоящее время покрывают лишь узкий спектр корпоративных потребностей в сертификатах. Например, не покрываются сертификаты для шифрования документов, почты, цифровых подписей. Часть задач, как аутентификация клиентов не покрывается совсем. Ещё одним ограничением является то, что для использования публичных сертификатов, выданных коммерческими CA вам необходимо иметь публичный домен. Получить сертификат для веб-сервера на имя domain.local от Let’s Encrypt технически невозможно. Именно поэтому актуальность частных PKI остаётся на очень высоком уровне. Пример использования частных PKI в корпоративной среде изображён на следующем рисунке:

Если компания решает использовать частный PKI в пределах организации, встаёт другой насущный вопрос: как же правильно его организовать, чтобы он отвечал современным практикам и стандартам хотя бы в пределах организации. В интернете можно найти многочисленные статьи о том, как развернуть PKI в компании на основе Active Directory Certificate Services (ADCS). Но в большинстве своём они изобилуют ошибками, исходят из неверных предпосылок и нередко являются копированием какого-то исходного (не всегда удачного) материала, а к имеющимся фундаментальным ошибкам привносят ещё и свои. Как следствие, многочисленные провалы в развёртывании PKI. Об этом можно судить по количеству соответствующих тем на форумах (в частности, TechNet Server Security). Качественной документации на английском языке не хватает, а на русском… Этот цикл статей призван восполнить этот пробел и систематизировать современные наработки.
 

Общие положения

PKI является технологией безопасности, которая основывается на стандарте X.509 и использует цифровые сертификаты. Целью PKI является повышение безопасности ИТ инфраструктуры предприятия за счёт предоставления механизмов по защите данных от несанкционированного доступа и незаконного изменения данных (подделка данных). Это достигается двумя основными криптографическими механизмами:

• Шифрование – защищает данные от несанкционированного доступа третьих лиц путём шифрования данных криптографическими ключами. Только пользователи, имеющие необходимые ключи, могут получить доступ к данным. Шифрование обеспечивает секретность данных, но не защищает от их подмены.
• Цифровая подпись – защищает данные от несанкционированного изменения или подделки путём применения к данным специальных алгоритмов, которые образуют цифровую подпись. Любые манипуляции по изменению данных будут немедленно обнаружены при проверке цифровой подписи. Цифровая подпись обеспечивает не конфиденциальность данных, а их целостность. Путём комбинирования шифрования и цифровой подписи можно организовать обеспечение конфиденциальности и защиты данных от несанкционированных изменений.

Типичная инфраструктура PKI состоит из следующих компонентов:

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

Структура ЦС и сертификатов выстраиваются в древовидную иерархию. Каждый ЦС может выполнять одну или несколько (совмещать) ролей:

• Корневой ЦС – специальный тип ЦС, который имеет самоподписанный сертификат и является корнем дерева (отсюда и название). Этот тип ЦС является стартовой точкой доверия ко всем сертификатам в данной иерархии (дерева). Иными словами, клиент должен явно доверять конкретному корневому сертификату (а именно, комбинации: издатель и открытый ключ), чтобы доверять сертификатам, находящимся в остальной части дерева. Важно отметить, что доверие транзитивно. Клиент при проверке конечного сертификата будет выстраивать цепочку (путь) от конечного сертификата до вершины иерархии (корневого сертификата). И если клиент доверяет вершине, то будут и основания доверять конечному сертификату на правах транзитивности.
• ЦС политик – технически, это такой же ЦС, как и все остальные (в разрезе иерархии), с тем отличием, что дополняется внешними политиками и ограничениями по выдаче и использования цифровых сертификатов.
• Издающий ЦС – это ЦС общего назначения, который выполняет подпись и выдачу цифровых сертификатов потребителям.

Для понимания процесса построения цепочек сертификатов рекомендую прочитать следующую статью: Certificate Chaining Engine - how it works . Данная статья ориентирована на платформу Microsoft CryptoAPI, она также справедлива (за некоторыми исключениями) и для других реализаций криптографических платформ.

Поскольку ЦС выстраиваются в древовидную иерархию, возможно организовать многоуровневую иерархию, где на каждом уровне ЦС будет выполнять как роль издающего ЦС, так и дополнительные функции. В самом простом случае один ЦС может совмещать все роли, т.е. быть корневым, обеспечивать какие-то политики выдачи и выдавать сертификаты конечным потребителям. Более крупные компании и/или с более зрелой организацией ИТ-процессов уже используют разделение ЦС по ролям. Например, в головном офисе держат корневой ЦС, выдающий сертификаты только другим ЦС, которые уже на себе накладывают политики выдачи. Они могут не обслуживать напрямую конечных потребителей, а выдавать сертификаты другим подчинённым ЦС, которые, в свою очередь, и будут обслуживать конечных потребителей. В каждом подходе есть свои плюсы и минусы, которые будут рассмотрены ниже.

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

Помимо задач по выпуску сертификатов, каждый ЦС периодически выпускает списки отзыва (Certificate Revocation List, CRL). Как и сертификаты, целостность списков отзыва обеспечивается цифровой подписью. CRL содержит серийные номера сертификатов, действие которых прекращено по какой-либо причине до официального истечения срока действия сертификата. Таким образом ЦС обеспечивает своевременное изъятие недействительного сертификата из оборота.

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

Фактически, если корневой ЦС отозвал все свои непосредственно изданные сертификаты, то ни один сертификат под этим корнем не будет доверенным вне зависимости от высоты иерархии. Здесь следует отметить один крайне важный и принципиальный момент: невозможно отозвать корневой (самоподписанный) сертификат . Т.е. если по какой-то причине он был скомпрометирован, его можно отозвать только принудительным удалением сертификата из хранилища сертификатов каждого клиента. Дело в том, что ЦС не определяет списки отзывов для самого себя, это делает издатель. В случае самоподписанного сертификата, ЦС является издателем самого себя. И при попытке включить себя в свой же список отзыва получается неопределённость: сертификат ЦС включен в CRL, который подписан ключом этого же ЦС. Если предположить, что сертификат ЦС недействителен, то и цифровая подпись на CRL является недействительной. Как следствие, невозможно достоверно утверждать, что сертификат корневого ЦС отозван. Причём, отзыв корневых сертификатов не предусмотрен и основным регламентирующим стандартом, RFC 5280 , параграф §6.1 которого гласит:

When the trust anchor is provided in the form of a self-signed certificate, this self-signed certificate is not included as part of the prospective certification path.

А на отзыв проверяется только проспективная цепочка. Если говорить в контексте Microsoft ADCS, то тут ситуация усугубляется ещё больше. В частности, вы технически можете отозвать корневой сертификат при помощи certutil.exe или CryptoAPI. Но как только вы это сделаете, ЦС не сможет подписать ни один CRL, как следствие, сертификат ЦС никогда не попадёт в CRL. Более того, даже если использовать различные утилиты (тот же certutil.exe), можно насильно включить сертификат ЦС в CRL, но это мало чем поможет. Дело в том, что конфигурация по умолчанию CryptoAPI даже не пытается проверить корневой сертификат на отзыв.

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

Типовые схемы развёртывания иерархии PKI

В этом разделе мы рассмотрим типовые (или классические) схемы развёртывания иерархии PKI в условиях предприятия и проводятся оценки каждой схемы и рекомендации. Следует отметить, что ни одна из них не является универсальной, и каждая может иметь смысл в своих пределах.

Одноуровневая иерархия

Одноуровневая иерархия является самой простой в реализации и имеет следующий вид:

Такая иерархия является самой простой и экономичной как по ресурсам (лицензиям), так и по расходам на обслуживание и управление. Достаточно развернуть один такой ЦС в лесу Active Directory, и он будет обеспечивать сертификатами всех потребителей. Из неочевидных, но немаловажных достоинств можно отметить очень короткую цепочку сертификатов. Т.е. время на проверку доверенности и отзыва сертификата будет тратиться гораздо меньше, чем в любых других иерархиях.

Однако одноуровневая иерархия обладает рядом достаточно существенных недостатков. Самый крупный из них – низкий уровень безопасности. Поскольку ЦС в такой схеме должен быть постоянно включенным в сеть, чтобы клиенты могли запрашивать сертификаты, значительно увеличивается риск его компрометации. Последствия компрометации могут быть чудовищными, вплоть до полной потери контроля над Active Directory и краху ИТ систем. Это может быть вызвано как недостаточными мерами безопасности, наличием не закрытых уязвимостей ОС или компонентах системы, которые позволяют удалённое исполнение кода и т.д. Как отмечалось выше, отозвать нормальным способом такой сертификат уже нельзя, и последствия будут действительно тяжёлыми.

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

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

Двухуровневая иерархия

Двухуровневая иерархия уже подразумевает как минимум два ЦС в дереве, в котором один строго корневой, а остальные - подчинённые. Схема такой иерархии представлена ниже:

Примечание: здесь пунктирными линиями отмечен ручной (неавтоматизированный) процесс получения сертификата. Сплошными линиями отмечен автоматизированный процесс получения сертификатов.

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

Другим достоинством двухуровневой иерархии является улучшенная гибкость в разбиении подчинённых ЦС на какие-то классы. Тот же типичный сценарий, когда два ЦС управляются разными подразделениями ИТ, и каждый ЦС выпускает сертификаты для своих групп потребителей. Например, для машин отдельно, для пользователей отдельно. Можно для корпоративных разработчиков (которые обычно живут в своих средах) выделить свой подчинённый ЦС.

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

Из недостатков можно выделить лишь некоторое увеличение как административных, так и финансовых издержек (требуется дополнительная лицензия). К административным издержкам добавятся контроль за сроком действия каждого ЦС и списка отзыва корневого ЦС, а также их своевременное обновление. Кроме того, несколько увеличится время построения и проверки цепочек сертификатов, поскольку добавляется ещё один уровень. На практике это время практически не ощутимо.

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

Трёх- и более уровневые иерархии

В более крупных компаниях со сложной организацией сетей может случиться, что двухуровневая иерархия не может обеспечить необходимый уровень гибкости управления ЦС. Например, когда компания использует географический принцип разделения с относительной автономией ИТ отделов в каждом регионе. Представьте международную компанию с региональными офисами в разных странах. В них может действовать своё законодательство в вопросах безопасности, например, при обработке персональных данных. Для соблюдения подобных юридических формальностей на каждый такой регион выделяется свой собственный ЦС политик (при этом, размещается он, как правило, в головном офисе компании). В в своём сертификате он указывает поддержку (и ссылку на соответствующий документ) тех или иных нормативных документов и выпускает сертификаты для издающих ЦС, действующих в рамках тех политик, которые обозначены в сертификате (грубо говоря, в данном регионе).

В таких иерархиях корневой ЦС и ЦС политик изолируют от сети, а к сети уже подключаются только издающие ЦС:

Здесь также пунктиром отмечен ручной процесс получения сертификата для ЦС и сплошными линиями автоматизированный процесс получения сертификата для клиентов.

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

В рамках этой серии статей рассматривается наиболее популярная (в большинстве случаев) двухуровневая иерархия.

Об авторе

Вадим Поданс - специалист в области автоматизации PowerShell и Public Key Infrastructure, Microsoft MVP: Cloud and Datacenter Management с 2009 года и автор модуля PowerShell PKI. На протяжении 9 лет в своём блоге освещает различные вопросы эксплуатации и автоматизации PKI на предприятии. Статьи Вадима о PKI и PowerShell можно найти на его Представим, у нас есть два сервера, работают они себе, и переодически они хотят, что-то друг у друга спросить по протоколу HTTP/HTTPS.

Протокол HTTP не безопасен и логично использовать протокол HTTPS для общения меду серверами.

Для организации такого общения нам нужно 2 SSL сертификата.

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

Создаем наше CA

Первая команда создаёт корневой ключ

Openssl genrsa -out rootCA.key 2048
Для меня ключ 2048 bit достаточен, если вам хочется, вы можете использовать ключ 4096 bit.

Вторая команда создаёт корневой сертификат.

Openssl req -x509 -new -key rootCA.key -days 10000 -out rootCA.crt
Отвечать на вопросы тут можно как душе угодно.

Country Name (2 letter code) : State or Province Name (full name) : Locality Name (eg, city) : Organization Name (eg, company) : Organizational Unit Name (eg, section) : Common Name (e.g. server FQDN or YOUR name) : Email Address :
10000 дней срок его годности, примерно столько живет сертификат, которым google требует подписывать андроид приложения для Google Play. Если вы паникер, подписывайте на год или два.

Все! Теперь мы можем создавать сертификаты для наших серверов и устанавливать корневой сертификат на наши клиентские машины.

Создаем сертификат подписаный нашим СА

Генерируем ключ.

Openssl genrsa -out server101.mycloud.key 2048
Создаем запрос на сертификат.

Openssl req -new -key server101.mycloud.key -out server101.mycloud.csr
Тут важно указать имя сервера: домен или IP (например домен server101.mycloud )

Common Name (eg, YOUR name) : server101.mycloud
и подписать запрос на сертификат нашим корневым сертификатом.

Openssl x509 -req -in server101.mycloud.csr -CA rootCA.crt -CAkey rootCA.key -CAcreateserial -out server101.mycloud.crt -days 5000
Теперь на клиенты нужно установить корневой сертификат rootCA.crt

rootCA.crt - можно давать друзьям, устанавливать, копировать не сервера, выкладывать в публичный доступ
rootCA.key - следует держать в тайне

Установка корневого сертификата

Windows

IE, Chrome - используют репозиторий сертификатов Windows.

Мой путь к нему таков:

Chrome - Settings - Manage Certificates…
Выбрать таб Trusted Root Certificate Authorities - Import - rootCA.crt
перезапустить Chrome

FireFox на виндоус имеет свой репозиторий.

Java имеет свой репозиторий.

Mac OS X

Safari, FireFox, Chrome - используют системный репозиторий.

Запускаем KeyChain Access.
Идём в меню File - Import Items (login или System) - выбираем файл rootCA.crt .
Когда нас спросят, отвечаем - Always Trust.

Для вашего личного Safari достаточно выбрать login.

В Ubuntu

sudo mkdir /usr/share/ca-certificates/extra sudo cp rootCA.crt /usr/share/ca-certificates/extra/rootCA.crt sudo dpkg-reconfigure ca-certificates sudo update-ca-certificates

Программа сервера на Go

Программа сервера на Go myserver.go, которая использует наш подписаный сертификат.
package main import ("log" "net/http") func main() { http.Handle("/files/", http.StripPrefix("/files/", http.FileServer(http.Dir("./files/")))) go func() { log.Fatal(http.ListenAndServeTLS(":8443", "server101.mycloud.crt", "server101.mycloud.key", nil)) }() http.ListenAndServe(":8080", nil) }
go run myserver.go
запустив программу на сервере server101.mycloud, ваш броузер не будет ругаться на страничку https://server101.mycloud:8443/ , и откроет её как родную, если перед этим вы установили rootCA.crt в систему как корневой сертификат.

Сервер на Питоне

Import BaseHTTPServer, SimpleHTTPServer, ssl httpd = BaseHTTPServer.HTTPServer(("localhost", 8443), SimpleHTTPServer.SimpleHTTPRequestHandler) httpd.socket = ssl.wrap_socket (httpd.socket, certfile="server101.mycloud.pem", server_side=True) httpd.serve_forever()

# скопируем клуч и сертификат в один файл cat server101.mycloud.key server101.mycloud.crt > server101.mycloud.pem # запустим сервер на питоне python myserver.py

PS

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

One of the most common forms of cryptography today is public-key cryptography. Public-key cryptography utilizes a public key and a private key . The system works by encrypting information using the public key. The information can then only be decrypted using the private key.

A common use for public-key cryptography is encrypting application traffic using a Secure Socket Layer (SSL) or Transport Layer Security (TLS) connection. One example: configuring Apache to provide HTTPS , the HTTP protocol over SSL. This allows a way to encrypt traffic using a protocol that does not itself provide encryption.

A Certificate is a method used to distribute a public key and other information about a server and the organization who is responsible for it. Certificates can be digitally signed by a Certification Authority , or CA. A CA is a trusted third party that has confirmed that the information contained in the certificate is accurate.

Types of Certificates

To set up a secure server using public-key cryptography, in most cases, you send your certificate request (including your public key), proof of your company"s identity, and payment to a CA. The CA verifies the certificate request and your identity, and then sends back a certificate for your secure server. Alternatively, you can create your own self-signed certificate.

Note that self-signed certificates should not be used in most production environments.

Continuing the HTTPS example, a CA-signed certificate provides two important capabilities that a self-signed certificate does not:

Browsers (usually) automatically recognize the certificate and allow a secure connection to be made without prompting the user.

When a CA issues a signed certificate, it is guaranteeing the identity of the organization that is providing the web pages to the browser.

Most Web browsers, and computers, that support SSL have a list of CAs whose certificates they automatically accept. If a browser encounters a certificate whose authorizing CA is not in the list, the browser asks the user to either accept or decline the connection. Also, other applications may generate an error message when using a self-signed certificate.

The process of getting a certificate from a CA is fairly easy. A quick overview is as follows:

Create a private and public encryption key pair.

Create a certificate request based on the public key. The certificate request contains information about your server and the company hosting it.

Send the certificate request, along with documents proving your identity, to a CA. We cannot tell you which certificate authority to choose. Your decision may be based on your past experiences, or on the experiences of your friends or colleagues, or purely on monetary factors.

Once you have decided upon a CA, you need to follow the instructions they provide on how to obtain a certificate from them.

When the CA is satisfied that you are indeed who you claim to be, they send you a digital certificate.

Install this certificate on your secure server, and configure the appropriate applications to use the certificate.

Whether you are getting a certificate from a CA or generating your own self-signed certificate, the first step is to generate a key.

If the certificate will be used by service daemons, such as Apache, Postfix, Dovecot, etc., a key without a passphrase is often appropriate. Not having a passphrase allows the services to start without manual intervention, usually the preferred way to start a daemon.

This section will cover generating a key with a passphrase, and one without. The non-passphrase key will then be used to generate a certificate that can be used with various service daemons.

Running your secure service without a passphrase is convenient because you will not need to enter the passphrase every time you start your secure service. But it is insecure and a compromise of the key means a compromise of the server as well.

To generate the keys for the Certificate Signing Request (CSR) run the following command from a terminal prompt:

openssl genrsa -des3 -out server.key 2048

Generating RSA private key, 2048 bit long modulus ..........................++++++ .......++++++ e is 65537 (0x10001) Enter pass phrase for server.key:

You can now enter your passphrase. For best security, it should at least contain eight characters. The minimum length when specifying -des3 is four characters. It should include numbers and/or punctuation and not be a word in a dictionary. Also remember that your passphrase is case-sensitive.

Re-type the passphrase to verify. Once you have re-typed it correctly, the server key is generated and stored in the server.key file.

Now create the insecure key, the one without a passphrase, and shuffle the key names:

openssl rsa -in server.key -out server.key.insecure mv server.key server.key.secure mv server.key.insecure server.key

The insecure key is now named server.key , and you can use this file to generate the CSR without passphrase.

To create the CSR, run the following command at a terminal prompt:

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

It will prompt you enter the passphrase. If you enter the correct passphrase, it will prompt you to enter Company Name, Site Name, Email Id, etc. Once you enter all these details, your CSR will be created and it will be stored in the server.csr file.

You can now submit this CSR file to a CA for processing. The CA will use this CSR file and issue the certificate. On the other hand, you can create self-signed certificate using this CSR.

Creating a Self-Signed Certificate

To create the self-signed certificate, run the following command at a terminal prompt:

openssl x509 -req -days 365 -in server.csr -signkey server.key -out server.crt

The above command will prompt you to enter the passphrase. Once you enter the correct passphrase, your certificate will be created and it will be stored in the server.crt file.

If your secure server is to be used in a production environment, you probably need a CA-signed certificate. It is not recommended to use self-signed certificate.

Installing the Certificate

You can install the key file server.key and certificate file server.crt , or the certificate file issued by your CA, by running following commands at a terminal prompt:

sudo cp server.crt /etc/ssl/certs sudo cp server.key /etc/ssl/private

Now simply configure any applications, with the ability to use public-key cryptography, to use the certificate and key files. For example, Apache can provide HTTPS, Dovecot can provide IMAPS and POP3S, etc.

Certification Authority

If the services on your network require more than a few self-signed certificates it may be worth the additional effort to setup your own internal Certification Authority (CA) . Using certificates signed by your own CA, allows the various services using the certificates to easily trust other services using certificates issued from the same CA.

First, create the directories to hold the CA certificate and related files:

sudo mkdir /etc/ssl/CA sudo mkdir /etc/ssl/newcerts

The CA needs a few additional files to operate, one to keep track of the last serial number used by the CA, each certificate must have a unique serial number, and another file to record which certificates have been issued:

sudo sh -c "echo "01" > /etc/ssl/CA/serial" sudo touch /etc/ssl/CA/index.txt

The third file is a CA configuration file. Though not strictly necessary, it is very convenient when issuing multiple certificates. Edit /etc/ssl/openssl.cnf , and in the [ CA_default ] change:

dir = /etc/ssl # Where everything is kept database = $dir/CA/index.txt # database index file. certificate = $dir/certs/cacert.pem # The CA certificate serial = $dir/CA/serial # The current serial number private_key = $dir/private/cakey.pem# The private key

Next, create the self-signed root certificate:

openssl req -new -x509 -extensions v3_ca -keyout cakey.pem -out cacert.pem -days 3650

You will then be asked to enter the details about the certificate.

Now install the root certificate and key:

sudo mv cakey.pem /etc/ssl/private/ sudo mv cacert.pem /etc/ssl/certs/

You are now ready to start signing certificates. The first item needed is a Certificate Signing Request (CSR), see Generating a Certificate Signing Request (CSR) for details. Once you have a CSR, enter the following to generate a certificate signed by the CA:

sudo openssl ca -in server.csr -config /etc/ssl/openssl.cnf

After entering the password for the CA key, you will be prompted to sign the certificate, and again to commit the new certificate. You should then see a somewhat large amount of output related to the certificate creation.

There should now be a new file, /etc/ssl/newcerts/01.pem , containing the same output. Copy and paste everything beginning with the line: -----BEGIN CERTIFICATE----- and continuing through the line: ----END CERTIFICATE----- lines to a file named after the hostname of the server where the certificate will be installed. For example mail.example.com.crt , is a nice descriptive name.

Subsequent certificates will be named 02.pem , 03.pem , etc.

Replace mail.example.com.crt with your own descriptive name.

Finally, copy the new certificate to the host that needs it, and configure the appropriate applications to use it. The default location to install certificates is /etc/ssl/certs . This enables multiple services to use the same certificate without overly complicated file permissions.

For applications that can be configured to use a CA certificate, you should also copy the /etc/ssl/certs/cacert.pem file to the /etc/ssl/certs/ directory on each server.