# Правилна конфигурация на TLS и HTTPS

> TLS конфигурация на уеб сървър по BSI TR-02102 и TLSRef: протоколи, набори от шифри, сертификати и команди за проверка за Nginx, Apache и PHP клиенти.

Източник: https://phpsos.de/bg/blog/tls-https-richtig-konfigurieren/  
Актуалност: 25.10.2026  
Доставчик: PHP SOS, Спешна помощ за PHP и сигурност на сървъри. Незабавна помощ по WhatsApp: https://wa.me/491736494914?text=%D0%97%D0%B4%D1%80%D0%B0%D0%B2%D0%B5%D0%B9%D1%82%D0%B5%2C%20PHP%20SOS%2C%20%D0%B8%D0%BC%D0%B0%D0%BC%D0%B5%20%D0%BD%D1%83%D0%B6%D0%B4%D0%B0%20%D0%BE%D1%82%20%D0%BF%D0%BE%D0%BC%D0%BE%D1%89%20%D1%81%20%D0%BD%D0%B0%D1%88%D0%B8%D1%8F%20PHP%20%D1%81%D1%8A%D1%80%D0%B2%D1%8A%D1%80.%20%D0%A4%D0%B8%D1%80%D0%BC%D0%B0%3A%20%E2%80%A6%20%D0%A3%D0%B5%D0%B1%D1%81%D0%B0%D0%B9%D1%82%3A%20%E2%80%A6

**Накратко:** Надеждната TLS конфигурация на уеб сървър предлага само TLS 1.2 и TLS 1.3, използва набори от шифри (cipher suites) с Forward Secrecy и удостоверено шифроване (AES-GCM, ChaCha20-Poly1305) и сертификат с ECDSA или достатъчно дълъг RSA ключ, който се подновява автоматично. Ориентир дават насоките на BSI (Федералната служба за информационна сигурност на Германия) TR-02102-2 и препоръките Server-Side TLS на TLSRef. Проверете резултата отвън и не забравяйте връзките, които PHP сам изгражда.

## Защо старите TLS настройки оцеляват толкова дълго

Катинарчето в браузъра го има, значи шифроването се смята за свършена работа. Така мислят много оператори и затова TLS конфигурацията често остава непроменена с години. Тя идва от времето на настройката на сървъра, от копиран шаблон или от стандартните стойности на един панел.

Проблемът: препоръките се променят. Версии на протоколи биват заменени, методи се смятат за слаби, добавят се нови методи за обмен на ключове. BSI публикува TR-02102 за последно във версия 2026-01 от 27.01.2026 г. и вече сочи там хибридни постквантови методи за TLS 1.3. Който не е поглеждал настройките си с години, най-вероятно вече не е на актуалното ниво.

Който така или иначе проверява сървъри след PHP2Shell, може да прегледа TLS конфигурацията наведнъж. Тя не затваря уязвимостта на PHP, но принадлежи към всяко прилично заздравяване.

## На какво се опира добрата TLS конфигурация на уеб сървър

Два източника са особено полезни за оператори в Германия. **BSI TR-02102** оценява криптографските методи; част 2 разглежда TLS. Тя е насочена най-вече към разработчици и проектанти и за държавни органи и регулирани сектори често е мерилото. **Препоръките Server-Side TLS**, които преди се поддържаха в уикито на Mozilla, днес се продължават в TLSRef и предлагат конкретни профили, готови за копиране.

TLSRef разграничава във версия 6.0 два профила:

| Характеристика | Intermediate (за повечето уебсайтове) | Modern |
|---|---|---|
| Протоколи | TLS 1.2 и TLS 1.3 | само TLS 1.3 |
| Набори от шифри TLS 1.2 | ECDHE с AES-GCM или ChaCha20-Poly1305 | няма |
| Групи за обмен на ключове | X25519MLKEM768, X25519, prime256v1, secp384r1 | както при Intermediate |
| Сертификат | препоръчва се ECDSA P-256 или RSA 2048 бита | ECDSA P-256 |
| Срок на валидност на сертификата | препоръчват се 90 дни, най-много 366 дни | 90 дни |
| HSTS max-age | две години | две години |

