Ca lic что это за папка

Как удалить lic98Service

Подлинный файл является одним из компонентов программного обеспечения CA License Client, разработанного www.ca.com .

Lic98Service — это аббревиатура от CA License Client Win98 Service

Lic98Service.exe — это исполняемый файл (программа) для Windows. Расширение имени файла .exe — это аббревиатура от англ. слова executable — исполнимый. Необходимо запускать исполняемые файлы от проверенных производителей программ, потому что исполняемые файлы могут потенциально изменить настройки компьютера или нанести вред вашему компьютеру. Бесплатный форум с информацией о файлах может помочь вам разобраться является ли lic98Service.exe вирусом, трояном, программой-шпионом, рекламой, которую вы можете удалить, или файл принадлежит системе Windows или приложению, которому можно доверять.

Вот так, вы сможете исправить ошибки, связанные с lic98Service.exe

1. Используйте программу Настройщик Windows, чтобы найти причину проблем, в том числе и медленной работы компьютера.
2. Обновите программу lic98Service. Обновление можно найти на сайте производителя (ссылка приведена ниже).
3. В следующих пунктах предоставлено описание работы lic98Service.exe.

Информация о файле lic98Service.exe

Описание: lic98Service.exe не является необходимым для Windows. Файл lic98Service.exe находится в подпапках «C:\Program Files» или иногда в подпапках диска C:\. Размер файла для Windows 10/11/7 составляет 29,960 байт.
Поставлена цифровая подпись. Нет описания файла. Это не системный процесс Windows. Это файл, подписанный Verisign. Приложение не видно пользователям. Процесс использует порт, чтобы присоединится к сети или интернету. Поэтому технический рейтинг надежности 40% опасности.

Важно: Некоторые вредоносные программы маскируют себя как lic98Service.exe, особенно, если они расположены в каталоге c:\windows или c:\windows\system32. Таким образом, вы должны проверить файл lic98Service.exe на вашем ПК, чтобы убедиться, что это угроза. Мы рекомендуем Security Task Manager для проверки безопасности вашего компьютера.

Комментарий пользователя

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

Лучшие практики для исправления проблем с lic98Service

Аккуратный и опрятный компьютер — это главное требование для избежания проблем с lic98Service. Для этого требуется регулярная проверка компьютера на вирусы, очистка жесткого диска, используя cleanmgr и sfc /scannow, удаление программ, которые больше не нужны, проверка программ, которые запускаются при старте Windows (используя msconfig) и активация Автоматическое обновление Windows. Всегда помните о создании периодических бэкапов, или в крайнем случае о создании точек восстановления.

Если у вас актуальные проблемы, попробуйте вспомнить, что вы делали в последнее время, или последнюю программу, которую вы устанавливали перед тем, как появилась впервые проблема. Используйте команду resmon, чтобы определить процесс, который вызывает проблемы. Даже если у вас серьезные проблемы с компьютером, прежде чем переустанавливать Windows, лучше попробуйте восстановить целостность установки ОС или для Windows 8 и более поздних версий Windows выполнить команду DISM.exe /Online /Cleanup-image /Restorehealth. Это позволит восстановить операционную систему без потери данных.

Следующие программы могут вам помочь для анализа процесса lic98Service.exe на вашем компьютере: Security Task Manager отображает все запущенные задания Windows, включая встроенные скрытые процессы, такие как мониторинг клавиатуры и браузера или записей автозагрузки. Уникальная оценка рисков безопасности указывает на вероятность процесса быть потенциально опасным — шпионской программой, вирусом или трояном. Malwarebytes Anti-Malware определяет и удаляет бездействующие программы-шпионы, рекламное ПО, трояны, кейлоггеры, вредоносные программы и трекеры с вашего жесткого диска.

lic98Service сканер

Security Task Manager показывает все запущенные сервисы Windows, включая внедренные скрытые приложения (например, мониторинг клавиатуры или браузера, авто вход). Уникальный рейтинг надежности указывает на вероятность того, что процесс потенциально может быть вредоносной программой-шпионом, кейлоггером или трояном.

Бесплатный aнтивирус находит и удаляет неактивные программы-шпионы, рекламу, трояны, кейлоггеры, вредоносные и следящие программы с вашего жесткого диска. Идеальное дополнение к Security Task Manager.

Инструмент ремонта ПК бесплатное сканирование, очистка, восстановление и оптимизация вашей системы.

Полное руководство по файлу calic.dll: Загрузка, Удаление и Исправление Ошибок

Файл calic.dll — это законный исполняемый файл, который обычно находится в e:\ Program Files\ CA\ CA Internet Security Suite\ . Этот файл связан с CA License Management, разработанным CA, Inc, MD5-сигнатура: b71f39b34df4532a348fd8fe8f52fe6a. Файл calic.dll обычно расположен в e:\ Program Files\ CA\ CA Internet Security Suite\ и имеет размер около 271600 байт. Этот файл необходим для правильной работы приложений, использующих CA License Management. Когда приложение требует этот файл, он загружается в память и выполняется в фоновом режиме.

Хотя файл calic.dll является законным CA License Management, иногда его могут нацелить создатели вредоносных программ, пытающихся замаскировать свой вредоносный код, используя тот же самый файловый путь. Поэтому важно удостовериться, что файл calic.dll на вашем компьютере является законным и не заражен вредоносным программным обеспечением. Один из способов проверить законность файла calic.dll — это проверить его цифровую подпись. У законного файла calic.dll должна быть цифровая подпись от корпорации CA, Inc, которую можно просмотреть, щелкнув правой кнопкой мыши по файлу, выбрав свойства, затем перейдя на вкладку «Цифровые подписи».

Как удалить calic.dll? Как удалить calic.dll? Как деинсталлировать calic.dll?

• Скачайте Asmwsoft PC Optimizer
• Из основного окна Asmwsoft PC Optimizer выберите инструмент «Force deleter».
• Затем в программе «Force deleter» выберите файл, перейдите в файл calic.dll, затем нажмите «Открыть».
• Теперь нажмите кнопку «Разблокировать и удалить» — появится сообщение с подтверждением, нажмите «Да», и все готово. P.S. Возможно, вам потребуется перезагрузить компьютер после этого шага.

Как скачать calic.dll?

Чтобы загрузить файл calic.dll, вы можете следовать этим общим шагам:

