...

Suaktyvinkite "All-Inkl" SSL sertifikatą - greitai ir saugiai nustatykite HTTPS

Aktyvuoju All-Inkl SSL vos per kelias minutes, švariai įdiegti HTTPS ir iš karto po to pašalinti tipines kliūtis, pvz., mišrų turinį. Šiame žingsnis po žingsnio vadove parodoma, kaip aktyvuoti sertifikatą KAS, teisingai nustatyti nukreipimus ir visiškai užtikrinti šifravimą tiek techniniu, tiek SEO požiūriu.

Centriniai taškai

  • Užšifruokime Suaktyvinkite KAS naudodami "All-Inkl" ir patikrinkite užraktą
  • Priversti HTTPS Tinkamai naudokite per persiuntimą ir HSTS
  • Mišrus turinys Patikimai rasti ir pakeisti
  • Sertifikato grandinė išbandyti ir išjungti senus protokolus.
  • SEO pasekmės paaiškinti su "Search Console" ir svetaine "Sitemap

Kodėl HTTPS su "All-Inkl" turi tiesioginį poveikį

Turėdamas aktyvų sertifikatą, užtikrinu užšifruotą Ryšys tarp naršyklės ir serverio, o tai reiškia, kad formos, prisijungimo ir mokėjimo duomenys išlieka apsaugoti. Kartu padidinu pasitikėjimą, nes šiuolaikinėse naršyklėse matomai rodomas užrakto simbolis ir paslepiami įspėjimai. Parduotuvėms ir daugeliui API šifruotas pristatymas jau seniai laikomas privalomu, o redakcijos taip pat saugo registracijos sritis ir kontaktines formas. Saugius puslapius "Google" vertina palankiai, o tai ilgalaikėje perspektyvoje palaiko matomumą ir paspaudimų skaičių. Tie, kurie šiandien praleidžia SSL protokolą, rizikuoja atšaukti užsakymus, gauti klaidų pranešimus ir sumažinti konversijų skaičių, nors naudojant "All-Inkl" aktyvinimas yra labai greitas.

Reikalavimai ir pasirengimas KAS

Pirmiausia įsitikinu, kad domenas ir Priegloba "All-Inkl", o DNS įrašai teisingai nukreipia į paketą. Jei atlikau DNS pakeitimus, laukiu platinimo, kad sertifikato patikra vyktų patikimai. Turėtų būti prieinamas administratoriaus prisijungimas prie KAS (klientų administravimo sistemos), taip pat pagrindinis domenas ir reikiami subdomenai. Prieš atlikdamas svarbius WordPress pakeitimus, eksportuoju Duomenų bazė ir pasidaryti atsarginę failų kopiją, kad prireikus galėčiau greitai grįžti atgal. Tada pradedu tikrąjį aktyvavimą, neprarasdamas laiko.

Suaktyvinti "All-Inkl SSL": Žingsnis po žingsnio

Prisijungiu prie KAS ir pasirenku atitinkamą Domenas iš apžvalgos. Redagavimo dialogo lange atidarau skirtuką "SSL apsauga" ir dar kartą spusteliu Redaguoti, kad pamatytumėte parinktis. Skirtuke "Let's Encrypt" (šifruokime) patvirtinu pranešimą ir inicijuoju išdavimą; po kelių minučių sertifikatas paruoštas ir puslapis įkeliamas per HTTPS. Norėdamas patikrinti, atidarau puslapį privačiame lange, išvalau talpyklą ir pažiūriu į spynos simbolį kairėje URL. Jei norite atlikti išsamesnius veiksmus, trumpas All-Inkl Let's Encrypt vadovas sinchronizuojant mano nustatymus.

Priversti HTTPS: Teisingai nustatykite nukreipimus

