SSL-atestil-eraroj post alidirektadoj kun propra CA-pakaĵo
Kontrolu ĉu la eksplicite elektita CA-dosiero enhavas la tutan fidaĵon bezonatan de la fakta petvojo, inkluzive alidirektitajn gastigantojn.
La CA-dosiero de la firmao riparas la unuan URL, poste alidirektado malsukcesas la kontrolon. Kontrolu ĉu la propra CA-opcio anstataŭigis la antaŭan fidenigon de la kliento anstataŭ aldoni al ĝi.
Tiu konduto dependas de la TLS-motoro kaj de la opcio. Dosiero enhavanta nur la firmaan CA povas lasi la klienton sen aliaj necesaj aŭtoritatoj.
- Sekvu ĉiun kontraŭulon. La unua gastiganto povas esti kaptita sub la firmaa eldoninto. Pli posta gastiganto povas uzi preterpason, alian inspektan vojon aŭ publike eldonitan ĉenon.
- Registru la enigojn de la malsukcesanta kliento. Konservu la petitan gastigantnomon, la alidirektan celon, la ricevitan eldoninton, la kontrolrezulton kaj la elektitan fidan agordon. Funkcianta retumilo povas uzi alian radikan konservejon.
- Kontrolu la elekto-regulojn de la motoro. curl-konstruaĵoj povas uzi denaskan kontrolon aŭ dosierbazajn radikojn, kaj eksplicitaj CA-opcioj povas ŝanĝi tiun elekton. Recepto por tiu plenumeblo ne agordas Python-medion nek JVM.
Uzu prizorgatan pakaĵon aŭ subtenatan fidkonservejan aranĝon enhavantan la publikajn kaj privatajn aŭtoritatojn, kiujn la aplikaĵo devas fidi. Ne aldonu la privatan ŝlosilon de CA kaj ne levu ĉiun malsukcesantan folian atestilon al radiko nur por forigi la sekvan eraron.
Liveru la fidaĵon per la subtenata ĝisdatiga vojo de la deplojo. Mana anstataŭigo de vendista CA-pakaĵo povas esti malfarita de ĝia sekva ĝisdatigo; tenu la posedanton kaj la prizorgan procezon eksplicitaj, por ke la kontrolado daŭru tra la tuta petvojo.