• Откройте веб-браузер: Запустите веб-браузер на своем компьютере. Можно использовать распространенные веб-браузеры, такие как Google Chrome, Mozilla Firefox, Microsoft Edge или Safari, чтобы загрузить файлы.
• Перейдите на доверенный веб-сайт: Перейдите на доверенный веб-сайт или ресурс, где файл calic.dll доступен для загрузки. Это может быть официальный веб-сайт разработчика программного обеспечения CA License Management, надежного репозитория программного обеспечения или любого другого авторитетного источника. Будьте осторожны при загрузке файлов с ненадежных или подозрительных веб-сайтов, так как они могут содержать вредоносное ПО.
• Поиск или просмотр: Используйте функцию поиска веб-сайта или просматривайте категории, чтобы найти приложение CA License Management, которое вы хотите загрузить. Убедитесь, что вы находитесь на официальном или доверенном веб-сайте, чтобы избежать загрузки вредоносных файлов.
• Нажмите на ссылку «Скачать»: Как только вы найдете нужный файл CA License Management, рядом с ним должна быть ссылка или кнопка для загрузки. Нажмите на ссылку загрузки. Она может называться «Скачать», «Получить» или что-то подобное.
• Выберите место загрузки: Может появиться диалоговое окно или запрос, спрашивающий, куда вы хотите сохранить файл EXE. Выберите место на вашем компьютере, где вы хотите сохранить файл. По умолчанию это часто папка «Загрузки».
• Дождитесь завершения загрузки: В зависимости от размера файла и скорости вашего интернет-соединения это может занять несколько секунд или минут. Вы можете проверить ход загрузки в строке состояния вашего веб-браузера или менеджере загрузок. Большинство антивирусных программ, таких как Windows Defender, будут сканировать файл на наличие вирусов во время загрузки
• Запустите файл CA License Management EXE: Если файл происходит из доверенного источника и не содержит вредоносного ПО, вы можете запустить загруженный файл CA License Management EXE, дважды щелкнув по нему. Следуйте инструкциям на экране для установки или запуска программы, связанной с файлом EXE.
• Следуйте инструкциям по установке: Если загруженный файл CA License Management EXE представляет собой установщик, следуйте подсказкам и инструкциям по установке, предоставленным программой. Это может включать в себя указание параметров установки, согласие с условиями и положениями, а также выбор директории установки.
• Завершите установку: После завершения установки вы должны быть готовы использовать программное обеспечение, связанное с файлом CA License Management EXE.

Всегда будьте осторожны при загрузке файлов CA License Management EXE из интернета. Следуйте доверенным источникам и избегайте загрузки файлов с подозрительных веб-сайтов или источников, чтобы защитить свой компьютер от потенциальных угроз безопасности.

Как исправить ошибку приложения calic.dll?

Ошибка приложения EXE — это тип ошибки, которая возникает, когда исполняемый файл calic.dll не может правильно запуститься в Windows. Существует множество возможных причин и решений для этой ошибки, в зависимости от конкретного файла calic.dll и обстоятельств проблемы. Вот несколько общих шагов, которые вы можете предпринять, чтобы исправить ошибку приложения calic.dll:

• Обновите Windows до последней версии: Иногда ошибка может быть вызвана устаревшими или несовместимыми системными файлами или драйверами. Чтобы проверить наличие обновлений, перейдите в «Настройки» > «Обновление и безопасность» > «Windows Update» и нажмите «Проверить наличие обновлений».
• Просканируйте компьютер на предмет вредоносного ПО: Вредоносное ПО часто маскируется под легитимные файлы calic.dll и может вызывать различные проблемы, включая высокое использование ЦП, сбои или ошибки. Используйте Windows Defender или любое другое антивирусное программное обеспечение, которому вы доверяете, для сканирования компьютера и удаления потенциальных угроз.
• Восстановите или переустановите CA License Management, связанный с файлом calic.dll: Если ошибка вызвана программой CA License Management, которую вы установили, вы можете попробовать исправить ее, восстановив или переустанавливая программу CA License Management. Для этого перейдите в «Настройки» > «Приложения» > «Приложения и функции» и найдите программу CA License Management в списке. Нажмите на нее и выберите «Изменить» или «Удалить». Следуйте инструкциям на экране, чтобы восстановить или переустановить программу CA License Management.
• Запустите инструмент System File Checker (SFC): Этот инструмент может сканировать вашу систему на наличие поврежденных или отсутствующих файлов и заменять их оригинальными версиями. Для запуска инструмента SFC откройте командную строку от имени администратора и введите sfc /scannow, затем нажмите Enter. Подождите завершения сканирования и перезагрузите компьютер
• Запустите инструмент диагностики памяти: Этот инструмент может проверить вашу оперативную память на наличие ошибок, которые могут повлиять на производительность компьютера. Для запуска инструмента диагностики памяти введите «memory» в строке поиска и выберите «Диагностика памяти Windows». Выберите «Перезагрузить сейчас и проверить на наличие проблем» или «Проверить на наличие проблем при следующем запуске компьютера». Компьютер перезагрузится и запустит тест. После завершения теста вы можете просмотреть результаты в «Просмотр событий».

Это лишь несколько возможных решений для устранения ошибки приложения calic.dll. Тем не менее различные файлы calic.dll могут требовать различных методов или условий, поэтому перед загрузкой и запуском любого файла calic.dll всегда внимательно читайте инструкции. Будьте осторожны при скачивании файлов calic.dll из неизвестных или недоверенных источников, так как они могут содержать вредоносное ПО или вирусы, которые могут повредить ваш компьютер. Никогда не открывайте файл calic.dll, который вам был отправлен в виде вложения в электронном письме, даже если вы знаете отправителя. Всегда сканируйте файл антивирусной программой перед его запуском.

Как устранить высокую загрузку процессора и диска, вызванную файлом calic.dll?

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

• Вы можете попробовать завершить процесс calic.dll из Диспетчера задач или Монитора производительности. Щелкните правой кнопкой мыши по calic.dll и выберите «Завершить задачу» или «Завершить дерево процессов». Это может временно решить проблему, но также может повлиять на функциональность CA License Management или службы, связанной с файлом calic.dll.
• Если завершение процесса не помогает, вы можете попробовать отключить или удалить CA License Management или службу, связанную с файлом calic.dll. Вы можете перейти в Панель управления > Программы и компоненты и удалить ее оттуда. Если файл calic.dll является частью Windows, вы можете перейти в Панель управления > Административные инструменты > Службы и отключить его оттуда. Однако будьте осторожны, чтобы не отключить или не удалить необходимые компоненты Windows, которые могут повлиять на стабильность или безопасность системы.
• Если отключение или удаление CA License Management или службы не помогает, вы можете попробовать отсканировать ваш компьютер на предмет вредоносных программ с использованием надежной программы антивируса. Вредоносное ПО часто может маскироваться под легитимный файл calic.dll и потреблять высокие ресурсы процессора. Вы можете использовать Windows Defender или любое другое антивирусное программное обеспечение, которому вы доверяете, для сканирования компьютера и удаления потенциальных угроз.
• Если сканирование компьютера на наличие вредоносных программ не помогает, вы можете попробовать восстановить системные файлы с помощью инструмента Проверки файлов системы (SFC). Этот инструмент может проверить вашу систему на наличие поврежденных или отсутствующих файлов и заменить их оригинальными версиями. Чтобы запустить инструмент SFC, откройте Командную строку от имени администратора и введите sfc /scannow, затем нажмите Enter. Подождите завершения сканирования и перезагрузите компьютер.
• Если восстановление системных файлов не помогает, вы можете попробовать оптимизировать производительность вашей системы с использованием различных методов, таких как удаление временных файлов, дефрагментация жесткого диска, обновление драйверов, настройка энергосберегающих параметров и отключение ненужных программ при запуске. Вы также можете использовать инструменты Asmwsoft PC optimizer для автоматического выполнения этих задач.

