Kyberturvallisuus

SSL-salaus ja TLS 1.3 -hardening WordPressille — A-luokka ilman ylioptimointia

Käytännön TLS 1.3 -hardening WordPress-sivulle: SSL Labs A-luokka, modernit cipher-asetukset, HSTS, OCSP stapling ja mixed content. Mikä on pakollista, mikä ylimääräistä 2026.

Olli Junes · · 9 min

SSL-salaus on WordPress-sivun perustaso, mutta hyvin harva pk-yrittäjän sivu on oikeasti hyvin konfiguroitu. Tyypillinen ero näkyy SSL Labsin testissä: oletusasennus saa B:n tai C:n, koska palvelin tukee yhä TLS 1.0:aa, listaa heikkoja ciphereita tai unohtaa HSTS-otsakkeen. A-luokkaan pääsy ei vaadi erikoisosaamista, mutta se vaatii että joku on käynyt asetukset läpi kerran kunnolla. Käydään läpi mitä TLS 1.3 -hardening WordPressillä käytännössä tarkoittaa vuonna 2026, mitä kannattaa tehdä itse ja mitä ei.

TLS 1.3 — mitä se on ja miksi sillä on väliä

TLS (Transport Layer Security) on protokolla joka salaa selaimen ja palvelimen välisen liikenteen. Kun puhutaan SSL-sertifikaatista, oikea tekninen termi on TLS-sertifikaatti; SSL on edeltäjäprotokolla joka poistui käytöstä jo viime vuosikymmenellä. TLS 1.3 julkaistiin elokuussa 2018, ja se on selvästi parempi kuin edeltäjänsä TLS 1.2 kahdessa asiassa.

Nopeudessa TLS 1.3 vähentää kättelyn yhden edestakaisen viestin verran. Käytännössä tämä lyhentää sivun ensimmäistä latausta muutamia kymmeniä millisekunteja, mikä näkyy etenkin mobiililaitteilla. Tietoturvassa TLS 1.3 poistaa kokonaan vanhentuneet algoritmit (RC4, 3DES, SHA-1, CBC-tila), joiden tunnetut heikkoudet ovat olleet hyökkäysvektoreita vuosikausia. Lisäksi se vaatii oletuksena forward secrecy -ominaisuuden: jos palvelimen yksityinen avain joskus paljastuu, hyökkääjä ei voi purkaa aiemmin tallennettua liikennettä.

WordPress-sivulle TLS 1.3:n tuki on käytännössä pakollinen 2026. Selaimet eivät enää näytä varoituksia vanhentuneista protokollista yhtä näkyvästi, mutta SSL Labs ja muut auditointityökalut alentavat luokkaa heti jos TLS 1.0 tai 1.1 on yhä päällä. Suomalaisten pk-sivustojen yleisin ongelma ei ole TLS 1.3:n puuttuminen — se on mukana lähes kaikissa nykyisissä webhotelliympäristöissä — vaan se että vanhat versiot ovat edelleen sallittuja samaan aikaan.

Selvitä nykytila: SSL Labs -testi

Ensimmäinen askel on aina mittaaminen. Avaa ssllabs.com/ssltest, syötä domain, odota pari minuuttia ja katso luokitus. Sivu antaa kirjainarvosanan A+, A, B, C, F sekä tarkat tiedot tuetuista protokollista, ciphereista, sertifikaattiketjusta ja yleisistä haavoittuvuuksista.

A-luokka edellyttää että palvelin tukee vain turvallisia protokollia (TLS 1.2 ja 1.3), käyttää avaintenvaihdossa ECDHE:tä tai DHE:tä turvallisilla parametreilla, käyttää vähintään 128-bittistä AEAD-salausta ja että sertifikaattiketju on eheä. A+-luokka vaatii lisäksi HSTS-otsakkeen pitkällä max-age-arvolla. Jos saat oletusasennuksella B:n, todennäköisin syy on jokin näistä kolmesta: TLS 1.0/1.1 yhä päällä, vanhentunut cipher-lista tai HSTS puuttuu.

