# TLS ja HTTPS oikein asetettuna

> TLS-asetukset verkkopalvelimelle BSI TR-02102:n ja TLSRefin mukaan: protokollat, salausjoukot, varmenteet ja tarkistuskomennot Nginxille ja Apachelle.

Lähde: https://phpsos.de/fi/blog/tls-https-richtig-konfigurieren/  
Tilanne: 25.10.2026  
Palveluntarjoaja: PHP SOS, PHP-hätäapu ja palvelimen tietoturva. Pikaapu WhatsAppilla: https://wa.me/491736494914?text=Hei%20PHP%20SOS%2C%20tarvitsemme%20apua%20PHP-palvelimemme%20kanssa.%20Yritys%3A%20%E2%80%A6%20Verkkosivusto%3A%20%E2%80%A6

**Lyhyesti:** Kunnollinen TLS-konfiguraatio verkkopalvelimelle tarjoaa vain TLS 1.2:ta ja TLS 1.3:a, käyttää salausjoukkoja, joissa on Forward Secrecy ja todennettu salaus (AES-GCM, ChaCha20-Poly1305), sekä varmennetta, jossa on ECDSA- tai riittävän pitkä RSA-avain ja joka uusiutuu automaattisesti. Suuntaa antavat BSI:n (Saksan liittovaltion tietoturvavirasto) ohje TR-02102-2 ja TLSRefin Server-Side-TLS-suositukset. Tarkistakaa tulos ulkopuolelta älkääkä unohtako yhteyksiä, joita PHP itse muodostaa.

## Miksi vanhat TLS-asetukset säilyvät niin pitkään

Selaimessa on lukko, joten salaus katsotaan hoidetuksi. Näin ajattelevat monet ylläpitäjät, ja siksi TLS-konfiguraatio pysyy usein vuosia muuttumattomana. Se on silloin peräisin palvelimen käyttöönoton ajalta, kopioidusta mallista tai paneelin oletusarvoista.

Ongelma: suositukset muuttuvat. Protokollaversiot korvataan, menetelmiä pidetään heikkoina, ja uusia avaintenvaihtomenetelmiä tulee lisää. BSI julkaisi TR-02102:n viimeksi versiona 2026-01 27.1.2026, ja siinä se viittaa jo hybridisiin kvanttiturvallisiin menetelmiin TLS 1.3:lle. Joka ei ole katsonut asetuksiaan vuosiin, ei todennäköisesti ole enää ajan tasalla.

Joka tarkistaa palvelimia PHP2Shellin takia joka tapauksessa, voi katsoa TLS-konfiguraation samalla kertaa. Se ei sulje PHP-aukkoa, mutta kuuluu jokaiseen kunnolliseen koventamiseen.

## Mihin hyvä TLS-konfiguraatio verkkopalvelimelle perustuu

Kaksi lähdettä on ylläpitäjille Euroopassa erityisen hyödyllisiä. **BSI TR-02102** arvioi kryptografisia menetelmiä; osa 2 käsittelee TLS:ää. Se on suunnattu ennen kaikkea kehittäjille ja suunnittelijoille, ja viranomaisille sekä säännellyille aloille se on usein mittapuu. **Server-Side-TLS-suosituksia**, joita aiemmin ylläpidettiin Mozillan wikissä, jatketaan nykyään TLSRefissä, ja ne tarjoavat konkreettisia, kopioitavia profiileja.

TLSRef erottaa versiossa 6.0 kaksi profiilia:

| Ominaisuus | Intermediate (useimmille verkkosivustoille) | Modern |
|---|---|---|
| Protokollat | TLS 1.2 ja TLS 1.3 | vain TLS 1.3 |
| Salausjoukot TLS 1.2 | ECDHE yhdessä AES-GCM:n tai ChaCha20-Poly1305:n kanssa | ei lainkaan |
| Avaintenvaihtoryhmät | X25519MLKEM768, X25519, prime256v1, secp384r1 | kuten Intermediate |
| Varmenne | ECDSA P-256 suositeltu tai RSA 2048 bittiä | ECDSA P-256 |
| Varmenteen voimassaoloaika | 90 päivää suositeltu, enintään 366 päivää | 90 päivää |
| HSTS max-age | kaksi vuotta | kaksi vuotta |

