- Что такое сертификат ssl? как работает ssl?
- Apache
- Nginx
- Windows (iis)
- Вариант 1: создать csr
- Вариант 3. создание csr для существующего сертификата и закрытого ключа
- Вариант 4: генерация самоподписанного(self-signed) сертификата
- Вариант 5: генерация самоподписанного сертификата из существующего закрытого ключа и csr
- Выбор цифровой подписи
- Доверенные и недоверенные сертификаты
- Закрытый ключ
- История версий сертификатов шифрования
- Как проверить, установлен ли сертификат
- Как скопировать содержимое файла csr
- Как создать csr
- Как создать сертификат ssl
- Команды openssl для конвертации csr
- Кому не обойтись без ssl-сертификата
- Назначение domain validation — dv
- Обходим проверку сертификата ssl
- Получение и установка ssl-сертификата
- Преобразовать pem csr и закрытый ключ в pkcs12 (.pfx .p12)
- Принцип работы tls и ssl
- Проверить версию openssl
- Продление сертификата – не используйте старые csr повторно
- Система не извлекает закрытый ключ автоматически
- Типы ssl сертификатов шифрования
- Установка
- Установка openssl в debian и ubuntu
- Установка openssl в red hat и centos
- Установка с помощью панелей управления
- Установка соединения ssl/tls на уровне сетевых пакетов
- Расширенная проверка (ev ssl – extended validation)
- Назначение extendet validation — ev
- Заключение
- Как браузеры реализуют отзыв цифровых сертификатов
Что такое сертификат ssl? как работает ssl?
Сертификат Secure Socket Layer (SSL) – это протокол безопасности, который защищает данные между двумя компьютерами с использованием шифрования.
Проще говоря, сертификат SSL – это файл данных, который в цифровом виде связывает криптографический ключ с сервером или доменом, а также с названием и местонахождением организации.
Как правило, сертификаты SSL используются на веб-страницах, которые передают и получают конфиденциальные данные конечного пользователя, такие как номер социального страхования, данные кредитной карты, домашний адрес или пароль. Онлайн формы оплаты являются хорошим примером и обычно шифруют вышеупомянутую деликатную информацию с использованием 128 или 256-битной технологии SSL.
Сертификаты SSL обеспечивают идентификацию удаленного компьютера, чаще всего сервера, но также подтверждают идентификацию вашего компьютера с удаленным компьютером для установления безопасного соединения. Обеспечение безопасности в Интернете всегда было улицей с двусторонним движением, и благодаря SSL-шифрованию сервер «пожимает руку» вашему персональному компьютеру, и обе стороны знают, с кем они общаются.
Apache
При использовании библиотеки OpenSSL в Apache закрытый ключ по умолчанию сохраняется в /usr/local/ssl. Запустите openssl version –a, команду OpenSSL, которая определяет, какую версию OpenSSL вы используете.
Выходные данные будут отображать каталог, который содержит закрытый ключ. Смотрите пример выходных данных ниже:
OpenSSL 1.0.2g 1 Dec 2022 built on: reproducible build, date unspecified platform: debian-amd64 options: bn(64,64) rc4(16x,int) des(idx,cisc,16,int) blowfish(idx) compiler: cc -I. -I.. -I../include -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS - D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -m64 -DL_ENDIAN -g -O2 -fstack-protector- strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -Wl,- Bsymbolic-functions -Wl,-z,relro -Wa,--noexecstack -Wall -DMD32_REG_T=int - DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 - DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM - DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -DECP_NISTZ256_ASM OPENSSLDIR: "/usr/lib/ssl"
Последняя строка OPENSSLDIR определяет путь к файлу. В приведенном примере это местоположение по умолчанию /usr/lib/ssl.
Nginx
Вы сможете найти местоположение личного ключа вашего сервера в файле виртуального хоста вашего домена.
Перейдите к местоположению корневого сервера сайта (обычно это каталог /var/www/) и откройте основной файл конфигурации сайта. Найдите директиву ssl_certificate_key, которая предоставит путь к файлу закрытого ключа.
Если вы не можете найти директиву ssl_certificate_key, возможно, существует отдельный файл конфигурации для деталей SSL. Ищите что-нибудь вроде ssl.conf.
Windows (iis)
На серверах, работающих под управлением Windows Internet Information Services, операционная система сохраняет закрытый ключ в скрытой папке, так же как любая обычная ОС Windows хранит важные системные данные.
Однако, экспортируя файл .pfx, вы можете получить закрытый ключ и сертификаты. Для этого выполните следующие действия:
- Откройте консоль управления MMC (Microsoft Management Console).
- Разверните дерево Сертификаты (локальный компьютер), расположенное в корне консоли.
- Ваш сертификат находится либо в личной папке, либо в папке веб-хостинга. Вы можете идентифицировать каждый сертификат по его Common name (домену)
- Щелкните правой кнопкой мыши сертификат, который вы хотите экспортировать, и выберите Все задачи -> Экспорт.
- Следуйте инструкциям мастера для экспорта файла
.pfx
.
Теперь у вас есть то, что вам нужно, если вы хотите сохранить резервную копию или установить сертификат на другом сервере Windows.
Если вам нужно установить сертификат на другом сервере, который не работает под управлением Windows (например, Apache), вам необходимо сконвертировать файл .pfx и разделить файлы .key и .crt или .cer. Вы можете сделать это с OpenSSL.
Вариант 1: создать csr
Первое, что нужно сделать, – это создать 2048-битную пару ключей RSA локально. Эта пара будет содержать как ваш закрытый, так и открытый ключ. Вы можете использовать инструмент Java key или другой инструмент, но мы будем работать с OpenSSL.
Чтобы создать открытый и закрытый ключ с запросом на подпись сертификата (CSR), выполните следующую команду OpenSSL:
openssl req –out certificatesigningrequest.csr -new -newkey rsa:2048 -nodes -keyout privatekey.key
Что эта команда означает:
openssl
– активирует программное обеспечение OpenSSLreq
– указывает, что мы хотим CSR–out
– указывает имя файла, в котором будет сохранен ваш CSR. У нас в примере этоcertificatesigningrequest.csr
–new –newkey
– создать новый ключrsa:2048
– cгенерировать 2048-битный математический ключ RSA–nodes
– нет DES, то есть не шифровать закрытый ключ в PKCS#12 файл–keyout
– указывает домен, для которого вы генерируете ключ
Далее ваша система должна запустить текстовую анкету для заполнения, которую мы описывали в таблице выше:
Country Name (2 letter code) [AU]: State or Province Name (full name) [Some-State]: Locality Name (eg, city) []: Organization Name (eg, company) [Internet Widgits Pty Ltd]: Organizational Unit Name (eg, section) []: Common Name (e.g. server FQDN or YOUR name) []: Email Address []:
После завершения работы программы вы сможете найти файл CSR в вашем рабочем каталоге. Запрос на подпись сертификата, сгенерированный с помощью OpenSSL, всегда будет иметь формат файла .csr. Чтобы найти в папке все файлы этого формата используйте команду
ls *.csr
Тут будет список всех сертификатов, останется только найти тот, что мы только что сгенерировали.
Также вы можете открыть файл .csr в текстовом редакторе, например nano, чтобы просмотреть сгенерированный буквенно-цифровой код.
sudo nano your_domain.csr
После того, как вы сгенерировали CSR с парой ключей, сложно увидеть, какую информацию она содержит, поскольку она не будет в удобочитаемом формате. Вы можете легко декодировать CSR на своем сервере, используя следующую команду OpenSSL:
openssl req -in server.csr -noout -text
Далее можно декодировать CSR и убедиться, что он содержит правильную информацию о вашей организации, прежде чем он будет отправлен в центр сертификации. В Интернете существует множество CSR-декодеров, которые могут помочь вам сделать то же самое, просто скопировав содержимое файла CSR, например sslshopper.
Вариант 3. создание csr для существующего сертификата и закрытого ключа
openssl x509 -x509toreq -in certificate.crt -out CSR.csr -signkey privateKey.key
Один маловероятный сценарий, в котором это может пригодиться, – это если вам нужно обновить существующий сертификат, но ни у вас, ни у вашего центра сертификации нет первоначального CSR. Это позволит извлечь информацию о вашем домене и организации из сертификата SSL и использовать его для создания нового CSR, что позволит вам сэкономить время. Параметр -x509toreq преобразует сертификат в запрос сертификата.
Вариант 4: генерация самоподписанного(self-signed) сертификата
Самозаверяющий сертификат обычно используется для сред тестирования и разработки, а также в интрасети. Давайте создадим самозаверяющий сертификат, используя следующую команду OpenSSL:
openssl req -newkey rsa:2048 -nodes -keyout domain.key-x509 -days 365 -out domain.crt
Параметр –days установлен на 365, что означает, что сертификат действителен в течение следующих 365 дней. Параметр x509 указывает, что это будет самозаверяющий сертификат. Временный CSR генерируется, и он используется только для сбора необходимой информации. Если вы не хотите защищать свой закрытый ключ паролем, вы можете добавить параметр –nodes.
Центры сертификации не проверяют самоподписанные сертификаты. Таким образом, они не так безопасны, как проверенные сертификаты. Если ЦС не подписал сертификат, каждый основной браузер отобразит сообщение об ошибке «Ненадежный сертификат», как показано на рисунке ниже.
Вариант 5: генерация самоподписанного сертификата из существующего закрытого ключа и csr
Если у вас уже есть CSR и закрытый ключ и вам нужно создать самозаверяющий сертификат, используйте следующую команду:
openssl x509 -signkey domain.key -in domain.csr -req -days 365 -out domain.crt
Параметр –days установлен на 365, что означает, что сертификат действителен в течение следующих 365 дней.
Выбор цифровой подписи
Какой SSL-сертификат выбрать, в первую очередь, зависит от владельца ресурса. Для физических лиц подойдет тип DV, который является подтверждением права на владение доменным именем.
Для компаний дело обстоит несколько сложнее:
- Если это сайт-визитка, цель которого — проинформировать о деятельности организации, то можно установить DV SSL. Он предотвратит появление всплывающего в браузере окна с информацией о небезопасности площадки и надежно закодирует данные. Обычно предоставляется бесплатно.
- Ресурсы, которые связаны с транзакциями и другими видами доступа к деньгам, должны подключить EV подпись. Она подтвердит подлинность компании, а в браузерной строке появится полоска зеленого цвета с названием фирмы. Это касается банков, СМИ, платежных систем.
- Интернет-магазины, форумы и благотворительные платформы должны позаботиться об установке OV SSL. Такие сайты практически не находятся в поле зрения злоумышленников. Однако пользователи захотят удостовериться в подлинности компании, где они планируют сделать заказ или куда собираются вложить свои деньги. SSL-сертификаты с проверкой организации предоставляются только платно.
Доверенные и недоверенные сертификаты
Главным источником SSL-сертификатов служат доверенные центры сертификации или удостоверяющие центры (Certification authority, CA). Это организации, имеющие неоспоримый авторитет на рынке IT-услуг и пользующиеся известным открытым криптографическим ключём. В браузерах их список обычно можно посмотреть в разделе «Доверенные корневые центры сертификации».
Цифровая подпись, заверенная сертификатом такого центра, является доказательством подлинности компании, которой принадлежит доменное имя, и обуславливает право владельца законно использовать секретный ключ. Она называется доверенной.
К недоверенным подписям относятся:
- Самоподписанный сертификат, который владелец сайта выдает себе сам. Он также обеспечивает безопасность соединения, но при этом не является гарантией подлинности компании. В этом случае браузер будет предупреждать посетителя, что SSL не надежен.
- Сертификат, который подписан недоверенным центром. В этом случае ресурс будет считаться проверенным, однако «проверяющий» остается под сомнением. Обычно такие центры продают сертификаты абсолютно всем, не проверяя подлинность фирмы.
- Цифровая подпись, выданная центром, который потерял доверие. К этому разряду относятся, например, SSL-сертификаты от удостоверяющего центра Symantec, которую Google обвинил в выдаче большого числа неликвидных сертификатов. В браузере Google Chrome 70 была прекращена поддержка сертификатов, выпущенных этой компаний и аффилированными с ней центрами GeoTrust и Thawte до 1 декабря 2022 года.
SSL сертификаты Eternalhost — выгодный способ получить электронную цифровую подпись от 100% надёжного Удостоверяющего Центра.
Закрытый ключ
Закрытый ключ кодируется и создается в формате PEM на основе Base-64, который не читается человеком. Вы можете открыть его в любом текстовом редакторе, но все, что вы увидите, это несколько десятков строк, которые кажутся случайными символами, заключенными в открывающие и закрывающие заголовки. Ниже приведен пример закрытого ключа:
-----BEGIN RSA PRIVATE KEY----- MIICXAIBAAKBgQCVqGpH2S7F0CbEmQBgmbiDiOOGxhVwlG yY/6OBQoPKcx4Jv2h vLz7r54ngjaIqnqRNP7ljKjFLp5zhnAu9GsdwXbgLPtrmMSB MVFHTJvKjQ eY9p dWA3NbQusM9uf8dArm 3VrZxNHQbVGXOIAPNHTO08cZHMSqIDQ6OvLma7wIDAQAB AoGAbxKPzsNh826JV2A253svdnAibeSWBPgl7kBIrR8QWDCtkH9fvqpVmHa 6pO5 5bShQyQSCkxa9f2jnBorKK4 0K412TBM/SG6Zjw DsZd6VuoZ7P027msTWQrMBxg Hjgs7FSFtj76HQ0OZxFeZ8BkIYq0w 7VQYAPBWEPSqCRQAECQQDv09M4PyRVWSQM S8Rmf/jBWmRnY1gPPEOZDOiSWJqIBZUBznvOPOOQSH6B vee/q5edQA2OIaDgNmn AurEtUaRAkEAn7/65w Tewr89mOM0RKMVpFpwNfGYAj3kT1mFEYDq iNWdcSE6xE 2H0w3YEbDsSayxc36efFnmr//4ljt4iJfwJAa1pOeicJhIracAaaa6dtGl/0AbOe f3NibugwUxIGWkzlXmGnWbI3yyYoOta0cR9fvjhxV9QFomfTBcdwf40FgQJAH3MG DBMO77w8DK2QfWBvbGN4NFTGYwWg52D1Bay68E759OPYVTMm4o/S3Oib0Q53gt/x TAUq7IMYHtCHZwxkNQJBAORwE 6qVIv/ZSP2tHLYf8DGOhEBJtQcVjE7PfUjAbH5 lr 9qUfv0S13gXj5weio5dzgEXwWdX2YSL/asz5DhU= -----END RSA PRIVATE KEY-----
В большинстве случаев вам не нужно импортировать код закрытого ключа в файловую систему сервера, так как он будет создан в фоновом режиме, пока вы создаете CSR, а затем автоматически сохраняется на сервере. Во время установки SSL-сертификата система извлекает ключ.
История версий сертификатов шифрования
Всегда нужно знать историю, как сертификат шифрования эволюционировал и какие у него выходили версии. Так как зная это и принцип работы, будет проще искать решение проблем.
- SSL 1.0 > данная версия в народ так и не попала, причины, возможно нашли его уязвимость
- SSL 2.0 > эта версия ssl сертификата была представлена в 1995 году, на стыке тысячелетий, она так же была с кучей дыр безопасности, сподвигнувшие компанию Netscape Communications к работе над третье версией сертификата шифрования
- SSL 3.0 > пришел на смену SSL 2.0 в 1996 году. Стало это чудо развиваться и в 1999 году крупные компании Master Card и Visa купили коммерческую лицензию на его использование. Из 3.0 версии появился TLS 1.0
- TLS 1.0 > 99 год, выходит обновление SSL 3.0 под названием TLS 1.0, проходит еще семь лет, интернет развивается и хакеры не стоят на месте, выходит следующая версия.
- TLS 1.1 > 04.2006 это его отправная точка, было исправлено несколько критичных ошибок обработки, а так же появилась защита от атак, где делался режим сцепления блоков шифротекста
- TLS 1.2 > появился в августе 2008
- TLS 1.3 > появится в конце 2022 года
Как проверить, установлен ли сертификат
Чтобы проверить правильность установки сертификата, воспользуйтесь сервисом SSLShopper, SSL4Less или SSL Labs — они работают по одинаковому принципу, и покажут, защищён ли ваш сайт.
Как скопировать содержимое файла csr
Откройте каталог, в котором находится ваш CSR-файл. Введите следующую команду:
sudo cat domain.csr
Замените domain параметром FQDN вашего CSR. Эта команда отобразит содержимое файла CSR. Скопируйте весь контент, начиная с BEGIN CERTIFICATE REQUEST и заканчивая END CERTIFICATE REQUEST.
Как создать csr
Запросы на подпись сертификата (CSR) создаются с помощью пары ключей – открытого и закрытого ключа. Только открытый ключ отправляется в центр сертификации и включается в сертификат SSL, и он работает вместе с вашим личным ключом для шифрования соединения. Любой может иметь доступ к вашему открытому ключу, и он проверяет подлинность SSL-сертификата.
Закрытый ключ – это блок закодированного текста, который вместе с сертификатом проверяет безопасное соединение между двумя компьютерами. Он не должен быть общедоступным, и его не следует отправлять в ЦС.
Целостность сертификата зависит от того, что только вы знаете закрытый ключ. Если вы когда-либо скомпрометированы или утеряны, как можно скорее введите новый сертификат с новым закрытым ключом. Большинство ЦС не взимают плату за эту услугу.
Большинство пар ключей состоят из 2048 битов. Хотя пары ключей длиной 4096 бит более безопасны, они замедляют SSL-рукопожатия и создают нагрузку на серверные процессоры. Из-за этого большинство сайтов по-прежнему используют 2048-битные пары ключей.
Как создать сертификат ssl
То, как сгенерировать запрос на подпись сертификата (CSR), зависит исключительно от платформы, которую вы используете, и конкретного выбранного вами инструмента.
Мы будем генерировать CSR с использованием OpenSSL.
OpenSSL – это широко используемый инструмент для работы с CSR-файлами и SSL-сертификатами, который можно загрузить с официального сайта OpenSSL. Это инструмент реализации с открытым исходным кодом для SSL/TLS, который используется примерно на 65% всех активных интернет-серверов, что делает его неофициальным отраслевым стандартом.
Команды openssl для конвертации csr
Если вы работаете с серверами Apache, запросы на подпись сертификатов (CSR) и ключи хранятся в формате PEM. Но что, если вы хотите перенести CSR на сервер Tomcat или Windows IIS? Вам придется конвертировать стандартный файл PEM в файл PFX. Следующие команды помогут вам сделать это.
Примечание: Используйте параметр -nodes
, если вы не хотите шифровать файл .key
. Если вы не используете этот параметр, вам нужно будет указать пароль.
Кому не обойтись без ssl-сертификата
Предоставляя данные о своих банковских картах, контактную и личную информацию, пользователь должен быть уверен, что они не попадут в руки третьего лица. Поэтому получение SSL-сертификата — важный пункт для интернет-магазинов, а также банков, платежных систем и площадок, где требуется создание аккаунта.
Для SEO-специалистов, которые учитывают малейшие аспекты продвижения, также рекомендуется подключение подписи. Хотя на данный момент этот фактор слабо влияет на ранжирование страниц.
А вот чисто информационным ресурсам — блогам, визиткам и личным страницам можно обойтись и без сертификации.
Назначение domain validation — dv
И так сертификаты шифрования, подтверждающие только домен ресурса, это самые распространенные в сети сертификаты, их делают всех быстрее, автоматически. Когда вам нужно проверить такой сертификат безопасности, отправляется email с гиперссылкой, кликая по которой подтверждается выпуск серта.
approver email так же имеет требования, логично, что если вы заказываете сертификаты шифрования для домена, то и электронный ящик должен быть из него, а не mail или rambler, либо он должен быть указан в whois домена и еще одно требование название approver email, должно быть по такому шаблону:
Я обычно беру ящик postmaster@ваш домен
Сертификат tls-ssl подтверждающие доменное имя выпускаются, когда CA произвел валидацию того, что заказчик обладает правами на доменное имя, все остальное, что касается организации в сертификате не отображается.
Обходим проверку сертификата ssl
В этом кратком обзоре я хотел бы поделиться своим опытом, как отключить проверку SSL для тестовых сайтов, иначе говоря, как сделать HTTPS сайты доступными для тестирования на локальных машинах.
В современное время https протокол становится все популярней, у него масса плюсов и достоинств, что хорошо. Правда для разработчиков он может вызывать легкий дискомфорт в процессе тестирования.
Всем известно, что при посещении сайта у которого “временно” что-то случилось c сертификатом вы обнаружите предупреждение, которое показывается, если сертификат безопасности не является доверенным net::ERR_CERT_AUTHORITY_INVALID?
Привет онлайн-кинотеатрам
Все современные браузеры показывают сообщение об ошибке HSTS
Самый простой способ обхода данного запрета — это, разумеется, нажатие на вкладку “Дополнительные” и согласиться с Небезопасным режимом.
Но не во всех браузерах как оказывается, есть данная возможность. Так я столкнулся с данной проблемой в Chrome на Mac OS
Разработчики данной операционной системы настолько обеспокоены безопасностью пользователей, что даже убрали доступ в «Небезопасном режиме» к сайту, несмотря на то, что это сайт владельца устройства.
Ну что ж, поскольку, вести разработку в других, более сговорчивых браузерах было не комфортно, вот способы как обойти эту проблему:
— Все хромоподобные браузеры (Chrome, Opera, Edge …) могут открыть небезопасную веб страницу, если на английской раскладке клавиатуры набрать фразу:
thisisunsafe
прямо на данной веб странице. Это даст возможность работать с сайтом без оповещение об ошибке на момент текущей сессии браузера, пока вы не закроете вкладку Chrome.
— Если же вам предстоит более длительная работа с сайтом, то рекомендую для этих нужд создать отдельного тестового пользователя на рабочем столе и указать ему необходимы флаги.
Для Windows
C:Program Files (x86)GoogleChromeApplicationchrome.exe" --ignore-certificate-errors
Для Mac OS
/Applications/Google Chrome.app/Contents/MacOS/Google Chrome --ignore-certificate-errors --ignore-urlfetcher-cert-requests &> /dev/null
Achtung! Данные манипуляции необходимо выполнять с выключенным Chrome приложением, иначе чуда не произойдет.
Если вы оставите сертификат ненадежным, то некоторые вещи не будут работать. Например, кэширование полностью игнорируется для ненадежных сертификатов.
Браузер напомнит, что вы находитесь в небезопасном режиме. Поэтому крайне не рекомендуется шастать по злачным сайтам Интернета с такими правами доступами.
*Так же есть метод с добавлением сертификатов тестируемого сайта в конфиги браузера Настройки->Безопасность->Настроить сертификаты->Импорт… но мне он показался не продуктивным и очень муторным, поэтому не привожу
Надеюсь моя краткая статья кому-то пригодится при разработке и тестировании сайтов =)
Получение и установка ssl-сертификата
Чтобы получить цифровую подпись, необходимо зайти на сайт центра сертификации и предоставить необходимую информацию для данного типа цифровой подписи. Например, для получения DV SSL достаточно предоставить доменное имя, email и номер телефона. Для других разновидностей могут понадобится документы, которые подтверждают наличие юридического лица: ИНН, сведения из ЕГРЮЛ и прочее.
После активации, ссылка на которую придет на указанную почту, следует дождаться окончания проверки. Этот процесс может занять от десятка минут до нескольких суток, после чего на e-mail придет архив с сертификатом, который требуется установить на сайт.
Преобразовать pem csr и закрытый ключ в pkcs12 (.pfx .p12)
Файлы FKCS12 используются для экспорта или импорта сертификатов в Windows IIS.
openssl pkcs12 -inkey domain.key -in domain.crt -export -out domain.pfx
Эта команда возьмет закрытый ключ и CSR и преобразует его в один файл .pfx. Вы можете настроить экспортную фразу-пароль, но также можете оставить это поле пустым. Обратите внимание, что, объединив строки символов сертификата в конец одного файла PEM, вы можете экспортировать цепочку сертификатов в формат файла .pfx.
Принцип работы tls и ssl
Давайте разбираться как работает протоколы SSL и TLS. Начнем с основ, все сетевые устройства имеют четко прописанный алгоритм общения друг с другом, называется он OSI, который порезан на 7 уровней. В ней есть транспортный уровень отвечающий за доставку данных, но так как модель OSI это некая утопия, то сейчас все работаю по упрощенной модели TCP/IP, из 4 уровней.
Список можно продолжать очень долго, так их более 200 наименований. Ниже представлена схема сетевых уровней.
Ну и схема стека SSL/TLS, для наглядности.
Проверить версию openssl
Эта команда отображает версию OpenSSL, и ее параметры, с которыми она была скомпилирована:
openssl version -a
Получим примерно такой вывод:
OpenSSL 1.0.1f 6 Jan 2022 built on: Mon Apr 7 21:22:23 UTC 2022 platform: debian-amd64 options: bn(64,64) rc4(16x,int) des(idx,cisc,16,int) blowfish(idx) compiler: cc -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -m64 -DL_ENDIAN -DTERMIO -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -Wl,-Bsymbolic-functions -Wl,-z,relro -Wa,--noexecstack -Wall -DMD32_REG_T=int -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM OPENSSLDIR: "/usr/lib/ssl"
Продление сертификата – не используйте старые csr повторно
То, что некоторые веб-серверы позволяют использовать старые CSR для обновления сертификатов, не означает, что вы должны их использовать. В качестве меры безопасности всегда генерируйте новый CSR и закрытый ключ при обновлении сертификата. Привязка к одному и тому же секретному ключу – это дорога, вымощенная уязвимостями безопасности.
Также рекомендуется обновить SSL-сертификат до истечения срока его действия. В противном случае потребуется покупать новый сертификат.
Система не извлекает закрытый ключ автоматически
Некоторые системы не автоматизируют процедуру извлечения закрытого ключа. Кроме того, если вам нужно установить существующий сертификат на другом сервере, вы, очевидно, не можете ожидать, что он получит закрытый ключ. Основная сложность здесь заключается в том, как найти точное местоположение ключа.
Типы ssl сертификатов шифрования
Следующим важным вопросом, будет какие типы SSL – TLS сертификатов шифрования существуют, и их отличия и стоимость.
- Обычные SSL сертификаты > это самые распространенные сертификаты, делаются автоматически, для подтверждения только домена. Стоят в среднем 18-22 доллара.
- SGC сертификаты > это SSL – TLS сертификаты с поддержкой, более высокого уровня шифрования. Они в основном идут для старперных браузеров, у которых есть поддержка только 40-56 битное шифрование. SGC принудительно повышает уровень шифрования , до 128 бит, что в несколько раз выше. Так как XP доживает свои последние годы, скоро SGC сертификаты шифрования не будут нужны. Стоит это чудо около 300-ста баксов за год.
- Wildcard сертификаты > Требуются, для субдоменов вашего основного домена. Простой пример мой блог pyatilistnik.org, если я покупаю Wildcard, то имею возможно его вешать на все домены 4 уровня у себя, *.pyatilistnik.org. Стоимость Wildcard сертификатов шифрования варьируется от количества поддоменов, от 190 баксов.
- SAN сертификаты > Допустим у вас есть один сервер, но на нем хостятся много разных доменов, вот SAN сертификат можно повесить на сервер и все домены будут использовать его, стоит от 400 баксов в год.
- EV сертификаты > про расширенные мы уже все обсудили выше, стоят от 250 баксов в год.
- Сертификаты c поддержкой IDN доменов
список сертификатов, у которых есть такая поддержка, IDN доменов:
Установка
После заказа сертификата в сертификационном центре ваша заявка обрабатывается какое-то время, после чего вам пришлют все необходимые файлы. Данные для установки сертификата обычно присылаются по электронной почте. Иногда сертификат можно установить прямо через форму на сайте сертификационного центра. В противном случае у вас есть ещё два варианта.
Установка openssl в debian и ubuntu
Сначала проверим, установлена ли у нас утилита OpenSSL при помощи команды:
dpkg -l |grep openssl
Если пакет OpenSSL установлен, мы получим следующий результат:
ii libgnutls-openssl27:amd64 2.12.23-12ubuntu2.4 amd64 GNU TLS library - OpenSSL wrapper ii openssl 1.0.1f-1ubuntu2.16 amd64 Secure Sockets Layer toolkit - cryptographic utility
Если вы не видите такого результата, выполните следующую команду для установки OpenSSL:
apt-get install openssl
Установка openssl в red hat и centos
Red Hat (версия 7.0 и более поздние) должна поставляться с предустановленной ограниченной версией OpenSSL. Он предлагает только ограниченную поддержку для IDEA, RC5 и MDC2, поэтому вы можете установить недостающие функции.
Чтобы проверить, установлен ли OpenSSL на сервере yum (например, Red Hat или CentOS), выполните следующую команду:
rpm -qa | grep -i openssl
Эта команда должна вернуть следующий результат:
openssl-1.0.1e-48.el6_8.1.x86_64 openssl-devel-1.0.1e-48.el6_8.1.x86_64 openssl-1.0.1e-48.el6_8.1.i686
Если ваш формат вывода отличается, это означает, что OpenSSL не установлен на вашем сервере. Выполните следующую команду для установки OpenSSL:
yum install openssl openssl-devel
Установка с помощью панелей управления
Через ISPmanager
- Для начала необходимо зайти в ISPmanager через пользователя — владельца домена:
ISPmanager → «Пользователи» → выбрать пользователя → «Вход»
- Необходимо также включить SSL для владельца домена:
ISPmanager → «Пользователи» → двойной клик по нужному пользователю → «Права»
- Затем непосредственно добавляем сертификат:
«World Wide Web» → «SSL-сертификаты» → «Создать»
- Необходимо заполнить поля:
«Тип сертификата» — существующий;
«Имя сертификата»— любое имя на ваш выбор. Под этим именем он будет отображаться в системе;
«Приватный ключ» — ключ, высланный вам сертификационным центром;
«Сертификат» — содержимое файла-сертификата, также высылается сертификационным центром;
«Пароль» — указывается в тех случаях, когда он есть, иначе поле оставить пустым;
«Цепочка сертификатов» — здесь необходимо указать всю цепочку сертификатов, которыми подписан ваш сертификат, т.е. промежуточные сертификаты и корневой;
Нажимаем «Ок»
- Включить сертификат:
«WWW домены» → двойной клик на домене → галочка на «SSL» → выбрать нужный сертификат из списка
Через Parallels Plesk
- Заходим в менеджер и добавляем сертификат:
Parallels Plesk → «Сайты и домены» → «Развернуть» → «Настройки SSL» → «Добавить SSL-сертификат»
- Заполняем поля:
«Имя сертификата»— любое имя на ваш выбор. Под этим именем он будет отображаться в системе
- Листаем страницу до «Загрузить сертификат как текст» и продолжаем заполнять:
«Закрытый ключ» — ключ, высланный вам сертификационным центром;
«Сертификат» — содержимое файла-сертификата, также высылается сертификационным центром;
«Корневой сертификат» — здесь необходимо указать всю цепочку сертификатов, которыми подписан ваш сертификат, т.е. промежуточные сертификаты и корневой;
Нажимаем «Отправить текст», после чего вы получите сообщение о том, что сертификат был успешно добавлен
- Включить сертификат:
«Сайты и домены» → «Настройки хостинга» → «Безопасность» → галочка на «Поддержка SSL» → выбрать сертификат
Через cPanel
- Выбираем домен, для которого устанавливаем сертификат:
cPanel → «Безопасность» → «SSL/TLS» → «Управление сайтами с SSL» → выбрать домен, для которого устанавливается сертификат
- Заполнить поля:
«Сертификат» — содержимое файла-сертификата, также высылается сертификационным центром;
«Закрытый ключ» — ключ, высланный вам сертификационным центром;
«Пакет центра сертификации» — здесь необходимо указать всю цепочку сертификатов, которыми подписан ваш сертификат, т.е. промежуточные сертификаты и корневой;
«Включить SNI для почтовых служб» — поставить галочку в случае, если у вас нет дополнительных IP-адресов;
Нажимаем «Установить сертификат» и в открывшемся окне нажимаем «Ок»
Установка соединения ssl/tls на уровне сетевых пакетов
На иллюстрации, черные стрелки показывают сообщения, которые отправляются открытым текстом, синие – это сообщения, подписанные открытым ключом, а зеленые – это сообщения, отправленные с помощью шифрования объёмных данных и того MAC, о которых стороны договорились в процессе переговоров.
Ну и подробно про каждый этап обмена сетевых сообщений протоколов SSL/TLS.
- 1. ClientHello > пакет ClientHello делает предложение со списком поддерживаемых версий протоколов, поддерживаемые наборы шифров в порядке предпочтения и список алгоритмов сжатия (обычно NULL). Еще от клиента приходит случайное значение 32 байта, его содержимое указывает отметку текущего времени, его позже будут использовать для симметричного ключа и идентификатора сессии, который будет иметь значение ноль, при условии, что не было предыдущих сессий.
- 2. ServerHello > пакет ServerHello, отсылается сервером, в данном сообщении идет выбранный вариант, алгоритма шифрования и сжатия. Тут так же будет случайное значение 32 байта (отметка текущего времени), его также используют для симметричных ключей. Если ID текущей сессии в ServerHello имеет значение ноль, то создаст и вернёт идентификатор сессии. Если в сообщении ClientHello был предложен идентификатор предыдущей сессии, известный данному серверу, то протокол рукопожатия будет проведён по упрощённой схеме. Если клиент предложил неизвестный серверу идентификатор сессии, сервер возвращает новый идентификатор сессии и протокол рукопожатия проводится по полной схеме.
- 3.Certificate (3) > в данном пакете сервер отправляет клиенту свой открытый ключ (сертификат X.509), он совпадает с алгоритмом обмена ключами в выбранном наборе шифров. Вообще можно сказать в протоколе, запроси открытый ключ в DNS, запись типа KEY/TLSA RR. Как я писал выше этим ключом будет шифроваться сообщение.
- 4. ServerHelloDone > Сервер говорит, что сессия установилось нормально.
- 5. ClientKeyExchange > Следующим шагом идет отсылка клиентом ключа pre-master key, используя случайные числа (или отметки текущего времени) сервера и клиента. Данный ключ (pre-master key) как раз и шифруется открытым ключом сервера. Данное сообщение может расшифровать только сервер, с помощью закрытого ключа. Теперь оба участника вычисляют общий секретный ключ master key из ключа pre-master.
- 6. ChangeCipherSpec — клиент > смысл пакета, указать на то, что теперь весь трафик, который идет от клиента, будет шифроваться, с помощью выбранного алгоритма шифрования объёмных данных и будет содержать MAC, вычисленный по выбранному алгоритму.
- 7. Finished — клиент > Это сообщение содержит все сообщения, отправленные и полученные во время протокола рукопожатия, за исключением сообщения Finished. Оно шифруется с помощью алгоритма шифрования объемных данных и хэшируется с помощью алгоритма MAC, о которых договорились стороны. Если сервер может расшифровать и верифицировать это сообщение (содержащее все предыдущие сообщения), используя независимо вычисленный им сеансовый ключ, значит диалог был успешным. Если же нет, на этом месте сервер прерывает сессию и отправляет сообщение Alert с некоторой (возможно, неконкретной) информацией об ошибке
- 8. ChangeCipherSpec — сервер > пакет, говорит, что теперь весь исходящий трафик с данного сервера, будет шифроваться.
- 9.Finished — сервер > Это сообщение содержит все сообщения, отправленные и полученные во время протокола рукопожатия, за исключением сообщения Finished
- 10. Record Protocol (протокол записи) > теперь все сообщения шифруются ssl сертификатом безопасности
Расширенная проверка (ev ssl – extended validation)
Центр сертификации проверяет право собственности на домен и проводит тщательное расследование организации, связанной с сертификатом EV. При рассмотрении расширенного запроса проверки соблюдаются строгие правила, и центр сертификации должен проверить следующее:
- Информация об организации соответствует официальным данным
- Физическое, юридическое и эксплуатационное существование субъекта
- Организация имеет исключительные права на использование домена, указанного в сертификате SSL
- Организация надлежащим образом санкционировала выдачу сертификата EV SSL
Назначение extendet validation — ev
И так, вы направили CSR запрос на выпуск сертификата шифрования для вашей организации, CA начинает проверять, реально ли ИП рога и копыта существуют, как в CSR и принадлежит ли ей домен указанный в заказе.
- Могут посмотреть есть ли организация международных желтых страницах, кто не знает, что это такое, то это телефонные справочники в Америке. Проверяют так не все CA.
- Смотрят whois домена у вашей организации, делают это все центры сертификации, если в whois нет ни слова о вашей организации, то с вас будут требовать гарантийное письмо, что домен ваш.
- Свидетельство о государственной регистрации ЕГРИП или ЕГРЮЛ
- Могут проверить ваш номер телефона, запросив счет у вашей телефонной компании, в котором будет фигурировать номер.
- Могут позвонить и проверить наличие компании по этому номеру, попросят к телефону человека указанного администратором в заказе, так что смотрите, чтобы человек знал английский.
Сам сертификат шифрования extendet Validation — EV, самый дорогой и получается всех сложнее, у них кстати есть green bar, вы его точно видели, это когда на сайте в адресной строке посетитель видит зеленую стоку с названием организации. Вот пример клиент банка от сбербанка.
К расширенным сертификатам шифрования (extendet Validation — EV) самое большое доверие, это и логично вы сразу видите, что компания существует и прошла жесткие требования к выдаче сертификата. SSL cертификаты extendet Validatio делаются CA, только при выполнении двух требований, что организация владеет нужным доменом и, что она сама существует в природе. При выпуске EV SSL сертификатов, существует строгий регламент, в котором описаны требования перед выпуском EV сертификата
SSL cертификаты extendet Validatio выпускаются примерно от 10-14 дней, подходят как для некоммерческих организаций, так и для государственных учреждений.
Заключение
Использование SSL-сертификата повышает доверие пользователей к вашему сайту. Это стоит учитывать владельцам интернет-магазинов, банковских и платежных систем, а также площадок, где посетителям требуется предоставить свои персональные данные для создания аккаунта. Однако важно понимать, что цифровая подпись не является стопроцентной гарантией защиты от хакерских или DDoS-атак.
Как браузеры реализуют отзыв цифровых сертификатов
В нашем
посте
, посвященном уязвимости Heartbleed, мы указывали, что одной из дополнительных мер безопасности при работе с HTTPS подключением является включенная в браузере опция проверки отозванного цифрового сертификата. Для Heartbleed это особенно актуально, так как после обновления уязвимой версии OpenSSL на сервере, специалистам компании необходимо заново получить новый приватный ключ (SSL/TLS) и сгенерировать новый сертификат, а старый отозвать. Браузеры должны различать подобные ситуации (использования в HTTPS отозванного цифрового сертификата) и уведомлять своих пользователей о том, что используемое ими соединение с сервером уже не является доверенным.
Цифровые сертификаты SSL или TLS используются для привязки криптографического открытого ключа к информации об организации (компании, сервисе и т. д.). Таким образом, будучи выданным центром сертификации (Certification Authority), он гарантирует клиенту этой организации, что используемый открытый ключ шифрования принадлежит именно этой организации. Безопасное HTTPS соединение использует преимущество такой системы шифрования с открытым ключом, при которой сертификаты SSL/TLS, а также закрытый ключ сервера, используются для установки полностью безопасного подключения, которому пользователь может безоговорочно доверять при передаче своих данных.
Ранее уже публиковалась информация о том, что исследователям с использованием уязвимости Heartbleed удалось успешно скомпрометировать такие защищенные сервисы как CloudFlare, OpenVPN, а также, Yahoo mail. Похитив секретный ключ атакующие могут расшифровать данные пользовательских сессий и позднее представиться сервером, при этом пользователь будет думать, что работает с легитимным источником. В таком случае, сам сертификат открытого ключа является скомпрометированным и CA, который выдал сертификат, не может гарантировать, что пользователь работает с настоящим сервером.
Рис. Перевыпущенный Yahoo цифровой сертификат.
Когда на сервере выполнено обновление одной из уязвимых версий OpenSSL до необходимой 1.0.1g, был получен новый сертификат открытого ключа (и соответствующий ему закрытый ключ сервера), старый сертификат отозван, а пользователь сменил пароль на свой аккаунт, он все равно может оставаться уязвим, работая со своим браузером. Мы указывали, что злоумышленники могут позднее использовать похищенный закрытый ключ для того, чтобы представиться сервером или организовать атаку типа Man-in-the-Middle, скомпрометировав таким образом HTTPS. Так может произойти потому, что используемый браузер не обновил информацию об отозванном цифровом сертификате и продолжает считать его доверенным.
Существуют два основных способа, с помощью которых браузер может проверить информацию о состоянии сертификата (т. е. является ли он действительным или отозванным): протокол получения статуса сертификата (Online Certificate Status Protocol, OCSP) и список отозванных сертификатов (Certificate Revocation List, CRL). Через OCSP клиент может получить информацию от CA о статусе сертификата перед созданием HTTPS подключения с соответствующим сервером. CRL содержит список отозванных цифровых сертификатов, причем этот список кэшируется браузером в процессе работы.
Google Chrome
В феврале 2022 г., Google отключил проверку отозванных цифровых сертификатов для Chrome в новых версиях браузера. Такое решение было обусловлено медленностью и временными задержками, которые необходимы для обработки запроса получения статуса сертификата через OCSP. Проверка статуса занимала около 300 миллисекунд или почти секунду для каждого нового HTTPS подключения. В Google также посчитали, что такая задержка может препятствовать переходу сервисов на использование HTTPS из-за того, что мало кому из их клиентов понравилась бы такая задержка при каждом подключении к серверу (установке нового подключения). Также компания отказалась от постоянного контроля статуса сертификатов, поскольку исследования показали, что большинство сертификатов были отозваны не из-за их компрометации со стороны злоумышленников, а из-за иных административных решений компаний.
Браузер проверяет статус сертификатов с использованием списков отозванных сертификатов CRL (набор CRL), но такая практика связана с кэшированием, и браузер не будет иметь самую свежую информацию об используемых сертификатах. Для того, чтобы включить своевременную проверку цифровых сертификатов перед их использованием в HTTPS, в настройках браузера необходимо установить опцию «Проверять, не отозван ли сертификат сервера». По умолчанию эта опция отключена. Когда эта настройка активирована, браузер будет использовать упоминавшиеся OCSP запросы для проверки статусов сертификатов при попытке установить новое HTTPS подключение. Браузер не позволит пользователю просматривать веб-страницу с отозванным сертификатом, отобразив соответствующее предупреждение.
Рис. Настройка Google Chrome.
Mozilla Firefox
Разработчики Firefox отказались от постоянной проверки статуса сертификатов с использованием списков CRL в последних версиях браузера, вместо этого там используется протокол OCSP, который включен по умолчанию. В то же время, списки CRL в браузере все еще присутствуют и информация для них обновляется на регулярной основе (асинхронно, вне зависимости от устанавливаемых подключений, через т. н. механизм Revocation List Push). Также как и Chrome, Firefox предупреждает пользователя об использовании сервером отозванного сертификата, блокируя таким образом доступ пользователя к запрашиваемой странице. Как видно на скриншоте ниже, браузер содержит опцию «При ошибке соединения с сервером OCSP рассматривать сертификат как недействительный», которая по умолчанию выключена. Таким образом в случае, если запрашиваемый CA недоступен, для проверки статуса сертификата, пользователь получит сообщение об ошибке при работе с любым сертификатом, так как невозможно утверждать является ли он действительным или отозванным.
Рис. Соответствующая опция проверки статуса цифрового сертификата с Mozilla Firefox.
MS Internet Explorer
Поведение браузера зависит от соответствующей версии и используемой ОС. На современных выпусках Windows 7 и Windows 8 Internet Explorer (начиная с 8-й версии) поддерживает проверку сертификатов новых подключений через OCSP, а также использует списки CRL в качестве запасного варианта. По умолчанию для проверки статуса сертификата используется OCSP. Как Google Chrome и Mozilla Firefox, Internet Explorer не разрешает пользователю просматривать веб-страницы, для подключения к которым используется отозванный цифровой сертификат.
Рис. Настройка проверки отозванных сертификатов в IE 8 на Windows 7 (включено по умолчанию).
Apple Safari
Этот браузер не имеет встроенных механизмов проверки отозванных сертификатов. Вместо этого он использует т. н. Apple Keychain Access. Настройки, связанные с проверкой отозванных сертификатов, находятся в меню «Настройки»->«Сертификаты». Настройка «Лучшая попытка» используется для задания проверок сертификатов с помощью проверок OCSP и CRL. По умолчанию проверка сертификатов отключена. В отличие от трех вышеупомянутых браузеров, Safari позволяет пользователю пропустить предупреждение об отозванном сертификате. Для этого пользователю нужно нажать на пункт «Продолжить» в всплывающем окне.
На основе первоисточника: blog.cisecurity.org/how-browsers-handle-certificate-revocation