From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on sa.int.altlinux.org X-Spam-Level: X-Spam-Status: No, score=-0.6 required=5.0 tests=BAYES_00,FAKE_REPLY_C autolearn=no version=3.2.5 X-Virus-Scanned: Debian amavisd-new at cryptocom.ru Date: Thu, 7 May 2009 12:38:36 +0400 From: "Victor B. Wagner" To: devel@lists.altlinux.org Message-ID: <20090507083836.GB7433@cryptocom.ru> Mail-Followup-To: devel@lists.altlinux.org MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.5.13 (2006-08-11) Subject: Re: [devel] =?koi8-r?b?98/Q0s/T2SDOz9fJ3svB?= X-BeenThere: devel@lists.altlinux.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ALT Linux Team development discussions List-Id: ALT Linux Team development discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2009 08:38:42 -0000 Archived-At: List-Archive: List-Post: 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 -----