F tai T (trust issues) tarkoittavat että sertifikaatti on viallinen, vanhentunut tai itse allekirjoitettu. Tämä on harvinaista oikealla webhotellilla mutta yleistä jos joku on yrittänyt asentaa Let's Encryptin manuaalisesti ilman uusintaprosessia.

Protokollat ja cipher-asetukset — älä keksi itse, käytä Mozillaa

Cipher-listojen kirjoittaminen käsin on virhealtista ja vanhenee nopeasti. Vuonna 2023 turvalliselta näyttänyt asetus voi olla 2026 jo riskialtis. Hyvä ratkaisu on käyttää Mozillan SSL Configuration Generator -työkalua, joka tarjoaa testatut nginx- ja Apache-asetukset kolmessa profiilissa.

Modern-profiili sallii vain TLS 1.3:n. Se on nopein ja turvallisin, mutta sulkee pois vanhat selaimet (käytännössä Internet Explorerin ja vanhojen Android-laitteiden esiasennetut selaimet). WordPress-sivulle joka palvelee suomalaista pk-yleisöä Modern toimii usein, mutta jos asiakaskunnassa on iäkkäämpää käyttäjäkuntaa tai erityislaitteita, jätä turvamarginaalia.

Intermediate-profiili sallii TLS 1.2:n ja 1.3:n. Tämä on oikea valinta valtaosalle pk-yrityksiä: yhteensopivuus on käytännössä 100 prosenttia kaikkien viimeisen kymmenen vuoden selainten kanssa, eikä turvataso kärsi merkittävästi.

Old-profiili sallii myös TLS 1.0:n ja 1.1:n. Älä käytä tätä WordPress-sivulle, ellet erikseen tiedä että asiakkaita tulee oikeasti vanhentuneilla selaimilla. SSL Labs alentaa luokituksen automaattisesti B:hen tai C:hen.

Yksi pieni mutta tärkeä yksityiskohta Mozillan profiileissa: ne suosittelevat ssl_prefer_server_ciphers off. Tämä menee vastoin vanhoja ohjeita, mutta nykyinen logiikka on että kun kaikki listan cipherit ovat turvallisia, anna selaimen valita laitteistolleen nopein. Mobiililaitteilla joilla ei ole AES-laitteistokiihdytystä ChaCha20-Poly1305 on nopeampi kuin AES-GCM.

HSTS — pakota selain HTTPS:ään, mutta varovasti

HTTP Strict Transport Security on vastausotsake jonka palvelin lähettää selaimelle. Se sanoo: "tästä eteenpäin älä koskaan yritä ladata tätä domainia HTTP:n yli, käytä aina HTTPS:ää". Tämä sulkee yhden yleisimmistä hyökkäysvektoreista, SSL strippingin, jossa hyökkääjä pakottaa selaimen putoamaan suojattomaan HTTP:hen.

Otsake näyttää käytännössä tältä:

Strict-Transport-Security: max-age=31536000; includeSubDomains

max-age kertoo kuinka monta sekuntia selain muistaa säännön. 31536000 on yksi vuosi, mikä on yleisin lähtöarvo. SSL Labs vaatii A+:aan vähintään puoli vuotta. Kun asetus on testattu toimivaksi, voi nostaa kahteen vuoteen (63072000).

includeSubDomains ulottaa säännön kaikkiin alidomaineihin. Tämä on tärkeä mutta vaarallinen lippu: jos sinulla on yhtäkään alidomainia joka palvelee yhä HTTP:tä (esim. vanha kehitysversio dev.yritys.fi), se lakkaa toimimasta selaimissa jotka ovat nähneet otsakkeen. Tarkista ennen lisäämistä.