Это некоторые из возможных решений для устранения высокого использования процессора файлом calic.dll в Windows. Если ни одно из них не работает для вас, возможно, вам придется обратиться к профессиональному технику или получить дополнительную поддержку от службы поддержки Microsoft.

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

Как другие пользователи поступают с этим файлом?

Всего голосов ( 270 ), 200 говорят, что не будут удалять, а 70 говорят, что удалят его с компьютера.

Как выглядит электронная подпись

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

В этой статье:

• Что такое электронная подпись
• Усиленная квалифицированная подпись
• Токен
• Smart-карта
• Flash или флеш-карта

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

Что такое электронная подпись

Электронная подпись (ЭП, или ЭЦП — устаревшее название) — это реквизит электронного документа. Она подтверждает автора ЭП, отсутствие изменений в подписанном файле, а также дает документам юридическую силу при определенных условиях.

В 63-ФЗ описаны три вида электронной подписи: простая — ПЭП, усиленная неквалифицированная — НЭП и усиленная квалифицированная — КЭП. Отличаются ли они внешне, расскажем далее в статье.

Мы упрощаем термины в статье. Например, говорим «получить квалифицированную электронную подпись», хотя фактически получают не подпись, а сертификат, участвующий в подписании документов.

Усиленная квалифицированная подпись

КЭП — самая универсальная подпись. Она равнозначна собственноручной и по умолчанию придает подписанному документу юридическую значимость. По этой причине бизнес часто использует ее в работе: чтобы участвовать в торгах, сдавать отчетность и обмениваться документами с контрагентами.

Усиленная неквалифицированная подпись

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

Из-за того, что КЭП по умолчанию придает документам юридическую силу, к получению ее сертификата больше требований: их выдают только специально отобранные организации — аккредитованные удостоверяющие центры (УЦ). Чтобы выпустить КЭП, нужно прийти туда и удостоверить личность.

НЭП же дает файлам юридическую значимость не по умолчанию, а когда стороны, которые обмениваются документами, заключили допсоглашение об этом. Отличаются и сферы применения КЭП и НЭП. КЭП универсальна — с ней можно работать одновременно в нескольких системах: зарегистрировать квартиру в Росреестре и при этом отчитаться в Честном ЗНАКе. А НЭП используется только на одной конкретной площадке.

Например, неквалифицированную подпись можно выпустить онлайн на сайте ФНС, если есть аккаунт на Госуслугах. Сделать это может физлицо, но не ИП или представитель юрлица. Такая НЭП будет работать только на сайте налоговой — по внутреннему регламенту ФНС. Или другой пример — кадровый электронный документооборот (ЭДО) в компании. Сотрудник с НЭП подписывает приказы, трудовые договоры, должностные инструкции и другие кадровые документы только в системе ЭДО организации. Подпись обеспечивает их юридическую значимость, так как работник и компания заключили соглашение об этом.

Простая электронная подпись

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

В зависимости от площадки и сервиса, где используют ПЭП, может стоять тот или иной знак, что документ подписан. Например, галочка или штамп «Платеж отправлен», «Подписано ПЭП».

ПЭП также не будет давать документам юридическую силу, если стороны документооборота не заключат между собой соглашение. Его обычно включают в договор обслуживания:например, между банком и клиентом.Или заключают во время обслуживания: например, анкета-согласие на использование электронной подписи на Почте России.

Как выглядит ЭП на электронных документах

По сути электронную подпись на документах никак не увидеть, так как это набор данных: информация, которая присоединяется к другой информации. Можно только проверить сам факт того, что документ подписан. Для этого есть специальные программы, например на портале Госуслуг или же Контур.Крипто.

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

• содержание электронного документа,
• визуализацию электронной подписи: информацию о том, что такой документ подписан электронной подписью, а также о номере, владельце и периоде действия сертификата ЭП.

Итак, представим, что вы подписали КЭП документ Microsoft Word. Вот как она будет выглядеть.

Если подпись открепленная

Когда документ подписали КЭП, создается отдельный файл с ЭП. У него такое же название, но другое расширение — sig, sgn или p7s.

Документ с открепленной электронной подписью выглядит как два файла — сам документ и файл подписи.

Чтобы проверить автора и неизменность подписанного документа, в программу, например Контур.Крипто, надо передать сразу два файла: оригинал «Файл.docx» и файл с подписью «Файл.sig».

Если подпись прикрепленная

Когда документ подписали электронной подписью, в тот же файл добавляется расширение «Файл.docx.sig». То есть ЭП находится внутри исходного документа.

Чтобы проверить такой документ, например в сервисе от Госуслуг, в программу надо загрузить именно этот файл — «Файл.docx.sig».

Если подпись встроенная

Когда файл подписали ЭП, его формат остался прежним, но в самом документе появляется штамп или специальный знак с информацией о подписи. Если изменить документ после подписания, электронная подпись станет недействительной.

Встроенную подпись создают внутри документов Word, Excel или PDF с помощью дополнительного ПО: например, КриптоПро Office Signature и КриптоПро PDF. Часто такой способ визуализации подписи используют государственные структуры: ФНС, Росреестр и другие. Внизу их документов стоят подобные штампы:

Как выглядит штамп, зависит от настроек программы, где он создан, или сервиса. Например, в Контур.Экстерне появляется галочка «Документ подписан», а в подписанном документе Microsoft Word на панели внизу — красный ярлык:

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

Посмотреть, есть ли в документе подпись, можно и на вкладке «Свойства». В пункте «Подпись» будут сведения о подписанте.