За публичните уебсайтове Intermediate е обичайната отправна точка. Профилът изключва много стари устройства, но покрива актуалните браузъри и операционни системи. Хибридната група X25519MLKEM768 изисква актуална TLS библиотека. Проверете дали Вашата версия на OpenSSL я познава, преди да я въведете.

## Nginx и Apache: сигурна отправна точка

Следващите примери реализират профила Intermediate. Пътищата са примерни стойности, списъкът с набори от шифри важи за TLS 1.2; TLS 1.3 носи собствени, сигурни стандартни методи.

```nginx
server {
    listen 443 ssl;
    server_name www.example.de;

    ssl_certificate     /etc/ssl/example/fullchain.pem;
    ssl_certificate_key /etc/ssl/example/privkey.pem;

    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305;
    ssl_prefer_server_ciphers off;
}

server {
    listen 80;
    server_name www.example.de;
    return 301 https://$host$request_uri;
}
```

```apache
SSLProtocol             -all +TLSv1.2 +TLSv1.3
SSLCipherSuite          ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305
SSLHonorCipherOrder     off
```

Вторият блок `server` пренасочва постоянно нешифрованите извиквания към HTTPS. Пренасочването трябва да сочи директно към крайния адрес и да не минава през няколко междинни спирки. След това проверете и вградените ресурси: изображения, скриптове или шрифтове, които още се зареждат през HTTP, предизвикват предупреждения в браузъра или биват блокирани.

