Расширенный SSL: Промежуточный центр сертификации и развертывание встроенных ящиков

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

Некоторые из предположений здесь просто: предположения, или, точнее, обнадеживающие предположения. Считайте это головоломкой, просто сказав: «Это невозможно», вы не понимаете сути.

Альтернативные и частичные решения приветствуются, личный опыт, если вы сделали что-то «подобное». Я хочу чему-то научиться из этого, даже если весь мой план ошибочен.

Вот сценарий:

Я разрабатываю на встроенной системе Linux и хочу, чтобы ее веб-сервер мог без проблем обслуживать готовый протокол SSL. Вот критерии дизайна, к которым я стремлюсь:

Должен быть:

• Я не могу заставить пользователя добавить мой сертификат CA собственного производства в свой браузер
• Я не могу заставить пользователя добавить статически сгенерированный (в mfg time) самозаверяющий сертификат в свой браузер
• Я не могу заставить пользователя добавить динамически сгенерированный (во время загрузки) самозаверяющий сертификат в свой браузер.
• Я не могу использовать HTTP по умолчанию, и у меня есть переключатель включения / отключения SSL. Это должен быть SSL.
• Как встроенный модуль, так и клиент веб-браузера могут иметь или не иметь доступа в Интернет, поэтому следует предполагать, что они работают правильно без доступа в Интернет. Единственные корневые центры сертификации, на которые мы можем положиться, - это те, которые поставляются с операционной системой или браузером. Давайте представим, что этот список «в основном» одинаков для всех браузеров и операционных систем, то есть у нас будет ~ 90% успеха, если мы будем полагаться на них.
• Я не могу использовать однодневную операцию, например: « Центр обмена сертификатами SSL Fast Eddie - с такими низкими ценами наши серверы ДОЛЖНЫ быть взломаны! '

Приятно иметь:

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

Не хочу:

• Я не хочу отправлять один и тот же набор статических ключей для каждой коробки. Вроде подразумевается в списке «не могу», но я знаю риск.

Да Да, я знаю ...

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

Thinking Cap Time

Мой опыт работы с SSL позволил генерировать сертификаты / ключи, которые должны быть подписаны «настоящим» корнем, а также немного усилил мою игру, создав свой собственный внутренний CA, распределяя внутреннее «самообслуживание». подписанные сертификаты. Я знаю, что сертификаты можно связывать, но я не уверен, каков порядок операций. т.е. «идет» ли браузер по цепочке, видит действительный корневой ЦС и видит его как действующий сертификат - или вам нужна проверка на каждом уровне?

Я наткнулся на описание промежуточного центра сертификации , что заставило меня задуматься о возможных решениях. Возможно, я перешел от «простого решения» к «кошмарному режиму», но возможно ли:

Сумасшедшая идея №1

• Получить промежуточный сертификат центра сертификации, подписанный «настоящим» ЦС. (МКА-1)
  • ROOT_CA -> ICA-1
• Этот сертификат будет использоваться во время производства для создания уникальной пары промежуточных центров сертификации без пароля для каждой коробки.
  • ICA-1 -> ICA-2
• Используйте ICA-2 для создания уникального сертификата / ключа сервера. Предостережение: можете ли вы сгенерировать ключ / пару для IP-адреса (а не DNS-имени?)? то есть потенциальным вариантом использования для этого будет то, что пользователь сначала подключается к ящику через http, а затем перенаправляет клиента в службу SSL, используя IP-адрес в URL-адресе перенаправления (чтобы браузер не жаловался на несоответствия). Это может быть карта, которая разрушает дом. Поскольку SSL-соединение должно быть установлено до того, как могут произойти какие-либо перенаправления, я вижу, что это тоже проблема. Но если бы все это сработало волшебным образом
• Могу ли я затем использовать ICA-2 для генерации новых пар сертификат / ключ каждый раз, когда ящик меняет IP, так что, когда веб-сервер возвращается в исходное состояние, он всегда имеет «действительную» цепочку ключей.
  • ICA-2 -> SP-1

Хорошо, ты такой умный

Скорее всего, мое запутанное решение не сработает - но было бы здорово, если бы оно работало. Была ли у вас подобная проблема? Что ты делал? Какие были компромиссы?