Solved - SSL certificate validation fails with 'The revocation function was unable to check revocation because the revocation server was offline."

Question

I have a very specific issue with my application. Currently, I host the .net core web service on the IIS on the machine installed in the domain. We use Windows Server 2019. The application connects to the service from our domain but the connection is checked and available. The firewall rules were set to enable it. The service has enabled revocation chain validation for the SSL domain certificate of the given service. I added additional tracing to my app and I see that it fails for each certificate in the chain with the error "The revocation function was unable to check revocation because the revocation server was offline". I checked the OCSP and CLR URLs with telnet and they are accessible by the given user. My service is installed on the application pool authorized by the identity from the domain. The user is not added to the machine administrators but its added to the groups:

• Certificate Service DCOM Access (added for testing but didn't help)
• Cryptographic Operators
• IIS_IUSRS
• List item

I see that the root certificate is installed in the LocalComputer/Trusted Root Certification Authorities and the intermediate certificate is installed in the LocalComputer\Intermediate Certification Authorities. The domain certificate contain the OCSP and CLR URLs. Both are accessible for the user. The intermediate certificate contains same CLR URL.

I used certutil to test CLR validation and it works correctly. (Logged in powershell as the given user)

certutil -URL "url"

Result

certutl -verify "ssl.cer"

Result

I used OpenSSL ocsp tool to test OCSP validation and it passes with OCSP Response Status: successful. I thought it could be the ssl version limitations but the OCSP and CLR uses the unencrypted http protocol.

What is important when I check disk cache with certutil -v -urlcache I don't see the cache for the given clrs in the location C:\Users{user}\AppData\LocalLow\Microsoft\CryptnetUrlCache. Although when I retrieve CLR with the command certutil -URL "url" the cache entry is created and the service can validate the certificate revocation for some time.

When I restart the IIS service, the error disappear too but after some time (about 3 hours) I can see the error again.

What is important, on different machines it works. Only the difference is that the user is added to the administrators. I can't find any documentation whether it's required and my preference is to not give the admin privileges to IIS users.

What I noticed additionally, when I run PowerShell session as the given user, the problem disappears for 3 hours. After that time, it shows again. I tried to add permissions to the shared disk cache with no result

read -C:\Windows\System32\config\systemprofile\AppData\LocalLow\Microsoft\

write -C:\Windows\System32\config\systemprofile\AppData\LocalLow\Microsoft\CryptnetUrlCache Do you know what could be the issue?

EDIT 1 :

When I add user to the admin group it works ok but after I remove the user from that group after a few hours I can see the error in the CAPI2 logs

- <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
- <System>
  <Provider Name="Microsoft-Windows-CAPI2" Guid="{5bbca4a8-b209-48dc-a8c7-b23d3e5216fb}" /> 
  <EventID>53</EventID> 
  <Version>0</Version> 
  <Level>2</Level> 
  <Task>53</Task> 
  <Opcode>2</Opcode> 
  <Keywords>0x4000000000000036</Keywords> 
  <TimeCreated SystemTime="2023-04-19T15:12:26.951701600Z" /> 
  <EventRecordID>93533</EventRecordID> 
  <Correlation /> 
  <Execution ProcessID="11464" ThreadID="10656" /> 
  <Channel>Microsoft-Windows-CAPI2/Operational</Channel> 
  <Computer>computerName</Computer> 
  <Security UserID="S-1-5-21-1525952054-1005573771-2909822258-408438" /> 
  </System>
- <UserData>
- <CryptRetrieveObjectByUrlWire>
  <URL scheme="http">http://domain/ocsp/MFQwUjBQME4wTDAJBgUrDgMCGgUABBS5xO7XtiSujkx%2FSG3nQqEMQPlZTQQUfR%2Bt1nzLSol4VWy6EPLtM9Yxus0CE2MAA%2FCOGz%2F%2F0t%2BhtSEAAQAD8I4%3D</URL> 
  <Object type="CONTEXT_OID_OCSP_RESP" constant="6" /> 
  <Timeout>PT15S</Timeout> 
  <Flags value="202004" CRYPT_WIRE_ONLY_RETRIEVAL="true" CRYPT_LDAP_SCOPE_BASE_ONLY_RETRIEVAL="true" CRYPT_PROXY_CACHE_RETRIEVAL="true" /> 
  <AuxInfo maxUrlRetrievalByteCount="104857600" cacheFileNamePrefix="53522CFD2721178B362346952DFE900A_" /> 
- <AdditionalInfo>
- <Action name="Call_WinHttpOpen">
  <Error value="3FA">Illegal operation attempted on a registry key that has been marked for deletion.</Error> 
  </Action>
  </AdditionalInfo>
  <EventAuxInfo ProcessName="w3wp.exe" /> 
  <CorrelationAuxInfo TaskId="{083CE273-6A9D-4F3E-BB76-31C370F81E0F}" SeqNumber="10" /> 
  <Result value="3FA">Illegal operation attempted on a registry key that has been marked for deletion.</Result> 
  </CryptRetrieveObjectByUrlWire>
  </UserData>
  </Event>

EDIT 2:

Finally I found the solution. I installed ProcMon and after looking for the events from the time of occurrence of errors in CAPI logs, I found that the application is trying to use the registry entries for the given application pool identity. Enabling the flag Load User Profile in the IIS Application pool options fixed the issue