Po aktyvavimo visą HTTP srautą nukreipiu į HTTPS priešingu atveju puslapis ir toliau bus pasiekiamas abiem protokolais. Paprastai per .htaccess nustatau 301 nukreipimą, naudodamas perrašymo taisyklę, taip pat naudoju All-Inkl galinę versiją, kad būtų patogu nukreipti. Kartu patikrinu, ar www ir be www nuosekliai veikia į pageidaujamą vietą, kad išvengčiau turinio dubliavimo. Kai tik svetainė veikia visiškai be sumaišyto turinio, įjungiu HSTS (Griežtas saugumas ir saugumas) ir taip sumažinamas atakos paviršius, kurį galima užvaldyti žemesnio lygio atakomis. Sėkmę tikrinu iš naujo paleidęs naršyklę arba naudodamas komandinę eilutę, kad vietinės talpyklos nesuklastotų rezultato.

Praktika: saugus .htaccess taisyklių ir HSTS nustatymas

Siekdamas užtikrinti, kad perėjimas prie euro įvyktų tinkamai, nustatiau aiškias taisykles .htaccess apie. Du tipiški kanonizacijos variantai:

1) iš http ir www į https be www:

RewriteEngine On

Priversti # pereiti prie https
RewriteCond %{HTTPS} !=on
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

# pašalinti www
RewriteCond %{HTTP_HOST} ^www\.(.+)$ [NC]
RewriteRule ^ https://%1%{REQUEST_URI} [L,R=301]

2) iš http ir ne www į https su www:

RewriteEngine On

Priversti # pereiti prie https
RewriteCond %{HTTPS} !=on
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

# force www
RewriteCond %{HTTP_HOST} !^www\.
RewriteRule ^ https://www.%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

HSTS Jį įjungiu tik tada, kai nebėra mišraus turinio klaidų. Pradedu konservatyviai ir palaipsniui didinu trukmę:

# 5 minutės testavimui
  Antraštė visada nustatoma Strict-Transport-Security "max-age=300"

Jei viskas stabilu, nustatau ilgesnį galiojimą, pasirinktinai subdomenus ir išankstinį įkėlimą:

Antraštė visada nustatyta Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"

Svarbu: išankstinę įkrovą turėčiau įjungti tik tuo atveju, jei kiekvienas subdomenas tikrai patikimai pasiekiamas per HTTPS, nes naršyklės ilgą laiką įrašą talpina į talpyklą.

Saugiai pašalinkite mišrų turinį

Dažna įspėjimų priežastis - kietai susieti http-išteklių, pavyzdžiui, paveikslėlių, scenarijų ar stilių rinkinių. Tokias nuorodas nuolat keičiu https arba nustatau santykinius kelius, kad turinys būtų įkeliamas teisingai, nepriklausomai nuo protokolo. "WordPress" programoje ištaisau adresus nustatymuose ir patikrinu puslapių kūrėjus, meniu, valdiklius ir temos parinktis, ar juose nėra paslėptų URL adresų. Didesnių kolekcijų atveju naudoju specialius įrankius, pvz. Duomenų bazė arba tinkamus įskiepius, kurie konvertuoja vidines nuorodas. Kompaktiškas įvadas, instrukcijos SSL 5 žingsniai per tipines statybvietes be ilgų apvažiavimų.

Trikčių šalinimas: naršyklė, konsolė ir komandinė eilutė

Atidarau naršyklės kūrėjo įrankius ir patikrinu Konsolė apie mišraus turinio įspėjimus ir saugumo skirtuką. Ten galiu matyti blokuojamus išteklius ir jų kilmę. Keletas komandų padeda man atlikti serverio pusės patikrinimą:

# HTTP turėtų grąžinti 301 HTTPS
curl -I http://example.com/

# Patikrinkite HTTPS atsakymo antraštę (HSTS, CSP, spartinimas)
curl -I https://example.com/

# Patikrinkite sertifikatų grandinę
openssl s_client -connect example.com:443 -servername example.com < /dev/null | openssl x509 -noout -issuer -subject -dates

Su garbanoti Galiu greitai atpažinti, ar yra neteisingų 302 nukreipimų, grandinių ar kilpų. Jei būsenos kodai, tikslinis URL ir antraštės yra teisingi, pagrindas yra teisingas. Jei kyla spartinančiosios atmintinės problemų, prieš bandydamas dar kartą išvalau naršyklės ir serverio spartinančiąją atmintinę ir, jei reikia, CDN spartinančiąją atmintinę.

Patikrinkite sertifikato grandinę ir protokolus