Julkisille verkkosivustoille Intermediate on tavallinen lähtökohta. Profiili sulkee pois hyvin vanhat laitteet, mutta kattaa nykyiset selaimet ja käyttöjärjestelmät. Hybridiryhmä X25519MLKEM768 edellyttää ajantasaista TLS-kirjastoa. Tarkistakaa, tunteeko OpenSSL-versionne sen, ennen kuin kirjaatte sen asetuksiin.

## Nginx ja Apache: turvallinen lähtökohta

Seuraavat esimerkit toteuttavat Intermediate-profiilin. Polut ovat paikkamerkkejä, salausjoukkojen luettelo koskee TLS 1.2:ta; TLS 1.3 tuo mukanaan omat turvalliset oletusmenetelmänsä.

```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
```

Toinen `server`-lohko ohjaa salaamattomat kutsut pysyvästi HTTPS:ään. Uudelleenohjauksen tulisi osoittaa suoraan lopulliseen osoitteeseen eikä kulkea useiden välietappien kautta. Tarkistakaa sen jälkeen myös upotetut resurssit: kuvat, skriptit tai fontit, jotka ladataan yhä HTTP:llä, aiheuttavat selaimessa varoituksia tai estetään.

Asetus, jossa asiakas valitsee järjestyksen, vastaa TLSRefin suositusta: kaikkia tarjottuja menetelmiä pidetään turvallisina, ja laitteet ilman AES-kiihdytystä voivat näin suosia ChaCha20:tä. Testatkaa konfiguraatio jokaisen muutoksen jälkeen (`nginx -t` tai `apachectl configtest`) ja ladatkaa palvelu uudelleen. Sopivan HSTS-otsikon ja muut selainohjeet kuvaa opas [Verkkosivustojen turvaotsikot](https://phpsos.de/fi/ratgeber/sicherheits-header/).

> **Vinkki:**
> Paneelit kuten Plesk tai cPanel ylikirjoittavat usein omat muutoksenne generoituihin tiedostoihin. Asettakaa TLS-määritykset siellä paneelin tarjoamien asetusten tai mallipohjien kautta.

## Varmenteet: avain, ketju, uusinta

Suuri osa käytännön TLS-ongelmista ei liity salausjoukkoihin vaan varmenteisiin. Tyypillisiä virheitä ovat puutteellinen ketju, josta välivarmenne puuttuu, sivudomainien vanhentuneet varmenteet ja yksityiset avaimet, joiden tiedosto-oikeudet ovat liian laajat.

Kolme sääntöä auttaa:

1. **Uusikaa automaattisesti** ja valvokaa uusintaa. Lyhyet voimassaoloajat, joita TLSRef suosittelee, ovat käytännöllisiä vain automaation kanssa.
2. **Suojatkaa yksityiset avaimet:** luettavissa vain rootille ja verkkopalvelinprosessille, ei koskaan verkkojuuressa, ei koskaan repositoriossa.
3. **Kartoittakaa kaikki nimet:** pääverkkotunnus, www, aliverkkotunnukset verkkokaupalle, stagingille, sähköpostin verkkokäyttöliittymälle ja paneeleille.

Joka käyttää varmenteita useassa paikassa, esimerkiksi CDN:ssä, kuormantasaajassa ja alkuperäpalvelimella, kannattaa pitää yleiskatsausta: mikä varmenne on asennettu minnekin, kuka sen uusii ja milloin se vanhenee. Ilman tätä yleiskatsausta vanhentunut varmenne huomataan usein vasta, kun asiakkaat ottavat yhteyttä.

## Näin tarkistatte konfiguraation ulkopuolelta

Seuraavat komennot ovat pelkkiä tarkistuksia, eivätkä muuta mitään. Korvatkaa isäntänimi omallanne:

```bash
# TLS 1.3:n ja TLS 1.2:n pitäisi toimia
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:n pitäisi epäonnistua
openssl s_client -connect www.example.de:443 -servername www.example.de -tls1_1 </dev/null
# Tarjotun varmenteen voimassaolo ja haltija
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 -testin epäonnistuminen voi johtua myös siitä, ettei paikallinen OpenSSL-versionne tarjoa vanhaa protokollaa enää lainkaan. Täydellistä raporttia kaikista tarjotuista menetelmistä varten sopii erikoistunut TLS-skanneri. Tarkistakaa siinä jokainen aliverkkotunnus erikseen, sillä ne toimivat usein omilla asetuksillaan.

## Unohdettu: TLS siellä, missä PHP itse on asiakas

PHP-sovellukset muodostavat itse monia yhteyksiä: maksupalveluihin, toimituspalveluihin, rajapintoihin, sähköpostipalvelimille ja tietokantoihin. Yleisin virhe ei tässä ole heikko asetus vaan kytketty pois varmenteen tarkistus, usein nopeana ratkaisuna kehityksen ongelmaan.

```php
<?php
// Turvallinen: varmenne ja isäntänimi tarkistetaan (säilytä oletuskäyttäytyminen)
$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);
```

Etsikää koodista `CURLOPT_SSL_VERIFYPEER` arvolla `false` sekä `verify_peer` stream-konteksteista. Jokainen löytö kumoaa TLS:n suojan tältä yhteydeltä käytännössä kokonaan. Missä palvelut ovat CDN:n takana, myös CDN:n ja alkuperäpalvelimen välisellä osuudella tulisi käyttää kelvollista, tarkistettua varmennetta. Lisää PHP-ympäristöjen verkkopalvelinasetuksia löydätte kirjoituksesta [Nginxin turvallinen asetus PHP:lle](https://phpsos.de/fi/blog/nginx-fuer-php-absichern/), koko koventamisen mittapuita kirjoituksesta [CIS-benchmarkit ja BSI-moduulit](https://phpsos.de/fi/blog/cis-benchmarks-bsi-bausteine/).

## Miten PHP SOS auttaa konkreettisesti?

- Kartoitamme kaikki isäntänimet ja TLS:ää käyttävät palvelut, myös paneelit, stagingin ja sähköpostin verkkokäyttöliittymät.
- Vertaamme asetukset TR-02102:een ja sopivaan TLSRef-profiiliin ja dokumentoimme tietoiset poikkeamat.
- Siirrämme varmenteet automaattiseen uusintaan ja valvontaan.
- Etsimme sovelluskoodista pois kytketyt varmenteen tarkistukset ja näytämme korjauksen.

TLS on yksi [PHP-verkkopalvelinten koventamisemme](https://phpsos.de/fi/leistungen/server-haertung/) osa; yhteyden ajankohtaiseen tilanteeseen selittää [Mikä on PHP2Shell?](https://phpsos.de/fi/php2shell/was-ist-php2shell/).


## Usein kysytyt kysymykset

**Pitääkö minun yhä tarjota TLS 1.0:aa ja TLS 1.1:tä?**  
Yleensä ei. Nykysuositukset, kuten TLSRefin Intermediate-profiili, asettavat alarajaksi TLS 1.2:n. Jos vanhempia protokollia tarvitaan vanhoille laitteille, päätös tulisi tehdä tietoisesti, dokumentoida ja rajata erilliseen palveluun.

**Onko ilmainen varmenne vähemmän turvallinen kuin ostettu?**  
Salauksen kannalta sillä ei ole merkitystä. Ratkaisevia ovat avaintyyppi, avaimen pituus, täydellinen varmenneketju ja luotettava automaattinen uusinta. Erot ovat tarkastuksen laajuudessa, voimassaoloajassa ja palveluntarjoajan palvelussa.

**Riittääkö HTTPS kävijän ja CDN:n välillä?**  
Ei. Myös CDN:n ja alkuperäpalvelimen välisen yhteyden tulisi olla salattu, ja sen tulisi tarkistaa alkuperäpalvelimen varmenne. Muuten tiedot kulkevat toisella osuudella salaamattomina tai tarkistamattomina verkossa.

**Mitä TLS:llä on tekemistä PHP2Shellin kanssa?**  
Suoraan ei mitään. TLS suojaa tietoja siirtotiellä, PHP2Shell koskee palvelimen PHP-tulkkia. Salattu yhteys kuljettaa myös hyökkäyspyynnöt luotettavasti, joten PHP-päivitys on pakollinen riippumatta tästä.

## Lähteet

- [BSI TR-02102: kryptografiset menetelmät, osa 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-dokumentaatio](https://nginx.org/en/docs/)
- [Apache HTTP Server: dokumentaatio](https://httpd.apache.org/docs/)