Розширення використання внутрішньокорпоративних сервісів, де-факто, є Web додатками, зростає з кожним днем. Це і портали Sharepoint і Project server, і Exchange OWA. Не кажучи вже про десятки самописних рішень.
І кожен подібний сервіс рано чи пізно приходить до тієї точки розвитку, коли цінність даних починає розуміти повністю захищений доступ навіть зсередини мережевого периметра. Тобто, використання SSL.
І все було б добре, якщо кожна компаній була загальновизнаним центром сертифікації. Але, зрозуміло, це не так.
А це означає, що кожен браузер кожного користувача кожної робочої станції буде отримувати сповіщення про те, що сертифікат вузла, до якого звертається користувач, не є виданими довіреною видавцем.
Так, звичайно ж, буде дивним припустити, що у великій мережі на клієнтів не поширена доменна політика, яка вказує правильний шлях до світлого майбутнього 😉 Але, на жаль, браузери альтернативні Internet Explorer, виявляються повністю безсилі і при зверненні до внутрішніх ресурсів, знову видають помилку довіри до пред'явленого сервером сертифікату.
Отже, нашим завданням є автоматизація імпорту довіреної кореневого сертифіката в локальне сховище сертифікатів FireFox. Для її вирішення нам знадобляться деякі додаткові компоненти:
З обох дистрибутивів скопіюємо вміст папок lib в окрему порожню папку, наприклад, c: \ cadd. Потім знайдемо всередині папки bin пакета NSS файл certutil.exe і також скопіюємо його в обрану нами директорію.
Тепер нам потрібно експортувати необхідний для додавання сертифікат кореневого центру (в залежності від архітектури мережі це також може бути сертифікат дочірнього центру, безпосередньо видав всі сертифікати в організації). Зробити це можна на будь-якій робочій станції мережі, запустивши оснащення «Сертифікати». Збережемо експортований сертифікат в ту ж саму папку c: \ cadd
Залишилося найцікавіше 😉 За допомогою створеного нами пакету бібліотек, модифікуємо базу сертифікатів FireFox. Правда, спочатку нам необхідно зрозуміти, де ж ця база знаходиться:
- Для систем за базі Windows XP профіль користувача, що містить в тому числі і базу сертифікатів, знаходиться по шляху% APPDATA% \ Mozilla \ Firefox \ Profiles \ [деякий заздалегідь невідоме ім'я] .default \
- Для систем на базі Windows Vista шлях, власне кажучи, точно такий же, вся різниця з'являється на етапі його перетворення токена% APPDATA% в абсолютне значення:
- Для XP абсолютний шлях, як правило виглядає так: C: \ Documents and Settings \ username \ Application Data \
- Для Vista, зазвичай, так: C: \ Users \ username \ AppData \ Roaming \
Таким чином, як ми бачимо, в повному шляху до профілю FireFox у нас є дві змінних в дорозі: папки username і [деякий заздалегідь невідоме ім'я] .default
Втім, ми можемо спростити своє завдання, вважаючи, що запускаємо скрипт для модифікації бази з ключами з-під того користувача, для якого нам і необхідно цю модифікацію здійснити. В цьому випадку, невідома змінна в шляху залишається всього одна і ми можемо написати, наприклад, наступний командний сценарій (c: \ cadd \ cadd.cmd):
for / D / R «% APPDATA% \ Mozilla \ Firefox \ Profiles» %% f in (* .default) do certutil.exe -A -n LibertineCA -t «TCu, Cu, Tuw» -d «%% f» -ic: \ cadd \ LibertineCA.cer
Так Так. Це дійсно все. Залишається тільки перезапустити FireFox і переконатися, що сертифікат кореневого цента успішно доданий в довірені.
В принципі, на цьому можна і зупинитися. Адже немає ні найменшої проблеми за допомогою sccm створити відповідний пакет з запуском від імені поточного увійшов на робочу станцію користувача.
А можна піти далі 😉
Змінимо наш командний сценарій наступним чином:
for / D %% f in ( «C: \ Documents and Settings \ *») do for / D %% z in ( «%% f \ Application Data \ Mozilla \ Firefox \ Profiles \ *. default») do certutil. exe -A -n LibertineCA -t «TCu, Cu, Tuw» -d «%% z» -ic: \ cadd \ LibertineCA.cer
for / D %% f in ( «C: \ Users \ *») do for / D %% z in ( «%% f \ AppData \ Roaming \ Mozilla \ Firefox \ Profiles \ *. default») do certutil.exe -A -n LibertineCA -t «TCu, Cu, Tuw» -d «%% z» -ic: \ cadd \ LibertineCA.cer
Кілька неестетично, зате, досить надійно. Тепер створимо пакет установки в sccm і заплануємо його запуск від імені локального адміністратора на всіх робочих станціях домену.