Orodhesha majina ya mwenyeji, utegemezi, na umiliki
Orodhesha kila jina la mwenyeji ambalo wageni au miunganisho hutumia: apex, www, vikoa vidogo, API, wahifadhi mali (asset hosts), portali, na majina ya kanda. Kwa kila moja, andika mahali TLS inapokoma, nani anaweza kubadilisha, ufunikaji na kumalizika kwa cheti, njia ya upya, na utegemezi unaotengeneza URL. Cheti lazima kiwe kinachofunika jina la mwenyeji lililoombwa katika orodha ya Subject Alternative Name ya cheti. Jumuisha CMS, CDN, meneja wa tag, uhifadhi wa vitu (object storage), msambazaji malipo, templeti za barua pepe, na viambatisho vya wahusika wa tatu; hizi mara nyingi huleta URL za HTTP baada ya uzinduzi wa kwanza wa HTTPS.
Chagua jina la www au apex linalotumika kama kimsingi (canonical) na elekeza mbadala moja kwa moja kwalo kupitia HTTPS.
Sakinisha cheti na matoleo ya sasa ya TLS
Sanidi seva ya wavuti, reverse proxy, CDN, au load balancer ambayo inajibu ombi la umma. Sakinisha cheti na mnyororo unaohitajika, yafunge kwa majina yaliyokusudiwa, na yathibitishe kutoka nje ya mtandao wa mwenyeji. Kivinjari kinakagua mnyororo, jina la mwenyeji, na tarehe; onyo la umma ni kizuizi cha uzinduzi. Tumia TLS 1.3 kwa chaguo-msingi na udumishe TLS 1.2 tu pale utangamano unapohitajika. Zima SSL na TLS 1.0 na 1.1. Tumia mwongozo wa kisasa wa jukwaa badala ya kunakili orodha ya cipher ya zamani, na sasisha seva na maktaba za TLS kwa viraka vya usalama.
Punguza ufikiaji wa funguo za kibinafsi na rekodi kila mfumo unaoshiriki funguo ili uingizwaji ufikie kila sehemu.
Elekeza HTTP mara moja na fanya HTTPS kuwa kimsingi
Rudisha redirect ya kudumu ya upande wa seva, kwa kawaida 301 au 308, kutoka kila URL ya HTTP kwenda kwenye URL yake sawa ya HTTPS. Epuka minyororo ya redirects: huongeza ucheleweshaji na sehemu zaidi za kushindwa. Chapisha URL za kanoni za HTTPS katika viungo vya ndani, vitambulisho vya canonical, ramani za tovuti, data iliyopangwa, tag za kijamii, barua pepe, na viungo kamili vinavyotengenezwa na programu. Jaribu ukurasa wa nyumbani, ukurasa wa ndani, URL yenye query, njia za kosa, na mabadiliko ya jina la mwenyeji. TLS inapokoma kwenye proxy, sanidi utunzaji wa itifaki inayotumwa na proxy inayoaminika ili programu isiingie katika mzunguko kati ya HTTP na HTTPS.
Inaweza kubaki ikipatikana tu kwa ajili ya kuelekeza au kukamilisha changamoto ya cheti, si kwa kuhudumia tovuti ya umma tofauti.
Tafuta na rekebisha mixed content kutoka chanzo chake
Mixed content ni ukurasa wa HTTPS unaoomba rasilimali kupitia HTTP au itifaki nyingine isiyo salama. Vivinjari vinaweza kuboresha baadhi ya media kiotomatiki, lakini huzuia maombi mengi hatarishi, yakiwemo scripts, stylesheet, frames, maombi ya fetch, na fonti. Badilisha kila rejea kwa URL ya HTTPS iliyojaribiwa, URL ya jamaa kwa maudhui yako mwenyewe, au mbadala ulioidhinishwa. Tumia crawler kukagua templeti wakilishi na chunguza zana za msanidi huku ukikamilisha safari muhimu za mgeni. Kagua CSS, JavaScript, blocks za CMS, orodha za mali (asset manifests), viingilio vya meneja wa tag, upakuaji, na embeds za muuzaji. Ukurasa salama haupaswi kutoa upakuaji wa HTTP.
Kuboreshwa kwa kivinjari kwa njia ya moja kwa moja bado kunaweza kuacha utegemezi wa mtu wa tatu usiopatikana au usioendekane; rekebisha URL iliyohifadhiwa.
Otomatisha usasishaji na fanyia mazoezi urejeshaji wa cheti
Chukulia usasishaji kama utoaji wa kiotomatiki, si ukumbusho wa kalenda. Lazima usasishe cheti, ukisambaze kwenye kila ngazi inayohudumia trafiki, na upakie upya huduma kwa usalama. Jaribu njia ile ile ya uthibitisho kabla ya kumalizika kwa muda kwenye uzalishaji. Kwa mfano, Let’s Encrypt inapendekeza kuipya cheti chake cha siku 90 kila siku 60; fuata mzunguko wa maisha kwa mtoaji wako na jukwaa. Hifadhi majina ya cheti, akaunti ya mtoaji, njia za changamoto, otomatiki, eneo la funguo, malengo, na mawasiliano ya dharura katika orodha ya mali. Thibitisha tarehe kutoka kwenye mwisho wa umma baada ya utekelezaji.
Kwa upya ulioshindwa, angalia DNS, upangaji wa changamoto, ruhusa, ufikiaji wa mtoaji, vikwazo vya kiwango (rate limits), na utoaji wa CDN-kwa-origin.
Tumia HSTS tu baada ya mazingira ya HTTPS kuwa tayari
HTTP Strict Transport Security, au HSTS, ni kichwa cha majibu cha HTTPS kinachowaambia vivinjari kutumia HTTPS kwenye ziara za baadaye kwa mwenyeji. Vivinjari basi haviwahi kutoa njia ya kupita kwa makosa ya cheti. Tuma tu kupitia HTTPS na udumishe redirect ya HTTP kwa sababu HSTS inajifunzwa baada ya majibu salama isipokuwa orodha ya preload itumike. Anza na max-age ndogo na uongeze taratibu baada ya kuthibitisha upya na njia zinazohitajika. Usijumuishe includeSubDomains hadi kila subdomain ya sasa na ya baadaye iweze kuhudumia HTTPS halali. Preload si sehemu ya vipimo vya HSTS na inahitaji ukaguzi wa kujitolea wa muda mrefu.
max-age=0 inafanya kazi tu baada ya kivinjari kufikia jibu halali la HTTPS; haiwezi kurekebisha mwenyeji usioweza kufikiwa kwa njia salama.
Toa, jaribu, na rejesha bila kudhoofisha usalama wa usafirishaji
Weka cheti kilichojulikana vizuri, mipangilio ya edge, na redirect kabla ya mabadiliko. Tambua nani anaruhusiwa kurejesha, panga hatua za awali pale linapowezekana, na badilisha kikontro moja kwa wakati. Mara moja angalia viunganisho vya umma kutoka mtandao zaidi ya mmoja, fuata redirects, chunguza cheti, na kamilisha vitendo muhimu vya mgeni. Jaribu vivinjari na vikundi vya wateja vinavyowahusu hadhira yako. Kwa malipo au mizunguko iliyodhibitiwa, uliza msambazaji wa malipo na mtaalamu aliyehitimu wa usalama akague mahitaji yanayohusika. Ikiwa mabadiliko yanavunja HTTPS, rejesha usanidi salama uliothibitishwa; usifanye kurasa za wateja kuwa HTTP kama suluhisho.
Chukua kumbukumbu za hostname, wakati, mteja, kosa, mabadiliko, na matokeo ili upya au uhamisho ufuatao uwe rahisi kugundua.