Mene sisältöön 
Onko varmenteesi vanhentunut tai vanhentumassa? Tässä oppaassa näytän sinulle erityisesti, miten voitte Uudista SSL-sertifikaatti manuaalisesti ja automaattisesti - mukaan lukien tyypilliset sudenkuopat, työkalut ja sopivat asetukset.
Opastan sinua hostingin, mukautettujen palvelimien ja WordPressin avulla välttämään käyttökatkoksia, lisäämään turvallisuutta ja suojaamaan konversioita - CSR:stä HSTS:ään, Let's Encryptistä Wildcardiin.
Keskeiset kohdat
- Automaattinen Laajenna: Aktivoi hoster-vaihtoehto, tarkista tila.
- Manuaalinen Renew: Luo CSR, asenna ja testaa ketju.
- WordPress turvallinen: Ota käyttöön HTTPS, käytä lisäosia
- Virhe välttää: .well-known, ketju, uudelleenohjaukset, uudelleenohjaukset
- Varovaisuus tavata: Seuranta, Cronjobs, HSTS
Miksi SSL-varmenteet vanhenevat ja mitä se tarkoittaa sinulle?
Kullakin todistuksella on määräaikainen voimassaoloaika, julkisten todistusten osalta enintään kaksi vuotta. 397 päivää. Vanhentumisen jälkeen selain estää yhteyden, kävijät näkevät varoituksia ja usein hyppäävät. Tämä vahingoittaa luottamusta, konversiota ja näkyvyyttä hakukoneissa. Vältän tämän riskin pitämällä voimassaolon päättymispäivää silmällä hyvissä ajoin ja suunnittelemalla uusimisen. Ne, jotka uusivat ajoissa, pysyvät lainmukainen ja pitää tiedonsiirrot suojattuina.
Aktivoi automaattinen uusiminen hosting-palveluntarjoajan kanssa
Monet hosting-paneelit tarjoavat yhden napsautuksen aktivoinnin seuraaville toiminnoille Automaattinen uusiminen. Aktivoin verkkotunnuskohtaisen vaihtoehdon, tarkistan tallennetun validoinnin (HTTP-01/DNS-01) ja tarkistan sitten voimassaolon selaimen lukituksessa. Kun käytössä on useita verkkotunnuksia ja aliverkkotunnuksia, säästän paljon aikaa ja vältän kahden varmenteen väliset aukot. Turvallista peruskäynnistystä varten kompakti 5 askelta turvalliseen verkkosivustoon. Sen jälkeen pidän vain silmällä palveluntarjoajan päättymisilmoituksia ja testaan säännöllisesti HTTPS-yhteyttä.
Varmistan myös, että Yhteydenotto sähköpostiosoite on ajan tasalla hoster-tilillä, jotta vanhenemis- ja virheilmoitukset saadaan. Jos Auto-Renew toimii ACME:n kautta, otan huomioon seuraavat seikat. Korkorajat CA:n ja - jos mahdollista - käytän testausympäristöä testejä varten, jotta en vahingossa estä itseäni. Suunnittelen DNS-01-validoinnin TTL-ajat niin, että merkinnät etenevät nopeasti. Onko CAA ennätykset vyöhykkeellä, tarkistan, onko varmentajani sallittu siellä - muuten uusiminen epäonnistuu automaattisesta uusimisesta huolimatta.
Jos kyseessä on usean domainin tai jokerimerkkijärjestelmä, tarkistan, tukeeko hostaja Automaattinen DNS-päivitys tuettu. Ilman API-yhteyttä määrittelen selkeät prosessit: Kuka luo TXT-tietueet, kuka valvoo ratkaisua ja milloin ne poistetaan uudelleen? Tämä valmistelutyö varmistaa, että automaattinen uusiminen ei epäonnistu organisatoristen esteiden vuoksi.
Manuaalinen laajennus: CSR:stä asennukseen
Erityisvaatimuksia, juuripalvelimia tai tiettyjä varmentajia varten uusin manuaalisesti. Ensin luon uuden CSR:n, jossa on sopiva avain (RSA 2048+ tai ECDSA), mukaan lukien oikea yleinen nimi/aiheiden vaihtoehtoiset nimet. Käynnistän uusintatilauksen CA-portaalissa, vahvistan verkkotunnuksen hallinnan (esim. HTTP-01 .well-known- tai DNS-01 TXT-tunnuksen kautta) ja odotan myöntämistä. Sen jälkeen lataan varmenteen ja välivarmenteet ja tarkistan ketjun paikallisesti. Tallennan varmenteen, avaimen ja välitunnisteen isännöintipaneeliin (esim. Plesk tai cPanel) ja testaan Ketju SSL-tarkistuksella.
Käytän yleensä Uudet avaimet jokaisen uusimisen yhteydessä, jotta kryptostandardit pysyvät ajan tasalla. Esimerkiksi ECDSA:lle käytän prime256v1:n kaltaista käyrää, RSA:lle vähintään 2048 bittiä. CSR sisältää aina kaikki isäntänimet, jotka haluan suojata - mukaan lukien Perusverkkotunnus ja www (esim. example.tld ja www.example.tld). Suunnittelen asennuksen niin, että uusi varmenne on valmis ennen vanhan varmenteen voimassaolon päättymistä; monet palvelimet sallivat tämän. Saumaton korvaaminen uudelleenlatauksella ilman seisokkiaikaa.
Asennuksen jälkeen testaan toimitusta sekä www:n kanssa että ilman www:tä, IPv4:n kautta ja IPv6ja tarkista koko ketju. Jos ketju ei ole oikea, tuon CA:n asianmukaisen välivaiheen. Varmistan, että palvelin on vain lataa uudelleen (lataa kokoonpano uudelleen), älä käynnistä kovaa uudelleen, jotta aktiivisia yhteyksiä ei peruuteta.
Palvelinkäytäntö: Apache, Nginx ja IIS yhdellä silmäyksellä
Osoitteessa Apache Tallennan polut vHostiin: SSLCertificateFile (palvelimen varmenne), SSLCertificateKeyFile (yksityinen avain) ja - versiosta riippuen - SSLCertificateChainFile tai niputettu koko ketjun tiedosto. Vaihdon jälkeen tarkistan konfiguraation ja lataan sen uudelleen. Osoitteessa Nginx Asetan ssl_certificate (koko ketju) ja ssl_certificate_key (avain). Testaan kokoonpanon, lataan sen uudelleen ja tarkistan sitten HTTP/2/HTTP/3- ja SNI-käsittelyn useiden palvelinnimien kautta.
Osoitteessa IIS Tuon varmenteen varmennesäilöön (tietokoneeseen) ja sidon sen sivustoon. On tärkeää, että jokaisen isäntänimen SNI jos samalla IP-osoitteella on useita varmenteita. Automaattisia Windows-asetuksia varten ajoitan ACME-asiakkaan hoitamaan uusimisen ja sitomisen. Kaikissa tapauksissa dokumentoin polut, tiedostojen käyttöoikeudet (avain vain verkkopalvelinprosessin osalta) ja tarkan menettelyn, jotta seuraava uusimispäivä sujuu ongelmitta.
SSL WordPressissä: Määritä, vahvista, laajenna automaattisesti
WordPressin kanssa pidän sen yksinkertainenAktivoin Let's Encryptin hostingissa, otan HTTPS:n käyttöön lisäosan avulla (esim. Really Simple SSL) ja tarkistan sekasisältöwidgetit. Jos WordPress toimii omalla palvelimellaan, käytän Certbotia, joka sisältää cronjobin automaattista uusimista varten. Multisite-asetuksissa kannattaa käyttää wildcard-sertifikaattia, jolla voidaan turvata aladomainit kollektiivisesti. Käytän tätä ohjetta pika-aloitukseen: Ilmainen SSL WordPressissä. Tarkistan sitten selaimessa olevan lukkosymbolin ja WordPress-työkaluissa olevan varmenteen voimassaolon päättymispäivän.
Vaihdon jälkeen vaihdan kovat http-linkit tietokantaan, jotta kuvat, skriptit ja tyylit latautuvat siististi HTTPS:n kautta. Tarkistan myös välimuistilaajennukset ja CDN-integraatiot varmistaakseni, että ne käsittelevät HTTPS-muunnosta oikein. Tärkeää: Kun HTTPS:ää pakotetaan, kiinnitän huomiota puhtaisiin uudelleenohjauksiin (301-ketju), jotta SEO-signaalit eivät vesity eikä loputtomia silmukoita synny.
Omilla palvelimillani aion käyttää Certbot-Renewal -palvelinta seuraavasti. Cronjob ja tallentaa post-koukkuja, jotka lataavat Nginxin/Apachen uudelleen onnistuneen uusimisen jälkeen. Hallituissa WordPress-ympäristöissä käytän hosterin automaattisia uusintatoimintoja ja tarkistan säännöllisesti, että .well-known-haasteisiin pääsee käsiksi - erityisesti silloin, kun tietoturvaliitännäisiä tai WAF-sääntöjä noudatetaan tiukasti.
Vältä tyypillisiä virheitä: Validointi, ketju, uudelleenohjaukset
Usein Validointijos HTTP-01-tiedosto osoitteessa /.well-known/pki-validation/ ei ole käytettävissä. Uudistusta varten poistan lyhyesti käytöstä aggressiiviset uudelleenohjaukset (esim. ei-www:stä www:hen) tai säännöt, jotka estävät pääsyn. Jos välivarmenteet puuttuvat, selaimet hylkäävät varmenteen; tuon koko ketjun. Jos yhdellä IP-osoitteella on useita varmenteita, SNI:n on oltava aktiivinen, muuten palvelin toimittaa väärän varmenteen. Poistan välimuistit jokaisen muutoksen jälkeen, jotta näen todellisen, nykyisen tilan.
Muut tyypilliset kompastumisvaarat: A AAAA ennätys (IPv6) osoittaa eri palvelimeen kuin A (IPv4), haaste epäonnistuu. Tai WAF estää pääsyn osoitteeseen .well-known. DNS-01:ssä korkeat TTL:t aiheuttavat viiveitä; asetan ne väliaikaisesti alhaisemmiksi. Olemassa CAA ennätykset ilman käytetyn CA:n hyväksyntää, peruutan uusimisen, kunnes merkintä on korjattu. Kontti- tai chroot-ympäristöissä kiinnitän huomiota oikeisiin kiinnityksiin ja oikeisiin käyttöoikeuksiin, jotta verkkopalvelin tai ACME-asiakas voi todella toimittaa haastetiedostot.
Hosting-vertailu: Kuka uusii luotettavimmin?
Kiinnitän huomiota Intuitiivinen käyttöliittymä, automaattinen uusiminen kaikille verkkotunnuksille ja nopea tuki. Näin säästän ylläpitoaikaa ja vähennän merkittävästi käyttökatkoksia. Let's Encrypt -integraation sisältäville palveluntarjoajille asetan automaattisen uusimisen kerran ja tarkistan saavutettavuuden HTTPS-seurannan avulla. All-Inkl:lle on selkeät ohjeet, jotka tekevät aktivoinnista erittäin nopeaa: Salataan All-Inkl:ssä. Seuraavassa taulukossa esitetään, mitä pidän erityisen tärkeänä vertailussa.
| Hosting-palveluntarjoaja | Automaattinen uusiminen | Pinta | Tuki | Arviointi |
|---|---|---|---|---|
| webhoster.de | Kyllä | Erittäin intuitiivinen | Nopea | 1. sija |
| All-Inkl | Kyllä | Yksinkertainen | Hyvä | 2. sija |
| Isäntä-Eurooppa | Osittain | Medium | Medium | 3. sija |
| SSD web hosting | Osittain | Medium | Medium | 4. sija |
Tarkistan myös, onko palveluntarjoaja DNS API:t DNS-01:n osalta (tärkeä jokerimerkkien kannalta), tarjoaa lokitietoja epäonnistuneista validoinneista ja siitä, voidaanko varmenteet viedä kätevästi koko ketjuna. Hyvä paneeli näyttää Vanhentuvat todistukset Järjestelmä alkaa varhaisessa vaiheessa, sallii yksityiskohtaiset oikeudet (esim. vain SSL:n hallinta) ja dokumentoi jokaisen vaiheen. Tämä säästää aikaa ja estää tiedon sitomisen yksittäisiin henkilöihin.
Prosessien tunnistaminen ja niiden ennakoiva ehkäiseminen
Näen tilan milloin tahansa komennolla Linna-kuvakkeesta selaimessa, varmenteen tiedot antavat tietoja voimassaolosta ja myöntäjästä. Asetan myös ilmoitukset hosting-paneeliin ja määrittelen seurannan, joka varoittaa voimassaolon päättymisestä. Omilla palvelimillani on cron-työ, joka ajaa Certbotin säännöllisesti ja tarkistaa lokit. WordPressissä tarkistan tietoturvaliitännäisten ilmoitukset ja tarkkailen konsolia sekalaisen sisällön varalta. Tämä yhdistelmä estää käyttökatkokset ja pitää salauksen aktiivisena keskeytyksettä.
Sillä Tekninen valvonta Käytän yksinkertaisia shekkejä: Varmenteen voimassaolon päättymispäivämäärien hakeminen, ketjun ja protokollatuen tarkistaminen (TLS 1.2/1.3). Valvonnassa suunnittelen varoitustasoja (esim. 30, 14 ja 7 päivää ennen voimassaolon päättymistä) ja tarkistan, ovatko uudelleenlatauskoukut todella toimineet onnistuneen uusimisen jälkeen. Näin voin tunnistaa ongelmat varhaisessa vaiheessa - ennen kuin kävijät näkevät varoitussivut.
Turvallisuusviritys uudistuksen jälkeen
Uudistamisen jälkeen otan TLS:stä kaiken irti ja aktivoin sen. TLS 1.3 (1.2:n lisäksi), vanhojen protokollien ja vanhentuneiden salakirjoitusten poistaminen käytöstä. HSTS riittävän pitkällä max-age-ajalla sitoo asiakkaat HTTPS:ään ja vähentää hyökkäyspintoja. OCSP-tappaus vähentää latensseja ja vapauttaa OCSP-vastaajan CA:sta. Jos käytät RSA:ta, valitse 2048-bittinen tai vaihda tarvittaessa ECDSA:han suorituskyvyn parantamiseksi. Lopussa validoin asetukset SSL-testillä ja tarkastelen tarkkaan protokollia ja salausasetuksia.
Mieluummin moderni salakirjoitus Forward Secrecy -toiminnolla ja aktivoi ALPN, jotta HTTP/2:ta ja HTTP/3:a käytetään tehokkaasti. Jos käytettävissä, asetan rinnakkaisen ECDSA- ja RSA-varmenteet Näin nykyaikaiset asiakkaat saavat tehokkaan ECDSA-vaihtoehdon, kun taas vanhemmat asiakkaat pysyvät yhteensopivina RSA:n avulla. Lisään HSTS:ää vähitellen (esim. ensimmäisinä päivinä, sitten viikkoina) välttääkseni virheellisten konfiguraatioiden pysyvän sementoinnin. Tarkistan aktiivisesti OCSP-niitotuksen uudelleenlatauksen jälkeen, jotta asiakkaat eivät joudu kärsimään ylimääräisistä verkkoviiveistä.
Käytännön menettely lyhyesti
Aloitan tilantarkastuksella, merkitsen muistiin Viimeinen voimassaolopäivä ja päätä: jätätkö automaattisen uusimisen aktiiviseksi vai uusitko manuaalisesti. Automaattista uusimista varten tarkistan validointipolun (HTTP-01/DNS-01) ja testaan haasteen saavutettavuuden. Manuaalista uusimista varten luon CSR:n, pyydän varmenteen varmentajalta ja asennan varmenteen ja ketjun. Sitten otan käyttöön HTTPS:n, poistan välimuistit ja tarkistan sekoitetun sisällön. Lopuksi määrittelen seurannan ja ilmoitukset, jotta en enää koskaan myöhästy määräajasta.
Erityistapaukset: Villi kortti, monialuetyyppi ja validointityypit.
Jos käytän useita alaverkkoja, käytän apuna Villi kortti-sertifikaatti (*.domain.tld) ja tallenna itselleni erilliset sertifikaatit. Useiden täysin erilaisten verkkotunnusten kohdalla luotan SAN/UCC-varmenteisiin, jotka tiivistävät useita isäntänimiä. DV-varmenteet riittävät useimpiin projekteihin, OV/EV-varmenteet tarjoavat ylimääräisen henkilöllisyyden varmentamisen - hyödyllistä kaupoissa tai portaaleissa, joissa on arkaluonteisia tietoja. Kiinnitän huomiota käyttöaikarajoituksiin ja suunnittelen uusimisen niin, että ruuhkahuippujen aikana ei tule risteyksiä. Tuottavien vyöhykkeiden DNS-validoinnissa käytän selkeitä nimeämiskäytäntöjä, jotta löydän merkinnät nopeasti uudelleen ja Muuta voi.
Osoitteessa Villi kortti on tärkeää: Validointi suoritetaan yksinomaan DNS-01:n kautta, joten käytän automaattisia DNS-päivityksiä tai erityisiä huolto-ikkunoita. Usean domainin ympäristöissä varmistan, että kaikki variantit ovat SAN-luettelossa (mukaan lukien vuoden aikana lisätyt aladomainit). Kuormantasaajan asetusten osalta suunnittelen Jakelu uudet varmenteet kaikkiin solmuihin ja testaa sitten jokainen VIP/alue erikseen. Kun tiimit vaihtuvat, auttaa selkeä dokumentaatio siitä, kuka saa mitäkin salaisuuksia (avaimia) ja milloin ja miten niitä säilytetään turvallisesti.
ACME ja monimutkaiset ympäristöt: CDN, WAF ja käänteiset välityspalvelimet.
Käytänkö CDN tai WAF:n avulla varmistan, että validointi saavuttaa Originin: Joko haastepyyntöihin vastataan Edge-palvelimessa (jos se on tuettu) tai suoritan kohdennettuja ohituksia, jotka koskevat /.well-known/ on. HTTP-01:n osalta voidaan tehdä uudelleenohjaus HTTPS:ään, mutta haasteeseen on päästävä käsiksi ilman auth-otsakkeita, nopeusrajoituksia tai maantieteellisiä estoja. DNS-01:n osalta testaan, onko TXT-merkintä saatavilla maailmanlaajuisesti ja häiritseekö mikään split horizon -konfiguraatio arviointia.
Takana Käänteiset välityspalvelimet Tarkistan otsikot kauempaa (X-Forwarded-Proto), jotta sovellus reagoi oikein HTTPS:ään eikä tuota sekasisältöä koskevia virheitä. Nollapudotusaikaisia uudistuksia varten kierrätän varmenteet seuraavasti askel askeleelta ensin yksi solmu, sitten muut - jotta voin palata nopeasti ongelmien ilmetessä vaarantamatta kaikkia yhteyksiä.
Hätäsuunnitelma: peruutus, avaimen menetys ja nopea vaihto
Jos on olemassa Key-Leak tai kompromissi, peruutan varmenteen välittömästi ja myönnän uuden varmenteen uusilla avaimilla. Säilytän Tarkistuslista valmis: Pääsy CA-portaaliin, peruutusmenettely, uusien avainten tuottaminen, nopea jakelu ja uudelleenlataus. Tämän jälkeen tarkistan OCSP-nippauksen ja välimuistit, jotta vanhat ketjut voidaan poistaa välimuistista. Merkitsen syyn, ajankohdan ja vastatoimet dokumentaatioon - tämä helpottaa tarkastuksia ja estää toistuvuuden.
Lyhyesti tiivistettynä
Uusin varmenteet hyvissä ajoin, tarkistan Automaattinen uusiminen-toiminto ja pidä validointi saatavilla. Jos automaattinen uusiminen ei toimi, uusin sen manuaalisesti: luon CSR:n, haen, asennan ketjun, testaan HTTPS:n. Suojaan WordPressin pakotetulla HTTPS:llä ja valvonnalla, omia palvelimiani valvotaan cronjobien ja Certbotin avulla. Vältän virheitä seuraamalla .well-known-haastetta, välivarmenteita, SNI:tä ja edelleenlähetyssääntöjä. Tällä prosessilla salaus pysyy aktiivisena, käyttäjät luottavat sivustoon ja näkyvyys ei kärsi vanhenemisvaroituksista.
