Gumawa ng imbentaryo ng mga hostname, dependencies, at pagmamay-ari
Ilista ang bawat hostname na ginagamit ng mga bisita o integrasyon: apex, www, subdomain, API, host ng asset, portal, at mga pang-rehiyong pangalan. Para sa bawat isa, itala kung saan nagtatapos ang TLS, sino ang maaaring magbago nito, saklaw at pag-expire ng sertipiko, paraan ng renewal, at mga dependency na gumagawa ng mga URL. Dapat saklawin ng isang sertipiko ang hinihinging hostname sa listahan ng Subject Alternative Name (SAN). Isama ang CMS, CDN, tag manager, object storage, payment provider, mga template ng email, at third-party embed; madalas na nag-iintroduce ang mga ito ng HTTP na URL pagkatapos ng unang HTTPS release.
Pumili ng isang canonical na www o apex hostname at i-redirect ang alternatibo diretso rito sa HTTPS.
I-deploy ang sertipiko at kasalukuyang mga bersyon ng TLS
I-configure ang web server, reverse proxy, CDN, o load balancer na tumatanggap ng pampublikong request. I-install ang sertipiko at kinakailangang chain, iugnay ang mga ito sa mga nilalayong pangalan, at beripikahin ang mga ito mula sa labas ng hosting network. Sinusuri ng browser ang chain, hostname, at mga petsa; ang pampublikong babala ay hadlang sa release. Gawing default ang TLS 1.3 at panatilihin ang TLS 1.2 lamang kapag kailangan para sa compatibility. I-disable ang SSL at TLS 1.0 at 1.1. Sundin ang napapanahong gabay ng platform sa halip na kumopya ng lumang listahan ng cipher, at panatilihing naka-patch ang server at TLS library.
Limitahan ang access sa mga private key at itala ang bawat sistemang gumagamit ng iisang key upang mailagay ang kapalit na key sa lahat ng ito.
I-redirect ang HTTP nang isang beses at gawing canonical ang HTTPS
Magbalik ng server-side permanent redirect, karaniwang 301 o 308, mula sa bawat HTTP URL papunta sa katumbas nitong HTTPS URL. Iwasan ang chains: nagpapadagdag ito ng delay at ng mas maraming punto ng pagkabigo. I-publish ang canonical na HTTPS URL sa mga internal link, canonical tag, sitemap, structured data, social tag, email, at mga application-generated absolute link. Subukan ang home page, isang malalim na pahina, isang query URL, mga error route, at mga hostname variant. Kapag nagtatapos ang TLS sa isang proxy, i-configure ang trusted forwarded-protocol handling upang hindi mag-loop ang aplikasyon sa pagitan ng HTTP at HTTPS.
Maaari itong manatiling available lamang para mag-redirect o kumpletuhin ang isang certificate challenge, hindi para magsilbi ng hiwalay na pampublikong site.
Hanapin at ayusin ang mixed content sa pinagmulan nito
Ang mixed content ay isang HTTPS na pahina na nagre-request ng resource sa pamamagitan ng HTTP o ibang hindi secure na protocol. Maaaring i-upgrade ng mga browser ang ilang media, ngunit binablock nila ang maraming mapanganib na request, kabilang ang scripts, stylesheets, frames, fetch calls, at fonts. Palitan ang bawat reference ng isang na-test na HTTPS URL, isang relative URL para sa sariling content, o isang aprubadong alternatibo. I-crawl ang mga representative template at inspeksyunin ang developer tools habang tinatapos ang mga pangunahing journey. Suriin ang CSS, JavaScript, mga block ng CMS, asset manifests, mga entry ng tag manager, downloads, at vendor embed. Ang isang secure na pahina ay hindi dapat mag-alok ng HTTP download.
Ang automatic browser upgrading ay maaari pa ring mag-iwan ng unavailable o hindi sinusuportahang third-party dependency; iwasto ang naka-store na URL.
I-automate ang renewal at magsanay para sa recovery ng sertipiko
Tratuhin ang renewal bilang isang automated deployment, hindi isang paalala sa kalendaryo. Dapat itong mag-renew, i-deploy sa bawat serving tier, at ligtas na mag-reload ng serbisyo. I-test ang parehong validation route bago ang production expiry. Halimbawa, inirerekomenda ng Let’s Encrypt ang pag-renew ng kanilang 90-araw na sertipiko bawat 60 araw; sundin ang lifecycle para sa iyong issuer at platform. Itago ang mga pangalan ng sertipiko, account ng issuer, method ng challenge, automation, lokasyon ng key, target, at emergency contact sa imbentaryo. Beripikahin ang mga petsa mula sa pampublikong endpoint pagkatapos ng deployment.
Para sa nabigong renewal, suriin ang DNS, challenge routing, permissions, access ng issuer, rate limits, at deployment mula CDN papuntang origin.
Gumamit ng HSTS lamang kapag handa na ang HTTPS estate
Ang HTTP Strict Transport Security, o HSTS, ay isang HTTPS response header na nagsasabi sa mga browser na gumamit ng HTTPS sa mga susunod na pagbisita sa isang host. Pagkatapos nito ay hindi na ibibigay ng browser sa mga bisita ang bypass para sa mga error ng sertipiko. Ipadala ito lamang sa HTTPS at panatilihin ang HTTP redirect dahil natututuhan ang HSTS pagkatapos ng secure na response maliban kung may preload list na inilalapat. Magsimula sa limitadong max-age at pahabain ito pagkatapos mapatunayan ang renewals at kinakailangang mga ruta. Huwag idagdag ang includeSubDomains hanggang ang bawat kasalukuyan at hinaharap na subdomain ay makapagsilbi ng valid na HTTPS. Ang preload ay hindi bahagi ng HSTS specification at nangangailangan ng hiwalay na pangmatagalang commitment review.
Ang max-age=0 ay gumagana lamang pagkatapos maabot ng browser ang isang valid na HTTPS response; hindi nito maayos ang isang hindi maaabot na secure host.
Mag-release, mag-test, at mag-roll back nang hindi pinapahina ang transport
Itala ang subok nang gumaganang sertipiko, edge, at redirect configuration bago ang pagbabago. Tukuyin kung sino ang mag-aapruba sa rollback, magsagawa ng staging kung maaari, at baguhin ang isang uri ng control sa bawat pagkakataon. Agad na suriin ang mga pampublikong endpoint mula sa higit sa isang network, sundan ang mga redirect, inspeksyunin ang sertipiko, at kumpletuhin ang mahahalagang aksyon ng bisita. Subukan ang mga browser at client group na mahalaga sa iyong audience. Para sa payment o regulated na daloy, humingi ng pagsusuri mula sa payment provider at kwalipikadong propesyonal sa seguridad tungkol sa mga naaangkop na requirement. Kung masira ng pagbabago ang HTTPS, ibalik ang napatunayang ligtas na configuration; huwag gawing HTTP ang mga pahina ng customer bilang workaround.
Kuhanan ng tala ang hostname, oras, client, error, pagbabago, at resulta upang mas madaling i-diagnose ang susunod na renewal o migration.