Po perjungimo išbandau Sertifikato grandinė su SSL tikrinimo programa, kad netrūktų tarpinių sertifikatų. Įsitikinu, kad grandinė yra teisinga iki pat patikimo šakninio sertifikato, nes priešingu atveju, nepaisant galiojančio sertifikato, atsiranda naršyklės įspėjimai. Taip pat įvertinu palaikomas versijas ir išjungiu pasenusius protokolus, pavyzdžiui, TLS 1.0 ir 1.1. Jei įmanoma, pirmenybę teikiu TLS 1.3 ir saugius šifrų rinkinius, palaikančius "Perfect Forward Secrecy". Galutinis kokybės testas iš karto parodo klasę, grandinę, protokolus ir galimas silpnąsias vietas.

Subdomenai, pseudodomenai ir persiuntimo matrica

Iš anksto suplanuoju, kokie šeimininkai yra prieinami ir kaip jie kanonizuojami. Tipiniai kandidatai: wwwnuogą sritį, cdn-, vaizdas- arba tinklaraštis-subdomenai, pakopiniai / dev hostai ir alias domenai. Mano matrica apibrėžta:

  • kurie prieglobsčio vardai aktyviai teikia HTTPS,
  • kuris tikslinis domenas laikomas kanoniniu,
  • kurie viduje nukreipia į kitus kelius (pvz., /blog),
  • kurie subdomenai neįtraukiami (pvz., dev tik per Basic-Auth).

Tinklalapiui "Wildcard" sertifikatai Aš aprėpiu visus zonos subdomenus. Naudojant "Let's Encrypt" paprastai reikia atlikti DNS patvirtinimą. Jei slapyvardžio domenas veikia tik kaip nukreipimas į pagrindinį domeną, pakanka tikslinio domeno sertifikato; jei pristatomas pats slapyvardžio domenas, jam reikia atskiro sertifikato arba SAN įrašo. Aš stengiuosi, kad peradresavimo šuolių skaičius būtų kuo mažesnis, geriausia, kad iš kiekvieno įvesties URL į tikslinį URL būtų vienas 301.

Švarus "WordPress" perjungimas į HTTPS

"WordPress" nustatiau Svetainės adresas ir "WordPress" adresą į https, ištrinkite talpyklas ir patikrinkite pagrindinį puslapį bei papildomus puslapius. Atskirai tikrinu valdiklius, meniu ir puslapių kūrimo laukus, nes juose dažnai saugomi seni keliai. Išorines integracijas, tokias kaip "YouTube", šriftai ir stebėjimo scenarijai, konvertuoju į https, kad naršyklė neblokuotų turinio. Jei naudoju CDN, pritaikau Galutiniai taškai ir nustatykite pristatymą į https, įskaitant teisingai išsaugotus sertifikatus. Tik tada, kai viskas sklandžiai įkeliama, nustatau HSTS ir palaipsniui didinu galiojimo laikotarpį.

WordPress: Praktinės komandos ir kliūtys

Didesnių svetainių konvertavimą pagreitinu naudodamas WP-CLI ir atkreipkite dėmesį į ypatingas serijinių duomenų savybes:

# Bazinių URL nustatymas
wp option update home 'https://example.com'
wp option update siteurl 'https://example.com'

# Ieškoti ir pakeisti visose lentelėse (praleisti GUID stulpelį)
wp search-replace 'http://example.com' 'https://example.com' --all-tables --skip-columns=guid

# Saugi administratoriaus sritis
wp config set FORCE_SSL_ADMIN true --raw

Keičiu GUID kodai duomenų bazėje, nes jie yra nekeičiami identifikatoriai. Temose tikrinu paveikslėlių URL adresus CSS (fono paveikslėlius) ir sunkiai užkoduotus scenarijų ar šriftų šaltinius. Naudodamasis puslapių kūrėjais, atkreipiu dėmesį į visuotinius nustatymus, kurie paveldi protokolo savybes. Po pakeitimo ištuštinu visas talpyklas (puslapio, objektų talpyklą, CDN) ir, jei reikia, regeneruoju. Miniatiūrosjei ekrano keliai pertvarkomi.

Išplėstiniai sertifikatai ir CSR "All-Inkl

