1. Навіщо встановлювати HTTPS локально?
2. Створення самоподпісанного сертифіката
3. установка сертифіката
4. Додаємо сертифікат в macOS Keychain

Локальна настройка HTTPS може стати досить складним завданням. Навіть якщо ви успішно вирішите питання з самоподпісанного сертифікатами, ви все одно зіткнетеся з помилками приватності в браузері. У цій статті я розповім вам про створення самоподпісанного сертифікатів, а також покажу вам цікавий трюк, який допоможе впоратися з помилками приватності в браузері.

Протягом приблизно року я працював з HTTPS в своїй локальному середовищі розробки. Минулого тижня я оновився до Google Chrome 58, і щось змінилося, моє середовище розробки перестала правильно функціонувати - я став отримувати повідомлення про приватності в браузері.

На відміну від минулих помилок приватності, тут вже не було варіанту «Add Exception». Я перевірив Firefox, і його поведінка була таким же. У Safari поки все як і раніше працювало.

Пошук по ERR_CERT_COMMON_NAME_INVALID практично не дав ніяких результатів, однак в кінцевому рахунку я виявив рішення в трекері багів Chromium. Виявилося, що Chrome і Firefox відмовилися від підтримки commonName відповідності в сертифікатах.

Мені вдалося виправити мою збірку, скориставшись пропозиціями в коментарі Chromium (я розповім про це далі). У цій статті я покажу вам, як позбавитися від помилок приватності в браузері. Я буду оновлювати цю статтю, якщо щось зміниться в майбутньому.

Навіщо встановлювати HTTPS локально?

Чому б просто не використовувати звичайний протокол HTTP локально? Причина проста: якщо ваш працює сайт перенесений на HTTPS, і ви ведете розробку локально на HTTP, ваші середовища розробки та продакшну будуть відрізнятися. Наприклад, моє середовище розробки є Ubuntu сервер на віртуальній машині VMware на Mac. Продакшн-середовище - це Ubuntu-сервер, що працює на Linode з практично аналогічною конфігурацією.

Природно, середовище розробки повинна бути максимально схожа на вашу продакшн-середу. Якщо цього не відбувається, ви отримуєте масу проблем, що виникають в продакшн, які не були видні в середовищі розробки. Розробка HTTP-сайту, коли ваш продакшн є HTTPS-сайт - це зайвий ризик.

Створення самоподпісанного сертифіката

Як і у випадку з включенням HTTPS в продакшн, вам спочатку знадобиться сертифікат. Для працюючого сайту ви зазвичай запитуєте сертифікат у засвідчувального центру, такого як Let's Encrypt, Comodo і т.д. Для локального середовища розробки можна цілком обійтися самоподпісанного сертифікатом, що генерується в командному рядку. Робиться це просто:

openssl req -new -sha256 -newkey rsa: 2048 -nodes \ -keyout dev.deliciousbrains.com.key -x509 -days 365 \ -out dev.deliciousbrains.com.crt

Виконавши цю команду, ви отримаєте ряд питань:

Country Name (2 letter code) [AU]: State or Province Name (full name) [Some-State]: Locality Name (eg, city) []: Organization Name (eg, company) [Internet Widgits Pty Ltd]: Organizational Unit Name (eg, section) []: Common Name (eg server FQDN or YOUR name) []: dev.deliciousbrains.com Email Address []:

Більшість з цих питань не так важливі для середовища розробки. Відповіді будуть відображатися при перегляді інформації в сертифікаті, але це ніяк не вплине на те, чи буде браузер вважати ваш сайт захищеним чи ні. Насправді єдине питання, на який потрібно дати відповідь - це Common Name (CN). Відповідь на це питання визначає, для якого домену сертифікат буде дійсний.

Однак зараз питання про CN також є неважливим. Що стосується Chrome 58 і Firefox 48, в них Common Name ігнорується при зіставленні доменного імені з сертифікатом. З цієї причини я і почав отримувати помилки приватності, коли оновився до Chrome 58.

«В RFC 2818 описані два методи зіставлення доменного імені з сертифікатом - використання доступних імен в розширенні subjectAlternativeName, або, в разі відсутності розширення SAN, відкат до commonName. Відкат до commonName був визнаний застарілим в RFC 2818 (опублікований ще в 2000 році), проте підтримка як і раніше залишалася в різних TLS-клієнтів, часто некоректно ».

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

Тому тепер доменне ім'я повинне визначатися в розширенні Subject Alternative Name (SAN) сертифікати:

При створенні самоподпісанного сертифіката нам потрібно надати конфігураційний файл в OpenSSL і визначити SAN в цьому файлі конфігурації. Команди будуть наступними:

