This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(169.60000000000002, 44%, 26%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EKB%3C/text%3E%3C/svg%3E)
I have a Cisco ISE application which does posture of endpoint by remoteshell / WinRM service using local admin privilege. All looks fine, application is able to get access to Window's RemoteShell, able to push script with curl code to endpoint and end point does initiate the script.
The curl script on endpoint tries to hit the appliance url : https:\xx.xx.com to download the file but end up with failed attempt with error - "curl: (35) schannel: next InitializeSecurityContext failed: Unknown error (0x80092013) - The revocation function was unable to check revocation because the revocation server was offline."
When checked the CRL test from endpoint to see if any CDP path is broken which could turn such error, but CDP path test seems fine as i don't see any error or see the test verification for complete certificate chain gets completed.
Below output for CDP path test (masked original crl url) :
---------------- Certificate AIA ----------------
Verified "Certificate (0)" Time: 0 b0e971dc53eaasfh39sfqw879fd90s04fj7d91a8d1
[0.0] http://xx.xx.com/crt/abc.crt
---------------- Certificate CDP ----------------
Verified "Base CRL (02d9)" Time: 1 f12ad2nf834bd9ene9fn09163b2a050350f1652
[0.0] http://xx.xx.com/crt/abc.crt
---------------- Base CRL CDP ----------------
No URLs "None" Time: 0 (null)
---------------- Certificate OCSP ----------------
Verified "OCSP" Time: 0 139e350f31f2a2j49g8enf9ew4gjv0499011d016845
[0.0] http://xx.xx.com/crt/abc.crt
Appreciate suggestion or input for further checks on endpoint to get rid of the error if anyone have dealt with same sort of problem.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(256, 74%, 34%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3ERM%3C/text%3E%3C/svg%3E)
I should probably leave this for security folks to answer (but it's tagged for PowerShell too), but is it possible you're trying to check for the CA certificates revocation on the root CA and the CA is off-line (as it should be)?
FYI, the subject for your post says the error is 0x80092012, but the error in the post itself says 0x80091213.
This might help: revocation-server-offline-error-0x80092013
@Rich Matheisen , Thanks for highlighting the discrepancy in error code, it was a typo and have corrected it. Actual error is 0x80092013.
Well, i have gone through the link - revocation-server-offline-error-0x80092013, and same certutil -urlfetch test are always successful for complete certificate chain and i don't see anywhere the path is broken and if I'm not wrong then from endpoint CRL checks happens to CDP point mentioned in certificate only, means the CDP point is up and server is online. Anyways I'm neophyte at certificate authority and curl so please excuse my ignorance.
Please let me know if there is any way if it can be checked - in what scenario we might see such error wherein actual CDP point is up and certutil -urlfetch is successful for complete chain ? - this may be for security/CA experts.
To add on with some more details, i have further checked by packet capture and i see difference when the CRL check done through certutil and when done from powershell/curl while hitting https:\xx.xx.com
For CRL check by running certutil - in packet capture i actually see the http get required sent to proxy server for crl url (CDP point).
Now when the http url is hit in curl - i don't see any such query generated for CRL check to CDP in packet capture.
Not exactly sure what difference it make when CDP check is done manually through certutil and when done by curl while hitting the http:\xx.xx.com, but seems when done by curl its failing even without initiating the request to CDP.
In PowerShell "curl" is an alias for the Invoke-WebRequest cmdlet. It isn't the *nix "curl" utility (or a Windows .exe equivalent).
So, can you clarify the "remoteshell / WinRM" part of the problem? Are you using "winrs" or "Invoke-Command" to run your script on the remote machine? BOTH use WinRM, but the code that's run is very different!
@Rich Matheisen
Application push the script on client machine and use Invoke-command to run as per my knowledge but let me check this from Cisco appliance side and come back to you on this.
It would be good to see the code that's being run on the remote machine, too.
FWIW, the error messages you posted look like they come from the curl utility, not the Invoke-WebRequest.
If it is the curl utility, is there a proxy server between appliance and the machine with the Certificate Revocation List? If there is, use the "-x nnn.nnn.nnn.nnn" to supply the IP address of the proxy.
Instead to trying (and dying) by using a url that begins with HTTPS, you can use the "--ssl" parameter and omit the "https://:" in which case it will try using a secure channel and if it fails revert to a non-secure channel; or you can use the "--ssl-no-revoke" parameter and continue to use the "https://" (in which case it won't check the CRL)
Basis the error, failure seems to be happening while executing attached141052-admin-script-formatted-test.txt code on remote machine from script. (first if segment "Hitting URL $downloadLinkAH"
Regarding proxy, yes all client machine are using proxy as per system setting for web access (System Setting -> Proxy -> Automatics Proxy Setup) and while checking winHTTP proxy setting, i see proxy setting is set.
Regarding proxy, while hitting the URL from cURL -> Does it use proxy setting configured on system by default while hitting URL ? or that has to be coded specifically as you mentioned with -x ? However for CRL check, direct reachability is also in place from client machine to CRL server, i mean proxy is not mandate.
Regarding adding proxy (in case it needed to be mentioned specifically, as well about "--ssl" parameter in script) -> the script is not pre defined on client machine, when the Cisco applicate initiate posture, the script is pushed on remote client machine from appliance as per the ongoing session and it get execute, hence i don't have option to modify the script on appliance so that those specific (proxy, --ssl parameters) can be used while executing url.
If proxy and "--ssl" parameters to be used in url hit, is there any other way where proxy or -ssl parameter can be setup on client machine as persistence setting, to use same setting whenever url query is hit from curl utility ?
Since the script runs on a Windows machine, curl will use the default proxy provided by the O/S. No need to add the "-x" parameter.
Going back to your explanation of the packet capture, when you run certutil, are you running it on the same machine that runs curl? And are you verifying the cert on the target machine or are you verifying the certificate specified in positional parameter 7 when the admin script (i.e. the one being invoked)?
If you're not seeing any request go to the machine that (should) hold the CRL, are you sure there's a CRL location present in the certs? If there is, is the name resolvable using the DNS used on the client machine?
Regarding curl to use default proxy provided by O/S, want to get it more clear. Which proxy setting does it use ? as i see two different proxy set on client machine. Proxy setting under system setting option have proxy server A and winHTTP proxy setting has proxy server B.
yes the CDP path check i did on same machine where curl execution is failing on CRL check failure point and yes CRL location is present in the certs and DNS resolution works fine for CDP point on client machine.
How the version of curl picks a proxy is different on *nix and Windows (*nix depends on 'environment' variables for the definition), and it may differ between versions of curl that run on Windows. It's be best to get the explanation of how it works and whether or not you need the "-x" (or it's longer "double-dash" name) right from curl's help (or from a man page if it came with one!).
When you go back to your packet capture, do you see a DNS query for the proxy? If you do, and it has the correct IP address, do you see a subsequent attempt to open a TCP/IP session with the proxy? If you do, does it succeed? You say that you never see any HTTP traffic to the CRL machine.
Right now you might be getting into the area where packet traces become hard to use and HTTP traces provide better information -- especially if you're using HTTPS. Something like 'Fiddler' might become more useful.
Yes, in packet capture i did not see any direct HTTP traffic to CRL machine.
As checked for proxy flow in packet capture, yes there are flow in packet capture for proxy however with filter i don't see any GET or Connect request being sent to proxy for CRL URL. Not getting clue whether client really initiated CRL check for the certificate when script executed !
Let me re-create the scenario and capture it again and see.