preload on kolmas mahdollinen lippu, ja se on syytä jättää aluksi pois. Preload tarkoittaa että haluat sivustosi sisäänrakennetulle HSTS-listalle, joka tulee selainten mukana ilman että otsaketta tarvitsee nähdä kertaakaan. Hyöty on todellinen, mutta poisto on käytännössä mahdotonta — jos otat preloadin käyttöön ja joudut myöhemmin palaamaan HTTP:hen (esim. siirron yhteydessä), poistoprosessi selainvalmistajien listoilta kestää kuukausia. Älä preloadaa ennen kuin olet ajanut HSTS:ää ongelmitta puoli vuotta.

OCSP stapling — tilanne muuttui Let's Encryptin myötä

OCSP stapling on mekanismi jolla palvelin tarjoaa selaimelle valmiiksi haetun todistuksen siitä, ettei sertifikaatti ole peruutettu. Ilman staplingia selain joutuu kysymään tätä itse sertifikaatin myöntäjältä, mikä hidastaa sivun latausta ja paljastaa selaushistoriaa.

Tilanne on kuitenkin muuttunut 2025. Let's Encrypt, joka myöntää valtaosan pk-yritysten ilmaisista sertifikaateista, lopetti OCSP-tukensa kokonaan. Jos sivustosi sertifikaatti tulee Let's Encryptiltä — ja webhotelliympäristössä se lähes varmasti tulee — OCSP stapling -asetuksilla ei ole enää mitään vaikutusta. Niiden poistaminen konfiguraatiosta ei haittaa, mutta niiden lisäämisestä ei myöskään ole hyötyä.

Jos käytät maksullista sertifikaattia DigiCertiltä, GlobalSignilta tai Sectigolta, OCSP stapling on yhä järkevä päälle. Webhotellisi asettaa sen tyypillisesti automaattisesti, mutta SSL Labs -raportti kertoo onko se aktiivinen.

Mixed content — WordPressin yleisin nakertaja

Mixed content tarkoittaa että sivu ladataan HTTPS:n yli mutta sivulla on yksittäisiä resursseja (kuvia, skriptejä, tyylitiedostoja) jotka tulevat HTTP-osoitteista. Selain näyttää tässä tapauksessa lukon harmaana tai rikottuna, ja osa skripteistä jää lataamatta kokonaan.

WordPressissä tyypilliset syyt ovat kolme. Ensimmäinen on vanhat artikkelit, joissa kuvien polut on tallennettu HTTP-muotoon ennen sertifikaatin asennusta. Toinen on lisäosat tai teemat jotka lataavat fontteja, ikoneja tai analytiikkaskriptejä kovakoodatusti HTTP:n yli. Kolmas on ulkoiset upotukset (YouTube, Twitter, Google Maps), joissa upotuskoodi on vanhalta ajalta.

Korjaaminen kannattaa tehdä kahdessa vaiheessa. Aja ensin Better Search Replace- tai Velvet Blues Update URLs -lisäosalla domain-laajuinen korvaus tietokantaan: http://yritys.fihttps://yritys.fi. Tämä korjaa valtaosan vanhoista poluista. Sen jälkeen aja sivu Mozillan Observatory -työkalun tai selaimen konsolin (F12) läpi ja korjaa loput tapaukset käsin.

Pidemmän aikavälin ratkaisu on Content Security Policy -otsake direktiivillä upgrade-insecure-requests, joka kertoo selaimelle että nostaa kaikki HTTP-pyynnöt automaattisesti HTTPS:ään. Tämä piilottaa ongelman mutta ei korjaa juurisyytä — käytä korjauksen jälkeen turvaverkkona, ei ratkaisuna.

Mitä jätetään pois

Internet on täynnä TLS-hardening-oppaita jotka listaavat kymmeniä otsakkeita, evästemääritteitä ja palvelinkonfiguraatiokikkoja. Valtaosa niistä on hyödyllisiä erikoistapauksissa ja täysin tarpeettomia pk-yrityksen WordPress-sivulle.

