SSL-varmenne vanhentunut: mitä tapahtuu ja miten korjaat sen nopeasti

Vanhentunut SSL-varmenne tarkoittaa, että sivustosi henkilöllisyyden todistava varmenne on ylittänyt vanhenemispäivänsä, ja selaimet lakkaavat luottamasta siihen saman tien. Kävijät näkevät sisältösi sijaan koko ruudun varoituksen, kuten NET::ERR_CERT_DATE_INVALID, rajapintojen asiakassovellukset ja mobiilisovellukset lakkaavat toimimasta kokonaan, ja liikenne romahtaa, kunnes varmenne on vaihdettu. Ratkaisu on uusia tai myöntää varmenne uudelleen, asentaa uusi täydellinen ketju jokaiselle TLS:n päättävälle palvelimelle ja ladata palvelut uudelleen; automatisoidulla ACME-kokoonpanolla tämä vie muutaman minuutin. Tässä oppaassa näet, miten tarkistat vanhenemispäivän, korjaat vanhentuneen varmenteen vaihe vaiheelta ja varmistat, ettei sama toistu.

Mitä kävijät näkevät, kun SSL-varmenteesi vanhenee

Selaimet eivät mainitse ongelmaa hienovaraisesti nurkassa. Ne korvaavat koko sivusi varoitusnäytöllä, ja kävijän on kaivauduttava "Lisäasetukset"-valikkoon päästäkseen lainkaan eteenpäin. Sanamuoto vaihtelee selaimittain:

Varoitukset ovat niin yleisiä, että niitä voidaan mitata suuressa mittakaavassa. Laajimmassa julkaistussa varmennevaroituksia koskevassa tutkimuksessa Googlen ja Carnegie Mellonin tutkijat analysoivat yli 300 miljoonaa Chromen varoitusraporttia ja totesivat, että 4,23 % Windowsin varoituksista johtui varmenteen päivämäärävirheistä (Acer ym., ACM CCS 2017). Vanhentuneet varmenteet ovat HTTPS:n arkinen vikatila, ja itse varoitussivu on usein ensimmäinen merkki, jonka omistaja saa.

Muutakin hajoaa kuin etusivu

Selaimen varoitus on vain näkyvä osa. Hiljaiset viat maksavat yleensä enemmän:

• Rajapinnat ja webhookit kaatuvat saman tien. Koneasiakkailla ei ole "Lisäasetukset"-painiketta. Maksujen paluukutsut, mobiilisovellukset, kumppani-integraatiot ja valvonta-agentit hylkäävät yhteyden sillä sekunnilla, kun varmenne vanhenee.
• HSTS poistaa varauloskäynnin. Jos sivustosi lähettää HSTS-otsakkeen, selain piilottaa "jatka silti" -linkin kokonaan. Kävijät eivät pääse ohi, vaikka haluaisivat.
• Sähköposti ja sisäiset työkalut pysähtyvät. SMTP:n, IMAPin ja hallintapaneelien TLS kaatuu yhtä kovaa, ja juuri niiden varmenteita kukaan ei vahdi.
• Luottamus rapautuu nopeimmin. Yritys, jonka omalla sivustolla on vanhentunut varmenne, on ristiriita, jonka kävijät muistavat. Hakukoneet näkevät saman varoitustilan, ja konvertoivat sivut menettävät liikenteensä niin kauan kuin varoitus on näkyvissä.

Kolme kuuluisaa käyttökatkoa, joiden syynä oli yksi vanhentunut varmenne

Varmenteen vanheneminen ei ole pienyritysten ongelma. Osa viime vuosikymmenen kalleimmista katkoista johtui juuri tästä:

Opetus on epämukava: näillä yrityksillä on maailmanluokan insinöörit, ja varmenne vanheni silti. Uusiminen on prosessiongelma, ei osaamisongelma, eikä kalenterimuistutus jonkun sähköpostissa ole prosessi.

Näin tarkistat, milloin varmenteesi vanhenee

Kolme tapaa nopeimmasta perusteellisimpaan:

1. Selaimessa. Napsauta osoiterivin lukkoa tai asetuskuvaketta, avaa "Yhteys on suojattu" ja sitten "Varmenne on kelvollinen". Tietopaneeli näyttää tarkan voimassaoloajan.