Если в документе стоит отметка «Подписано ЭП» и подобные, это не значит, что файл на самом деле подписан и не изменен. Чтобы проверить подлинность документа и верность ЭП, надо загрузить электронный оригинал документа в специальный сервис (например, Контур.Крипто).

Распечатывать документ с ЭП не нужно, ведь он подписан в электронном, а не в бумажном виде.

Какие виды физической оболочки есть у ЭП

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

Сертификат и ключи можно записать на съемные носители или хранить только в памяти компьютера. Далее перечислим, на каких устройствах хранят элементы ЭП, и покажем, как выглядят такие носители.

Ключи для создания ЭП руководитель формирует самостоятельно на компьютере, а вот за сертификатом надо идти в ФНС.

Получите сертификат у доверенного лица налоговой без визита в инспекцию

Токен

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

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

Использовать обычную флешку для хранения подписи опасно. Ведь она не защитит данные.

Smart-карта

Smart-карта — это пластиковая карта с микросхемой, похожая на банковскую карту. Она выполняет ту же функцию, что и токен, то есть защищает информацию: на ней есть пароль и СКЗИ. Однако возможности карты в отличие от токена шире. Например, иногда компании делают из smart-карт электронные удостоверения сотрудников.

Для считывания информации с карты обычно нужно специальное устройство. Некоторые карты работают бесконтактно.

Smart-карта для хранения электронной подписи выглядит, как банковская карточка. Изображение с сайта rutoken.ru

Flash или флеш-карта

Flash, или флешка, — это небольшое устройство для хранения информации, где есть карта памяти и разъем USB. Она не предназначена для защиты и шифрования данных в отличие от токена, поэтому на ней нет пароля и СКЗИ. Из этого следует, что хранить ЭП на флешке не стоит, так как информация легко может попасть не в те руки.

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

Итак, на носителях хранят не электронные подписи, а файлы, из которых формируются ЭП. Самые безопасные устройства для этого — токен и smart-карта: они защищены паролями, а некоторые — СКЗИ.

Чтобы сохранить подпись в безопасности, не стоит передавать носитель с ЭП другим людям. Так, сотрудники не должны иметь доступ к подписям руководителя и друг друга. Иначе они могут подписать документ самовольно, а доказать, что подпись поставил не ее владелец, трудно.

OpenSSL Certificate Authority. Центр сертификации OpenSSL.

Эта инструкция демонстрирует, как работает собственный центр сертификации (CA – Certificate Authority), используя набор инструментов командной строки OpenSSL. Это полезно в ряде случаев, таких как выдача сертификата сервера для защиты вебсайта в интранете, или для выдачи сертификатов для клиентов, чтобы позволить им проверить подлинность сервера.

Вступление

OpenSSL — это криптографическая библиотека со свободным и открытым исходным кодом, которая предоставляет несколько инструментов командной строки для работы с цифровыми сертификатами. Некоторые из этих инструментов могут быть использованы в качестве центра сертификации.

Центр сертификации (CA) является объектом, который подписывает цифровые сертификаты. Многие веб-сайты нуждаются в том, чтобы их клиенты знали, что соединение является безопасным, поэтому они платят международным доверенным центрам сертификации (например, VeriSign, DigiCert) за подпись сертификата для своего домена.

В некоторых случаях имеет больше смысла выступать в качестве вашего собственного центра сертифкации, чем платить центрам сертификации, таким как DigiCert. Например, обеспечение безопасности вебсайта в интранете или для выдачи собственных сертификатов клиентам, чтобы позволить им проверять подлинность сервера (Apache, OpenVPN).

Создание корневой пары ключей

Выступая в качестве центра сертификации (CA) означает иметь дело с криптографическими парами приватных (частных) ключей и публичными сертификатами. Самой первой криптографической парой создадим корневую пару. Она состоит из корневого ключа (ca.key.pem) и корневого сертификата (ca.cert.pem). Эта пара образует идентичность нашего центра сертификации.

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

Подготовка каталогов

Выберите каталог для хранения всех ключей и сертификатов. К примеру, /root/ca (все производится на Ubuntu 14.04.3 LTS)

Создадим структуру каталогов. Файлы index.txt и serial будут выступать в качестве плоской базы для отслеживания подписанных сертификатов.

# cd /root/ca # mkdir certs crl newcerts private # chmod 700 private # touch index.txt # echo 1000 > serial 

Подготовка конфигурационных файлов

Необходимо создать конфигурационный файл для OpenSSL. Создадим файл /root/ca/openssl.cnf , скопируем в него следующее содержимое root-config.txt.
Раздел [ca] является обязательным. Здесь мы говорим OpenSSL использовать параметры из раздела [CA_default] :

[ ca ] #man ca default_ca = CA_default 

Раздел [CA_default] содержит ряд значений по умолчанию:

[ CA_default ] # Directory and file locations. dir = /root/ca certs = $dir/certs crl_dir = $dir/crl new_certs_dir = $dir/newcerts database = $dir/index.txt serial = $dir/serial RANDFILE = $dir/private/.rand # The root key and root certificate. private_key = $dir/private/ca.key.pem certificate = $dir/certs/ca.cert.pem # For certificate revocation lists. crlnumber = $dir/crlnumber crl = $dir/crl/ca.crl.pem crl_extensions = crl_ext default_crl_days = 30 # SHA-1 is deprecated, so use SHA-2 instead. default_md = sha256 name_opt = ca_default cert_opt = ca_default default_days = 375 preserve = no policy = policy_strict 

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

[ policy_strict ] # The root CA should only sign intermediate certificates that match. # See the POLICY FORMAT section of man ca. countryName = match stateOrProvinceName = match organizationName = match organizationalUnitName = optional commonName = supplied emailAddress = optional 

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

[ policy_loose ] # Allow the intermediate CA to sign a more diverse range of certificates. # See the POLICY FORMAT section of the `ca` man page. countryName = optional stateOrProvinceName = optional localityName = optional organizationName = optional organizationalUnitName = optional commonName = supplied emailAddress = optional 

Параметры из секции [ req ] применяются когда создаются сертификаты или запросы на подписывание сертификатов.

[ req ] # Options for the `req` tool (`man req`). default_bits = 2048 distinguished_name = req_distinguished_name string_mask = utf8only # SHA-1 is deprecated, so use SHA-2 instead. default_md = sha256 # Extension to add when the -x509 option is used. x509_extensions = v3_ca 

Секция [ req_distinguished_name ] определяет информацию, которая обычно требуется при запросе на подписывание сертификата. Можно указать некоторые значения по умолчанию.

