14.4.4. Сертифікати, підписані CA (публічно довірені)¶

Самопідписані сертифікати підходять, коли ви контролюєте обидва кінці. Якщо ж довільні клієнти (браузери, телефони, стороннє програмне забезпечення) повинні підключатися до камери без отримання вказівки довіряти власному сертифікату, цей сертифікат повинен бути підписаний публічним Центром сертифікації (CA), якому ці клієнти вже довіряють. TLS-код на камері ідентичний випадку з самопідписаним сертифікатом – load_cert_chain з сертифікатом і ключем у форматі DER – змінюється лише спосіб отримання сертифіката.

Найважливіший момент: ви генеруєте приватний ключ самостійно, і він ніколи не залишає вашу машину. CA його ніколи не бачить. Те, що ви надсилаєте CA, – це запит на підписання сертифіката (CSR) – невеликий файл, що містить ваш публічний ключ та доменне ім’я – а у відповідь ви отримуєте сертифікат (ваш публічний ключ і ім’я, підписані CA). Ключ і сертифікат – це два окремі файли, отримані двома окремими кроками; CA обробляє лише публічну половину.

Загальний процес, виконуваний на звичайній машині (ніколи не на камері):

Отримайте доменне ім’я. Публічні CA сертифікують DNS-ім’я, яке ви контролюєте (наприклад, cam.example.com); вони не видаватимуть сертифікат для чистої IP-адреси або локального імені на кшталт mycam.
Згенеруйте ключ і CSR. Одна команда OpenSSL створює приватний ключ і відповідний CSR. Використовуйте той самий тип ключа, що й для самопідписаного сертифіката (див. Концепції: довіра, ключі та формат файлів); рекомендується ECDSA P-256.

ECDSA P-256 – рекомендовано:
```
openssl req -new -newkey ec -pkeyopt ec_paramgen_curve:prime256v1 \
    -nodes -keyout domain.key -out domain.csr \
    -subj "/CN=cam.example.com" \
    -addext "subjectAltName=DNS:cam.example.com"
```
ECDSA P-384 – надійніше, більший/повільніший:
```
openssl req -new -newkey ec -pkeyopt ec_paramgen_curve:secp384r1 \
    -nodes -keyout domain.key -out domain.csr \
    -subj "/CN=cam.example.com" \
    -addext "subjectAltName=DNS:cam.example.com"
```
RSA-2048 – максимальна сумісність:
```
openssl req -new -newkey rsa:2048 \
    -nodes -keyout domain.key -out domain.csr \
    -subj "/CN=cam.example.com" \
    -addext "subjectAltName=DNS:cam.example.com"
```
Зберігайте domain.key у таємниці – це файл ключа, який ви врешті-решт розмістите на камері. domain.csr – це файл, який ви передаєте CA; він не містить жодних секретів.
Надішліть CSR та доведіть, що ви контролюєте домен. Тут два поширені шляхи розходяться:
- Автоматизований ACME CA, наприклад Let’s Encrypt, керований таким інструментом, як certbot або acme.sh, виконує кроки 2 і 3 за вас: він генерує ключ, будує CSR, автоматично відповідає на виклик (HTTP-01: надати токен через порт 80 на домені, або DNS-01: опублікувати TXT-запис у його DNS) і записує готові файли.
- Комерційний CA (придбаний безпосередньо або через реселера домену/хостингу): ви вставляєте текст domain.csr у веб-форму, а потім підтверджуєте контроль, відповівши на електронного листа для підтвердження, опублікувавши DNS-запис або розмістивши файл на веб-сервері цього домену. Після підтвердження ви завантажуєте видані файли.
Зберіть видані файли. Щоб зрозуміти, що ви отримали, корисно знати, що сертифікати утворюють ланцюжок довіри: сертифікат вашого домену підписаний проміжним CA, який своєю чергою підписаний кореневим CA. Кожна ланка поручається за ту, що нижче. У результаті ви маєте:
- Ваш приватний ключ (з кроку 2). CA його ніколи не мав; він залишається на вашій машині та є ключем, який ви врешті-решт розміщуєте на камері.
- Сертифікат листового вузла – також відомий як сертифікат кінцевого суб’єкта або сервера. Це сертифікат для вашого конкретного домену (cam.example.com): він містить ваш публічний ключ і ваше ім’я, підписані проміжним CA. Це сертифікат, який камера пред’являє для ідентифікації себе.
- Один або більше сертифікатів проміжного CA («ланцюжок» або «пакет CA»). CA не підписує ваш листовий сертифікат безпосередньо своїм кореневим – кореневий ключ зберігається офлайн під суворим захистом – тому він підписує проміжним, який сам підписаний кореневим. Проміжний сертифікат – це ланка, що з’єднує ваш листовий сертифікат із кореневим.
Сертифікат кореневого CA є якорем довіри: самопідписаний сертифікат, що належить CA і знаходиться на вершині ланцюжка. Вам його не надають і ви його ніде не розміщуєте, оскільки він вже є у кожного клієнта – операційні системи, браузери, телефони та мовні середовища виконання постачаються з вбудованим «сховищем довіри» кореневих сертифікатів. Клієнт довіряє вашому листовому сертифікату, проходячи ланцюжок: він вже довіряє кореневому, кореневий поручається за проміжний, а проміжний – за ваш листовий. (Саме це робить ваш єдиний server.der / cafile у випадку із самопідписаним сертифікатом – там ви є своїм власним кореневим CA.)

Файл fullchain – це просто листовий сертифікат та проміжний(і), об’єднані в один файл (листовий першим), навмисно без кореневого (надсилати кореневий безглуздо – клієнт довіряє лише тим кореневим, що вже має). Звичайний сервер надає весь цей повний ланцюжок, щоб будь-який клієнт міг його пройти. Камера не може: вона завантажує та надає один сертифікат – листовий – і не може також надіслати проміжний(і) сертифікат(и), отримані від CA.

Імена файлів, які ви реально побачите: інструмент ACME, наприклад certbot, записує privkey.pem (ваш ключ), cert.pem (лише листовий), chain.pem (лише проміжний(і)) та fullchain.pem (листовий + проміжний(і)). Комерційний CA зазвичай дає вам .crt для листового та .ca-bundle для проміжного(их), тоді як .key – це той, що ви згенерували самостійно.
Конвертуйте та скопіюйте. Конвертуйте приватний ключ і листовий сертифікат у DER та скопіюйте їх на камеру точно так само, як на сторінці Самопідписані сертифікати. Камера потім пред’являє їх як свій серверний сертифікат, а стандартні клієнти приймають з’єднання автоматично, оскільки вони вже довіряють CA – жодного налаштування на стороні клієнта не потрібно.

Порада

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

Клієнти, які вже мають кешований проміжний сертифікат CA – основні браузери та HTTPS-бібліотеки зазвичай так і роблять – самостійно добудовують ланцюжок і успішно підключаються.
Клієнти, які розраховують на те, що сервер надішле проміжний сертифікат, не пройдуть рукостискання з камерою.

Якщо кожен можливий клієнт повинен мати можливість підключитися, не завершуйте публічний TLS безпосередньо на камері. Розмістіть перед нею шлюз / зворотний проксі, який подає повний ланцюжок зовнішньому світу, а проксі підключається до камери за схемою із самопідписаним сертифікатом, описаною вище.