Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
корневой это ca_cert который? 24.08.05 12:49 Число просмотров: 2556
Автор: mentat[bugtraq.ru] <Александр> Статус: Elderman
|
> p.s. Еще вспомнил: а корневой сертификат на сколько
> выпущен? Ты в конфиге можешь писать что угодно, но если
> корневик на 30 дней, он подчиненные издаст только в
> пределах своего срока жизни.
корневой это ca_cert который?
вот как я делаю.. мож ошибки найдешь?
#openssl req -new -x509 -days 3650 -keyout private/ca_key.pem -out certs/ca_cert.pem
Введи пароль и не забудь его.
#openssl req -new -nodes -days 3650 -keyout keys/Kserv.pem -out req/Rserv.pem
Для этой строки важно, чтобы параметр Organization Name совпадал с тем, что ты указал при генерации CA_cert.pem.
#openssl ca -extfile /etc/ssl/openssl.cnf -extensions server -out certs/Cserv.pem -infiles req/Rserv.pem
Тебя зададут пару вопросов, на которые не думая долго отвечай «y». Это было для сервера. Теперь повторим все то же
самое, но для клиента.
#cd /etc/ssl
#rm index.txt
#touch index.txt
#openssl req -new -keyout keys/Khome.pem -out req/Rhome.pem
#openssl ca -out certs/Chome.pem -infiles req/Rhome.pem
на этом месте у тебя возникнет ошибка "TXT_DB error number 2"
После долгих поисков и умственных усилий был найден источник ошибки - файл index.txt.
Теоретически он должен сохранять информацию об удостоверенных сертификатах:
их серийный номер и информацию о корневом сертификате. Фактически,
внеся информацию о первом сертификате, программа не может повторно обновить содержимое файла.
Так что надо ручками удалять его содержимое, или заменять пустым файлом.
то есть убить index.txt после чего
#touch index.txt
кстати надо почитать что делает тач :)
Значительно позже, в инструкции по nix версии я нашел краткое объяснение:
The CA program does not update the 'certificate' file correctly right now.
The serial field should be unique as should the CN/status combination.
The ca program checks these at startup. What still needs to be written is a program to
'regenerate' the data base file from the issued certificate list (and a CRL list).
Что можно перевести на русский язык так: мы знаем почему она не работает "корректно",
но исправить руки не доходят.:)
Создаем ХЭШ-функции для каждого сертификата на сервере для "самоподписных":
#ee /etc/ssl/certs/hash_cert.sh
где:
#!/bin/sh
#
# usage: certlink.sh filename [filename ...]
for CERTFILE in $*; do
# make sure file exists and is a valid cert
test -f "$CERTFILE"|continue
HASH=$(openssl x509 -noout -hash -in "$CERTFILE")
test -n "$HASH"|continue
# use lowest available iterator for symlink
for ITER in 0 1 2 3 4 5 6 7 8 9; do
test -f "${HASH}.${ITER}" && continue
ln -s "$CERTFILE" "${HASH}.${ITER}"
test -L "${HASH}.${ITER}" && break
done
done
#/etc/ssl/certs/hash_cert.sh /etc/ssl/certs/Cserv.pem
#/etc/ssl/certs/hash_cert.sh /etc/ssl/certs/ca_cert.pem
Не забудем про ta.key:
#openvpn --genkey --secret ta.key
#chmod 644 ta.key
Так, и на последок создаем Diffie-Hellman (фиг знает как это по-русски написать) файл
#openssl dhparam -out dh1024.pem 1024
|
|
|
подробно о проекте
Анализ криптографических сетевых...
