У нас є веб-сервіс, який використовує наш додаток, і розробники вимагають підключення https до веб-сервісу. Оскільки це внутрішня веб-послуга, чи використовуєте ви сертифікат, який підписався самостійно?
У нас є веб-сервіс, який використовує наш додаток, і розробники вимагають підключення https до веб-сервісу. Оскільки це внутрішня веб-послуга, чи використовуєте ви сертифікат, який підписався самостійно?
Відповіді:
Замість того, щоб сертифікувати сертифікат, який я підписав самостійно, я створив локальний кореневий CA, а потім генерував би SSL cert з цього, гарантуючи, що всі внутрішні системи мають копію відкритого ключа кореневого CA.
Створені таким чином ключі мають безліч застосувань поза звичайним HTTPS, їх також можна використовувати для OpenVPN, POP3S, SMTPS тощо, навіть для окремих акаунтів SMIME.
Мати єдиний корінний офіційний центр для вашої організації - це набагато краще, ніж проводити викуп у визнаних ЦА, які стягуватимуть плату за кожен сервер, на який ви хочете отримати сертифікат, і смієте стягувати з вас плату за ліцензію, якщо хочете щоб розмістити один і той же серт на декількох серверах в кластері, збалансованому навантаженням.
спробуйте CAcert . вони безкоштовні, вам просто потрібно встановити корінь. на один крок вище, щоб мати самопідписані сертифікати.
Якщо вартість є проблемою, і ви орієнтовані на Windows, як пропонує пан Денні, перейдіть з сервісами сертифікатів Microsoft і розгорніть сертифікати як частина GPO домену за замовчуванням. Вам, швидше за все, знадобляться три системи, але тоді вони можуть бути машинами управління. Вам знадобиться кореневий CA, який слід використовувати лише для видачі сертифікатів для проміжних ЦО. У вас повинен бути один проміжний CA як Enterprise CA, а потім третій як "окремий" CA, щоб ви могли видавати сертифікати для недоменних активів.
Якщо у вас багато клієнтів і ви досить великі, ви можете поглянути на те, що ви маєте корінь одного із сторонніх рішень та видаєте власні сертифікати від КА, які отримують його сертифікат від зазначеної третьої сторони. Таким чином, вам не потрібно розгортати сертифікат CA. Наприклад, є рішення від GeoTrust .
За низької ціни стартерних сертів, як-от quickssl, я, мабуть, придбаю одну з них, принаймні, якщо вам потрібна лише мінімальна їх кількість. Я вважаю, що варто того невеликого внеску, щоб зупинити користувачів, щоб просити прийняти непідтверджений самопідписаний сертифікат, оскільки це завжди спричиняє деякі проблеми з нетехнічними користувачами.
Якщо припустити, що ви домен Windows для своїх робочих столів, встановіть Windows CA в будинку, якому автоматично будуть довіряти всі комп'ютери компанії через AD. Таким чином, ви можете видавати сертифікати для будь-яких внутрішніх додатків, які вам потрібні, не купуючи сертифікат.
Як правило, так, я б використовував сертифікат PEM, який підписався власноруч. Однак наскільки чутливим є сайт у вашій інтрамережі? Дотримуйтесь належних практик щодо машини, яка фактично підписує сертифікати .. та інших, які можуть або не стосуються вас.
Крім того, як буде налаштований внутрішній магазин CA для користувачів? Після того, як ви приймете сертифікат, ви дізнаєтесь, чи зміниться він .. що повертає мене до передового досвіду, пов’язаного з машиною, яка насправді їх підписує (тобто підпишіть, а потім відключіть її від мережі).
Зручно мати власний внутрішній офіс, якщо ви керуєте ним правильно. Будь ласка, надайте більше інформації.
Проблема з самопідписаним сертифікатом полягає в тому, що клієнти, як правило, подають попередження про неперевіреність. Залежно від параметрів безпеки, деякі можуть взагалі заблокувати їх.
Якщо це суто внутрішня потреба, навіщо навіть використовувати https, встановлений з http?
Особисто я б або дотримувався http або купував дешевий сертифікат (вони не такі дорогі).