[ req_distinguished_name ] # See https://en.wikipedia.org/wiki/Certificate_signing_request. countryName = Country Name (2 letter code) stateOrProvinceName = State or Province Name localityName = Locality Name organizationName = Organization Name organizationalUnitName = Organizational Unit Name commonName = Common Name emailAddress = Email Address # Optionally, specify some defaults. countryName_default = GB stateOrProvinceName_default = England localityName_default = England organizationName_default = Alice Ltd #organizationalUnitName_default = #emailAddress_default = 

Следующие несколько секций являются расширениями, которые могут применять при подписывании сертификатов. Например, при указании аргумента командной строки -extensions v3_ca будут применены расширения из секции [ v3_ca ] . Эти расширения будут применяться при создании корневого сертификата.

[ v3_ca ] # Extensions for a typical CA (`man x509v3_config`). subjectKeyIdentifier = hash authorityKeyIdentifier = keyid:always,issuer basicConstraints = critical, CA:true keyUsage = critical, digitalSignature, cRLSign, keyCertSign 

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

[ v3_intermediate_ca ] # Extensions for a typical intermediate CA (`man x509v3_config`). subjectKeyIdentifier = hash authorityKeyIdentifier = keyid:always,issuer basicConstraints = critical, CA:true, pathlen:0 keyUsage = critical, digitalSignature, cRLSign, keyCertSign 

Расширение usr_cert будет применяться при подписывании клиентских сертификатов, таких, которые используются для аутентификации удаленных пользователей.

[ usr_cert ] # Extensions for client certificates (`man x509v3_config`). basicConstraints = CA:FALSE nsCertType = client, email nsComment = "OpenSSL Generated Client Certificate" subjectKeyIdentifier = hash authorityKeyIdentifier = keyid,issuer keyUsage = critical, nonRepudiation, digitalSignature, keyEncipherment extendedKeyUsage = clientAuth, emailProtection 

Расширение server_cert будет применяться при подписывании серверных сертификатов, таких, которые используются для веб-серверов.

[ server_cert ] # Extensions for server certificates (`man x509v3_config`). basicConstraints = CA:FALSE nsCertType = server nsComment = "OpenSSL Generated Server Certificate" subjectKeyIdentifier = hash authorityKeyIdentifier = keyid,issuer:always keyUsage = critical, digitalSignature, keyEncipherment extendedKeyUsage = serverAuth 

Расширение crl_ext будет автоматически применяться при создании списков отзыва сертификатов (CRL — certificate revocation lists).

[ crl_ext ] # Extension for CRLs (`man x509v3_config`). authorityKeyIdentifier=keyid:always 

Расширение ocsp будет применяться при подписывании сертификата OCSP (Online Certificate Status Protocol, онлайн протокол статуса сертификатов).

[ ocsp ] # Extension for OCSP signing certificates (`man ocsp`). basicConstraints = CA:FALSE subjectKeyIdentifier = hash authorityKeyIdentifier = keyid,issuer keyUsage = critical, digitalSignature extendedKeyUsage = critical, OCSPSigning 

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

Создадим корневой ключ (ca.key.pem), который следует хранить защищенно. Любой, владеющий корневым ключом, может выдавать доверенные сертификаты. Зашифруем ключ стойким алгоритмом AES-256 и надежным паролем. Следует использовать 4096 битное шифрование для ключей корневого и промежуточных центров сертификации. Серверные и клиентские сертификаты возможно подписывать шифрованием с меньшей битностью.

# cd /root/ca # openssl genrsa -aes256 -out private/ca.key.pem 4096 Enter pass phrase for ca.key.pem: secretpassword Verifying - Enter pass phrase for ca.key.pem: secretpassword # chmod 400 private/ca.key.pem 

Создание корневого сертификата

Для создания корневого сертификата (ca.cert.pem) используется корневой ключ (ca.key.pem). Следует указать длинный срок годности сертификата, например, 20 лет. После того, как истечет корневой сертификат, все сертификаты, подписанные центром сертификации становятся недействительными. Всякий раз при использовании утилиты req следует указывать файл конфигурации для использования с опцией –config , в противном случае OpenSSL будет использовать по умолчанию конфигурационный файл /etc/pki/tls/openssl.cnf !

# cd /root/ca # openssl req -config openssl.cnf \ -key private/ca.key.pem \ -new -x509 -days 7300 -sha256 -extensions v3_ca \ -out certs/ca.cert.pem Enter pass phrase for ca.key.pem: secretpassword You are about to be asked to enter information that will be incorporated into your certificate request. ----- Country Name (2 letter code) [XX]:GB State or Province Name []:England Locality Name []: Organization Name []:Alice Ltd Organizational Unit Name []:Alice Ltd Certificate Authority Common Name []:Alice Ltd Root CA Email Address []: # chmod 444 certs/ca.cert.pem 

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

# openssl x509 -noout -text -in certs/ca.cert.pem

• Используемый алгоритм Signature Algorithm
• Даты периода действия сертификата Validity
• Длину публичного ключа Public-Key
• Эмитент сертификата Issuer, который является объектом, который подписал сертификат
• Предмет Subject, который относится к самому сертификату.

Эмитент (Issuer) и предмет (Subject) идентичны для самоподписанных сертификатов. Все корневые сертификаты являются самоподписанными.

Signature Algorithm: sha256WithRSAEncryption Issuer: C=GB, ST=England, O=Alice Ltd, OU=Alice Ltd Certificate Authority, CN=Alice Ltd Root CA Validity Not Before: Apr 11 12:22:58 2015 GMT Not After : Apr 6 12:22:58 2035 GMT Subject: C=GB, ST=England, O=Alice Ltd, OU=Alice Ltd Certificate Authority, CN=Alice Ltd Root CA Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (4096 bit) 

Вывод также показывает расширения X509v3, т.к. было применено расширение v3_ca , и опции из секции [ v3_ca ] отражены в выводе.

X509v3 extensions: X509v3 Subject Key Identifier: 38:58:29:2F:6B:57:79:4F:39:FD:32:35:60:74:92:60:6E:E8:2A:31 X509v3 Authority Key Identifier: keyid:38:58:29:2F:6B:57:79:4F:39:FD:32:35:60:74:92:60:6E:E8:2A:31 X509v3 Basic Constraints: critical CA:TRUE X509v3 Key Usage: critical Digital Signature, Certificate Sign, CRL Sign 

Создание промежуточной пары ключей

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

Цель использования промежуточного центра сертификации, прежде всего, для обеспечения безопасности. Корневой ключ должен храниться «оффлайн» и использоваться как можно реже. Если промежуточный ключ будет скомпрометирован, корневой центр сертификации может отозвать промежуточный сертификат и создать новую промежуточную криптографическую пару.