Specialių reikalavimų turintiems projektams galiu pasiūlyti "Wildcard"-Tada galiu naudoti CSR, OV arba EV sertifikatą ir integruoti jį į KAS. Tai padarysiu sukurdamas CSR, pavesdamas jį pasirašyti paslaugų teikėjui ir importuodamas sertifikatą, privatųjį raktą ir tarpinius sertifikatus į skirtuką SSL apsauga. Pakaitinis sertifikatas apima visus zonos subdomenus ir tinka, jei naudojama daug subdomenų. Daugumai svetainių pakanka "Let's Encrypt" su geru Suderinamumas ir trumpas rodymo laikas, todėl paprastai pradedu nuo jo. Keisti ar atnaujinti planuoju tik tada, kai reikia organizacinio patvirtinimo arba specialaus rodymo naršyklėje.

Padidinti saugumą po perėjimo prie naujos valiutos

Be nukreipimo, nustatau, kai tik viskas veikia sklandžiai, HSTS su atitinkamu maksimaliu amžiumi ir neprivaloma išankstine registracija. Įjungiu OCSP susegimą, kad naršyklės greičiau gautų atšaukimo duomenis ir reikėtų mažiau užklausų į išorines vietas. Griežta turinio saugumo politika su "upgrade-insecure-requests" padeda automatiškai atnaujinti pamirštas http nuorodas į https. Slapukus žymiu Saugus ir "SameSite", kad seansai išliktų apsaugoti ir būtų mažesnė atakų tikimybė. Jei įmanoma, naudoju HTTP/2 arba HTTP/3, kad sumažėtų vėlavimas ir puslapis būtų pateikiamas greičiau.

Turinio saugumo politika ir antraštės sustiprinimas

Taikau antraštės struktūros metodą ir palaipsniui diegiu ribojamąją politiką. Švelni pradžia yra upgrade-insecure-requeststada aiškiai apibrėšiu šaltinius:

Visada nustatoma antraštė Content-Security-Policy "upgrade-insecure-requests"
  Antraštė visada nustato Referrer-Policy "strict-origin-when-cross-origin"
  Antraštė visada nustato X-Content-Type-Options "nosniff"
  Antraštė visada nustato X-Frame-Options "SAMEORIGIN"
  Antraštėje visada nustatytas Permissions-Policy "geolocation=(), microphone=()"

Naudojant griežtą CSP (default-src 'self' plius tam tikros išimtys) neleidžiu iš naujo įkelti nepageidaujamų išteklių. Report-Only tinka bandymams prieš blokuojant. Dokumentuoju išimtis, kad supaprastinčiau vėlesnius auditus.

Automatinis atnaujinimas ir stebėjimas

"Let's Encrypt" sertifikatai paprastai galioja apie 90 dienų, o "All-Inkl" perima Pratęsimas automatiškai. Reguliariai tikrinu galiojimo datą naršyklėje arba stebėdamas, kad nebūtų netikėtumų. Jei pastebiu problemą, atnaujinimą paleidžiu rankiniu būdu ir tada dar kartą patikrinu grandinę, žurnalus ir nukreipimus. Taip pat stebiu prieinamumą ir reaguoju į perspėjimus apie sertifikatus anksčiau, nei lankytojai ką nors pastebi. Trumpas įrašas kalendoriuje primena man dar kartą patikrinti, net jei automatinė sistema veikia patikimai.

CDN, atvirkštinio tarpinio serverio ir spartinančiosios spąstai

Ar naudoju CDN arba atvirkštinį tarpinį serverį, užtikrinu "Full (strict)" režimą ir saugau galiojantį sertifikatą kilmės vietoje. Tikrinu antraštes, pvz. X-Forwarded-Protokad programa atpažintų teisingą schemą (svarbu absoliučių URL adresų atveju). Dėl Spartinančiosios atmintinės strategija taikoma: perėjus prie HTTPS, visiškai panaikinu CDN talpyklą, kad išvengčiau mišrių versijų. Užtikrinu, kad dubliuojančios talpyklos (pvz., įskiepis + CDN) neteiktų skirtingų versijų. Dėl parašo mechanizmų (dalinio išteklių vientisumo) atnaujinu hashes, jei ištekliai buvo perkelti iš http į https.

