То, почему я не могу использовать сертификаты SSL, импортировало через Администратора Сервера в пользовательской установке Apache?
Извините.. Я голосовал для закрытия, поскольку это - довольно ясно не проблема системного администратора. Но я дам Вам некоторую справку, прежде чем подсчет голосов доберется до 5!
Будучи Менеджером по ИТ небольшой компании, я могу чувствовать Вашу боль. Существует много FUD вокруг ERP. Существует много консультантов, там предлагающих помочь для непомерных уровней (включая меня!).
ERP не о технологии, это о бизнес-процессах. То, что ERP выглядит датированным или не использует Ajax, или могло бы (удушье!) быть основанным на тексте не релевантно. То, что релевантно, - то, как хорошо ERP поддерживает процессы, которые дают Ваше конкурентное преимущество компании.
Забудьте демонстрации. Запустите с процесса. Перейдите к каждому отделу и попросите, чтобы они определили критические процессы, как они сделаны теперь, и что относительно процесса делает это очень важным или дает конкурентное преимущество компании. Например, группа материально-технических ресурсов/приобретения могла бы размещать заказы компонента каждый день, и их процесс позволяет им знать точно, сколько заказывать каждый день. Затем перейдите к поставщикам ERP и спросите их, как они будут поддерживать выполнение того процесса способом, который сохраняет преимущество или превосходство. Имейте ремесло поставщиков определенная демонстрация Ваших критических процессов.
Некоторые элементы ERP являются взаимозаменяемыми. Например, существует много способов управлять Кредиторской задолженностью, и она, вероятно, не будет иметь значения для Вашей компании, какой используется, пока счета оплачены. С другой стороны, процессы вокруг руководящих потребительских заказов и материально-технических ресурсов могли бы быть очень важными, если компания получает преимущество путем поставки вовремя, каждый раз. В этом случае Вы хотели бы удостовериться, что ERP может поддерживать вещи, которые делают Вашу работу процесса порядка.
Наконец.. удостоверьтесь, что операционные отделы вовлечены в процесс. Общайтесь со всеми включенными. Если Вы не можете получить справку и соответствие, рекомендовать, чтобы проект был отменен. Новый ERP не может просто быть наложен IT.
Экспортируйте сертификат как .p12 . Запишите используемый пароль.
Извлеките открытый ключ из файла .p12 - он запросит пароль, который был только что установлен при экспорте.
openssl pkcs12 -in /path/to/exported/cert.p12 -out /etc/certificates/new.pem -nokeys
Проверьте, сколько сертификатов сейчас в выходной файл; вы можете открыть его в любом текстовом редакторе - это может быть только субъектный сертификат или он может содержать всю цепочку (сертификаты в файле .ca , которые вам предоставил ваш CA). Если у него есть вся цепочка, ничего страшного - Apache без проблем примет все это в одном файле. Если нет, то продолжайте использовать файл цепочки, который они вам дали.
Затем давайте также извлечем закрытый ключ:
openssl pkcs12 -in /path/to/exported/cert.p12 -out /etc/certificates/new.key -nocerts -nodes
Обратите внимание, что флаг -nodes указывает команде не использовать шифрование для закрытого ключа; это предотвратит запрос пароля Apache.
Укажите Apache на эти новые файлы и перезапустите. Должно быть хорошо!
Как намекнул Шейн в комментариях, можно экспортировать сертификат как файл PKCS # 12 ( .p12 ) из Keychain Access (с паролем или без него, естественно пароль, защищающий этот шаг, более безопасен). Для этого вы должны сначала запустить Keychain Access от имени пользователя root, поэтому sudo / Applications / Utilities / Keychain \ Access.app/Contents/MacOS/Keychain \ Access & . Оттуда я смог выполнить следующие команды, чтобы извлечь закрытый ключ из экспортированного файла .p12 без шифрования и поместить его вместе с зашифрованным ключом в / etc / Certific / :
sudo openssl pkcs12 -in *.domain.tld.p12 -out /etc/certificates/*.domain.tld.SOMELONGHASH.key.no_password.pem -nodes -nocerts
sudo chown root:certusers /etc/certificates/*.domain.tld.SOMELONGHASH.key.no_password.pem
sudo chmod 640 /etc/certificates/*.domain.tld.SOMELONGHASH.key.no_password.pem
Итак, теперь у меня есть следующие файлы в / etc / Certific / :
-rw-r--r-- 1 root wheel 1655 Apr 9 13:44 *.domain.tld.SOMELONGHASH.cert.pem
-rw-r--r-- 1 root wheel 4266 Apr 9 13:44 *.domain.tld.SOMELONGHASH.chain.pem
-rw-r----- 1 root certusers 3406 Apr 9 13:44 *.domain.tld.SOMELONGHASH.concat.pem
-rw-r----- 1 root certusers 1867 Apr 11 08:30 *.domain.tld.SOMELONGHASH.key.no_password.pem
-rw-r----- 1 root certusers 1751 Apr 9 13:44 *.domain.tld.SOMELONGHASH.key.pem
Я обновил свой httpd-ssl.conf файл до:
SSLCertificateFile /etc/certificates/*.domain.tld.SOMELONGHASH.cert.pem
SSLCertificateKeyFile /etc/certificates/*.domain.tld.SOMELONGHASH.key.no_password.pem
SSLCertificateChainFile /etc/certificates/*.domain.tld.SOMELONGHASH.chain.pem
Перезапустил Apache, и он работает в совершенстве.
Я пропустил эту часть в моем первоначальном вопросе, но чтобы гарантировать, что пользователь _www добавлен в группу certusers (которая требуется для Apache для чтения закрытый ключ, так как я сохранил эти разрешения), я использовал следующую команду:
sudo dseditgroup -o edit -a _www -t user certusers