Сертификация Microsoft / Habr
Сертификация Microsoft предназначена для специалистов в различных областях, связанных с информационными технологиями, а также c сертификациями аппаратного и программного обеспечения на предмет совместимости с продуктами Microsoft.
Экзамены сдаются в центрах VUE. Экзамены по направлению Office сдаются в Certiport центрах тестирования.
Стоимость экзаменов обычно равна 80$ (60 EU), но некоторые экзамены могут стоить дешевле (60$).
Общую картинку можно увидеть на следующем плакате:
Но рассмотрим сертификацию подробнее, всего у Microsoft существуют несколько различных уровней и ступеней
1) Microsoft Certified IT Professional (MCITP) – дается за сдачу одного экзамена в определенной области.
2) Microsoft Certified Technology Specialist (MCTS) – так же дается за сдачу какого-то одного экзамена.
3) Microsoft Certified Professional Developer (MCPD) – статус дается за сертификации в области разработки.
4) Microsoft Certified Solutions Associate (MCSA) – статус дается за сдачу нескольких экзаменов в определенной области. Получить данный статус можно по нескольким направлениям: Windows Server2012, Windows Server 2008, Windows 8, Windows 7, SQL Server 2012, SQL Server 2008, Office 365.
5) Microsoft Certified Solutions Developer (MCSD) – статус дается за сдачу нескольких экзаменов в различных направлениях разработки. Таких, как: Windows Store Apps, Web Applications, SharePoint Applications, Applications Lifecycle Management.
6) Microsoft Certified Solutions Expert (MCSE) – является более глубоким уровнем к MCSA, поэтому для получения MCSE требуется наличие MCSA.
7) Microsoft Office Specialist (MOS) – направление сертификации по офисным продуктам MS.
8) Microsoft Technology Associate (MTA) — это сертификация Microsoft начального уровня для лиц, планирующих профессиональную деятельность в качестве технического специалиста.
9) Microsoft Certified Trainer (MCT) – сертификация для инструкторов по Microsoft.
10) Microsoft Certified Database Administrator (MCDBA) – направление для администраторов баз данных на SQL.
Теперь рассмотрим подробнее по определенным специализациям, всего можно разделить на пять специализаций.
Серверное направление
Windows Server
MTA IT Infrastructure
Специализация предназначена для лиц, планирующих профессиональную деятельность в области разработки инфраструктуры настольных компьютеров или серверов либо частных сред облачных вычислений.
Для сертификации необходимо сдать четыре экзамена:
1) Экзамен 98-349 Windows Operating System Fundamentals
2) Экзамен 98-365 Windows Server Administration Fundamentals
3) Экзамен 98-366 Networking Fundamentals
4) Экзамен 98-367 Security Fundamentals
Стоимость каждого экзамена 46 EUR.
Сертификация доступна по двум версиям продуктов – 2008 и 2012.
Сертификация MCSA 2008 подтверждает повышенный уровень умений, необходимых для работы с Windows Server 2008 в реальной корпоративной среде.
Для сертификации необходимо сдать три экзамена:
1) Экзамен 70-640 Windows Server 2008 Active Directory, Configuring
2) Экзамен 70-642 Windows Server 2008 Network Infrastructure, Configuring
3) Экзамен 70-646 Windows Server 2008, Server Administrator
Стоимость каждого экзамена 60 EUR.
Сертификация Windows Server 2012 является свидетельством квалификации, позволяющей занимать должность администратора сети или вычислительных систем, а также специалиста по работе сети.
Для сертификации необходимо сдать три экзамена:
1) Экзамен 70-410 Installing and Configuring Windows Server 2012
3) Экзамен 70-412 Configuring Advanced Windows Server 2012 Services(или
70-346: Managing Office 365 Identities and Requirements, или
70-409: Server Virtualization with Windows Server Hyper-V and System Center, или
70-462: Administering Microsoft SQL Server 2012 Databases
Стоимость каждого экзамена 60 EUR.
MCSE: Server Infrastructure
Сертификат Microsoft Certified Solutions Expert (MCSE): Server Infrastructure подтверждает наличие умений, необходимых для управления современным экономичным центром обработки данных, включая умения в области управления идентификационными данными, управления системами, виртуализации, хранения и работы в сети.
Получение сертификата MCSE: Server Infrastructure свидетельствует о квалификации, достаточной для работы в таких должностях, как специалист по обслуживанию компьютеров и специалист по анализу информационной безопасности.
Для сертификации необходимо сдать два экзамена:
1) Экзамен 70-413 Designing and Implementing a Server Infrastructure
2) Экзамен 70-414 Implementing an Advanced Server Infrastructure
Так же необходимо иметь MCSA по Server Infrastructure.
Стоимость каждого экзамена 60 EUR.
MCSE: Desktop Infrastructure
Этот сертификат демонстрирует способность к развертыванию настольных компьютеров и устройств, обеспечивающих доступ из любого местоположения, и управлению такими устройствами, включая обеспечение безопасности и совместимости. Он также подтверждает наличие умений в области виртуализации удаленных рабочих столов, служб удаленного рабочего стола и виртуализации приложений.
Получение сертификата MCSE: Desktop Infrastructure свидетельствует о квалификации, достаточной для работы в таких должностях, как специалист по обслуживанию настольных компьютеров и других устройств или администратор данных и приложений.
Для сертификации необходимо сдать два экзамена:
1) Экзамен 70-415 Implementing a Desktop Infrastructure
2) Экзамен 70-416 Implementing Desktop Application Environments
Так же необходимо иметь MCSA по Server Infrastructure.
Стоимость каждого экзамена 60 EUR.
Exchange Server
Сертификация доступна только в одной ступени – MCSE, предварительное требование – наличие сертификации MCSA Office 365 или MCSA: Windows Server 2012.
MCSE: Messaging
Этот сертификат подтверждает способность внедрить работу в среде облачных вычислений, повысить производительность труда пользователей и расширить их возможности, сократить потери данных и повысить уровень их защиты в масштабе организации.
Получение сертификата MCSE: Messaging свидетельствует о квалификации, достаточной для работы в области администрирования сетей и компьютерных систем.
Для сертификации необходимо сдать два экзамена:
1) Экзамен 70-341 Core Solutions of Microsoft Exchange Server 2013
2) Экзамен 70-342 Advanced Solutions of Microsoft Exchange Server 2013
Стоимость каждого экзамена 60 EUR.
Lync
Сертификация доступна только в одной ступени – MCSE, предварительное требование – наличие сертификации MCSA Office 365 или MCSA: Windows Server 2012.
MCSE: Communication
Этот сертификат подтверждает профессиональные знания и умения в области создания корпоративных систем обмена данными с единообразным пользовательским интерфейсом, обеспечивающим связь сотрудников с пользователями за пределами организации.
Получение сертификата MCSE: Communication свидетельствует о квалификации, достаточной для работы в области администрирования сетей и компьютерных систем.
Для сертификации необходимо сдать два экзамена:
1) Экзамен 70-336 Core Solutions of Microsoft Lync Server 2013
2) Экзамен 70-337 Enterprise Voice & Online Services with Microsoft Lync Server 2013
Стоимость каждого экзамена 60 EUR.
Sharepoint
Сертификация доступна в двух направлениях:
1) MCSE (администрирование и развертка продукта), предварительное требование – наличие сертификации MCSA Office 365
2) MCSD– разработка.
MCSE: SharePoint
Этот сертификат подтверждает профессиональные умения в области управления информацией в масштабе организации, включая структурирование, синхронизацию, использование в совместной работе и обмен.
Получение сертификата MCSE: SharePoint свидетельствует о квалификации, достаточной для работы в должности специалиста по анализу систем или сетей.
Для сертификации необходимо сдать два экзамена:
1) Экзамен70-331 Core Solutions of Microsoft SharePoint Server 2013
2) Экзамен70-332 Advanced Solutions of Microsoft SharePoint Server 2013
Стоимость каждого экзамена 60 EUR.
MCSD: SharePoint Applications
Этот сертификат подтверждает профессиональные знания и умения в области проектирования и разработки приложений для совместной работы с помощью SharePoint. Для его получения необходимо иметь устойчивые навыки веб-программирования с помощью HTML5 with JavaScript и ASP.NET MVC 4. (Для начинающих специалистов по разработке приложений: Просмотрите сведения о сертификации по программам MTA для новых участников.)
Получение сертификата MCSD: SharePoint Applications свидетельствует о квалификации, достаточной для работы в таких должностях, как разработчик программного обеспечения или веб-сайтов.
Для сертификации необходимо сдать четыре экзамена:
1) Экзамен 70-480 Programming in HTML5 with JavaScript and CSS3(или 70-483: Programming in C#)
2) Экзамен 70-486 Developing ASP.NET MVC Web Applications
3) Экзамен 70-488 Developing Microsoft SharePoint Server 2013 Core Solutions
4) Экзамен 70-489 Developing Microsoft SharePoint Server 2013 Advanced Solutions
Стоимость каждого экзамена 60 EUR.
Private Cloud
Сертификация доступна только в одной ступени – MCSE.
MCSE: Private Cloud
Этот сертификат подтверждает профессиональные знания и умения в области работы с технологиями частных сред облачных вычислений Microsoft. Реализация частной среды облачных вычислений с помощью WindowsServerandSystemCenter позволяет оптимизировать предоставление информационно-технологических услуг, повысить уровень автоматизации и расширить возможности информационно-технологической инфраструктуры в соответствии с задачами, которые выполняются в настоящее время или могут быть поставлены в будущем.
Получение сертификата MCSE: Private Cloud свидетельствует о квалификации, достаточной для работы в таких должностях, как администратор сервера, системный программист или администратора сети.
Предварительные требования – MCSA Windows Server.
Для получения необходимо сдать следующие два экзамена:
1) Экзамен 70-246 Monitoring and Operating a Private Cloud with System Center 2012
2) Экзамен 70-247 Configuring and Deploying a Private Cloud with System Center 2012
Стоимость каждого экзамена 60 EUR.
System Center
Доступна только одна ступень – MCTS System Center.
MCTS: Administering and Deploying System Center 2012 Configuration Manager
Подтверждает способности специалиста к управлению клиентскими компьютерами и устройствами на предприятиях.
Для получения статуса необходимо сдать экзамен 70-243 Administering and Deploying System Center 2012 Configuration Manager.
Стоимость экзамена 60 EUR.
Virtualization
По виртуализации в данный момент можно получить только один статус – Microsoft Specialist. В основном все сертификация по виртуализации теперь сдается в Private Cloud.
Для получения статуса Microsoft Virtualization Specialist необходимо сдать экзамен 74-409 Server Virtualization with Windows Server Hyper-V and System Center.
Стоимость экзамена 60 EUR.
Направление настольных ПК
В данной специализации специалисты развертывают и управляют клиентскими приложениями, что необходимо для работы в сложных ИТ-средах.
MTA IT Infrastructure
Для получения статуса достаточно сдать один экзамен Экзамен 98-349 Windows Operating System Fundamentals. Стоимость экзамена 46 EUR.
MCSA: Windows 8
Этот сертификат подтверждает наличие профессиональных знаний и умений, необходимых для настройки корпоративной системы Windows 8.
Сертификация по программе MCSA: Windows 8 подтверждает квалификацию, необходимую для работы в должности специалиста по компьютерному обеспечению.
1) Экзамен 70-687 Configuring Windows 8.1
2) Экзамен 70-688 Supporting Windows 8.1
Стоимость каждого экзамена 60 EUR.
MCSA: Windows 7
Этот сертификат подтверждает наличие профессиональных знаний и умений, необходимых для настройки корпоративной системы Windows 7.
Для получения необходимо сдать следующие два экзамена:
1) Экзамен 70-680 Windows 7, Configuring
2) Экзамен70-685 Windows 7, Enterprise Desktop Support Technician
Стоимость каждого экзамена 60 EUR.
Приложения
Office
Этот сертификат подтверждает наличие экспертных знаний в области использования приложений Microsoft Office.
Microsoft Office Specialist (MOS)
Получение сертификата Microsoft Office Specialist для конкретного приложения Office свидетельствует об умении максимально использовать возможности пакета Microsoft Office.
Сертификат Microsoft Office Specialist рекомендуется на начальном этапе для последующего получения более высоких уровней сертификаций Microsoft Office Specialist Expert и Microsoft Office Specialist Master.
Экзамены есть по разным версиям MS Office – 2007, 2010 и 2013.
Для Office 2013:
Для Office 2010:
Для Office 2007:
Microsoft Office Specialist (MOS) Expert
Сертификат Microsoft Office Specialist Expert подтверждает наличие расширенных навыков работы с важнейшими приложениями пакета Office.
Для Office 2013:
Для Office 2010:
Для Office 2007:
Microsoft Office Specialist (MOS) Master
Сертификат Microsoft Office Specialist Master подтверждает наивысший уровень развития умений, необходимых для эффективной работы с приложениями пакета Office.
Для Office 2013 необходимо сдать пять экзаменов:
Плюс один из:
Для Office 2010 необходимо сдать три следующих экзамена:
Плюс один из:
Для Office 2007 необходимо сдать экзамены:
Плюс один из:
Office 365
Этот сертификат подтверждает наличие экспертных знаний в области использования программных средств из пакета Office 365, обеспечивающих совместную работу в среде облачных вычислений и повышение производительности труда.
MCSA: Office 365
Сертификат MCSA: Office 365 позволяет получить классификацию для своей позиции в качестве администратора программного обеспечения как служб (SaaS) или администратора облачной среды, сосредотачиваясь на управлении продуктами Office 365 для производительности компаний, такими как Exchange, SharePoint и Lync.
Для получения необходимо сдать следующие два экзамена:
1) Экзамен 70-346 Managing Office 365 Identities and Requirements
2) Экзамен 70-347 Enabling Office 365 Service
Стоимость каждого экзамена 60 EUR.
Microsoft Dynamics
Данное направление показывает знания в определенном продукте Microsoft Dynamics, предоставляя возможность получения сертификации Microsoft Specialist. Microsoft Dynamics — линия программных приложений для планирования ресурсов предприятия (ERP) и управления взаимоотношениями с клиентами (CRM), разработанных компанией Microsoft.
Microsoft Dynamics CRM
Microsoft Dynamics CRM – это пакет программного обеспечения для управления взаимоотношениями с клиентами, разработанный компанией Microsoft и ориентированный на организацию продаж, маркетинга и предоставления услуг (службы поддержки).
Microsoft Certified Technology Specialist (MCTS)
Содержит четыре экзамена:
Microsoft Specialist по Microsoft Dynamics GP 2013
Содержит пять экзаменов:
Microsoft Dynamics AX
Microsoft Dynamics AX — одно из программных решений корпорации Microsoft для автоматизации управления предприятием (ERP-систем), поставляемых подразделением Microsoft Dynamics. Система была разработана для среднего и крупного сегментов бизнеса и предоставляет функции финансового менеджмента, бизнес-анализа, управления процессами производства, движением товарно-материальных ценностей, проектами, а также отношениями с клиентами и персоналом.
Microsoft Specialist по Microsoft Dynamics AX 2012
Данное направление содержит девять экзаменов:
Microsoft Dynamics GP
Microsoft Dynamics GP (ранее Great Plains Software) – решение по планированию ресурсов предприятия (ERP) для малого и среднего бизнеса, с функциями управления финансами, сотрудниками и цепочками поставок (в России и странах СНГ не продается и не поддерживается).
Microsoft Specialist по Microsoft Dynamics GP 2013
По данному направлению есть только один экзамен Microsoft Dynamics GP 2013 Installation & Configuration MB3-700.
Microsoft Dynamics NAV
Microsoft Dynamics NAV (ранее Navision) – решение для малого и среднего бизнеса, с функциями управления финансами, сотрудниками, цепочками поставок.
Microsoft Specialist по Microsoft Dynamics NAV 2013
По данному направлению есть три экзамена:
Базы данных
Направление для специалистов проектирования, развертывания и обслуживания баз данных на основе облачных технологий и информационных решений нового поколения.
Microsoft Technology Associate (MTA) Database
Специализация MTA Database. Предназначена для лиц, планирующих профессиональную деятельность в области администрирования платформ хранения и обработки данных или анализа деловой информации.
Экзамен 98-364 Database Fundamentals
Microsoft Certified Solutions Associate (MCSA)
Наличие сертификата MCSA: SQL Server подтверждает необходимую квалификацию для работы в должности разработчика баз данных или специалиста по их анализу.
Сертификация доступна по двум версиям продуктов — 2008 и 2012.
Сертификация MCSA 2008 подтверждает повышенный уровень умений, необходимых для работы с SQL Server 2008.
Для сертификации необходимо сдать два экзамена:
1) Экзамен 70-432 Microsoft SQL Server 2008, Implementation and Maintenance
2) Экзамен 70-448 Microsoft SQL Server 2008, Business Intelligence Development and Maintenance
Стоимость каждого экзамена 60 EUR.
Наличие сертификата MCSA: SQL Server 2012 подтверждает необходимую квалификацию для работы в должности разработчика баз данных или специалиста по их анализу.
Для сертификации необходимо сдать три экзамена:
1) Экзамен 70-461 Querying Microsoft SQL Server 2012
2) Экзамен 70-462 Administering Microsoft SQL Server 2012 Databases
3) Экзамен 70-463 Implementinga Data Warehouse with Microsoft SQL Server 2012(или 70-411: Administering Windows Server 2012, или 70-412: Configuring Advanced Windows Server 2012 Services, или 70-483: Programming in C#).
Стоимость каждого экзамена 60 EUR.
MCSE: Data Platform
Этот сертификат позволяет продемонстрировать обширный набор умений в области разработки и администрирования корпоративных систем хранения и обработки данных как в локальной среде, так и в среде облачных вычислений.
Получение сертификата MCSE: Data Platform свидетельствует о квалификации, достаточной для работы в таких должностях, как специалист по анализу баз данных и их проектировщик.
Для получения сертификации требуется наличие MCSA SQL 2012 и сдача двух экзаменов:
1) 70-465 Designing Database Solutions for Microsoft SQL Server
2) 70-464 Developing Microsoft SQL Server Databases
Стоимость каждого экзамена 60 EUR.
MCSE: Business Intelligence
Этот сертификат подтверждает владение навыками и методами, необходимыми для проектирования, разработки и развертывания систем, позволяющих увеличить как объем доставляемых данных, так и количество сотрудников организации, которым они доставляются.
Получение сертификата MCSE: Business Intelligence свидетельствует о квалификации, достаточной для работы в должности специалиста по анализу деловой информации или по формированию отчетов.
Для получения сертификации требуется наличие MCSA SQL 2012 и сдача двух экзаменов:
1) 70-466 Implementing Data Models and Reports with Microsoft SQL Server
2) 70-467 Designing Business Intelligence Solutions with Microsoft SQL Server
Стоимость каждого экзамена 60 EUR.
Разработка
Microsoft Azure
Azure — облачная среда для современного бизнеса. Если у вас уже есть опыт работы с Azure, получите две сертификации Specialist и расширьте свои навыки, чтобы соответствовать бизнес-требованиям завтрашнего дня.
Данное направление содержит два экзамена уровня Microsoft Specialist.
Visual Studio
MTA Developer
Предназначена для лиц, планирующих профессиональную деятельность в области разработки программного обеспечения; предусматривает практическое обучение работе с конкретными приложениями и упрощает подготовку к сертификации по программе MCSD. Начните с раздела MTA Software Development Fundamentals, затем выберите другие разделы этой специализации в соответствии с целями профессионального развития.
Для получения статуса необходимо сдать шесть экзаменов:
1) 98-379 Software Testing Fundamentals
2) 98-375 HTML5 Application Development Fundamentals
3) 98-374 MTA: Gaming Development Fundamentals
4) 98-372 Microsoft .NET Fundamentals
5) 98-363 Web Development Fundamentals
6) 98-361 Software Development Fundamentals
Стоимость каждого экзамена 46 EUR.
MCSD: Windows Store Apps
Этот сертификат подтверждает профессиональные знания и умения в области проектирования и разработки быстродействующих приложений на платформе Windows 8 с широкими возможностями настройки. Предусмотрено два варианта этой сертификационной программы: с применением HTML5 или C#.
Получение сертификата MCSD: Windows Store Apps свидетельствует о квалификации, достаточной для работы в таких должностях, как разработчик программного обеспечения, разработчик веб-страниц или инженер по обеспечению качества.
Для получения статуса MCSD: Windows Store Apps Using HTML5 необходимо сдать три экзамена:
1) 70-480 Programming in HTML5 with JavaScript and CSS3
2) 70-481 Essentials of Developing Windows Store Apps Using HTML5 and JavaScript
3) 70-482 Advanced Windows Store App Development Using HTML5 and JavaScript
Стоимость каждого экзамена 60 EUR.
Для получения статуса MCSD: Windows Store Apps Using C# необходимо сдать три экзамена:
1) 70-483 Programming in C#
2) 70-484 Essentials of Developing Windows Store Apps Using C#
3) 70-485 Advanced Windows Store App Development Using C#
Стоимость каждого экзамена 60 EUR.
MCSD: Web Applications
Этот сертификат подтверждает профессиональные знания и умения в области создания и развертывания современных веб-приложений и веб-услуг.
Получение сертификата MCSD: Web Applications свидетельствует о квалификации, достаточной для работы в должности разработчика или администратора веб-сайтов.
Для получения статуса необходимо сдать три экзамена:
1) 70-480 Programming in HTML5 with JavaScript and CSS3
2) 70-486 Developing ASP.NET MVC Web Applications
3) 70-487 Developing Microsoft Azure and Web Services
Стоимость каждого экзамена 60 EUR.
MCSD: Application Lifecycle Management
Этот сертификат подтверждает профессиональные знания и умения в области управления полным циклом разработки приложений.
Получение сертификата MCSD: Application Lifecycle Management свидетельствует о квалификации, достаточной для работы в таких должностях, как разработчик, специалист по приложениям и руководитель информационно-технологических проектов.
Для получения статуса необходимо сдать три экзамена:
1) 70-496 Administering Visual Studio Team Foundation Server
2) 70-497 Software Testing with Visual Studio
3) 70-498 Delivering Continuous Value with Visual Studio Application Lifecycle Management
Стоимость каждого экзамена 60 EUR.
Sharepoint Applications
Этот сертификат подтверждает профессиональные знания и умения в области проектирования и разработки приложений для совместной работы с помощью SharePoint. Для его получения необходимо иметь устойчивые навыки веб-программирования с помощью HTML5 with JavaScript и ASP.NETMVC 4.
Получение сертификата MCSD: SharePoint Applications свидетельствует о квалификации, достаточной для работы в таких должностях, как разработчик программного обеспечения или веб-сайтов.
Данное направление содержит четыре экзамена уровня Microsoft Specialist.
Станьте сертифицированным специалистом Microsoft | MCP
Что такое сертификация Microsoft Certified Professional (MCP)?
Сертификация Microsoft Certified Professional больше не доступна. Когда вы сдадите экзамен MCP, он будет добавлен в вашу выписку, но вы не сможете воспользоваться всеми преимуществами программы, пока не получите свой первый сертификат. Все сертификаты, связанные с программой сертификации Microsoft, можно просмотреть на странице Microsoft Technical Certifications стр.
Сертификация Microsoft Certified Professional (MCP) подтверждает профессиональную квалификацию IT-специалистов и разработчиков благодаря строгим, проверенным в отрасли и признанным в отрасли экзаменам. Экзамены MCP охватывают широкий спектр продуктов, технологий и решений Microsoft.
Когда вы сдаете свой первый экзамен MCP, вы автоматически становитесь сертифицированным специалистом Microsoft и получаете доступ к MCP. benefits. Вы также присоединяетесь к сообществу миллионов MCP, и тысячи людей присоединяются каждый месяц. После того, как вы станете MCP, вы сможете отличить себя через сертификаты экспертов, включая Microsoft Certified Solutions Expert (MCSE), и Microsoft Certified Solutions Developer (MCSD).
Квалификационные экзамены MCP включают все экзамены, необходимые в Microsoft Certified Solutions Associate (MCSA), MCSE, и MCSDсертификаты Microsoft Technology Associate (MTA) exams И Microsoft Office Specialist (MOS) exams не могут претендовать на сертификацию MCP.
.NET | Использование сертификатов
C# и .NET — Основы .NET — Использование сертификатов
Чтобы потребители программного обеспечения могли проверять подлинность идентификационных данных его издателя, можно также использовать цифровые сертификаты и подписывать сборки. В зависимости от сферы применения приложения, наличие у него сертификата может быть обязательным. Например, наличие сертификата у приложения ClickOnce дает возможность пользователю, который его устанавливает, определять, стоит ли доверять издателю. Указание сертификата в отчете об ошибке Windows (Windows Error Reporting) может позволить Microsoft определить, с каким производителем придется иметь дело.
В коммерческой среде сертификаты обычно приобретаются у таких компаний, как Verisign или Thawte. Преимущество подхода с приобретением сертификата у известного стороннего поставщика состоит в том, что он обеспечивает высокий уровень доверия к подлинности сертификата; поставщик выступает в роли стороннего гаранта. Для целей тестирования, однако, в .NET предлагается утилита командной строки, позволяющая создавать тестовые сертификаты. Процесс создания сертификатов и их применения для публикации программного обеспечения является довольно сложным, но в этом разделе рассматривается один простой пример.
В этом примере предполагается, что есть некая вымышленная компания под названием ABC Corporation и требуется обеспечить доверие к ее программному продукту simple.ехе. Сначала нужно создать для этой компании тестовый сертификат, для чего служит следующая команда:
makecert -sv abckey.pvk -r -n "CN=ABC Corporation" abccorptest.cerВыполнение этой команды приведет к созданию тестового сертификата под названием ABC Corporation и его сохранению в файле с именем abccorptest.cer. Аргумент -sv abckey.pvk позволяет создать специальный файл для сохранения секретного ключа. При создании этого файла появится приглашение ввести пароль, который нужно обязательно запомнить.
После создания сертификата можно переходить к созданию тестового сертификата издателя программного обеспечения с помощью утилиты Software Publisher Certificate Test (Cert2spc.ехе):
cert2spc abccorptest.cer abccorptest.spcИмея сертификат, хранящийся в файле spc, и ключ, хранящийся в файле pvk, можно создать файл pfх, содержащий то и другое, с помощью утилиты pvk2pfx:
pvk2pfx -pvk abckey.pvk -spc abccorptest.spc -pfx abccorptest.pfxТеперь можно подписать сборку с помощью утилиты signtool.ехе. Опция sign используется для подписания, опция -f указывает, что нужный сертификат находится в файле .pfx, а опция -v — что вывод должен отображаться в режиме расширенных сообщений:
signtool sign -f abccorptest.pfx -v simple.exeЧтобы обеспечить доверие к сертификату, нужно установить его в разделе Trusted Root Certification Authorities (Доверяемые органы сертификации) и Trusted Publishers (Доверяемые издатели) с применением либо диспетчера сертификатов Certificate Manager (certmgr), либо оснастки Certificates (Сертификаты) консоли ММС. После этого с помощью утилиты signtool можно проверить, успешно ли прошло подписание:
> signtool verify -v -а simple.exeТребования к сертификатам для серверов федерации
- Время чтения: 4 мин
В этой статье
В любом службы федерации Active Directory (AD FS) (AD FS) проектирования, для защиты связи и упрощения проверки подлинности пользователей между Интернетом и серверами федерации необходимо использовать различные сертификаты.In any Active Directory Federation Services (AD FS) design, various certificates must be used to secure communication and facilitate user authentications between Internet clients and federation servers. Каждый сервер федерации должен иметь сертификат связи службы и маркер-сертификат подписи, прежде чем он сможет участвовать в AD FS связи.Each federation server must have a service communication certificate and a token-signing certificate before it can participate in AD FS communications. В следующей таблице описаны типы сертификатов, связанные с сервером федерации.The following table describes the certificate types that are associated with federation server.
| Тип сертификатаCertificate type | ОписаниеDescription |
|---|---|
| Сертификат для подписи-токенToken-signing certificate | Маркер-сертификата подписи — это сертификат X509.A token-signing certificate is an X509 certificate. Серверы федерации используют связанные пары открытых/закрытых ключей для цифровой подписи всех выдающихся маркеров безопасности.Federation servers use associated public/private key pairs to digitally sign all security tokens that they produce. Сюда относится подписывание опубликованных метаданных федерации и запросов на разрешение артефактов.This includes the signing of published federation metadata and artifact resolution requests. Можно использовать несколько маркеров-сертификатов подписи, настроенных в-оснастки управления AD FS в, чтобы разрешить смену сертификатов, когда срок действия одного из сертификатов близок к истечению.You can have multiple token-signing certificates configured in the AD FS Management snap-in to allow for certificate rollover when one certificate is close to expiring. По умолчанию все сертификаты в списке публикуются, но только основной маркер-сертификат подписи используется AD FS для фактического подписывания маркеров.By default, all the certificates in the list are published, but only the primary token-signing certificate is used by AD FS to actually sign tokens. Все выбранные сертификаты должны иметь соответствующий закрытый ключ.All certificates that you select must have a corresponding private key. Дополнительные сведения см. в статьях Token-Signing Certificates и Add a Token-Signing Certificate.For more information, see Token-Signing Certificates and Add a Token-Signing Certificate. |
| Сертификат взаимодействия службService communication certificate | Серверы федерации используют сертификат проверки подлинности сервера, который также называется связью службы для Windows Communication Foundation (WCF) безопасности сообщений.Federation servers use a server authentication certificate, also known as a service communication for Windows Communication Foundation (WCF) Message Security. По умолчанию это тот же сертификат, который используется сервером федерации в качестве SSL (сертификат SSL) в службы IIS (IIS).By default, this is the same certificate that a federation server uses as the Secure Sockets Layer (SSL) certificate in Internet Information Services (IIS). Примечание. -оснастки управления AD FS в относится к сертификатам проверки подлинности сервера для серверов федерации в качестве сертификатов связи служб.Note: The AD FS Management snap-in refers to server authentication certificates for federation servers as service communication certificates. Дополнительные сведения см. в разделе сертификаты связи служб и Настройка сертификата связи службы.For more information, see Service Communications Certificates and Set a Service Communications Certificate. Так как сертификат связи служб должен быть доверенным для клиентских компьютеров, рекомендуется использовать сертификат, подписанный доверенным центром сертификации (CA).Because the service communication certificate must be trusted by client computers, we recommend that you use a certificate that is signed by a trusted certification authority (CA). Все выбранные сертификаты должны иметь соответствующий закрытый ключ.All certificates that you select must have a corresponding private key. |
| SSL (сертификат) SSLSecure Sockets Layer (SSL) certificate | Серверы федерации используют сертификат SSL для обеспечения безопасности трафика веб-служб при обмене данными SSL с веб-клиентами и прокси-серверами федерации.Federation servers use an SSL certificate to secure Web services traffic for SSL communication with Web clients and with federation server proxies. Поскольку сертификату SSL должны доверять клиентские компьютеры, рекомендуется использовать сертификат, подписанный доверенным центром сертификации.Because the SSL certificate must be trusted by client computers, we recommend that you use a certificate that is signed by a trusted CA. Все выбранные сертификаты должны иметь соответствующий закрытый ключ.All certificates that you select must have a corresponding private key. |
| Сертификат расшифровки токена-Token-decryption certificate | Этот сертификат используется для расшифровки токенов, полученных этим сервером федерации.This certificate is used to decrypt tokens that are received by this federation server. Можно использовать несколько сертификатов расшифровки.You can have multiple decryption certificates. Это позволяет серверу федерации ресурсов расшифровывать маркеры, выпущенные с помощью старого сертификата, после того как новый сертификат будет установлен в качестве основного сертификата расшифровки.This makes it possible for a resource federation server to be able to decrypt tokens that are issued with an older certificate after a new certificate is set as the primary decryption certificate. Для расшифровки можно использовать все сертификаты, но только основной маркер,-расшифровку сертификата, фактически публикуется в метаданных федерации.All certificates can be used for decryption, but only the primary token-decrypting certificate is actually published in federation metadata. Все выбранные сертификаты должны иметь соответствующий закрытый ключ.All certificates that you select must have a corresponding private key. Дополнительные сведения см. в разделе Добавление сертификата для расшифровки маркера.For more information, see Add a Token-Decrypting Certificate. |
Вы можете запросить и установить SSL-сертификат или сертификат связи службы, запросив сертификат связи службы с помощью консоли управления (MMC) (оснастку ММС) привязать-в для IIS.You can request and install an SSL certificate or service communication certificate by requesting a service communication certificate through the Microsoft Management Console (MMC) snap-in for IIS. Дополнительные общие сведения об использовании SSL-сертификатов см. в разделе iis 7,0: настройка SSL в iis 7,0 и IIS 7,0: Настройка сертификатов сервера в IIS 7,0 .For more general information about using SSL certificates, see IIS 7.0: Configuring Secure Sockets Layer in IIS 7.0 and IIS 7.0: Configuring Server Certificates in IIS 7.0 .
Примечание
В AD FS можно изменить (алгоритм SHA), используемый для цифровых подписей с помощью SHA-1 или SHA-256 (более безопасным).In AD FS you can change the Secure Hash Algorithm (SHA) level that is used for digital signatures to either SHA-1 or SHA-256 (more secure). AD Фсдоес не поддерживает использование сертификатов с другими методами хэширования, например MD5 (алгоритма хэширования по умолчанию, который используется с программой командной-line программы Makecert. exe).AD FSdoes not support the use of certificates with other hash methods, such as MD5 (the default hash algorithm that is used with the Makecert.exe command-line tool). Для обеспечения безопасности рекомендуется использовать SHA-256 (который по умолчанию установлен в) для всех подписей.As a security best practice, we recommend that you use SHA-256 (which is set by default) for all signatures. SHA-1 рекомендуется использовать только в сценариях, в которых необходимо взаимодействовать с продуктом, который не поддерживает обмен данными с помощью SHA-256, например, не-продукта Майкрософт или AD FS 1.SHA-1 is recommended for use only in scenarios in which you must interoperate with a product that does not support communications using SHA-256, such as a non-Microsoft product or AD FS 1. x.x.
Определение стратегии центра сертификацииDetermining your CA strategy
AD FS не требует, чтобы сертификаты выдавались центром сертификации.AD FS does not require that certificates be issued by a CA. Однако SSL-сертификат (сертификат, который также используется по умолчанию, так как сертификат взаимодействия служб) должен быть доверенным для AD FS клиентов.However, the SSL certificate (the certificate that is also used by default as the service communications certificate) must be trusted by the AD FS clients. Для этих типов сертификатов не рекомендуется использовать собственные сертификаты, подписанные-.We recommend that you not use self-signed certificates for these certificate types.
Важно!
Использование собственной-подписанных SSL-сертификатов в рабочей среде может позволить злоумышленнику в организации партнера по учетным записям осуществлять управление серверами федерации в организации партнера по ресурсам.Use of self-signed, SSL certificates in a production environment can allow a malicious user in an account partner organization to take control of federation servers in a resource partner organization. Такая угроза безопасности существует потому, что-самозаверяющие сертификаты являются корневыми сертификатами.This security risk exists because self-signed certificates are root certificates. Они должны быть добавлены в доверенное корневое хранилище другого сервера федерации (например,)сервера федерации ресурсов, который может оставить этот сервер уязвимым для атак.They must be added to the trusted root store of another federation server (for example, the resource federation server), which can leave that server vulnerable to attack.
После получения сертификата из центра сертификации необходимо убедиться, что все сертификаты импортированы в хранилище личных сертификатов на локальном компьютере.After you receive a certificate from a CA, make sure that all certificates are imported into the personal certificate store of the local computer. Сертификаты можно импортировать в личное хранилище с помощью оснастки MMC «сертификаты»-в.You can import certificates to the personal store with the Certificates MMC snap-in.
В качестве альтернативы привязке сертификатов-в можно также импортировать SSL-сертификат с помощью оснастки «Диспетчер IIS»-в во время назначения сертификата SSL веб сайту по умолчанию.As an alternative to using the Certificates snap-in, you can also import the SSL certificate with the IIS Manager snap-in at the time that you assign the SSL certificate to the default Web site. Дополнительные сведения см. в разделе Импорт сертификата проверки подлинности сервера на веб-сайт по умолчанию.For more information, see Import a Server Authentication Certificate to the Default Web Site.
Примечание
Перед установкой AD FS программного обеспечения на компьютер, который станет сервером федерации, убедитесь, что оба сертификата находятся в хранилище личных сертификатов локального компьютера и что сертификат SSL назначен веб-сайту по умолчанию.Before you install the AD FS software on the computer that will become the federation server, make sure that both certificates are in the Local Computer personal certificate store and that the SSL certificate is assigned to the Default Web Site. Дополнительные сведения о порядке задач, необходимых для настройки сервера федерации, см. в разделе Контрольный список: Настройка сервера федерации.For more information about the order of the tasks that are required to set up a federation server, see Checklist: Setting Up a Federation Server.
В зависимости от требований безопасности и бюджетных ограничений необходимо тщательно продумать, какие из сертификатов будут присваиваться публичным или корпоративным центром сертификации.Depending on your security and budget requirements, carefully consider which of your certificates will be obtained by a public CA or a corporate CA. На рисунке ниже показаны рекомендованные издатели (центры сертификации) определенных типов сертификатов.The following figure shows the recommended CA issuers for a given certificate type. Эта рекомендация отражает лучший-подход к безопасности и затратам.This recommendation reflects a best-practice approach regarding security and cost.
Списки отзыва сертификатовCertificate revocation lists
Если у какого-либо используемого сертификата есть списки отзыва сертификатов (CRL), сервер с настроенным сертификатом должен иметь возможность связаться с сервером, распространяющим CRL.If any certificate that you use has CRLs, the server with the configured certificate must be able to contact the server that distributes the CRLs.
См. такжеSee Also
Руководство по разработке служб федерации Active Directory в Windows Server 2012AD FS Design Guide in Windows Server 2012
Установка центра сертификации на предприятии. Часть 1 / Microsoft corporate blog / Habr
Вторая часть серииТретья часть серии
Введение
Целевая аудитория
ИТ-администраторы, ИТ-инженеры и специалисты по безопасности, имеющие основные понятия о цифровых сертификатах.
Словарь терминов
В этой части серии использованы следующие сокращения и аббревиатуры:
- 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 можно найти на его сайте.
Универсальный https c использованием ГОСТ сертификата / Habr
Когда-то я прочитал статью kyprizel «Как и зачем мы делаем TLS в Яндексе», где упоминалось о том, что OpenSSL начиная с версии 1.0.2 позволяет назначать сертификат сервера в зависимости от параметров клиента, но реализации на стороне Web-сервера нет. В Nginx 1.11.0 появилась такая возможность:
директивы ssl_certificate и ssl_certificate_key теперь можно указывать несколько раз для загрузки сертификатов разных типов (например, RSA и ECDSA).
Я решил собрать стенд с целью протестировать возможность организации https web-сервера c сертификатами ГОСТ для посетителей с установленным крипопровайдером ГОСТ-шифрования и сертификатами ECDSA для остальных.
В качестве тестового стенда выступила VM с Ubuntu 16.04.1 LTS
Собираем nginx
Я собирал nginx со статической библиотекой OpenSSL 1.0.2h
cd /opt/src/
#Скачиваем nginx
wget http://nginx.org/download/nginx-1.11.2.tar.gz
#Скачиваем openssl
wget https://openssl.org/source/openssl-1.0.2h.tar.gz
#Распаковываем
tar -zxvf nginx-1.11.2.tar.gz
tar -zxvf openssl-1.0.2h.tar.gz
cd nginx-1.11.2
#И собираем
./configure --prefix=/opt/work/nginx2 --user=nginx --group=nginx --with-http_ssl_module --with-openssl=/opt/src/openssl-1.0.2h/
make
make install
Далее необходимо сконфигурировать OpenSSL для поддержки алгоритмов ГОСТ. В сети даже ленивый сможет найти материалы по настройке. мой openssl.cnf
cat /opt/src/openssl-1.0.2h/.openssl/ssl/openssl.cnf
openssl_conf=openssl_def
HOME = .
RANDFILE = $ENV::HOME/.rnd
oid_section = new_oids
[ new_oids ]
tsa_policy1 = 1.2.3.4.1
tsa_policy2 = 1.2.3.4.5.6
tsa_policy3 = 1.2.3.4.5.7
[ ca ]
default_ca = CA_default
[ CA_default ]
dir = ./demoCA
certs = $dir/certs
crl_dir = $dir/crl
database = $dir/index.txt
new_certs_dir = $dir/newcerts
certificate = $dir/cacert.pem
serial = $dir/serial
crlnumber = $dir/crlnumber
crl = $dir/crl.pem
private_key = $dir/private/cakey.pem
RANDFILE = $dir/private/.rand
x509_extensions = usr_cert
name_opt = ca_default
cert_opt = ca_default
default_days = 365
default_crl_days= 30
default_md = default
preserve = no
policy = policy_match
[ policy_match ]
countryName = match
stateOrProvinceName = match
organizationName = match
organizationalUnitName = optional
commonName = supplied
emailAddress = optional
[ policy_anything ]
countryName = optional
stateOrProvinceName = optional
localityName = optional
organizationName = optional
organizationalUnitName = optional
commonName = supplied
emailAddress = optional
[ req ]
default_bits = 2048
default_keyfile = privkey.pem
distinguished_name = req_distinguished_name
attributes = req_attributes
req_extensions = v3_req
x509_extensions = v3_ca
string_mask = utf8only
[ req_distinguished_name ]
countryName = Country Name (2 letter code)
countryName_default = RU
countryName_min = 2
countryName_max = 2
stateOrProvinceName = State or Province Name (full name)
stateOrProvinceName_default = Moscow region
localityName = Locality Name (eg, city)
localityName_default = Moscow
0.organizationName = Organization Name (eg, company)
0.organizationName_default = JSC Example
organizationalUnitName = Organizational Unit Name (eg, section)
organizationalUnitName_default = It Department
commonName = Common Name (e.g. server FQDN or YOUR name)
commonName_max = 64
emailAddress = Email Address
emailAddress_max = 64
[ req_attributes ]
challengePassword = A challenge password
challengePassword_min = 4
challengePassword_max = 20
unstructuredName = An optional company name
[ v3_req ]
basicConstraints = CA:FALSE
keyUsage = nonRepudiation, digitalSignature, keyEncipherment
subjectAltName = @alt_names
[alt_names]
DNS.1 = test.example.ru
DNS.2 = gost.example.ru
[ usr_cert ]
basicConstraints=CA:FALSE
nsComment = "OpenSSL Generated Certificate"
subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid,issuer
[ v3_req ]
basicConstraints = CA:FALSE
keyUsage = nonRepudiation, digitalSignature, keyEncipherment
[ v3_ca ]
subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid:always,issuer
basicConstraints = CA:true
[ crl_ext ]
authorityKeyIdentifier=keyid:always
[ proxy_cert_ext ]
basicConstraints=CA:FALSE
nsComment = "OpenSSL Generated Certificate"
subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid,issuer
proxyCertInfo=critical,language:id-ppl-anyLanguage,pathlen:3,policy:foo
[ tsa ]
default_tsa = tsa_config1
[ tsa_config1 ]
dir = ./demoCA
serial = $dir/tsaserial
crypto_device = builtin
signer_cert = $dir/tsacert.pem
certs = $dir/cacert.pem
signer_key = $dir/private/tsakey.pem
default_policy = tsa_policy1
other_policies = tsa_policy2, tsa_policy3
digests = md5, sha1
accuracy = secs:1, millisecs:500, microsecs:100
clock_precision_digits = 0
ordering = yes
tsa_name = yes
ess_cert_id_chain = no
[openssl_def]
engines = engine_section
[engine_section]
gost = gost_section
[gost_section]
engine_id = gost
default_algorithms = ALL
CRYPT_PARAMS = id-Gost28147-89-CryptoPro-A-ParamSet
Выпускаем сертификаты для тестового web-ресурса. Я не стал отягощать себя самоподписанными сертификатами, а создал запросы и подписал их в Тестовом УЦ КриптоПРО и у Китайских «друзей», уже давно выдающих бесплатные сертификаты.
#Формируем закрытый ключ
openssl genrsa -out test.example.ru.key 2048
#генерируем запрос
openssl req -new -sha256 -key test.example.ru.key -out test.example.ru.csr
#генерирум закрытый ключ по алгоритму ГОСТ
openssl genpkey -algorithm gost2001 -pkeyopt paramset:A -out gost.example.ru.key
#генерируем запрос
openssl req -engine gost -new -key gost.example.ru.key -out gost.example.ru.csr
Выгружаем полученные запросы и подписываем в УЦ.
Конфигурирование Nginx
Ниже приведен мой конфигурационный файл Web-сервера Nginx. Следует обратить внимание на дублирующиеся директивы ssl_certificate и ssl_certificate_key, в которых задаются 2 сертификата для одного https сервера, а также на строку ssl_ciphers GOST2001-GOST89-GOST89:HIGH:MEDIUM , где определяется список и порядок применяемых алгоритмов шифрования.
user nginx;
worker_processes 1;
events {
worker_connections 1024;
}
http {
include mime.types;
default_type application/octet-stream;
sendfile on;
keepalive_timeout 65;
server {
listen 443 ssl;
server_name gost.example.ru;
ssl_certificate keys/gost.example.ru_bundle.crt;
ssl_certificate_key keys/gost.example.ru.key;
ssl_certificate keys/test.example.ru_bundle.crt;
ssl_certificate_key keys/test.example.ru.key;
ssl_ciphers GOST2001-GOST89-GOST89:HIGH:MEDIUM;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_prefer_server_ciphers on;
location / {
proxy_pass http://192.168.1.249;
}
error_page 500 502 503 504 /50x.html;
location = /50x.html {
root html;
}
}
}
На просторах паутины я нашел init script для более удобного запуска:
/etc/init.d/nginxPATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
DESC="Nginx Daemon"
NAME=nginx
PREFIX=/opt/work/nginx2
DAEMON=$PREFIX/sbin/$NAME
CONF=$PREFIX/conf/$NAME.conf
PID=$PREFIX/logs/$NAME.pid
SCRIPT=/etc/init.d/$NAME
if [ ! -x "$DAEMON" ] || [ ! -f "$CONF" ]; then
echo -e "\033[33m $DAEMON has no permission to run. \033[0m"
echo -e "\033[33m Or $CONF doesn't exist. \033[0m"
sleep 1
exit 1
fi
do_start() {
if [ -f $PID ]; then
echo -e "\033[33m $PID already exists. \033[0m"
echo -e "\033[33m $DESC is already running or crashed. \033[0m"
echo -e "\033[32m $DESC Reopening $CONF ... \033[0m"
$DAEMON -s reopen -c $CONF
sleep 1
echo -e "\033[36m $DESC reopened. \033[0m"
else
echo -e "\033[32m $DESC Starting $CONF ... \033[0m"
$DAEMON -c $CONF
sleep 1
echo -e "\033[36m $DESC started. \033[0m"
fi
}
do_stop() {
if [ ! -f $PID ]; then
echo -e "\033[33m $PID doesn't exist. \033[0m"
echo -e "\033[33m $DESC isn't running. \033[0m"
else
echo -e "\033[32m $DESC Stopping $CONF ... \033[0m"
$DAEMON -s stop -c $CONF
sleep 1
echo -e "\033[36m $DESC stopped. \033[0m"
fi
}
do_reload() {
if [ ! -f $PID ]; then
echo -e "\033[33m $PID doesn't exist. \033[0m"
echo -e "\033[33m $DESC isn't running. \033[0m"
echo -e "\033[32m $DESC Starting $CONF ... \033[0m"
$DAEMON -c $CONF
sleep 1
echo -e "\033[36m $DESC started. \033[0m"
else
echo -e "\033[32m $DESC Reloading $CONF ... \033[0m"
$DAEMON -s reload -c $CONF
sleep 1
echo -e "\033[36m $DESC reloaded. \033[0m"
fi
}
do_quit() {
if [ ! -f $PID ]; then
echo -e "\033[33m $PID doesn't exist. \033[0m"
echo -e "\033[33m $DESC isn't running. \033[0m"
else
echo -e "\033[32m $DESC Quitting $CONF ... \033[0m"
$DAEMON -s quit -c $CONF
sleep 1
echo -e "\033[36m $DESC quitted. \033[0m"
fi
}
do_test() {
echo -e "\033[32m $DESC Testing $CONF ... \033[0m"
$DAEMON -t -c $CONF
}
do_info() {
$DAEMON -V
}
case "$1" in
start)
do_start
;;
stop)
do_stop
;;
reload)
do_reload
;;
restart)
do_stop
do_start
;;
quit)
do_quit
;;
test)
do_test
;;
info)
do_info
;;
*)
echo "Usage: $SCRIPT {start|stop|reload|restart|quit|test|info}"
exit 2
;;
esac
exit 0
Все, запускаем веб-сервер и проверяем. В браузере Internet Explorer 11 c установленным криптопровайдером КриптоПро CSP посетителю отдается ГОСТ сертификат, подписанный CRYPTO-PRO Test Center 2 при обращении к gost.example.ru, в Mozilla Firefox нет поддержки алгоритмов ГОСТ и посетитель получает «обычный» сертификат, подписанный WoSign CA Limited.
Internet Explorer
Mozilla Firefox
С моей точки зрения получился достаточно интересный вариант использования технологии, хочется надеяться, что скоро появится поддержка в openresty ssl_certificate_by_lua_block.
Что такое цепочка сертификатов и корневой сертификат и как их установить?
Корневой сертификат (СА) — часть ключа, которым центры сертификации подписывают выпущенные SSL-сертификаты. Выдавая корневой сертификат, каждый такой центр гарантирует, что пользователи или организации, запросившие SSL, верифицированы и действия с доменом легальны.
Центры сертификации с двадцатилетней историей: GlobalSign, Comodo, Symantec, TrustWave, GeoTrust. Они используют «именные» корневые сертификаты, которые распознаются большинством современных браузеров.
Это значит: если на сайт установлен корневой сертификат GlobalSign, браузер идентифицирует его как выпущенный доверенным «поручителем» и приступает к частной проверке сайта.
Если информация о корневом сертификате центра отсутствует в браузере, у сайта нет «поручителя», и браузер считает его недостоверным. Так иногда происходит с самоподписанными сертификатами безопасности (например, Let’s Encrypt):
Читайте об этом в статье Браузер пишет, что подключение не защищено или соединение является недоверенным.
Однако одного корневого сертификата недостаточно. Чтобы конкретный домен считался защищенным, помимо корневого сертификата необходимы промежуточный сертификат и индивидуальный сертификат домена, которые так же выдаются центром сертификации при выпуске SSL. Достоверность промежуточных и «индивидуальных» сертификатов подтверждается корневым сертификатом. Цепочка сертификатов, установленных на сайт, дает основание считать его «защищенным SSL-сертификатом» в сети Интернет.
Где взять корневой сертификат?
Корневые сертификаты выдают сертификационные центры. REG.RU сотрудничает с шестью сертификационными центрами. Выберите SSL-сертификат, который подходит для ваших целей, и закажите его со страницы SSL-сертификаты.
Также вы можете воспользоваться специальным предложением REG.RU и получить бесплатный SSL-сертификат на 1 год при заказе домена или хостинга. Читайте об этом в статье: Как заказать бесплатный SSL-сертификат?
После заказа SSL и его активации на указанную контактную почту придет письмо с необходимыми данными для установки сертификата на сайт (в частности, корневой сертификат). Подробнее о содержимом письма в статье Где взять данные для установки SSL-сертификата.
Могу ли я создать корневой сертификат самостоятельно?
Чтобы создать корневой сертификат самому, нужно получить статус сертификационного центра. Эта процедура связана со значительными финансовыми затратами, поэтому в большинстве случаев мы рекомендуем обращаться к существующим центрам сертификации.
Установка цепочки сертификатов
Список доверенных сертификатов, использующихся для создания цепочки, приходит в информационном письме после выпуска и активации SSL. Для установки цепочки сертификатов (в том числе, корневого) воспользуйтесь подробными инструкциями справочного раздела: Установка SSL-сертификата.
Помогла ли вам статья?
13
раз уже
помогла
Отправить ответ