SEO veiksmai po HTTPS: "Search Console", svetainės žemėlapis, atgalinės nuorodos

Po aktyvavimo pridedu https savybę į Paieškos konsolė ir pateikite naują svetainės žemėlapį. Patikrinu vidines nuorodas ir kanonines nuorodas šablonuose ir antraštėse, kad viskas būtų teisingai nukreipta į https. Patikrinu, ar analizės, skelbimų ir išorės įrankiuose teisingai išsaugoti adresai, kad stebėjimas ir konversijos išliktų išsamūs. Dideliems projektams naudinga, kad atgalinės nuorodos į svarbius puslapius būtų atnaujintos, siekiant išsaugoti nukreipimo grandines. Apžvalgai mėgstu naudoti kompaktišką HTTPS vadovas kaip baigiamųjų veiksmų kontrolinį sąrašą.

Internacionalizacija, Hreflang ir struktūrizuoti duomenys

Daugiakalbiuose projektuose įsitikinu, kad hreflang-žymos turi nuosekliai nurodyti https variantus. Kanoniniuose ir alternatyviuose ryšiuose neturi būti jokių protokolų mišinių. Struktūrizuotuose duomenyse (schemoje) pirmenybę teikiu absoliutus https URL adresai ir tas pats logotipas, paveikslėlis ir leidėjo nuorodos. . robots.txt išlieka prieinamas ir jame yra https svetainės žemėlapio URL. Peradresavimas turi įtakos naršymo biudžetui; stabilūs 301 tikslai padeda išvengti nereikalingų šuolių.

Prieglobos ir našumo palyginimas

Tinkamas Priegloba supaprastina SSL integravimą, suteikia naujausius serverių stekus ir užtikrina trumpą krovimo laiką. Nepriklausomuose bandymuose daugiausia dėmesio saugumui ir spartai skiriantys paslaugų teikėjai pirmauja, o tai aiškiai pastebima kasdienėje veikloje. "All-Inkl" pasiekia gerų rezultatų dėl paprasto valdymo, patikimų KAS įrankių ir gero sertifikatų valdymo. Kas nori aukštos Veikimas ieškokite HTTP/2/3, greitų SSD diskų ir švarios spartinančiosios atminties koncepcijos. Toliau esančioje lentelėje pateikiama trumpa paslaugų teikėjų klasifikacija ir jų stipriosios pusės.

Reitingas Teikėjas Speciali funkcija
1 webhoster.de Greitas ir labai saugus
2 all-inkl.com Patikimas, paprastas
3 Strato Geras prieinamumas

Atkūrimo planas ir saugus perėjimas

Planuoju Atšaukimasjei po perėjimo prie naujos valiutos nepavyksta atlikti svarbiausių integracijos veiksmų. Tai apima: Atsarginė kopija iš anksto, aiškus pakeistų nustatymų sąrašas, išjungiamos antraštės (HSTS iš pradžių su trumpomis maksimalus amžius) ir laiko langą bandymams atlikti ne didžiausio eismo intensyvumo metu. Pranešu apie diegimą viduje, kad redakcija ir rinkodara galėtų iš naujo prijungti talpyklas ir įrankius. Baigęs darbą, dokumentuosiu nukreipimus, antraštes ir sertifikatų duomenis, kad būtų lengviau atlikti priežiūrą ir auditą.

Trumpa santrauka

Aktyvuoju All-Inkl SSL KAS, nuosekliai užtikrinti HTTPS ir iš karto po perėjimo pašalinti mišrų turinį. Tada patikrinu grandinę, protokolus ir šifrus, įjungiu HSTS pritaikytu būdu ir užtikrinu automatinį atnaujinimą. "WordPress" sistemoje atnaujinu adresus, sutvarkau sunkiai įveikiamus kelius ir pritaikau išorines integracijas. Dėl SEO-puslapį, į "Search Console" įtraukiu https savybę, pateikiu naują svetainės žemėlapį ir išlaikau švarų kanoninį turinį. Taip užtikrinamas greitas svetainės saugumas, didelis įkrovimo našumas ir vienodai didinamas pasitikėjimas bei matomumas.

Aktualūs straipsniai