Який пароль використовує OSX-сервер під час імпорту SSL-сертифікатів?


2

Я переміщую свій веб-сайт далеко від домашнього сервера OSX на віртуальний сервер Linux, розміщений у відповідному центрі обробки даних, і у мене виникають проблеми із сертифікатами SSL, які я імпортував у сервер OSX.

Схоже, він зберігав сертифікати, /etc/certificatesпроте я не знаю парольну фразу, яку він використовував для шифрування файлу ключів. Це не мій звичайний пароль для облікового запису / брелка, тому я не маю уявлення, яку парольну фразу, або я вибрав у той час.

(Я намагався отримати оригінальні сертифікати SSL, але це не так просто, але я можу єдину надію).

Може хтось скаже мені, як це працює, щоб я міг розплутатись і скористатись сертифікатами на новому веб-сайті, будь ласка?

Відповіді:


2

Сам власне "сертифікат" не шифрується. Ваш приватний ключ, який використовується разом із сертифікатом, зазвичай шифрується. Він шифрується за допомогою парольної фрази, яку ви вибрали під час створення приватного ключа. Можливо, ви зробили це деякий час раніше, ніж створили цей специфічний сертифікат, якщо у вас є кілька сертифікатів - тому обов'язково спробуйте "старі паролі", якщо вони у вас є.

Якщо ви не можете згадати пароль для свого приватного ключа, вам не пощастить. Ви більше не зможете використовувати цей конкретний сертифікат. Емітент сертифіката не зможе надати вам копію приватного ключа, оскільки він не отримав його.

Зазвичай ви зможете відкликати наявний сертифікат і змусити свого емітента надати вам новий - залежно від вашого емітента, який може стягуватися з платою.

Оскільки ви сьогодні можете придбати нові сертифікати SSL вартістю менше 10 доларів, намагатися спробувати старий працювати вже не варто. Просто придбайте нову.


+1 Добре, тож ви підтвердили, що фразу пропуску обрали я, а не система. Це дасть мені щось працювати.
trojanfoe

ОК проблема вирішена. Знайшов копію в резервній копії, яку я мав, яка була розблокована. Тож дивно, як він заблокував OSX Server за допомогою наданої мені парольної фрази, яку я з тих пір забув. Звичайно мені це не трапляється: - $
trojanfoe

4

Схоже, проблема ОР вирішена, але для запису дістати ключі від OS X Server досить просто, якщо у вас є доступ адміністратора до сервера. Я дам вам два способи це зробити:

  1. Запустіть утиліту Keychain Access на сервері, виберіть "Система" зі списку Keychains, а потім "Мої сертифікати" зі списку категорій під цим. Виберіть відповідний сертифікат у правій частині вікна, а потім у меню Файл виберіть "Експорт елементів. У діалоговому вікні експорту переконайтесь, що для формату файлу встановлено значення" Обмін персональною інформацією (.p12) ", щоб експортувати і приватний ключ і (загальнодоступний) сертифікат. Він запитає ім'я та пароль вашого адміністратора, щоб отримати доступ до брелка, а потім попросить новий пароль для шифрування експортованого файлу.

  2. Сертифікат та пов’язаний із ним приватний ключ також зберігаються (як ви вже сказали) у / etc / сертифікатах. Переконайтеся, що ви отримуєте як сертифікат (ім'я файлу, що закінчується ".cert.pem"), так і відповідний приватний ключ (".key.pem"); Вам також може знадобитися ланцюг cert (".chain.pem"), який включає ваш сертифікат та підтверджуючі сертифікати, які підтверджують його справжність.

    Файл приватного ключа буде зашифрований випадковим чином згенерованим паролем. Без проблем; для того, щоб серверні сервіси могли використовувати цей ключ, його пароль зберігається (фактично в системному брелоку) у формі, яку можна отримати. Маючи права адміністратора, ви можете отримати його так само, як це робить веб-сервер. Скористайтеся цією командою (замінивши server.example.com фактичним іменем домену):

    sudo /Library/Server/Web/Config/apache2/getsslpassphrase server.example.com:443 RSA
    

    Тут знадобиться пароль вашого адміністратора, а потім виплюнете те, що схоже на GUID. Це пароль шифрування для файлу .key.pem.

    (Примітка: у старих версіях OS X Server getsslpassphrase був у / etc / apache2 / замість / Library / Server / Web / Config / apache2 /. Налаштуйте за потребою.)

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.