Files
XC_VM/docs/ru/administration/ssl-generation.md
T
Divarion-D 76844fef11 docs: restructure, fix PSR-4 drift, and unify en/ru
Overhaul the Docsify documentation (English + Russian) so it matches the current
codebase and follows one consistent pattern.

Content accuracy (post-migration):
- Rewrite development/autoloader.md to PSR-4 / Composer (the old XC_Autoloader
  scanner, igbinary tmp/cache/autoload_map and registerDirectories are gone).
- PascalCase every source path (src/core -> src/Core, domain/Stream, cli/Commands,
  public/Controllers, Infrastructure/Redis, ...) across all docs.
- Replace the removed autoload.php references with vendor/autoload.php
  (build_system, bootstrap-contexts, error-handling, modules).
- ssl-generation: note that the installer now auto-generates a unique self-signed
  certificate before Nginx starts.

Common pattern (Clean & uniform):
- Strip emoji from headings; remove the in-page Navigation blocks (the Docsify
  sidebar already provides navigation).
- One H1 + intro per doc; uniform "Related files" / "Связанные файлы" section,
  added to the code-centric docs that lacked it.

Structure:
- Remove the empty stray docs/api/; move updates_checklist.md into builds/;
  link the previously-orphaned ucs-integration.md.
- Regroup the sidebars (split the oversized guides group into Developer Guides /
  Security & Access / Integrations; fold builds into Build & Release).

Augment:
- dev-workflow: Local Setup (make dev-tools) + Quality Checks (phpstan, cs, gates).
- build_system: Composer Dependencies section (committed prod-only vendor,
  committed lock, dev tools via composer install, no build-time vendor step).

en/ru parity:
- Apply the same structure, fixes and pattern to docs/ru/ (translated), including
  a new Russian ucs-integration.md. The en and ru file sets are now identical.
2026-06-26 15:56:15 +03:00

141 lines
5.8 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# Генерация SSL-сертификата для Nginx в XC_VM
В этом документе описан процесс создания самоподписанного SSL-сертификата. Следуйте шагам, чтобы настроить безопасное HTTPS-соединение.
> **Примечание:** Свежая установка уже генерирует **уникальный** самоподписанный
> сертификат автоматически (инсталлятор запускает `openssl` и пишет
> `server.key`/`server.crt` в `bin/nginx/conf/` до старта Nginx), а `CertbotCronJob`
> позже заменяет его настоящим сертификатом Let's Encrypt. Следуйте этому
> руководству только для **ручной перегенерации или замены** сертификата.
---
## Обзор
**SSL (Secure Sockets Layer)** используется для шифрования соединений между клиентом и сервером, обеспечивая безопасность данных и доверие пользователей.
В этой инструкции показано, как создать **самоподписанный SSL-сертификат** для встроенного **Nginx** в проекте **XC_VM**.
---
## Расположение конфигурации
Все SSL-файлы (ключ, сертификат и конфигурация) хранятся в директории:
```bash
/home/xc_vm/bin/nginx/conf
```
Перед началом работы перейдите в неё:
```bash
cd /home/xc_vm/bin/nginx/conf
```
---
## Шаг 1. Создание приватного ключа
Сгенерируйте **RSA-приватный ключ** (2048 бит):
```bash
openssl genrsa -out server.key 2048
```
📄 После выполнения появится файл `server.key`, содержащий **закрытый ключ**.
Храните его **в секрете** — этот файл используется для подписи SSL-сертификата.
---
## Шаг 2. Создание конфигурационного файла `server.cnf`
Создайте файл конфигурации с параметрами сертификата:
```bash
cat > server.cnf << EOF
[req]
distinguished_name = req_distinguished_name
x509_extensions = v3_req
prompt = no
[req_distinguished_name]
C = RU
ST = Moscow
L = Moscow
O = XC_VM
OU = XC_VM
CN = XC_VM
[v3_req]
keyUsage = keyEncipherment, dataEncipherment
extendedKeyUsage = serverAuth
subjectAltName = @alt_names
[alt_names]
DNS.1 = XC_VM
EOF
```
📘 **Описание параметров:**
| Поле | Значение | Назначение |
| ------- | -------- | ------------------------------- |
| `C` | RU | Страна (Country) |
| `ST` | Moscow | Регион (State) |
| `L` | Moscow | Город (Locality) |
| `O` | XC_VM | Организация |
| `OU` | XC_VM | Отдел / подразделение |
| `CN` | XC_VM | Имя хоста (Common Name) |
| `DNS.1` | XC_VM | Альтернативное имя домена (SAN) |
> 💡 **Совет:** можно указать реальное доменное имя, например `DNS.1 = example.com`, чтобы избежать предупреждений в браузере.
---
## Шаг 3. Генерация самоподписанного SSL-сертификата
Сгенерируйте сертификат с помощью созданного ключа и конфигурации:
```bash
openssl req -new -x509 -key server.key -out server.crt -days 3650 -config server.cnf
```
📆 **Пояснения:**
* `-new -x509` — создаёт новый самоподписанный сертификат.
* `-days 3650` — срок действия сертификата (10 лет).
* `-config server.cnf` — использование конфигурационного файла.
* Результатом будет файл `server.crt`.
---
## Итоговые файлы
После всех шагов в `/home/xc_vm/bin/nginx/conf` должны находиться:
| Файл | Назначение |
| ------------ | ------------------------------ |
| `server.key` | Приватный ключ |
| `server.crt` | Самоподписанный SSL-сертификат |
| `server.cnf` | Конфигурация сертификата |
---
## Результат
Теперь ваш **XC_VM Nginx сервер** доступен по протоколу **HTTPS**, используя созданный самоподписанный сертификат.
Браузеры могут предупреждать о «недоверенном сертификате» — это нормально для самоподписанных SSL.
---
## Примечания
* Самоподписанные сертификаты подходят **для внутреннего использования или тестирования**.
* Для публичных доменов используйте сертификаты от **доверенных центров** (например, [Let's Encrypt](https://letsencrypt.org/)).
* При изменении доменного имени (`CN` или `DNS.1`) необходимо **сгенерировать сертификат заново**.
* Чтобы проверить сертификат, выполните:
```bash
openssl x509 -in server.crt -text -noout
```
---