Простой тестового CA

Данная установка может понадобиться для локального тестирования и отладки различных компонент системы. В Интернет можно по ключевым словам "Simple CA" найти кучу примеров как все это сделать руками, но проще всего воспользоваться тем, что нам предлагает сам пакет GT4.

В большинстве случаев тестовая установка не предполагает серьезных мер безопасности. Однако, если сертификаты подписанные тестовым CA будут использоваться параллельно с сертификатами настоящего CA, о некоторых элементарных мерах предосторожности стоит позаботится. В частности, не стоит делать пароли слишком простыми и хранить их в доступном месте. И т.д.

Установка CA

Установка CA осуществляется после установки пакета GT4. В приведенном ниже пример, пароль совершенно небезопасным способом сохраняется в файловой системе. Теоретически, при установке тестового CA, пароль можно передать параметром командной строки, что чуть более безопасно, но к сожаления не работает, видимо не доделано. Безопаснее вводить пароль в интерактивном режиме, однако это затруднит автоматизацию процесса.

mkdir -p /root/.globus
echo "very_strong_password" > /root/.globus/.simplecapass
HOME=/root perl /tmp/gt4/gt4.2.1-all-source-installer/gt-server-ca.pl -y
chown -R ${GLOBUS_USER}:${GLOBUS_GROUP} ${GLOBUS_LOCATION}

Следует учесть, что .simplecapass ищется (и создается если его небыло) в каталоге '${HOME}/.globus'. В штатной ситуации, эта переменная окружения существует. Однако, в случае установки всего хозяйства, скажем, из kickstart файла, такой переменной не будет. И .globus будет создаваться в текущем, для запуска этого всего, каталоге. Немного неприятно, но факт.

Еще одно замечание, хоть для создания паролей и требуется проявить изобретательность, но могут быть всякие подводные камни. Если память не изменяет с кем-то еще, то пробелы в пароле пагубно влияют на работу этих не доделанных скриптов. Чтож, дареному халявному коню в зубы смотреть моветон, Бог им судья.

Установка сертификатов простейшего CA на остальные узлы

Для того чтоб сертификаты от нашего простого CA действовали и на других узлах, а не только на узле где он установлен, необходимо скопировать папку '${GLOBUS_LOCATION}/share/certificates/' на все узлы. ${GLOBUS_LOCATION} на этих узлах не обязательно должен совпадать.

Про myproxy

Дальнейшие операции для облегчения жизни будут проводиться через myproxy. Впринципе, будет не плохо, если этот сервис будет установлен штатно. Но и без запущенного myproxy можно жить, капаясь у него во внутренностях.

Сертификат узла

При установке тестового CA, скрипты автоматически создадут сертификаты для узла, на котором CA создается. Их необходимо перенести в правильное место. Кроме того, эти же сертификаты нам понадобятся и для нашего WS контейнера:

mkdir -p /etc/grid-security
mv ${GLOBUS_LOCATION}/etc/host*.pem /etc/grid-security/
cp /etc/grid-security/{host,container}cert.pem
cp /etc/grid-security/{host,container}key.pem
chown ${GLOBUS_USER}:${GLOBUS_GROUP} /etc/grid-security/container*.pem

Владельцем '/etc/grid-security/host*.pem' должен остаться 'root', иначе работать не будет.

Дополнительные сертификаты

На узле, который содержит простое CA, необходимов выполнить следующую команду:

myproxy-admin-addservice -c "cognito.mcs.anl.gov" -l rik5 -p "pass:ca_password" -n

Ключ '-c' задает 'CN', ключ '-l' задает имя пользователя, для которого 'myproxy' будет хранить данные. Пароль 'CA' указывается через ключ '-p' с использование префикса 'pass:'. Формат аргумента ключа '-p' соответствует параметру '-passin' 'openssl'. Если не использовать ключ '-p', то пароль, конечно же, спросят. К сожалению, у 'myproxy-admin-addservice нет возможности указать пароль для шифрования ключа. Однако, есть возможность указать что ключ не надо шифровать вообще. Для настоящего 'CA' это, конечно, абсолютно неприемлемо, но удобно для скриптования в тестовой сборке.

Найти подписанный сертификат и ключ можно либо в каталоге '/var/myproxy', либой '${GLOBUS_LOCATION}/var/myproxy'. Или же в каталоге, указанном через ключ '-s'. Для указанного примера, файл будет называться 'rik5-cognito.mcs.anl.gov.creds'.

Если ключ не зашифрован, то его можно извлеч используя 'ed', 'sed' и т.п. Однако, проще всего это будет сделать используя 'openssl':

openssl rsa -in /var/myproxy/rik5-cognito.mcs.anl.gov.creds -out rik5-cognito.mcs.anl.gov.hostkey.pem

или же, для варианта с зашифрованным ключем:

openssl rsa -in /var/myproxy/rik5-cognito.mcs.anl.gov.creds -out rik5-cognito.mcs.anl.gov.hostkey.pem -passin "pass:superpassword"

Убедитесь что файл с ключем может читать только его владелец.

Сертификат же можно извлеч следующей командой:

openssl x509 -in /var/myproxy/rik5-cognitox.mcs.anl.gov.creds -out rik5-cognito.mcs.anl.gov.hostcert.pem

Что дальше со всем этим делать было описано уже чуть выше.

Сертификат пользователя

Получение сертификата пользователя не сильно отличается пот получения сертификата узла. Вместом 'myproxy-admin-addservice' нужно будет использовать 'myproxy-admin-adduser':

myproxy-admin-adduser -c "Vasily Pupkin" -l vpup -p "pass:ca_password" -n

В отличие от ключа узла/сервиса, ключ пользователя должен храниться в зашифрованном виде. Таким образом, извлеченный ключ нужно сразу зашифровать. Опять же, сделать это можно openssl-ем, например:

openssl rsa -des3 -in /var/myproxy/vpup.creds -out vpup_userkey.pem -passin "pass:myproxy_pass" -passout "pass:enduser_pass"

Сами же получившиеся файлы нужно положить в папку '~/.globus' с именами 'userkey.pem' и 'usercert.pem'. У файла 'userkey.pem' должен стоять атрибут чтение только для владельца файла.