KEYTOOL, эквивалентный в апаче

Оформить заказ на бесплатный инструмент openssl, отличный от Java: http://en.wikipedia.org/wiki/OpenSSL

Это довольно просто, любые трудности заключаются в создании CSR в первое место.

openssl req -batch -newkey rsa:2048 -out something.pem

Это также должно дать вам something.key (ваш закрытый ключ)

(подсказка: найдите сценарий для вышеуказанного и отредактируйте; вы, возможно, будете часто его использовать).

] Отправьте это вашему ЦС, чтобы получить обратно сертификат. Обычно мы просим вернуть его как подходящий для «Apache для Linux». Это означает, что вы получаете сертификат PEM с цепочкой промежуточных и корневых сертификатов CA, также в PEM. Скорее всего, вы получите их объединение.

Чтобы настроить Apache (это для каталогов Red Hat с некоторыми локальными соглашениями об именах):

• SSLPrivateKey указывает на / etc / pki / tls / private / something. key, а доступ к файлу должен быть ограничен, чтобы root не мог его прочитать.
• SSLCertificateFile указывает на /etc/pki/tls/certs/something.crt (или .pem - фактические имена файлов совсем не важно, и полезнее просто быть последовательным). Он содержит ваш сертификат (единственный PEM)
• SSLCertificateChainFile указывает на /etc/pki/tls/certs/something.ca-bundle (это мое собственное местное соглашение). Он содержит объединение промежуточных и корневых сертификатов CA, которые должен предложить сервер. Вам не нужно включать корневой сертификат, но вы должны убедиться, что присутствует достаточное количество цепочки, чтобы все клиенты могли создать достаточную часть цепочки для установления доверия.

Честно говоря, ] БОЛЬШЕ неприятностей в этом вопросе является выяснение, где разместить файлы, когда вы работаете на сервере другого типа (например, Red Hat и Debian имеют совершенно разные соглашения). По большей части, это не имеет значения, ЕСЛИ у вас не задействовано какое-то обязательное управление доступом (например, SELinux - вы захотите поместить файлы туда, где httpd разрешено читать их файл).

Другая неприятная вещь - это выяснить, как это проверить. Я разработал пару скриптов (потому что я делаю это очень часто), названных ssl-get-basics и ssl-rfc-xargs, которые вы можете найти в моем репозитории скрипторий github .

Обратите внимание, что вы часто можете получить цепочку сертификатов CA в одном из двух очень запутанных порядков («обратный» - что может быть противоположным вашим ожиданиям) и. Если вы используете мой ssl-get-basics (или openssl s_client -show-certs -connect something.example.com:443 , тогда вам нужно убедиться, что эмитент одного сертификата является объектом следующего. У меня были проблемы с этим в прошлом (но это не относится к Apache).