Настройката клиентът да избира реда съответства на препоръката на TLSRef: всички предлагани методи се смятат за сигурни и устройства без AES ускорение така могат да предпочетат ChaCha20. След всяка промяна тествайте конфигурацията (`nginx -t`, съответно `apachectl configtest`) и презаредете услугата. Подходящата HSTS заглавна част и други указания за браузъра описва наръчникът [Защитни заглавни части (headers) за уебсайтове](https://phpsos.de/bg/ratgeber/sicherheits-header/).

> **Съвет:**
> Панели като Plesk или cPanel често презаписват собствените Ви промени в генерираните файлове. Задавайте TLS настройките там чрез предвидените настройки или шаблони на панела.

## Сертификати: ключ, верига, подновяване

Голяма част от проблемите с TLS на практика нямат нищо общо с наборите от шифри, а със сертификатите. Типични грешки са непълна верига, при която липсва междинният сертификат, изтекли сертификати на второстепенни домейни и частни ключове със твърде широки права върху файла.

Три правила помагат:

1. **Подновявайте автоматично** и наблюдавайте подновяването. Кратките срокове на валидност, каквито препоръчва TLSRef, са практични само с автоматизация.
2. **Защитавайте частните ключове:** четими само за root и за процеса на уеб сървъра, никога в уеб корена (webroot), никога в хранилище (repository).
3. **Отчетете всички имена:** основния домейн, www, поддомейни за магазин, staging, уеб интерфейс на пощата и панели.

Който използва сертификати на няколко места, например на CDN, балансьор на натоварването и първоизточник, трябва да води преглед: кой сертификат къде е инсталиран, кой го подновява и кога изтича. Когато този преглед липсва, изтекъл сертификат често се забелязва едва когато се обадят клиентите.

## Как да проверите конфигурацията си отвън

Следващите команди са чисти проверки и не променят нищо. Заменете името на хоста със своето:

```bash
# TLS 1.3 и TLS 1.2 трябва да работят
openssl s_client -connect www.example.de:443 -servername www.example.de -tls1_3 </dev/null
openssl s_client -connect www.example.de:443 -servername www.example.de -tls1_2 </dev/null
# TLS 1.1 трябва да се провали
openssl s_client -connect www.example.de:443 -servername www.example.de -tls1_1 </dev/null
# Срок и притежател на предоставения сертификат
openssl s_client -connect www.example.de:443 -servername www.example.de </dev/null 2>/dev/null | openssl x509 -noout -subject -dates
```

Неуспех при теста за TLS 1.1 може да се дължи и на това, че Вашата локална версия на OpenSSL изобщо не предлага вече стария протокол. За пълен отчет за всички предлагани методи е подходящ специализиран TLS скенер. Проверявайте при това всеки поддомейн поотделно, защото често работят със собствени настройки.

## Забравено: TLS там, където PHP сам е клиент

PHP приложенията сами изграждат много връзки: към доставчици на плащания, към куриерски услуги, към интерфейси, пощенски сървъри и бази данни. Тук най-честата грешка не е слаба настройка, а изключена проверка на сертификата, често като бързо решение на проблем при разработката.

```php
<?php
// Сигурно: сертификатът и името на хоста се проверяват (запазете стандартното поведение)
$ch = curl_init('https://api.partner.example/v1/status');
curl_setopt_array($ch, [
    CURLOPT_RETURNTRANSFER => true,
    CURLOPT_SSL_VERIFYPEER => true,
    CURLOPT_SSL_VERIFYHOST => 2,
    CURLOPT_TIMEOUT        => 10,
]);
$antwort = curl_exec($ch);
```

Потърсете в кода `CURLOPT_SSL_VERIFYPEER` със стойност `false` и `verify_peer` в stream контексти. Всяко намерено място на практика премахва защитата на TLS за тази връзка. Където услугите са зад CDN, и участъкът между CDN и първоизточника трябва да използва валиден, проверяван сертификат. Допълнителни настройки на уеб сървъра за PHP конфигурации ще намерите в [Сигурно конфигуриране на Nginx за PHP](https://phpsos.de/bg/blog/nginx-fuer-php-absichern/), мерила за цялостното заздравяване в [CIS Benchmarks и модули на BSI](https://phpsos.de/bg/blog/cis-benchmarks-bsi-bausteine/).

## Как помага PHP SOS конкретно?

- Отчитаме всички имена на хостове и услуги с TLS, включително панели, staging и уеб интерфейси на пощата.
- Сверяваме настройките с TR-02102 и подходящия профил на TLSRef и документираме съзнателните отклонения.
- Преминаваме сертификатите към автоматично подновяване с наблюдение.
- Търсим в кода на приложението изключени проверки на сертификати и показваме корекцията.

TLS е един от модулите на нашето [заздравяване на сървъри за PHP уеб сървъри](https://phpsos.de/bg/leistungen/server-haertung/); връзката с актуалната ситуация обяснява [Какво е PHP2Shell?](https://phpsos.de/bg/php2shell/was-ist-php2shell/).


## Често задавани въпроси

**Трябва ли още да предлагам TLS 1.0 и TLS 1.1?**  
По правило не. Актуални препоръки като профила Intermediate на TLSRef определят TLS 1.2 като долна граница. Който се нуждае от по-стари протоколи заради стари устройства, трябва да вземе това решение съзнателно, да го документира и да го ограничи до отделна услуга.

**По-малко сигурен ли е безплатният сертификат от купения?**  
За шифроването няма разлика. Решаващи са типът на ключа, дължината на ключа, пълната верига от сертификати и надеждното автоматично подновяване. Разликите са в обема на проверката, срока на валидност и обслужването от страна на доставчика.

**Достатъчно ли е HTTPS между посетителя и CDN?**  
Не. И връзката между CDN и първоизточника на сървъра трябва да е шифрована и да проверява сертификата на първоизточника. Иначе данните минават през мрежата по втория участък нешифровани или непроверени.

**Какво общо има TLS с PHP2Shell?**  
Пряко нищо. TLS защитава данните по пътя на предаване, а PHP2Shell засяга интерпретатора на PHP на сървъра. Шифрованата връзка пренася надеждно и атакуващите заявки, затова актуализацията на PHP остава задължителна независимо от това.

## Източници

- [BSI TR-02102: Криптографски методи, част 2 TLS](https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/Technische-Richtlinien/TR-nach-Thema-sortiert/tr02102/tr-02102.html)
- [TLSRef: Server-Side TLS Guidelines](https://docs.tlsref.org/)
- [Документация на Nginx](https://nginx.org/en/docs/)
- [Apache HTTP Server: документация](https://httpd.apache.org/docs/)