Подготовка каталогов

Файлы корневого центра сертификации хранятся в /root/ca. Выберем каталог (/root/ca/intermediate) для хранения файлов промежуточного центра сертификации.

Создадим точно такую же структуру каталогов, которая используется для корневого центра сертификации. Также удобно создать каталог csr для хранения запросов на подпись сертификатов.

# cd /root/ca/intermediate # mkdir certs crl csr newcerts private # chmod 700 private # touch index.txt # echo 1000 > serial 

Добавим файл crlnumber к дереву каталогов промежуточного центра сертификации. Crlnumber будет использоваться для отслеживания списков отзывов сертификатов.

# echo 1000 > /root/ca/intermediate/crlnumber

Создадим конфигурационный файл /root/ca/intermediate/openssl.cnf , скопируем в него следующее содержимое intermediate-config.txt. В нем изменены пять опций, по сравнению с конфигурационным файлов корневого центра сертификации:

[ CA_default ] dir = /root/ca/intermediate private_key = $dir/private/intermediate.key.pem certificate = $dir/certs/intermediate.cert.pem crl = $dir/crl/intermediate.crl.pem policy = policy_loose 

Создание промежуточного ключа

Создадим промежуточный ключ (intermediate.key.pem). Зашифруем ключ стойким алгоритмом AES-256 и надежным паролем.

# cd /root/ca # openssl genrsa -aes256 \ -out intermediate/private/intermediate.key.pem 4096 Enter pass phrase for intermediate.key.pem: secretpassword Verifying - Enter pass phrase for intermediate.key.pem: secretpassword # chmod 400 intermediate/private/intermediate.key.pem 

Создание промежуточного сертификата

Используя промежуточный ключ создадим запрос на подписывание сертификата (CSR — certificate signing request). Сведения должны, как правило, соответствовать корневому центру сертификации. Общие имена (Common Name), однако, должны быть разными. И убедитесь, что используете конфигурационный файл промежуточного центра сертификаци ( intermediate/openssl.cnf ).

# cd /root/ca # openssl req -config intermediate/openssl.cnf -new -sha256 \ -key intermediate/private/intermediate.key.pem \ -out intermediate/csr/intermediate.csr.pem Enter pass phrase for intermediate.key.pem: secretpassword You are about to be asked to enter information that will be incorporated into your certificate request. ----- Country Name (2 letter code) [XX]:GB State or Province Name []:England Locality Name []: Organization Name []:Alice Ltd Organizational Unit Name []:Alice Ltd Certificate Authority Common Name []:Alice Ltd Intermediate CA Email Address []: 

Чтобы создать промежуточный сертификат используем корневой центр сертификации с расширением v3_intermediate_ca для подписывания промежуточного запроса. Промежуточный сертификат должен быть действителен на меньший период, чем корневой. К примеру, на 10 лет. В этот раз следует использовать конфигурационный файл корневого центра сертификации ( /root/ca/openssl.cnf ).

# cd /root/ca # openssl ca -config openssl.cnf -extensions v3_intermediate_ca \ -days 3650 -notext -md sha256 \ -in intermediate/csr/intermediate.csr.pem \ -out intermediate/certs/intermediate.cert.pem Enter pass phrase for ca.key.pem: secretpassword Sign the certificate? [y/n]: y # chmod 444 intermediate/certs/intermediate.cert.pem 

Для хранения базы данных сертификатов, выданных утилитой ca OpenSSL, используется файл index.txt. Не следует удалять или править вручную этот файл. Сейчас он должен содержать одну строку, которая относится к промежуточному сертификату.

V 250408122707Z 1000 unknown . /CN=Alice Ltd Intermediate CA

Проверка промежуточного сертификата

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

# openssl x509 -noout -text \ -in intermediate/certs/intermediate.cert.pem 

Сверим промежуточный сертификат с корневым сертификатом. ОК показывает, что цепочка доверия не повреждена.

# openssl verify -CAfile certs/ca.cert.pem \ intermediate/certs/intermediate.cert.pem intermediate.cert.pem: OK 

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

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

Чтобы создать цепочку сертификатов требуется объеденить промежуточные и корневые сертификаты вмете. Позже мы будем использовать этот файл для проверки сертификатов подписанных промежуточным центром сертификации.

# cat intermediate/certs/intermediate.cert.pem \ certs/ca.cert.pem > intermediate/certs/ca-chain.cert.pem # chmod 444 intermediate/certs/ca-chain.cert.pem 

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

Подписывание серверного и клиентского сертификатов

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

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

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

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

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

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

# cd /root/ca # openssl genrsa -aes256 \ -out intermediate/private/www.example.com.key.pem 2048 # chmod 400 intermediate/private/www.example.com.key.pem 

Создание сертификата

Используем частный ключ для создания запроса на подписывание сертификата (CSR). Детали в CSR не обязательно должны совпадать с промежуточным центром сертификации. Для серверных сертификатов, Общее Имя (Common Name) должно быть полным доменным именем (fully qualified domain name — FQDN) (к примеру, www.example.com), в то время как для клиентского сертификата оно должно быть любым уникальным идентификатором (к примеру, e-mail адресом). Common Name не может быть таким же, как любой корневой или промежуточный сертификат.

# cd /root/ca # openssl req -config intermediate/openssl.cnf \ -key intermediate/private/www.example.com.key.pem \ -new -sha256 -out intermediate/csr/www.example.com.csr.pem Enter pass phrase for www.example.com.key.pem: secretpassword You are about to be asked to enter information that will be incorporated into your certificate request. ----- Country Name (2 letter code) [XX]:US State or Province Name []:California Locality Name []:Mountain View Organization Name []:Alice Ltd Organizational Unit Name []:Alice Ltd Web Services Common Name []:www.example.com Email Address []: 

Для создания сертификата воспользуемся промежуточным центром сертификации для подписи CSR. Если сертификат будет использоваться на сервере, используйте расширение server_cert . Если сертификат будет использоваться для аутентификации клиентов, то используйте расширение usr_cert . Сертификаты обычно даются сроком на один год, на центре сертификации обычно дают несколько дней для удобства.

# cd /root/ca # openssl ca -config intermediate/openssl.cnf \ -extensions server_cert -days 375 -notext -md sha256 \ -in intermediate/csr/www.example.com.csr.pem \ -out intermediate/certs/www.example.com.cert.pem # chmod 444 intermediate/certs/www.example.com.cert.pem 

Файл intermediate/index.txt должен содержать строку, которая относится к этому сертификату

V 160420124233Z 1000 unknown . /CN=www.example.com

Проверка сертификата

