Re: [devel] Вопросы новичка

["Victor B. Wagner" <vitus@altlinux.org>]

On 2009.05.07 at 10:13:51 +0400, Afanasov Dmitry wrote:

> On Tue, May 05, 2009 at 06:11:13PM +0400, Victor B. Wagner wrote:
> > On 2009.05.05 at 16:26:09 +0300, Alexander Bokovoy wrote:
> > > "Список, сестра!". 
> > Лично у меня план действий такой:
> > 
> > 1. Запакетировать openssl-1.0. С тем чтобы она максимально
> > соответстовала текущей полиси дистрибутива и перевод приложений на неё
> > был возможно более безболезненным. 
> мне как админу от сертификатов хотелось бы:
> 1. иметь "машинный" сертификат, которым автоматом бы подписывались все
> остальные сервисные. подписать этот сертификат чем-нибудь другим, как я
> помнимаю, можно и позже.

Насчет подписать можно и позже - будут проблемы.
Если вы отправите заявку на получение сертификата intermediate CA на 
свой ключ, которым вы уже подписали несколько сертификатов,
то вам будет выдан сертификат с определенным сроком действия. 

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

Но в принципе "подписать на чем-нибудь" сертификат своего CA - не
обязательно. Можно распространить самоподписанный сертификат вашего CA
по всем клиентским машинам и установить его там в Trusted CA store. 
После этого он будет ничем не хуже Verisign-а.

В принципе, и перевыпустить сертификаты серверов после получения
сертификата CA недолго.



> 2. иметь возможность подставлять свои параметры в автогенерируемые
> сертификаты: organization там, organizationUnit, ссылку на crl.

Угу. Причем по-русски. Сделать это можно достаточно просто. Для этого
необходимо, чтобы

1. При установке сервисов сертификаты генерировались с использованием
системного openssl.cnf.

2. Иметь какой-то достаточно удобный инструмент, чтобы в этот самый
openssl.cnf прописывать параметры вашей организации.

3. Не забыть прописать в openssl.cnf прямо при создании пакета
необходимые параметры, которые обеспечат корректную обработку кириллицы.

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

1-е и 3-е я уже делал в CryptoPack 1.0. К сожалению, до второго - руки
не дошли.


> все пакеты, что используют ssl, при установке генерируют сертификаты.

Что вообще говоря, не обязательно. В Debian, например, есть отдельный
пакет ssl-cert, который генерирует один-единственный сертификат на
hostname данной машины, которым потом польузются все установленные
сервисы.

> как сделать эту генерацию интерактивной при установке пакета я не
> представляю - rpm и все такое. но пусть хотя бы берут мои данные, а не
> какой-нибудь cat << EOF | openssl req. и ещё и подпишутся напоследок
> "машинным CA" :)
> 
> subject'ом таким сертификатам можно проставлять имя сервиса. ftp - для
> ftp, mail - для MTA, etс. мыло - одно на всех мыло админа. suport@, или
> личное.

subject сертификата - это набор полей. Куда входят как раз
organization, unit etc. Вы, наверное, имеете в виду поле CN (Common
Name). Так оно ОБЯЗАНО в случае серверного сертификата TLS совпадать
с именем хоста. Причем именно того, к которому идет обращение со стороны
клиента. До OpenSSL 0.9.8f не было никакой возможности иметь разные 
сертификаты на разные виртуальные хосты на одном IP, что создавало
определенные проблемы с виртуальными хостами в apache.

Начиная с 0.9.8f поддерживается TLS extension SNI (Server Name
Indication), так что теперь в принципе можно делать виртуальные хосты с
разными сертификатами. При условии что SNI поддерживается и клиентским
приложением (Firefox >= 2, MSIE >= 7 его поддерживают), и сервером (не
только на уровне библиотеки, но и на уровне приложения, так как именно
приложение решает какой именно сертификат отдать)

Что сейчас с поддержкой SNI у Apache - давно не смотрел.
Feature Request с соответствующим патчем был в апачевском SVN еще год
назад, но попал он в релиз или нет - не в курсе.

Для других сервисов, как правило, задача виртуальных хостов менее
актуальна.

Но общий принцип такой - иметь имя сервиса в CN можно только если 
имеется алиас в DNS (CNAME или A), содержащий это имя в DNS-имени
машины.



> > 2. Взаимодействие с мейнтейнерами
> если что нужно сделать в gnutls - предлагайте. к сожалению, "как это
> тикает" я не разобрался, но будет задача - будем думать :)

В данном случае, я имел в виду скорее мейнтейнеров приложений.
Apache, openvpn, postfix, dovecot, postgresql, mysql etc - неполный список тех
приложений которые я уже тестировал на работу с российской криптографией
и точно знаю что нужно, чтобы оно работало.

(например, в случае с postgresql нужно только его пересобрать с OpenSSL 
поддерживающей российскую криптографию и прописать в openssl.cnf
соответствующий модуль)

В gnutls - нужно начать и кончить. Написать поддержку российских
алгоритмов, поддержку российских шифрсьютов etc. Если алгоритмы
шифрования и хэширования можно тупо содрать из моей реализации для
OpenSSL (они там ни от чего не зависят), то алгоритмы подписи и
распределения ключей там сильно завязаны на библиотеку длинной
арифметики и эллиптических кривых OpenSSL, так что придется переписывать 
с нуля.

И, насколько я понимаю, нет никаких шансов сделать на базе gnutls
сертифицированное решение. В результате чего оно абсолютно неинтересно
моему руководству.


----- End forwarded message -----