ഒരു വെബ്സൈറ്റ് അഭ്യർത്ഥന അതിന്റെ പ്രോക്സിൽ എത്തിയാലും പരാജയപ്പെടാം, കാരണം സർട്ടിഫിക്കറ്റ് സ്ഥിരീകരണത്തിന് മറ്റൊരു നെറ്റ്വർക്ക് അഭ്യർത്ഥന വേണം. ആപ്ലിക്കേഷന്റെ HTTP ക്ലയന്റിൽ നിന്ന് വ്യത്യസ്തമായ അക്കൗണ്ടും പ്രോക്സി നയവുമുള്ള ഒരു പ്ലാറ്റ്ഫോം ഘടകത്തിലൂടെയാകാം CRL അല്ലെങ്കിൽ OCSP വീണ്ടെടുക്കൽ നടക്കുന്നത്.

കൃത്യമായ ചെയിൻ പിശകിൽ നിന്ന് തുടങ്ങുക. Revoked എന്നത് നിലവിലെ റദ്ദാക്കൽ വിവരങ്ങൾ ലഭ്യമാക്കാനാകുന്നില്ല എന്നതിൽ നിന്ന് വ്യത്യസ്തമാണ്. കാലഹരണവും വിശ്വസിക്കാനാകാത്ത ഇഷ്യൂവറും വീണ്ടും വേറെ പ്രശ്നങ്ങളാണ്. വീണ്ടെടുക്കൽ പരാജയത്തിന് മാത്രമാണ് സ്റ്റാറ്റസ് URL-ലേക്കുള്ള കാണാത്ത റൂട്ട് കണ്ടെത്തേണ്ടത്.

ആ പരാജയത്തിന്, മൂന്ന് കാര്യങ്ങൾ ഒരുമിച്ച് കണ്ടെത്തുക: വീണ്ടെടുക്കുന്ന URL, വീണ്ടെടുക്കൽ നടത്തുന്ന ഘടകം, അതിന്റെ പ്രോസസ് ഐഡന്റിറ്റി. നിങ്ങളുടെ ഇന്ററാക്ടീവ് അക്കൗണ്ടിൽ ഒരു ബ്രൗസർ URL വിജയകരമായി തുറക്കുന്നത്, ഒരു സേവനത്തിന് അതേ പ്രോക്സിയിൽ പ്രാമാണീകരിക്കാനാകും എന്നതിന് തെളിവല്ല.

തിരിച്ചറിഞ്ഞ ഘടകം WinHTTP ഉപയോഗിക്കുന്നെങ്കിൽ, അതിന് ബാധകമായ നയം പരിശോധിക്കുക. സ്റ്റാറ്റിക് പ്രോക്സി കോൺഫിഗറേഷനും URL അനുസരിച്ചുള്ള ഓട്ടോമാറ്റിക് പ്രോക്സി മൂല്യനിർണയവും വെവ്വേറെ സംവിധാനങ്ങളാണ്. ഉദ്ദേശിച്ച അക്കൗണ്ടിന് പിന്തുണയുള്ള കോൺഫിഗറേഷൻ പ്രയോഗിക്കുക; ബ്രൗസർ ക്രമീകരണങ്ങൾ പകർത്തുന്നതോ ബന്ധമില്ലാത്ത റൺടൈം മാറ്റുന്നതോ യഥാർത്ഥ വീണ്ടെടുക്കൽ തൊടാതെ വിടാം.

.NET-ൽ, ചെയിൻ നയത്തിലെ UrlRetrievalTimeout ഓൺലൈൻ സ്ഥിരീകരണത്തിനോ CRL വീണ്ടെടുക്കലിനോ വേണ്ട കാത്തിരിപ്പ് നിയന്ത്രിക്കുന്നു. സാധാരണ HTTP പ്രതികരണ ടൈംഔട്ട് നീട്ടുന്നത് അതേ ടൈമർ നീട്ടുന്നില്ല, വീണ്ടെടുക്കൽ ടൈമർ നീട്ടുന്നത് പ്രോക്സി ക്രെഡൻഷ്യലുകളോ റൂട്ടോ നൽകുന്നുമില്ല.

ഒരു HTTPS പ്രോക്സി ഈ ആശ്രിതത്വം ലക്ഷ്യത്തിലേക്കുള്ള TLS-ന് മുമ്പുതന്നെ ദൃശ്യമാക്കാം: പ്രോക്സി കണക്ഷനിലുള്ള വിശ്വാസത്തിന് തന്നെ റദ്ദാക്കൽ വീണ്ടെടുക്കൽ ആവശ്യമായേക്കാം. ആ ഘട്ടത്തിൽ പിന്തുണയുള്ള വീണ്ടെടുക്കൽ ആക്സസും വിശ്വാസ ക്രമീകരണവും പുനഃസ്ഥാപിക്കുക. റദ്ദാക്കൽ പരിശോധന അപ്രാപ്തമാക്കുന്നത് സർട്ടിഫിക്കറ്റ് നയം മാറ്റുന്നു; അത് പരാജയപ്പെട്ട വീണ്ടെടുക്കൽ പുനഃസ്ഥാപിക്കുന്നില്ല.

അനുബന്ധ ലേഖനങ്ങൾ