# openssl x509 -noout -text \ -in intermediate/certs/www.example.com.cert.pem 

Issuer сертификата наш промежуточный центр сертификации. Subject относится к самому сертификату.

Signature Algorithm: sha256WithRSAEncryption Issuer: C=GB, ST=England, O=Alice Ltd, OU=Alice Ltd Certificate Authority, CN=Alice Ltd Intermediate CA Validity Not Before: Apr 11 12:42:33 2015 GMT Not After : Apr 20 12:42:33 2016 GMT Subject: C=US, ST=California, L=Mountain View, O=Alice Ltd, OU=Alice Ltd Web Services, CN=www.example.com Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (2048 bit) 

Вывод также покажет расширения X509V3. При создании сертификата можно использовать расширения server_cert или usr_cert . Варианты о соответствующем разделе конфигурации будут отражаться в выводе.

X509v3 extensions: X509v3 Basic Constraints: CA:FALSE Netscape Cert Type: SSL Server Netscape Comment: OpenSSL Generated Server Certificate X509v3 Subject Key Identifier: B1:B8:88:48:64:B7:45:52:21:CC:35:37:9E:24:50:EE:AD:58:02:B5 X509v3 Authority Key Identifier: keyid:69:E8:EC:54:7F:25:23:60:E5:B6:E7:72:61:F1:D4:B9:21:D4:45:E9 DirName:/C=GB/ST=England/O=Alice Ltd/OU=Alice Ltd Certificate Authority/CN=Alice Ltd Root CA serial:10:00 X509v3 Key Usage: critical Digital Signature, Key Encipherment X509v3 Extended Key Usage: TLS Web Server Authentication 

Используя файл цепочки сертификатов центра сертификации, который мы создали ранее (ca-chain.cert.pem) для проверки того, что новый сертификат имеет действительную цепочку доверия.

# openssl verify -CAfile intermediate/certs/ca-chain.cert.pem \ intermediate/certs/www.example.com.cert.pem www.example.com.cert.pem: OK 

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

Теперь можно установить новый сертификат на сервере, или распространить сертификат на клиентов. При установке на серверное приложение (к примеру, Apache), понадобятся следующие файлы:

• ca-chain.cert.pem
• example.com.key.pem
• example.com.cert.pem

Если вы подписывали CSR от стороннего лица, у вас нет доступа до их частного ключа, и вы должны им дать только файл цепочки ca-chain.cert.pem и сертификат www.example.com.cert.pem.

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

Списки отзывов сертификатов (CRL) предоставляют список сертификатов, которые были отозваны. Клиентское приложение, к примеру, веб-браузер, может использовать CRL для проверки подлинности сервера. Серверные приложения, такие как Apache или OpenVPN, могут использовать CRL для запрета доступа клиентам, которые больше не являются доверенными.