2. Komentoriviltä. Kysy aktiivista varmennetta OpenSSL:llä:

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

Tuloste näyttää kentät notBefore ja notAfter; jälkimmäinen rivi on määräaikasi.

3. Tarkista koko ketju, älä vain omaa varmennettasi. Myös välivarmenteet ja juurivarmenteet vanhenevat. Kun AddTrust External CA Root -juurivarmenne vanheni 30.5.2020, täysin kelvollisilla palvelinvarmenteilla toimivat palvelut kaatuivat ympäri maailmaa, mukaan lukien Roku-laitteet ja useat maksualustat. Ulkoinen skannaus, joka validoi koko ketjun, löytää sen, mikä jää huomaamatta, kun vilkaiset vain omaa varmennettasi.

Näin korjaat vanhentuneen SSL-varmenteen vaihe vaiheelta

Vaihe 1: varmista, että vanheneminen on todella syy. Aja yllä oleva OpenSSL-komento ja lue notAfter. Jos varmenne onkin voimassa, vika on kävijän laitteen kellossa, eikä palvelimellasi tarvitse korjata mitään.

Vaihe 2: uusi tai myönnä uudelleen. Let's Encryptillä tai muulla ACME-asiakkaalla uusiminen on yksi komento (sudo certbot renew), ja harjoitusajo (sudo certbot renew --dry-run) kertoo etukäteen, onnistuuko validointi. Kaupallisen varmentajan kanssa luot uuden CSR:n hallintapaneelissa ja suoritat validoinnin siellä.

Vaihe 3: asenna täydellinen ketju kaikkialle, missä TLS päättyy. Uuden varmenteen on päästävä jokaiseen päätepisteeseen, joka puhuu TLS:ää verkkotunnukselle: alkuperäpalvelimille, kuormantasaajille ja CDN:n reunalle. Asenna fullchain.pem (palvelinvarmenne ja välivarmenteet), älä pelkkää palvelinvarmennetta, tai vaihdat päivämäärävirheen ketjuvirheeseen.

Vaihe 4: lataa palvelu uudelleen. Uusittu tiedosto levyllä ei muuta mitään, ennen kuin palvelin lukee sen uudelleen. Aja sudo systemctl reload nginx (tai vastaava Apachelle, HAProxylle tai alustallesi). Tämä on "automatisoitujen" kokoonpanojen yleisin vika: uusimisajo toimii täydellisesti, mutta uudelleenlatauskoukkua ei koskaan määritetty, joten palvelin tarjoilee vanhaa varmennetta muistista.

Vaihe 5: varmista ulkopuolelta. Tarkista puhelimella mobiilidatalla, uudella selainprofiililla tai ulkoisella skannerilla. Varmenteilla ei ole leviämisviivettä: sillä hetkellä, kun palvelin on ladattu uudelleen, jokainen uusi yhteys saa uuden varmenteen.

Uusimisesta tulee pian armotonta

Jos uusiminen tuntuu tänään hallittavalta, aikataulu muuttuu jalkojesi alla. CA/Browser Forumin äänestyksessä SC-081v3, joka hyväksyttiin huhtikuussa 2025 yksimielisesti äänin 29-0, julkisten TLS-varmenteiden enimmäisvoimassaolo putosi 398 päivästä 200 päivään 15.3.2026, laskee 100 päivään 15.3.2027 ja asettuu 47 päivään 15.3.2029 (CA/Browser Forum). Let's Encrypt on mennyt jo pidemmälle: joulukuussa 2025 se ilmoitti laskevansa oletusvoimassaolon 90 päivästä 45 päivään, ja sen kuuden päivän varmenteet tulivat yleisesti saataville 15.1.2026.

Vuonna 2026 tarjolla olevat ja sallitut varmenteiden voimassaoloajat. Lähteet: CA/Browser Forum, äänestys SC-081v3; Let's Encrypt.

Suunta on yksisuuntainen: uusimiset, jotka ennen tehtiin kerran vuodessa, tehdään pian kuuden tai seitsemän viikon välein ja lyhytikäisillä varmenteilla muutaman päivän välein. Manuaalinen uusiminen ei selviydy siitä tahdista. Automaatio lakkaa olemasta mukava lisä ja muuttuu ainoaksi tavaksi pitää varmenne voimassa.

Näin varmenne ei vanhene enää koskaan