Älä ota käyttöön HPKP-otsaketta (Public Key Pinning) — se on poistettu selaimista jo vuosia sitten, ja jäljellä oleva ohjeistus on vanhentunutta. Älä yritä konfiguroida custom Diffie-Hellman -parametreja käsin, ellet ymmärrä mitä teet — Mozillan profiilit hoitavat tämän. Älä poista TLS-sessiotikettejä ellei sinulla ole erityistä syytä, mutta jos käytät niitä, varmista että avaimet kierrätetään. Tämä on webhotellin vastuulla.

Yksi pieni nginx-yksityiskohta joka kannattaa tehdä: lisää server_tokens off;. Se estää palvelinta paljastamasta tarkkaa nginx-versiotaan vastauksissa, mikä vaikeuttaa hyökkääjien työtä kun he etsivät kohteita tunnetuille haavoittuvuuksille.

WordPress-spesifit asiat

WordPressin asetuksissa kannattaa varmistaa kaksi asiaa kun HTTPS on aktivoitu. Asetukset → Yleiset -sivulla sekä WordPress Address (URL) että Site Address (URL) pitää olla https://-muodossa. Jos toinen on HTTP, syntyy uudelleenohjaussilmukoita ja sekamuotosisältöä.

Wp-config.php-tiedostoon kannattaa lisätä:

define('FORCE_SSL_ADMIN', true);

Tämä pakottaa hallintapaneelin aina HTTPS:ään, mikä on tärkeää koska admin-evästeet vuotavat hyökkääjälle välittömästi jos joku pääsee verkossa kuuntelijaksi suojattoman yhteyden aikana.

Lisäosat Really Simple SSL tai vastaavat tekevät valtaosan tästä automaattisesti, mutta ne eivät korvaa palvelintason TLS-konfiguraatiota. Lisäosa voi pakottaa uudelleenohjaukset HTTPS:ään, mutta se ei voi sammuttaa TLS 1.0:n tukea palvelimelta. Se vaatii pääsyä nginx- tai Apache-konfiguraatioihin.

Resahost ja oletustaso

Yksi syy miksi rakennamme Resahostia on että pk-yrittäjän ei pitäisi joutua opettelemaan nginx-konfiguraatiota saadakseen SSL Labsin A-luokan. Resahost-paketeissa (49, 79, 129 €/kk) TLS 1.3 on päällä oletuksena, vanhat protokollat ovat pois, cipher-lista vastaa Mozillan Intermediate-profiilia ja HSTS on aktiivinen. Palvelimet ovat Hetznerin Helsingin datakeskuksessa, joten data ei matkaa ulos EU:sta. Sertifikaatti uusiutuu automaattisesti, eikä konfiguraatioon tarvitse koskea.

Tämä ei ole markkinointia vaan suunnittelupäätös: oikeasti yksinkertaisin paketti on sellainen jossa oletukset ovat valmiiksi kunnossa. Lue tarkemmin lähestymistavasta Yhden oven mallin manifestista.

Yhteenveto kolmena askeleena

Jos haluat WordPress-sivusi A-luokkaan ilman ylioptimointia, tee nämä kolme asiaa: aja SSL Labsin testi ja kirjoita ylös mikä luokitus tulee; vie palvelimen TLS-konfiguraatio Mozillan Intermediate-profiilin tasolle ja sammuta TLS 1.0/1.1; lisää HSTS-otsake max-age-arvolla 31536000. Korjaa mixed content -varoitukset Better Search Replace -lisäosalla. Tämän jälkeen ole tarkkana jokaisen sertifikaatin uusinnan yhteydessä, että automaatio toimii ja että SSL Labs -luokitus ei tipu.

Lue lisää aiheeseen liittyvistä artikkeleista: SSL-sertifikaatti — mitä se on ja miten valita 2026, Webhotelli-vertailu 2026 ja WordPress-haavoittuvuudet 2024–2026.