openssl req -config dev.deliciousbrains.com.conf -new -sha256 -newkey rsa: 2048 \ -nodes -keyout dev.deliciousbrains.com.key -x509 -days 365 \ -out dev.deliciousbrains.com.crt

Для конфігураційного файлу dev.deliciousbrains.com.conf я використовував код з Stack Overflow, пов'язаний з коментарем в Chromium, який я вже згадував раніше.

Єдина зміна, яку я зробив, це замінив рядок DNS.1 = example.com на DNS.1 = dev.deliciousbrains.com і видалив інші рядки DNS під нею. Ось повний конфіг з віддаленими коментарями і очищенням форматування:

[Req] default_bits = 2048 default_keyfile = server-key.pem distinguished_name = subject req_extensions = req_ext x509_extensions = x509_ext string_mask = utf8only [subject] countryName = Country Name (2 letter code) countryName_default = US stateOrProvinceName = State or Province Name (full name) stateOrProvinceName_default = NY localityName = Locality Name (eg, city) localityName_default = New York organizationName = Organization Name (eg, company) organizationName_default = Example, LLC commonName = Common Name (eg server FQDN or YOUR name) commonName_default = Example Company emailAddress = Email Address emailAddress_default = [email protected] [x509_ext] subjectKeyIdentifier = hash authorityKeyIdentifier = keyid, issuer basicConstraints = CA: FALSE keyUsage = digitalSignature, keyEncipherment subjectAltName = @alternate_names nsComment = "OpenSSL Generated Certificate" [req_ext] subjectKeyIdentifier = hash basicConstraints = CA: FALSE keyUsage = digitalSignature, keyEnciphermen t subjectAltName = @alternate_names nsComment = "OpenSSL Generated Certificate" [alternate_names] DNS.1 = dev.deliciousbrains.com

Якщо ви використовуєте MAMP, у вас може виникнути спокуса створити свої самоподпісанного сертифікати через MAMP UI:

Я пробував це з MAMP 4.1.1, але, на жаль, він не визначає SAN, і тому ви отримаєте помилку приватності ERR_CERT_COMMON_NAME_INVALID в браузері. Поки розробники MAMP не оновиться програму для визначення SAN, вам доведеться створювати сертифікати в командному рядку і потім додавати їх в MAMP.

установка сертифіката

Потім вам потрібно буде встановити сертифікат в Nginx, Apache або на будь-який інший веб-сервер, який ви використовуєте. Я не буду описувати цей процес, оскільки він залежить від вашої середовища. У моєму випадку я просто слідував інструкціям Hosting WordPress Yourself. Якщо ви використовуєте MAMP, ви можете вибрати сертифікат і файли ключів через інтерфейс, як показано на скріншоті.

Після того, як ви відновите конфиг вашого веб-сервера і перезапустіть його (не забудьте це зробити), завантаження вашого сайту все одно призведе до появи помилки приватності в браузері.

Ви можете помітити, що тепер виникає інша помилка - ERR_CERT_AUTHORITY_INVALID. Браузер не довіряє сертифікату, тому що ми підписали його самостійно, а не отримали від засвідчує центру. Однак ми можемо додати сертифікат в систему macOS Keychain і вказати, що сертифікат завжди повинен бути довіреною.

Додаємо сертифікат в macOS Keychain

1. У Chrome відкриваємо розробляється сайт, який ви сконфигурировали для використання сертифіката
2. Клацаємо Cmd-Alt-I, щоб відкрити інструменти розробника
3. Клацаємо по вкладці Security
4. Клацаємо по кнопці View certificate

Ви повинні побачити це вікно.

Тепер перетягуємо іконку сертифіката в папку в додатку Finder.

Сертифікат буде створений в цій папці. Робимо подвійне клацання по файлу. Якщо у вас є численні keychain'и, ви повинні побачити наступне вікно:

Клацаємо Add. Якщо у вас тільки один keychain, то в такому випадку ваш сертифікат буде додано без будь-якого повідомлення. Незалежно від того, з'являлося чи повідомлення чи ні, у вас повинно відкритися вікно Keychain Access. Знайдіть там свій сертифікат:

Зробіть по ньому подвійне клацання. Відкриється вікно з інформацією про сертифікат. Розкрийте секцію Trust. Змініть поле «When using this certificate:» на «Always Trust».

Закрийте вікно сертифіката. Він попросить вас ввести пароль (або просканувати ваш палець), зробіть це. Тепер знову зайдіть на свій розробляється сайт.

Ви можете видалити файл сертифіката з папки, в яку ви його перетягнули, оскільки тепер він доданий в keychain системи.

Якщо вам потрібно SSL-сертифікат для активного сайту, ви можете завжди придбати його в магазині LeaderSSL .

Джерело: https://deliciousbrains.com