Eiti prie turinio 
Ar jūsų sertifikato galiojimo laikas baigėsi arba netrukus baigsis? Šiame vadove parodysiu, kaip Atnaujinti SSL sertifikatą rankiniu ir automatiniu būdu, įskaitant tipinius spąstus, įrankius ir tinkamus nustatymus.
Padėsiu jums susipažinti su priegloba, pasirinktiniais serveriais ir "WordPress", kad išvengtumėte sutrikimų, padidintumėte saugumą ir apsaugotumėte konversijas - nuo CSR iki HSTS, nuo "Let's Encrypt" iki "Wildcard".
Centriniai taškai
- Automatinis Išplėsti: suaktyvinti talpyklos parinktį, patikrinti būseną
- Rankinis Atnaujinti: sukurti CSR, įdiegti, išbandyti grandinę
- WordPress saugus: Įtvirtinkite HTTPS, naudokite įskiepius
- Klaida vengti: .well-known, grandinė, nukreipimai
- Atsargumo priemonės susitikti: Stebėsena, Cronjobs, HSTS
Kodėl baigiasi SSL sertifikatų galiojimas ir ką tai reiškia jums
Kiekvieno sertifikato galiojimo laikas yra fiksuotas, o viešųjų sertifikatų - ne ilgesnis kaip 397 dienos. Pasibaigus galiojimui, naršyklė blokuoja ryšį, lankytojai mato įspėjimus ir dažnai atkrenta. Tai kenkia pasitikėjimui, konversijai ir matomumui paieškos sistemose. Šios rizikos išvengiu laiku stebėdamas galiojimo pabaigos datą ir planuodamas atnaujinimą. Tie, kurie atnaujina laiku, išlieka atitinka teisės aktų reikalavimus. ir saugo duomenų perdavimą.
Suaktyvinkite automatinį atnaujinimą su prieglobos paslaugų teikėju
Daugelyje prieglobos skydų vienu spustelėjimu galima aktyvuoti Automatinis atnaujinimas. Aš aktyvuoti parinktį vienam domenui, patikrinkite išsaugotą patvirtinimą (HTTP-01/DNS-01) ir tada patikrinkite galiojimą naršyklės užraktas. Naudodamasis keliais domenais ir subdomenais sutaupau daug laiko ir išvengiu spragų tarp dviejų sertifikatų. Saugi pagrindinė pradžia, kompaktiškas 5 saugios svetainės kūrimo žingsniai. Po to tiesiog stebiu prieglobos paslaugų teikėjo pranešimus apie galiojimo pabaigą ir reguliariai tikrinu HTTPS prieinamumą.
Taip pat užtikrinu, kad Kontaktinis el. paštas yra atnaujintas prieglobos paskyroje, kad būtų gaunami pranešimai apie galiojimo pabaigą ir klaidas. Jei automatinis atnaujinimas vykdomas per ACME, atsižvelgiu į Įkainių ribos CA ir, jei yra galimybė, bandymams atlikti naudokite bandymų aplinką, kad netyčia neužblokuotumėte savęs. DNS-01 patvirtinimui planuoju TTL, kad įrašai būtų greitai platinami. Ar yra CAA įrašai zonoje, patikrinu, ar mano sertifikavimo įstaiga yra leidžiama - priešingu atveju atnaujinimas nepavyks, nepaisant automatinio atnaujinimo.
Jei naudojate kelių domenų arba pakaitinių ženklų sąrankas, patikrinkite, ar prieglobos tarnyba palaiko Automatinis DNS atnaujinimas remiamas. Neturėdamas API ryšio, apibrėšiu aiškius procesus: Kas sukuria TXT įrašus, kas kontroliuoja jų perdavimą ir kada jie vėl pašalinami? Šis parengiamasis darbas užtikrina, kad automatinis atnaujinimas nesugriūtų dėl organizacinių kliūčių.
Rankinis išplėtimas: nuo CSR iki įdiegimo
Specialių reikalavimų, šakninių serverių ar konkrečių sertifikavimo tarnybų atveju atnaujinu rankiniu būdu. Pirmiausia sukuriu naują CSR su tinkamu raktu (RSA 2048+ arba ECDSA), įskaitant teisingus bendrinius pavadinimus ir alternatyvius subjekto pavadinimus. CA portale pradedu atnaujinimo užsakymą, patvirtinu domeno valdymą (pvz., HTTP-01 per .well-known arba DNS-01 per TXT) ir laukiu išdavimo. Tada atsisiųsiu sertifikatą ir tarpinius sertifikatus ir patikrinu grandinę vietoje. Sertifikatą, raktą ir tarpinį sertifikatą išsaugau prieglobos skydelyje (pvz., "Plesk" arba "cPanel") ir patikrinu grandinę. Grandinė su SSL patikrinimu.
Paprastai naudoju Nauji raktai su kiekvienu atnaujinimu, kad kriptografijos standartai būtų nuolat atnaujinami. Pavyzdžiui, ECDSA naudojau tokią kreivę kaip prime256v1, o RSA - bent 2048 bitų. CSR visada pateikiami visi prieglobsčio vardai, kuriuos noriu apsaugoti, įskaitant Bazinis domenas ir www (pvz., example.tld ir www.example.tld). Įdiegimą planuoju taip, kad naujasis sertifikatas būtų paruoštas prieš baigiantis senojo galiojimo laikui; daugelis serverių tai leidžia Sklandus pakeitimas su perkrovimu be prastovos.
Įdiegus, išbandžiau pristatymą tiek su www, tiek be www, per IPv4 ir IPv6ir patikrinkite visą grandinę. Jei grandinė nėra teisinga, importuoju atitinkamą tarpinį CA produktą. Įsitikinu, kad serveris yra tik perkrauti (perkrauti konfigūraciją), neperkraukite iš naujo, kad aktyvūs ryšiai nebūtų atšaukti.
Serverio praktika: "Apache", "Nginx" ir IIS iš pirmo žvilgsnio
Su Apache Aš saugau kelius į vHost: SSLCertificateFile (serverio sertifikatas), SSLCertificateKeyFile (privatus raktas) ir - priklausomai nuo versijos - SSLCertificateChainFile arba susietą visos grandinės failą. Po apsikeitimo patikrinu konfigūraciją ir ją perkraunu. Dėl Nginx Nustatau ssl_certificate (visą grandinę) ir ssl_certificate_key (raktą). Išbandau konfigūraciją, perkraunu ją ir patikrinu HTTP/2/HTTP/3 ir SNI tvarkymą per kelis serverių pavadinimus.
Svetainėje IIS Importuoju sertifikatą į sertifikatų saugyklą (kompiuterį) ir susieju jį su svetaine. Svarbu, kad kiekvienam prieglobsčio vardui SNI jei tame pačiame IP veikia keli sertifikatai. Automatizuotoms "Windows" konfigūracijoms planuoju naudoti ACME klientą, kad jis tvarkytų atnaujinimą ir susiejimą. Visais atvejais dokumentais patvirtinu kelius, failų leidimus (raktas tik žiniatinklio serverio procesui) ir tikslią procedūrą, kad kitas atnaujinimas vyktų sklandžiai.
SSL "WordPress": nustatymas, vykdymo užtikrinimas, automatinis išplėtimas
Naudodamasis "WordPress", aš jį saugau paprastasAktyvuoju "Let's Encrypt" prieglobos sistemoje, per įskiepį (pvz., "Really Simple SSL") užtikrinu HTTPS ir patikrinu mišraus turinio valdiklius. Jei "WordPress" veikia savo serveryje, naudoju "Certbot", įskaitant cronjob automatiniam atnaujinimui. Daugiaviečių svetainių konfigūracijose verta naudoti pakaitinį sertifikatą, kad kolektyviai apsaugotumėte subdomenus. Greitai pradžiai naudoju šį vadovėlį: Nemokamas SSL "WordPress. Tada naršyklėje patikrinu užrakto simbolį, o "WordPress" įrankiuose - sertifikato galiojimo datą.
Po pakeitimo pakeičiu kietosios http nuorodos duomenų bazėje, kad vaizdai, scenarijai ir stiliai būtų tvarkingai įkeliami per HTTPS. Taip pat tikrinu spartinančiosios spartinimo programos įskiepius ir CDN integraciją, kad įsitikinčiau, jog jie tinkamai tvarko HTTPS variantą. Svarbu: Priverčiant naudoti HTTPS, atkreipiu dėmesį į švarius peradresavimus (301 grandinė), kad nebūtų susilpninti SEO signalai ir nesusidarytų nesibaigiančios kilpos.
Savo serveriuose planuoju naudoti "Certbot-Renewal" kaip Cronjob ir saugoti pašto kabliukus, kurie po sėkmingo atnaujinimo perkrauna "Nginx/Apache". Valdomose "WordPress" aplinkose naudoju prieglobos paslaugų teikėjo automatinio atnaujinimo funkcijas ir reguliariai tikrinu, ar pasiekiami .well-known iššūkiai - ypač kai griežtai laikomasi saugumo įskiepių ar WAF taisyklių.
Venkite tipinių klaidų: Patvirtinimas, grandinė, nukreipimai
Dažnai Patvirtinimasjei HTTP-01 failas /.well-known/pki-validation/ yra nepasiekiamas. Dėl atnaujinimo trumpam išjungiu agresyvius nukreipimus (pvz., iš ne www į www) arba taisykles, kurios blokuoja prieigą. Jei trūksta tarpinių sertifikatų, naršyklės atmeta sertifikatą; importuoju visą grandinę. Jei viename IP yra keli sertifikatai, SNI turi būti aktyvi, kitaip serveris pateiks neteisingą sertifikatą. Po kiekvieno pakeitimo ištrinu talpyklas, kad galėčiau matyti tikrąją, dabartinę būseną.
Kiti tipiniai suklupimo pavojai: A AAAA rekordas (IPv6) nukreipia į kitą serverį nei A (IPv4), iššūkis nepavyksta. Arba WAF blokuoja prieigą prie .well-known. Naudojant DNS-01, dėl didelių TTL vėluoja; laikinai nustatau mažesnius. Egzistuoja CAA įrašai nesant patvirtinimo dėl naudojamos CA, atšaukiau pratęsimą, kol įrašas bus ištaisytas. Konteinerių arba chroot aplinkose atkreipiu dėmesį į teisingą prijungimą ir leidimus, kad žiniatinklio serveris arba ACME klientas iš tikrųjų galėtų pristatyti iššūkio failus.
Prieglobos palyginimas: kas atnaujina patikimiausiai?
Atkreipiu dėmesį į Intuityvus sąsaja, automatinis visų domenų atnaujinimas ir greitas palaikymas. Taip sutaupau laiko priežiūrai ir gerokai sumažinu prastovas. Paslaugų teikėjams, turintiems "Let's Encrypt" integraciją, vieną kartą nustatau automatinio atnaujinimo parinktį ir tikrinu prieinamumą per HTTPS stebėseną. Yra aiškios All-Inkl instrukcijos, dėl kurių aktyvavimas labai greitas: Šifruokime "All-Inkl. Toliau pateikiamoje lentelėje parodyta, ką palyginime laikau ypač svarbiu dalyku.
| Prieglobos paslaugų teikėjas | Automatinis atnaujinimas | Paviršius | Parama | Vertinimas |
|---|---|---|---|---|
| webhoster.de | Taip | Labai intuityvus | Greitai | 1 vieta |
| All-Inkl | Taip | Paprastas | Geras | 2 vieta |
| Priimančioji Europa | Iš dalies | Vidutinis | Vidutinis | 3 vieta |
| SSD priegloba | Iš dalies | Vidutinis | Vidutinis | 4 vieta |
Taip pat tikrinu, ar paslaugų teikėjas DNS API DNS-01 (svarbu pakaitiniams ženklams), pateikia žurnalo įžvalgas apie nepavykusius patvirtinimus ir ar sertifikatus galima patogiai eksportuoti kaip visą grandinę. Geras skydelis rodo Sertifikatai, kurių galiojimas baigiasi Sistema pradedama taikyti ankstyvuoju etapu, suteikiama galimybė suteikti konkrečias teises (pvz., tik SSL valdymą) ir dokumentuoti kiekvieną žingsnį. Taip sutaupoma laiko ir išvengiama žinių susiejimo su atskirais žmonėmis.
Procesų atpažinimas ir aktyvi jų prevencija
Būseną bet kuriuo metu galiu matyti per Pilis-ikona naršyklėje, o sertifikato detalėse pateikiama informacija apie galiojimą ir išdavėją. Prieglobos skydelyje taip pat nustačiau pranešimus ir įdiegiau stebėseną, kuri įspėja apie galiojimo pabaigą. Mano serveriuose yra įdiegta cron užduotis, kuri reguliariai paleidžia "Certbot" ir tikrina žurnalus. WordPress sistemoje nuolat informuoju save apie saugumo įskiepių pranešimus ir konsolėje tikrinu mišrų turinį. Šis derinys apsaugo nuo prastovų ir užtikrina, kad šifravimas veiktų be pertrūkių.
Dėl Techninė kontrolė Naudoju paprastus čekius: Tikrinu sertifikato galiojimo laiką, tikrinu grandinę ir protokolo palaikymą (TLS 1.2/1.3). Stebėdamas planuoju įspėjimo lygius (pvz., likus 30, 14 ir 7 dienoms iki galiojimo pabaigos) ir tikrinu, ar po sėkmingo atnaujinimo tikrai suveikė perkrovimo kabliukai. Tai leidžia man atpažinti problemas ankstyvoje stadijoje - prieš lankytojams pamatant įspėjamuosius puslapius.
Saugos derinimas po atnaujinimo
Po atnaujinimo aš maksimaliai išnaudoju TLS ir aktyvuoju TLS 1.3 (be 1.2), išjungti senus protokolus ir pasenusius šifrus. HSTS su pakankamai ilgu maksimaliu amžiumi susieja klientus su HTTPS ir sumažina atakų paviršių. OCSP susegimas sumažina vėlavimą ir atleidžia OCSP atsakiklį nuo CA. Jei naudojate RSA, pasirinkite 2048 bitų arba, jei reikia, pereikite prie ECDSA, kad užtikrintumėte didesnį našumą. Pabaigoje sąranką patvirtinu SSL testu ir atidžiai apžvelgiu protokolus bei kriptografinius nustatymus.
Man labiau patinka modernus šifras su "Forward Secrecy" ir įjungti ALPN, kad HTTP/2 ir HTTP/3 būtų naudojami efektyviai. Jei yra galimybė, nustatau lygiagretųjį ECDSA ir RSA sertifikatai Tokiu būdu šiuolaikiniai klientai gauna našų ECDSA variantą, o senesni klientai gali naudoti RSA. HSTS didinu palaipsniui (pvz., pirmosiomis dienomis, paskui savaitėmis), kad išvengčiau nuolatinio neteisingų konfigūracijų įtvirtinimo. Po perkrovimo aktyviai tikrinu OCSP susegimą, kad klientai nepatirtų papildomų tinklo uždelsimų.
Trumpa praktinė procedūra
Pradedu nuo būsenos patikrinimo, pasižymiu Galiojimo data ir nuspręskite: palikti aktyvų automatinį atnaujinimą arba atnaujinti rankiniu būdu. Automatinio atnaujinimo atveju patikrinu patvirtinimo kelią (HTTP-01/DNS-01) ir patikrinu iššūkio prieinamumą. Jei atnaujinimas atliekamas rankiniu būdu, sukuriu CSR, paprašau sertifikato iš sertifikavimo įstaigos ir įdiegiu sertifikatą bei grandinę. Tada užtikrinu HTTPS, ištrinu talpyklą ir patikrinu mišrų turinį. Galiausiai nustatau stebėseną ir pranešimus, kad daugiau niekada nepraleisčiau termino.
Ypatingi atvejai: Pakaitiniai ženklai, kelių domenų ir patvirtinimo tipai
Jei naudoju daug subdomenų, naudoju "Wildcard"-certificate (*.domain.tld) ir išsaugoti sau atskirus sertifikatus. Keliems visiškai skirtingiems domenams naudoju SAN/UCC sertifikatus, kuriuose apibendrintai nurodyti keli kompiuterių vardai. Daugumai projektų pakanka DV sertifikatų, OV/EV suteikia papildomą tapatybės patvirtinimą - tai naudinga parduotuvėms ar portalams, kuriuose saugomi slapti duomenys. Atkreipiu dėmesį į veikimo laiko apribojimus ir atnaujinimą planuoju taip, kad piko metu nebūtų susikirtimų. DNS patvirtinimui produktyviose zonose dirbu su aiškiomis pavadinimų konvencijomis, kad galėčiau greitai vėl rasti įrašus ir Keisti gali.
Su "Wildcard" svarbu: Patvirtinimas atliekamas tik per DNS-01, todėl naudoju automatinius DNS atnaujinimus arba specialius priežiūros langus. Daugelio domenų aplinkoje įsitikinu, kad visi variantai yra SAN sąraše (įskaitant per metus pridėtus subdomenus). Apkrovos balansavimo įrenginiuose planuoju Platinimas naujuosius sertifikatus visiems mazgams ir tada atskirai išbandykite kiekvieną VIP/regioną. Keičiantis komandoms, naudinga turėti aiškią dokumentaciją apie tai, kas ir kada gauna kokias paslaptis (raktus) ir kaip jos saugiai saugomos.
ACME ir sudėtingos aplinkos: CDN, WAF ir atvirkštiniai tarpiniai serveriai
Ar naudoju CDN arba WAF, užtikrinu, kad patvirtinimas pasiektų pradinį įrenginį: arba į užklausas atsakoma "Edge" (jei palaikoma), arba tiksliniai apeinami /.well-known/ apie. HTTP-01 atveju gali būti peradresavimas į HTTPS, tačiau iššūkis turi būti pasiekiamas be autentifikavimo antraščių, greičio apribojimų ar geografinio blokavimo. DNS-01 atveju tikrinu, ar TXT įrašas prieinamas visame pasaulyje ir ar vertinimui netrukdo "split horizon" konfigūracija.
Už Atvirkštiniai įgaliotiniai Tikrinu tolesnes antraštes (X-Forwarded-Proto), kad programa teisingai reaguotų į HTTPS ir negeneruotų mišraus turinio klaidų. Atnaujindamas sertifikatus su nuliniu nusileidimo laiku, sukuriu sertifikatus žingsnis po žingsnio iš pradžių vieną mazgą, paskui kitus, kad kilus problemoms galėčiau greitai grįžti atgal, nerizikuodamas visomis jungtimis.
Avarinis planas: atšaukimas, rakto praradimas ir greitas pakeitimas
Jei yra Raktų nutekėjimas arba kompromitavimo, nedelsdamas panaikinu sertifikatą ir išduodu naują su naujais raktais. Aš saugau Kontrolinis sąrašas paruoštas: Prieiga prie CA portalo, atšaukimo procedūra, naujų raktų generavimas, greitas platinimas ir įkėlimas. Tada patikrinu OCSP susegimą ir talpyklas, kad iš talpyklų pašalinčiau senas grandines. Dokumentuose pasižymiu priežastį, laiką ir atsakomąsias priemones - tai palengvina auditą ir užkerta kelią pasikartojimams.
Trumpa santrauka
Laiku atnaujinu sertifikatus, tikrinu Automatinis atnaujinimas-funkcija ir išsaugokite prieinamumą prie patvirtinimo. Jei automatinis atnaujinimas neveikia, atnaujinu rankiniu būdu: sugeneruoju CSR, pritaikau, įdiegiu grandinę, išbandau HTTPS. Apsaugau "WordPress" su priverstiniu HTTPS ir stebėjimu, mano pačių serverius kontroliuoja "cronjobs" ir "Certbot". Klaidų išvengiu stebėdamas .well-known iššūkį, tarpinius sertifikatus, SNI ir persiuntimo taisykles. Taikant šį procesą šifravimas išlieka aktyvus, naudotojai pasitiki svetaine, o matomumas nenukenčia dėl įspėjimų apie galiojimo pabaigą.
