Re: proftpd + inetd + ssl/tls и другие вопросы.

[Oleksandr Gavenko <gavenkoa@gmail.com>]

On 2015-11-24, Artem Chuprina wrote:

> Тут, вероятно, для начала нужен некоторый ликбез.
>
> Клиенты доверяют сертификату сервера, если этот сертификат подписан
> доверенным центром сертификации.  Вот то самое "ca" в ca-certificates.
> Certification Authority.  У CA тоже есть сертификат, и подпись на
> сертификате сервера проверяется об этот сертификат (там содержится
> открытый ключ подписи).
>
> Для построения цепочки доверия нужно выполнение нескольких условий.
> Применительно к твоей ситуации, не выполнено в первую очередь условие
> "сертификат сервера и сертификат CA - разные сертификаты, с разными
> разрешенными областями применения".
>
> Чтобы нормально работало, надо сделать честный сертификат CA,
> распространить его по клиентам, в норме - установить в набор доверенных
> корневых (это то, что ты пытался сделать с сертификатом сервера),
> сделать честный серверный сертификат и подписать его ключом CA.
>
> Или купить серверный сертификат у какого-нибудь известного CA, про
> которого большинство клиентов знает из коробки.  Это минус необходимость
> устанавливать свой сертификат CA на клиентов - довольно сложная операция
> для юзера на винде (вероятно, разная для разных версий винды),
> работоспособная не в каждом андроиде, и т.п.
>
> Я не знаю точно, что именно делает proftpd-gencert, но почти наверняка
> он делает самоподписанный сертификат сервера, на котором можно защищать
> соединение, но которому в нормальной инфраструктуре никто не будет
> доверять.
>
> Сделать честно не то чтобы офигительно сложно, но я не знаю простых
> энд-юзерских инструментов для этого.  Сам тупо пользуюсь openssl, но я
> этой криптографией занимался профессионально, и понимаю, что делать с
> его ключами и конфигом.  А так-то openssl как утилита - штука
> отладочная, для реальной работы не предазначенная.  Хотя может.
>
> Вроде бы, в комплекте gnutls было что-то попроще для построения PKI.

Да, схема то закручена. Вместо прямого доверия cертификату сервера (как я
думал выше что получится) мы доверяем всем сетрификатам подписаными доверенным
CA.

В общем ниже сырой материал, подготовленый для блогозаписи.

Может есть проще (я встречал упоминание о ca.pl скрипте) но так сработало.
openssl.cnf подбирал копированием /usr/lib/ssl/openssl.cnf подряд по
выпадающим ошибкам от "openssl ca". Остальное извлек из кучи вкладок браузера.

Я тоже занимался криптографией (БИФИТ, оптимизация криптопримитивов), но
сменил работу в то время как подоспели прикладные задачи (связать примитивы в
публичные API и PKI), не успел помучится с x509 и PKI ))

================================================================

Create CA root self-signed certificate::

  $ openssl req -x509 -sha256 -days 1000 -nodes -newkey rsa:4096 -keyout ca-root-key.pem -out ca-root-cert.pem
  ...
  $ ls ca-root-*.pem
  ca-root-cert.pem  ca-root-key.pem

Dump content::

  $ openssl x509 -text -noout -in ca-root-cert.pem
  ...
  $ openssl pkey -text -noout -in ca-root-key.pem
  ...

Check certificate purpose::

  $ openssl x509 -purpose -in ca-root-cert.pem
  ...

Generate server key and certificate::

  $ openssl req -sha256 -days 1000 -nodes -newkey rsa:4096 -keyout server-key.pem -out server-cert.csr
  $ ls server-*.pem
  server-cert.csr  server-key.pem

Dump content::

  $ openssl req -text -noout -in server-cert.csr
  ...
  $ openssl pkey -text -noout -in server-key.pem
  ...

To fill subject automatically::

  $ openssl req -sha256 -days 1000 -nodes -newkey rsa:4096 -subj "/C=UA/ST=User/L=City/O=Corp/OU=SubCorp/CN=myvps.com" -keyout server-key.pem -out server-cert.csr


Prepare use minimal ``openssl.cnf``::

  [ ca ]
  default_ca  = CA_default

  [ CA_default ]
  new_certs_dir = .
  database = index.txt
  serial = serial.txt

  default_md  = default
  policy      = policy_anything

  [ policy_anything ]
  countryName     = optional
  stateOrProvinceName = optional
  localityName        = optional
  organizationName    = optional
  organizationalUnitName  = optional
  commonName      = supplied
  emailAddress        = optional

Prepare some CA database files::

  $ echo 01 > serial.txt
  $ touch touch index.txt index.txt.attr

Sign server CSR with CA key::

  $ openssl ca -days 1000 -config openssl.cnf -cert ca-root-cert.pem -keyfile ca-root-key.pem -out server-cert.pem -in server-cert.csr

Dump signed server certificate::

  $ openssl x509 -text -noout -in server-cert.pem
  ...

Copy CA certificate to Debian tructed store::

  $ sudo cp ca-root-cert.pem /usr/share/ca-certificates/my/my-ca-root-cert.crt

and register certificate::

  $ sudo dpkg-reconfigure ca-certificate

Copy signed server key + certificate to server and resister it::

  $ scp server-key.pem server-cert.pem user@vps
  $ ssh user@vps
  % sudo cp server-cert.pem  /etc/ssl/certs/proftpd.crt
  % sudo cp server-key.pem  /etc/ssl/private/proftpd.key

After all I can run::

  $ lftp ftp://user@myvps.com
  lftp user@myvps.com:~> ls
  -rw-r-----   1 ftp      ftp           276 Nov 24 20:16 index.html
  lftp user@myvps.com:/> exit

without::

  $ lftp -e 'set ssl:verify-certificate no' ftp://user@myvps.com

Note that ftp:// URL domain name SHOULD match certificate CN name or you get error::

  Fatal error: Certificate verification: certificate common name doesn't match requested host name ‘myvps.com’

-- 
Best regards!