В Linux SSL сертификаты настраиваются и устанавливаются, как правило в каждом приложении отдельно, кроме того все приложения без проблем работают с форматом PEM (закодированный в BASE64 файл со строками “—–BEGIN CERTIFICATE—–” и “—–END CERTIFICATE—- в начале и конце файла соответственно”). Как оказалось, Windows “из коробки” такой формат поддерживает ограничено.
ЧитатьАрхив метки: ssl
Про SSL часть 3: как проверить сертификат на почтовом сервере
Таким вопросом озадачился.
Собственно, ответ:
настройки постфикса можно проверить так:
openssl s_client -CApath /etc/ssl/certs/ -connect mail.example.com:25 -starttls smtp
Читать
Про SSL, часть вторая: получение и настройка OV сертификата
Решили мы однажды, на одном из серверов, сайт на SSL перетащить, ибо неприлично в наше время на голом http сидеть.
Сказано – сделано, купили OV сертификат (с валидацией организации), и вот что это значит.
В нашем случае (сертификат был от comodo.com), обязательными условиями было:
- наличие электронной почты привязанной к домену (у нас не было, т.к. доменов у нас 2, и почта как раз на втором)
- наличие у организации страницы на одном из справочных ресурсов http://ru.kompass.com или http://www.dnb.com
- возможность ответить на звонок по номеру телефона указанному на странице организации в вышеуказанном справочнике
После оплаты счета, в личном кабинете, на сайте нашего регистратора, появилась возможность выпустить сертификат, для этого необходим CSR (Certificate Signing Request), создать его можно самому (openssl), либо с помощью мастера в личном кабинете. Я выбрал openssl. Читать
Про SSL, часть первая: какие бывают сертификаты
После обновления Firefox до версии 52, оно стало ругаться на незащищенное соединение, и задумался о настройке подключения SSL к некоторым своим серверам. Понятное дело, хочется бесплатно, или как минимум “по дешевле”. Пока разбирался в ньюансах, накопал некоторое количество интересной информации, которую и постараюсь упорядоченно изложить.
Собственно, если задуматься на тему “для чего нужны сертификаты”, можно было и самому догадаться, что основное отличие сертификатов – в степени доверия. Т.е. если не привязываться к набору услуг какого-то одного удостоверяющего центра, то разделить сертификаты по степени доверия можно на три части:
- сертификаты, которые подтверждают только доменное имя (Domain Validation — DV);
- сертификаты, которые подтверждают домен и организацию (Organization Validation — OV);
- сертификаты с расширенной проверкой (Extended Validation — EV).
Сертификаты первого типа, нередко выдаются бесплатно, проверяются они обычно в автоматическом режиме. Для получения такого сертификата достаточно всего лишь подтвердить, что данный домен принадлежит вам. Сделать это можно разными способами, например путем отправки письма на один из зафиксированных в rfc адресов, таких как postmaster@вашдомен.ру (webmaster, hostmaster и т.д.).
Т.е. такой сертификат подтверждает, что страница которую вы видите в браузере, действительно загружена с сайта с тем доменным именем, которое вы видите в адресной строке. (Если не понятно зачем это нужно, почитайте, что такое mitm атака).
Выглядит это вот так:
wordpress SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
Вот странная ошибка, на мой взгляд.
По логике, это должно означать, что wordpress, не смог средствами операционной системы в которой он установлен проверить валидность сертификата, и соединяться не стал. Но нет. Средствами ОС он этого сделать не может, и что бы оставить движек максимально простым в использовании, разработчики пошли на не совсем простой шаг. Встроили проверку сертификата вместе с хранилищем сертификатов в сам wordpress.
Если вы попали сюда из поисковика, в поиске решения этой ошибки, то лечится она легко:
Достаточно в директорию wp-includes/certificates положить файл http://curl.haxx.se/ca/cacert.pem под именем ca-bundle.crt
А теперь, чем меня насторожило такое решение. Дело в том, что движки подобные wordpress легко ломаются, всегда найдется пара не пропатченных багов. А загрузка файлов через SSL не стартует без проверки подлинности, на случай, если нам пытаются подсунуть левый контент посредством атаки Men in middle.
Получается, что проверку подлинности сервера можно легко отключить, путем замены файла ca-bundle.crt на свой, где будет добавлен сфабрикованный корневой сертификат которым будет подписан сертификат узла men in middle.
UPD: Как показала практика, не везде можно решить проблему таким образом.
На сайте разработчиков curl нашел вот что: http://osdir.com/ml/web.curl.php/2007-02/msg00008.html
Суть в том, что если у вас установлена версия curl из перечисленных:
>libcurl/7.10.3 OpenSSL/0.9.6g
> libcurl/7.12.1 OpenSSL/0.9.7a
> libcurl/7.11.2 OpenSSL/0.9.7c
То без обновления curl не обойтись.
Представлен перехват и извлечение данных HTTPS-соединения
На прошедшей конференции Black Hat была обнародована информация о новом виде атаки BREACH, позволяющем восстановить содержимое отдельных секретных идентификаторов (например, сессионные cookie и CSRF-токены), передаваемых внутри зашифрованного HTTPS-соединения, сообщает opennet.ru. Метод атаки BREACH практически идентичен представленной в прошлом году атаке CRIME (Compression Ratio Info-leak Made Easy), за тем исключением, что атака оперирует особенностью изменения характера потока при сжатии на уровне HTTP, а не при сжатии на уровне TLS/SSL, как в случае с CRIME. Для организации атаки требуется получение контроля за трафиком на промежуточном шлюзе и выполнение на стороне браузера клиента JavaScript-кода злоумышленника (в случае получения контроля над транзитным шлюзом, осуществить подстановку JavaScript-кода в незащищённый трафик не составляет труда). Читать
Кто же стоит за кражей SSL-сертификатов
Автор: Виктор Ласло
Опубликовано 28.03.2011 в блоге «Компьютерры»
На прошлой неделе наделала шуму кража SSL-сертификатов у одного из партнёров компании Comodo. Неизвестные взломщики добыли поддельные криптосертификаты Yahoo, Google, Skype, Mozilla и Live.com. Поскольку атака шла с иранских IP, немедленно возникло подозрение, что её устроили иранские спецслужбы (у них был и мотив, и возможность). Однако, похоже, в действительности дело обстояло проще.
В субботу и воскресенье некто по имени Comodohacker сначала разразился пространным заявлением по поводу недавнего взлома, а затем подкрепил свои слова дизассемблированным кодом библиотеки TrustDLL.dll, с помощью которой осуществляются запросы в Comodo на получение сертификатов от её партнёров.