Публикация CRL в публично доступном месте (к примеру, http://example.com/intermediate.crl.pem) позволит треьтим сторонам получать CRL из этого места, чтобы проверить, нет ли в нем сертификатов, которые могут быть отозваны. Некоторые разработчики приложений вместо устаревшего CRL используют Онлайн Протокол Статуса Сертификата (Online Certificate Status Protocol — OCSP).

Подготовка файла конфигурации

Когда центр сертификации подписывает сертификат, он обычно зашифровывает расположение CRL в сертификат. Добавляется crlDistributionPoints в подходящие секции. В нашем случае, добавляет к секции server_cert .

[ server_cert ] # . snipped . crlDistributionPoints = URI:http://example.com/intermediate.crl.pem 

Создание CRL

# cd /root/ca # openssl ca -config intermediate/openssl.cnf \ -gencrl -out intermediate/crl/intermediate.crl.pem 

Секция CRL OPTIONS в man ca содержит больше информации о том, как создавать CRL.

Можно проверить содержимое CRL с помощтю утилиты crl.

# openssl crl -in intermediate/crl/intermediate.crl.pem -noout –text

Пока еще не было отозванных сертификатов, поэтому в выводе указано:

No Revoked Certificates.

Необходимо пересоздавать CRL на регулярной основе. По умолчанию, CRL истекает через 30 дней. Это настраивается опцией default_crl_days в секции CA_default .

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

Давайте разберем пример. Алиса запустила веб-сервер Apache и имеет личную папку с сердцу трогательными милыми картинками котят. Алиса хочет предоставить своему другу, Бобу, доступ к этой коллекции.

Боб создает запрос частного ключа и запрос на подпись сертификата (CSR).

$ cd /home/bob $ openssl genrsa -out bob@example.com.key.pem 2048 $ openssl req -new -key bob@example.com.key.pem \ -out bob@example.com.csr.pem You are about to be asked to enter information that will be incorporated into your certificate request. ----- Country Name [XX]:US State or Province Name []:California Locality Name []:San Francisco Organization Name []:Bob Ltd Organizational Unit Name []: Common Name []:bob@example.com Email Address []: 

Боб посылает свой CSR Алисе которая затем подписывает его.

# cd /root/ca # openssl ca -config intermediate/openssl.cnf \ -extensions usr_cert -notext -md sha256 \ -in intermediate/csr/bob@example.com.csr.pem \ -out intermediate/certs/bob@example.com.cert.pem Sign the certificate? [y/n]: y 1 out of 1 certificate requests certified, commit? [y/n]: y 

Алиса проверяет, что сертификат действителен:

# openssl verify -CAfile intermediate/certs/ca-chain.cert.pem \ intermediate/certs/bob@example.com.cert.pem bob@example.com.cert.pem: OK 

Файл index.txt должен содержать новую запись.

V 160420124740Z 1001 unknown . /CN=bob@example.com

Алиса посылает Бобу подписанный сертификат. Боб устанавливает сертификат в своем веб-браузере и теперь у него есть доступ к фотографиям котят Алисы. Ура!

К сожалению, выясняется, что Боб себя плохо вел. Боб отправил фотографии котят Алисы в Hacker News, заявляя, что они его и теперь набирает огромную популярность. Алиса это узнает и нуждается в немедленном отзыве его доступа.

# cd /root/ca # openssl ca -config intermediate/openssl.cnf \ -revoke intermediate/certs/bob@example.com.cert.pem Enter pass phrase for intermediate.key.pem: secretpassword Revoking Certificate 1001. Data Base Updated 

Строка в index.txt, которая относится к сертификату Боба теперь начинается с буквы R. Это означает, что он был отозван (Revoked).

R 160420124740Z 150411125310Z 1001 unknown . /CN=bob@example.com

После отзыва сертификата Боба, Алисе необходимо пересоздать CRL.

Ипользование CRL на сервере

Обычно серверное приложение (к примеру, Apache) делает проверку для клиентских сертификатов.Это приложение должно иметь локальный доступ до CRL.

В случае Алисы, она может добавить директиву SSLCARevocationPath в ее конфигурацию Apache и скопировать CRL на свой сервер. В следующий раз, когда Боб подключится к веб-серверу, Apache проверит его клиентский сертификат в CRL и запретит доступ. По аналогии, OpenVPN имеет директиву crl-verify , и можно блокировать клиентов, чьи сертификаты были отозваны.

Использование CRL клиентами

Для серверных сертификатов, обычно клиентское приложение (к примеру, веб-браузер) выполняет проверку. Это приложение должно иметь удаленный доступ к CRL.

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

Точки распространения CRL видны в спецификациях X509v3 сертификата.

# openssl x509 -in cute-kitten-pictures.example.com.cert.pem -noout -text X509v3 CRL Distribution Points: Full Name: URI:http://example.com/intermediate.crl.pem 

Online Certificate Status Protocol

Online Certificate Status Protocol (OCSP) был создан в качестве альтернативы CRL. Как и CRL, OCSP позволяет запрашивающей стороне (к примеру, веб-браузеру) определять статус отзыва сертификата.

Когда центр сертификации подписывает сертификат, он обычно включает адрес сервера OCSP (к примеру, http://ocsp.example.com) в в сертификат. Это похоже на функцию crlDistributionPoints , используемой для CRL.

Например, когда веб-браузеру предоставлен сертификат сервера, он посылает запрос на адрес сервера OCSP, указанном в сертификате. По этому адресу OCSP слушает запросы и отвечает статусом отзыва сертификата.

Рекомендуется использовать OCSP вместо CRL, где это возможно, хотя реально, как правило, OCSP нужен только для сертификатов веб-сайтов. Некоторыми веб-браузерами поддержка CRL считается устаревшей, или вообще убрана.

Подготовка конфигурационного файлы

Для использования OCSP центр сертификации должен закодировать расположение сервера OCSP в сертификат, который он подписывает. Используем опцию authorityInfoAccess в соответствующей секции, в нашем случае в секции server_cert .

[ server_cert ] # . snipped . authorityInfoAccess = OCSP;URI:http://ocsp.example.com 

Создание пары OCSP

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

Создадим частный ключ и зашифруем его алгоритмом AES-256.

# cd /root/ca # openssl genrsa -aes256 \ -out intermediate/private/ocsp.example.com.key.pem 4096 

Создадим запрос на создание сертификата (CSR). Детали должны, как правило, совпадать с подписывающим центром сертификации. Common Name, однако, должен быть полным доменным именем.

# cd /root/ca # openssl req -config intermediate/openssl.cnf -new -sha256 \ -key intermediate/private/ocsp.example.com.key.pem \ -out intermediate/csr/ocsp.example.com.csr.pem Enter pass phrase for intermediate.key.pem: secretpassword You are about to be asked to enter information that will be incorporated into your certificate request. ----- Country Name (2 letter code) [XX]:GB State or Province Name []:England Locality Name []: Organization Name []:Alice Ltd Organizational Unit Name []:Alice Ltd Certificate Authority Common Name []:ocsp.example.com Email Address []: 

Подпишем CSR промежуточным центром сертификации.

# openssl ca -config intermediate/openssl.cnf \ -extensions ocsp -days 375 -notext -md sha256 \ -in intermediate/csr/ocsp.example.com.csr.pem \ -out intermediate/certs/ocsp.example.com.cert.pem 

Проверим, что сертификат содержит коррестные расширения X509v3.

# openssl x509 -noout -text \ -in intermediate/certs/ocsp.example.com.cert.pem X509v3 Key Usage: critical Digital Signature X509v3 Extended Key Usage: critical OCSP Signing 

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

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

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

# cd /root/ca # openssl genrsa -out intermediate/private/test.example.com.key.pem 2048 # openssl req -config intermediate/openssl.cnf \ -key intermediate/private/test.example.com.key.pem \ -new -sha256 -out intermediate/csr/test.example.com.csr.pem # openssl ca -config intermediate/openssl.cnf \ -extensions server_cert -days 375 -notext -md sha256 \ -in intermediate/csr/test.example.com.csr.pem \ -out intermediate/certs/test.example.com.cert.pem 

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

# openssl ocsp -port 127.0.0.1:2560 -text -sha256 \ -index intermediate/index.txt \ -CA intermediate/certs/ca-chain.cert.pem \ -rkey intermediate/private/ocsp.example.com.key.pem \ -rsigner intermediate/certs/ocsp.example.com.cert.pem \ -nrequest 1 Enter pass phrase for ocsp.example.com.key.pem: secretpassword 

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

# openssl ocsp -CAfile intermediate/certs/ca-chain.cert.pem \ -url http://127.0.0.1:2560 -resp_text \ -issuer intermediate/certs/intermediate.cert.pem \ -cert intermediate/certs/test.example.com.cert.pem 

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

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

OCSP Response Data: OCSP Response Status: successful (0x0) Response Type: Basic OCSP Response Version: 1 (0x0) Responder Id: . CN = ocsp.example.com Produced At: Apr 11 12:59:51 2015 GMT Responses: Certificate ID: Hash Algorithm: sha1 Issuer Name Hash: E35979B6D0A973EBE8AEDED75D8C27D67D2A0334 Issuer Key Hash: 69E8EC547F252360E5B6E77261F1D4B921D445E9 Serial Number: 1003 Cert Status: good This Update: Apr 11 12:59:51 2015 GMT 

# openssl ca -config intermediate/openssl.cnf \ -revoke intermediate/certs/test.example.com.cert.pem Enter pass phrase for intermediate.key.pem: secretpassword Revoking Certificate 1003. Data Base Updated 

Как и раньше, запускаем ответчик OCSP в другом терминале и шлем запрос. В этот раз вывод показывает «Cert Status: revoked» и «Revocation Time» .

OCSP Response Data: OCSP Response Status: successful (0x0) Response Type: Basic OCSP Response Version: 1 (0x0) Responder Id: . CN = ocsp.example.com Produced At: Apr 11 13:03:00 2015 GMT Responses: Certificate ID: Hash Algorithm: sha1 Issuer Name Hash: E35979B6D0A973EBE8AEDED75D8C27D67D2A0334 Issuer Key Hash: 69E8EC547F252360E5B6E77261F1D4B921D445E9 Serial Number: 1003 Cert Status: revoked Revocation Time: Apr 11 13:01:09 2015 GMT This Update: Apr 11 13:03:00 2015 GMT