TLS ja HTTPS oikein asetettuna

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:

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ä.

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;
}

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.

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:

# 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
// 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, koko koventamisen mittapuita kirjoituksesta CIS-benchmarkit ja BSI-moduulit.

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 osa; yhteyden ajankohtaiseen tilanteeseen selittää Mikä on PHP2Shell?.

Usein kysytyt kysymykset

Lähteet

• BSI TR-02102: kryptografiset menetelmät, osa 2 TLS
• TLSRef: Server-Side TLS Guidelines
• Nginx-dokumentaatio
• Apache HTTP Server: dokumentaatio