Al kiu Docker CA konservejo montras la prokura fiasko?
Apartigu bildajn elŝutojn, konstruajn elŝutojn kaj petojn de la uzhava aplikaĵo kiam vi fidas rajtigitan inspektan CA.
Aldoni firmaan CA ene de ujo ne povas ripari la malsukcesan bildan elŝuton de kolego. Sukcesa elŝuto ankaŭ ne pruvas, ke la aplikaĵo ene de la bildo fidas la inspektitan HTTPS-servon.
| Operacio | Fido esplorota |
|---|---|
| Elŝuti bildon per la inspekta prokuro de la organizo | La gastiganto aŭ Docker-medio faranta la elŝuton |
| Elŝuti dum bilda konstruo | La konstrua medio kaj ĝia elŝutilo |
| Voki HTTPS-servon el la kuranta aplikaĵo | La OS-konservejo de la bildo aŭ la propra fidagordo de la aplikaĵo |
Spuru la eraron al la procezo, kiu kontrolas la samtavolan, poste konfirmu la eldoninton, gastigan nomon kaj manpreman fazon. Rajtigita inspekta servo povas subskribi la celan atestilon per la CA de la organizo. TLS-fiasko ĉe HTTPS-prokura aŭskultanto ne estas aŭtomate fiasko de la cela atestilo atingata tra ĝi. Enigi la IP de la prokuro donas neniun fidmaterialon.
Instalu la aprobitan publikan eldonintan atestilon per la subtenata mekanismo de la koncerna gastiganto, bilddistribuo aŭ aplikaĵo. La CA-gvidado de Docker kovras gastigajn kaj ujajn konservejojn, sed CentOS-vojo ne estas portebla instrukcio por Debian aŭ Windows. Aldono al generita fasko povas esti nuligita per ĝisdatigo; Java-aplikaĵo aŭ alia kliento kun propra CA-agordo povas tute ignori la OS-faskon.
Por daŭra aplikaĵa fido, metu la ŝanĝon en la aprobitan bildan aŭ aplikaĵan agordan procezon. Interaga redakto de unu kuranta ujo mankos en la sekva ujo kreita el la bildo.
Distribuu nur la bezonatan publikan fidatestilon per la rajtigita kanalo. Neniam metu CA-privatan ŝlosilon en bildon kaj ne traktu la radikinstalan peton de nekonata publika prokuro kiel ordinaran agordon. Tenu gastignoman kaj ĉenan kontrolon ŝaltitaj post kiam la celata konservejo estas agordita.