SSL/TLS-varmenteen vanheneminen: miksi se kaataa yhä verkkosivustoja

Kun TLS-varmenne vanhenee, selaimet lakkaavat luottamasta yhteyteen ja näyttävät verkkosivustonne sijaan koko sivun varoituksen. Samaan palvelimeen yhteyttä ottavat rajapinnat, mobiilisovellukset ja integraatiot yleensä lakkaavat toimimasta kokonaan, koska niiden asiakasohjelmat hylkäävät vanhentuneen varmenteen kysymättä keneltäkään. Sivusto voi itsessään toimia moitteettomasti, mutta kävijöille se on poissa käytöstä.

Uusiminen on ollut automatisoitua jo vuosia, joten miksi näin käy yhä? Koska automaatio kattaa vain ne varmenteet, jotka joku muisti automatisoida. Vanhenemisesta johtuvat katkot tulevat yleensä unohdetuista varmenteista: kampanjaa varten perustetusta aliverkkotunnuksesta, kuormantasaajasta, jolle varmenne on ladattu käsin, sähköpostipalvelimesta tai uusimistehtävästä, joka on epäonnistunut hiljaa jo viikkojen ajan.

Varmenteiden voimassaoloajat myös lyhenevät, joten jokaista uusimisprosessia käytetään yhä useammin.

Varmenteiden voimassaoloajat lyhenevät

CA/Browser Forum laatii säännöt, joita selainten hyväksymät varmentajat noudattavat. Huhtikuussa 2025 se hyväksyi äänestyksen SC-081v3, ja nykyiset TLS Baseline Requirements (kohta 6.3.2) asettavat varmenteen enimmäisvoimassaololle seuraavan aikataulun:

• ennen 15.3.2026 myönnetyt: enintään 398 päivää,
• 15.3.2026 alkaen myönnetyt: enintään 200 päivää,
• 15.3.2027 alkaen myönnetyt: enintään 100 päivää,
• 15.3.2029 alkaen myönnetyt: enintään 47 päivää.

Käytännössä tämä tarkoittaa, että vuoteen 2029 mennessä käsin uusittava varmenne pitäisi vaihtaa noin 6 tai 7 viikon välein. Jokaisesta varmenteesta, jota uusitaan yhä käsin kalenterimuistutuksen perusteella, tulee toistuva katkoriski.

Varmentajan muistutuksiin ei myöskään kannata nojata. Esimerkiksi Let's Encrypt lopetti vanhenemisilmoitukset sähköpostitse 4.6.2025.

Miksi uusiminen epäonnistuu

Tavalliset syyt ovat arkisia:

• Validointi epäonnistuu. HTTP-validointi rikkoutuu uudelleenohjauksen tai palomuurimuutoksen jälkeen, DNS-validointi DNS-palveluntarjoajan vaihdon tai vanhentuneen API-tunnisteen jälkeen.
• Uusiminen onnistuu, mutta palvelua ei ladata uudelleen, joten verkkopalvelin tarjoaa yhä vanhaa varmennetta.
• Varmenteet on kopioitu käsin kuormantasaajaan, CDN:ään, laitteeseen tai sähköpostipalvelimeen, johon automaatio ei ulotu.
• Palvelimella ei ole omistajaa. Testipalvelimilla ja vanhoilla markkinoinnin aliverkkotunnuksilla on usein varmenne mutta ei omistajaa. Lisää artikkelissa unohdetut staging- ja testipalvelimet.
• Kaupallisen varmenteen tili tai maksu on rauennut.
• Välivarmenneketju on puutteellinen, jolloin osa asiakasohjelmista hylkää varmenteen jo ennen vanhenemista.

Miten tarkistatte varmenteen voimassaolon itse

Yksittäiselle palvelimelle openssl näyttää päivämäärät, jotka palvelin todella esittää:

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -dates -issuer

Katsokaa kohtaa notAfter. Tarkistakaa jokainen nimi erikseen, myös www, rajapintapalvelimet ja sähköpostipalvelimet. STARTTLS:ää käyttävän sähköpostipalvelimen voi tarkistaa näin:

echo | openssl s_client -starttls smtp -connect mail.example.com:25 2>/dev/null | openssl x509 -noout -enddate

Unohtuneet palvelimet löydätte hakemalla Certificate Transparency -lokeista palvelussa crt.sh hakulausekkeella %.example.com. Siellä näkyy jokainen verkkotunnuksellenne myönnetty varmenne, myös aliverkkotunnuksille, joita kukaan ei enää muista. Artikkelimme Certificate Transparency -lokeista kertoo, miten tuloksia luetaan.

Miten estätte varmenteiden vanhenemisen

1. Automatisoikaa myöntäminen ja uusiminen ACME-protokollalla aina, kun mahdollista, ja varmistakaa, että uusimistehtävä lataa palvelun uudelleen.
2. Uusikaa hyvissä ajoin ennen vanhenemista, niin että epäonnistuneen validoinnin korjaamiseen jää aikaa.
3. Asettakaa hälytys epäonnistuneesta uusimisesta, ei vain onnistuneesta. Cron-tehtävä, joka päättyy virheeseen kertomatta kenellekään, on klassinen syy.
4. Pitäkää luetteloa jokaisesta palvelimesta, jolla on varmenne, ja koostakaa se Certificate Transparency -tuloksista, ei muistinvaraisesti.
5. Valvokaa ulkopuolelta. Tarkistakaa varmenne, jonka palvelin todella esittää, sillä juuri sen asiakkaat näkevät. Sisäinen merkintä ”uusittu” ei ole sama asia.
6. Poistakaa se, mitä ette enää käytä. Aliverkkotunnukselta, joka ei enää palvele mitään, kannattaa poistaa sekä DNS-tietue että varmenne.

Jos varmenne on jo vanhentunut

• Uusikaa tai myöntäkää varmenne uudelleen, ottakaa se käyttöön ja ladatkaa palvelu uudelleen.
• Varmistakaa komennolla openssl s_client verkkonne ulkopuolelta, että uusi notAfter-päivämäärä näkyy.
• Tarkistakaa, että palvelin tarjoaa koko ketjun eikä vain palvelinvarmennetta.
• Tarkistakaa riippuvaiset asiakasohjelmat: mobiilisovellukset, kumppanien integraatiot ja webhookit voivat vaatia uuden yhteysyrityksen.
• Selvittäkää, miksi hälytys ei lauennut, ja korjatkaa se.

Tarkistuslista

• Luettelo kaikista palvelimista, joilla on varmenne, myös sähköposti- ja rajapintapalvelimista.
• ACME-automaatio, joka lataa palvelun uudelleen.
• Hälytykset epäonnistuneista uusimisista.
• Ulkoinen voimassaolon tarkistus jokaiselle palvelimelle.
• Valmius 100 ja 47 päivän voimassaoloaikoihin.

Miten Datahorses auttaa

Datahorses valvoo yritystänne ulkopuolelta ja tarkistaa varmenteet, jotka palvelimenne todella esittävät: vanhenemisen, rikkinäiset ketjut ja itse allekirjoitetut varmenteet. Muistutukset lähtevät 30, 14 ja 3 päivää, ennen kuin varmenne tai verkkotunnus vanhenee. Emme mene järjestelmiinne emmekä tarvitse pääsyoikeuksia. Katsokaa, mitä valvomme. Esimerkkinäkymästä näette, miltä tämä näyttää.