Добрый вечер!

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

Я создал сертификаты. Так же создал crl.pem. После добавления сертификата в crl.pem локально подключиться с этим сертификатом уже не могу к серверу БД, что отлично. Но, стоит этот сертификат сохранить на другом сервере и от туда подключиться, то все пройдет отлично. Вопрос, как этом можно выключить, нужно чтобы вообще ни откуда ни кто не смогу подключиться к серверу с отозванным сертификатом. 

Что это за сертификаты вообще ?
Напишите на [email protected] - почти заинтересовался   

Это сообщение отредактировал(а) _zorn_ - 26.1.2017, 19:36

Ssl сертификаты. Ни чего особенного. 

Просто у ssl сертификатов есть, такое понятие, как отозванные сертификаты, обычно файл от них имеет название crl.pem в нем находятся соответственно отозванные сертификаты. Вот собственно про этот файл и идет речь. 

То есть межсерверные подключения у тебя не используют SSL?

Верно. У меня по ssl только реплика в mysql.

Ну тогда какие претензии-то? Если SSL - то везде SSL. 

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

Под межсетевыми соединениями вы понимаете что?

Добавлено через 5 минут и 14 секунд
Исходя из выше сказанного, складывается у меня впечатление, что мне нужно помимо того, что БД работает на ssl, так и еще подключать ssl на apache2/nginx, чтобы все это заработало. Да же, если на сервере не используется apache2/nginx и так далее. Или вы, говорите о чем-то другом, а я просто не могу догнать о чем именно. Поправьте меня если я ошибаюсь.

Я не говорил этого слова.


Я говорю о том, что сервер должен работать либо по SSL - но тогда абсолютно со всеми, либо никакого смысла в SSL нет, за исключением тех случаев, когда не-SSL соединения разрешены со строго определённых хостов (например, с админки или от локалхоста), причём фильтрация при этом выполняется не на уровне MySQL-сервера, а на уровне сетевой подсистемы ОС. 

Хм. Интересно. Честно, очень интересно. 

Скажем, есть три сервера, на которых стоит mysql и вместе они образуют реплику. 
В конфиг файлах всех серверов пишем 

ssl-ca=/etc/mysql/ssl/cacert.pem
ssl-cert=/etc/mysql/ssl/servercert.pem
ssl-key=/etc/mysql/ssl/serverkey.pe
ssl-crl=/etc/mysql/ssl/crl.pem

ну или, что-то подобное. 

Тем самым мы здесь организуем подключение к БД через сертификат посредством самой БД, а не ОС.
Вот пример, того, как это делается через средства БД. Это я знаю и мне это понятно.

А, вот пример с 

мне как-то в голову ни какой пример сразу и не лезет. Кроме, как проверка ssl на уровне nginx, но это мы ведь проводим тем самым подключение к 80 порту, а проверка происходит браузером клиента. Что то же не сходится одно с другим. 
Пожалуйста приведите конкретный пример, если это возможно.

Добавлено через 13 минут и 24 секунды
Тут есть еще одна штука. Я просто не знаю, как она настраивается в сертификатах БД. А, то о чем я говорю, это хранение crl.pem не локально, а на удаленном сервере, пусть это будет четвертый сервер. И, данные о том, что искать crl.pem на удаленном сервер, нужно прописывать то ли в самих сертификатах, то ли в БД или в обоих местах сразу. 

Вот пример с сертификатами для nginx/apache2 

там рассматривается crlDistributionPoints = URI:http://example.com/intermediate.crl.pem
Но, вся статься посвящена корневому сертификату, а не сертификату для БД. Вот не знаю, есть ли такое в БД или нет.

MySQL устанавливает SSL-соединение по TCP, используя определённый порт (обычно 3306). Переопределим его, например, на 3307. Включаем в ОС фильтр входящих пакетов (как вариант - во встроенном брэндмауэре или файрволе третьей фирмы) на пропускание входящих TCP/3307 только с определённых адресов - и всё. Вот и пример, и реализация одновременно. 

Впрочем, всё то же можно сделать и на уровне аутентификации MySQL-пользователя (GRANT ... REQUIRE SSL;)


Ну вот... и мухи, и котлеты в одну кучу, да ещё и сковородку туда же. nginx в процессе общения скрипт-сервера (обычно PHP) и MySQL-сервера вообще не участвует никаким боком! А то, что он может этот трафик проксить, тоже никакого отношения к делу не имеет, как не имеет отношения к производству смартфонов курьер магазина, который привёз тебе на дом купленный заказ (да и сам магазин тоже, и склад этого магазина, хоть там тех смартфонов можно центнерами мерить).

Спасибо за развернутый ответ. 

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

Если разобрать протокол TCP, то при подмене он(третье лицо) сможет только отправляться данные на сервер, но не сможет принять их. По этому, он может послать такую команду, которая или удалит все данные или что-то изменит в БД.
Так что, вопрос все же открыт. 

А, ваш способ довольно хороший. 

Решение проблемы нашел вот в этом посте. Теперь да же украденный сертификат не будет запущен на чужом компе, да же если он сделает подмену IP.

Добавлено через 2 минуты и 14 секунд
-extfile mycrl.cnf  - это и есть решение. )) вынести в отдельный файл или можно сразу в файле openssl.cnf все поправки внести.