56 минут назад, LostSoul сказал:

и чем это плохо?

Мы сами себе не доверяем или свой корень кому-то постороннему предлагать к использованию будем?

Да, не доверяем. Во всяком случае, не до конца. Админская машина - вкусная цель для целевой атаки. Не надо создавать лишние возможности. Правильно обращаться с ключиком от этого своего CA - достаточно трудно, поэтому лучше принять меры, чтобы при его компрометации ущерб был поменьше.

 

Корневой CA - он и может быть только на весь интернет.

Если у вас центр сертификации на определенный узел иерархии ( домен с поддоменами ) то это не корневой CA уже.

Корневой - это тот, который в цепочке подписей в начале стоит и про который мы сказали, что мы доверяем. Обычно они да 'доверяем всегда для всех доменов', но для личного использования можно и нужно ограничивать. Это можно сделать как на промежуточном, так и на корневом. Пример от Мозиллы. Смотрим внимательно на шаг 3 в 'Generate your CA Root'

 

 

И такие мелочи могут беспокоить только тех, кто делает ПРОМЕЖУТОЧНЫЙ центр сертификации, и хочет чтоб его удостоверил кто-то из root ca.

Что является рекомендуемой практикой и для корпоративных/личных CA. Корневой сертификат лежит в сейфе и достается где-то раз в несколько лет, чтобы более короткоживущие сертификаты промежуточных subordinate CA подписать. И уже они используется в работе для генерации сертификатов для конечных точек.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
20 часов назад, Sergey Gilfanov сказал:

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
42 минуты назад, Черномазов сказал:

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

В описанной ситуации ( сертификат для одной админской машины ) весь CA может быть размещен в домашнем каталоге администратора прям на этой машине.

да и  вообще его после генерации и импорта сертификата можно с чистой совестью грохнуть.

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
7 минут назад, LostSoul сказал:

В описанной ситуации

В этой теме описано 2 основные ситуации:

* сертификаты для доступа к разнообразным устройствам с админской машины,

* сертификаты для доступа к личному кабинету провайдера с машин его клиентов.

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
14 минут назад, LostSoul сказал:

В описанной ситуации ( сертификат для одной админской машины ) весь CA может быть размещен в домашнем каталоге администратора прям на этой машине.

 

Откуда потому ключ упрут и MitM кому-нибудь, кто этому сертификату доверяет, сделают. Или даже самому админу, когда он какой-нибудь критический сервер вроде сервиса регистратора доменов, пойдет.

Ну геморройно правильно с ключами обращаться, что поделаешь.

 

да и  вообще его после генерации и импорта сертификата можно с чистой совестью грохнуть.

 

Если 'грохнут' - то заморачиваться с CA смысла нет. Просто для конечной точки самоподписанный сертификат сделать и с ним в браузере согласиться.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Интересно откуда сейчас такая параноя? Несколько лет назад вполне допустимым считалось управлять дивайсами внутри ЛВС по telnet. Вы защищаетесь от прослушивания вашего трафика вашими же сотрудниками? А перед началом работы не прозваниваете провод от клавиатуры? Может там жучок повесили, что намного проще и удобнее, чем включить mirror на коммутаторе и замести следы.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
11 минут назад, vodz сказал:

Интересно откуда сейчас такая параноя?

Паранойя - с тех пор, как в баннеры nag-а пару(кажется) лет назад зловреда посадили с атакой на ключи ssh-а. Очень конкретная атака была именно на машины админов сетей.

 

11 минут назад, vodz сказал:

 А перед началом работы не прозваниваете провод от клавиатуры? Может там жучок повесили, что намного проще и удобнее, чем включить mirror на коммутаторе и замести следы.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
5 минут назад, Sergey Gilfanov сказал:

Паранойя - с тех пор, как в баннеры nag-а пару(кажется) лет назад зловреда посадили с атакой на ключи ssh-а.

Однако... Но предложенные методы от этого защитят?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Только что, vodz сказал:

Однако... Но преложенные методы от этого защитят?

от атаки на ssh - это отдельно думать надо, Но правильное обращение с ключами и ограничениями личного корневого CA хотя бы защитит от возможных MitM при заходе на сторонние критические сайты.

 

10 минут назад, vodz сказал:

Однако...

Ага. Историческая справка.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
2 часа назад, Черномазов сказал:

* сертификаты для доступа к личному кабинету провайдера с машин его клиентов.

Не, вы читали невнимательно.

Этот пример автор темы привел просто пытаясь объяснить что ему нужно.

Для личного кабинета тут думать нечего - нужен нормальный подписанный публичным CA сертификат.

 

 

 

2 часа назад, Sergey Gilfanov сказал:

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

Вы-ж невнимательно читаете.

Вся проблема возникла оттого что браузер на машине админа на такой вариант не соглашается.

А требует подтверждать каждый раз.

 

1 час назад, vodz сказал:

Однако... Но предложенные методы от этого защитят?

Ключ в привязкой к IP-сетям с которых его допустимо применять - вполне.

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
21 минуту назад, LostSoul сказал:

Этот пример автор темы привел просто пытаясь объяснить что ему нужно.

Ну, для чего автор привёл этот пример, мы можем узнать только у автора. Если, конечно, вы не готовы взять на себя обвинение в телепатии.

 

А без телепатии мы видим, что 2 ситуации прямо противоположны: в одной - один клиент и много серверов (управляемых сетевых устройств), а в другой - много клиентов и один сервер (ЛК).

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

В втором случае отсутствует проблема и повод для вопросов,не?

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Я, как ТС, уточню. У меня есть сервер мониторинга, с доступом по web. Но имя я ему не регистрировал, захожу просто по http://хх.хх.хх.хх/cacti .  И подумалось мне, что неплохо было бы перевести его на https://xx.xx.xx.xx/cacti. Просто для большей защищенности соединения. И вопрос был в том, можно ли получить сертификат не на имя хоста, а на IP адрес

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Для публикации сообщений создайте учётную запись или авторизуйтесь

Вы должны быть пользователем, чтобы оставить комментарий

Создать учетную запись

Зарегистрируйте новую учётную запись в нашем сообществе. Это очень просто!


Регистрация нового пользователя

Войти

Уже есть аккаунт? Войти в систему.


Войти