• Automatisoi myöntäminen ja uusiminen ACMElla ja määritä deploy-koukku, joka lataa verkkopalvelimen uudelleen jokaisen uusimisen jälkeen.
• Valvo vanhenemista ulkopuolelta. Ulkoinen tarkistus löytää jokaisen varmenteen, jonka uusimisskripti ohitti hiljaa. Hälytä 30, 14 ja 7 päivää ennen vanhenemista.
• Inventoi jokainen varmenne, ei vain pääsivustoa: rajapintojen aliverkkotunnukset, sähköpostipalvelimet, testiympäristöt ja sisäiset paneelit vanhenevat omilla aikatauluillaan.
• Käsittele uusiminen käyttöönottona. Se muuttaa sitä, mitä tuotanto tarjoilee, joten se ansaitsee saman varmistusvaiheen kuin koodijulkaisu.

Aiheeseen liittyvät oppaat

• SSL/TLS-varmenteet: täydellinen opas A+-arvosanaan käsittelee protokollat, ketjut ja asetukset vanhenemista laajemmin.
• "Yhteytesi ei ole yksityinen": mitä virhe tarkoittaa ja miten korjaat sen selittää varoitussivun, jonka kävijäsi näkevät juuri nyt.
• ERR_CERT_AUTHORITY_INVALID: mistä virhe johtuu ja miten korjaat sen käsittelee ketjuvirheet, jotka ilmestyvät usein heti kiireisen uusimisen jälkeen.
• Mikä on HSTS? selittää, miksi osa kävijöistä ei voi ohittaa varmennevaroituksia lainkaan.

Usein kysytyt kysymykset

Voivatko kävijät yhä avata sivustoni, kun varmenne on vanhentunut? Useimmissa selaimissa he voivat jatkaa "Lisäasetukset"-valikon kautta, mutta suurin osa ei tee niin, ja jos sivustosi lähettää HSTS:n, selain poistaa vaihtoehdon kokonaan. Rajapintojen asiakkaat ja sovellukset hylkäävät yhteyden suoraan.

Haittaako vanhentunut SSL-varmenne hakukonenäkyvyyttä? Välillisesti kyllä. Hakurobotit näkevät saman kelvottoman varmenteen, kävijät poistuvat varoitussivulta, ja HTTPS on vahvistettu sijoitussignaali. Mitä kauemmin varoitus on näkyvissä, sitä enemmän liikennettä ja luottamusta menetät.

Kauanko korjaus kestää? Kun ACME-automaatio on paikallaan: minuutteja. Uusi, lataa uudelleen, varmista. Leviämisviivettä ei ole, koska uusi varmenne tarjoillaan jokaiselle uudelle yhteydelle heti uudelleenlatauksen jälkeen.

Miksi varmenteeni vanheni, vaikka automaattinen uusinta oli päällä? Tavallisimmat syyt: uusinta ajettiin, mutta uudelleenlatauskoukkua ei ollut määritetty, joten vanha varmenne jäi muistiin; validointi epäonnistui hiljaa DNS- tai palomuurimuutoksen jälkeen; tai uusinta kattoi eri palvelinnimen kuin varmenne, joka todella vanheni.

Onko sisäisten työkalujen vanhentuneilla varmenteilla väliä? On. Sisäiset ja rajapintojen varmenteet kaatuvat samalla tavalla kuin julkiset, ja niitä valvotaan vähemmän. Useampi tämän artikkelin tapauksista alkoi varmenteesta, jota kukaan ei ollut inventoinut.

Tarkista varmenteesi ennen kuin kävijäsi tekevät sen

Vanhenemispäivä ei neuvottele koskaan. Aja ilmainen FortifyNet-skannaus ja näe varmenteesi tarkka vanhenemispäivä, koko ketju, protokolla-asetukset, tietoturvaotsakkeet, DNS ja sähköpostitodennus noin 60 sekunnissa. Ei vaadi rekisteröitymistä.

---

Lähteet: CA/Browser Forum, äänestys SC-081v3; Let's Encrypt, Certificate Lifetimes; Let's Encrypt, kuuden päivän varmenteet GA; The Register Ericssonin katkosta; TechCrunch Teamsin katkosta; Data Center Dynamics Spotifyn katkosta; Acer ym., "Where the Wild Warnings Are", ACM CCS 2017.