KEYTOOL эквивалент в apache

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

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

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

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

Отправьте это вам в CA, чтобы получить сертификат обратно. Обычно мы просим вернуть его как подходящий для "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 scriptorium.

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

Кроме того, если в будущем вам понадобится объединить их в хранилище ключей, проще объединить их в хранилище ключей PKCS#12, а не в JKS... все (Java), поддерживающее JKS, будет поддерживать PKCS#12. (он же PKCS12, он же P12)

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