The first thing you want to test is opening https://dist.0patch.com in Internet Explorer (not some other web browser!) on the affected computer, because 0patch Agent is using the same networking functions as Internet Explorer. If the page does not open at all, you probably have problems with missing updates or with proxy of firewall (see reasons #1 and #2 below). If you see a security warning about an invalid certificate, reasons #3 and #4 below are the most likely culprit.
Reason #1: Missing Windows Updates
Note: this issue only applies to Windows 7, Server 2008 R2 and older systems.
Older Windows systems, such as Windows 7, Windows XP, Server 2008 R2 or Server 2003, must have all available service packs and updates installed, or their networking support may not meet the requirements for establishing secure connections with our server.
On Windows 7 and Windows Server 2008 R2 computers, make sure all service packs and all official Windows updates up to the latest ones (or the January 2020 monthly rollup, KB4534310, which includes both latest security fixes and all past security and non-security fixes) are installed, and also any subsequent updates that Microsoft may issue. In case you are receiving Extended Security Updates, apply them all.
On Windows XP and Server 2003, make sure all available service packs and updates are installed, and that Internet Explorer 8 is installed and updated.
Reason #2: Proxy server or firewall
The most frequent reason for this is the Agent being behind a proxy server, or a firewall blocking outgoing requests from Agent to server.
Make sure to configure your firewall and/or proxy server as described in 0patch User Manual in section "Network Connectivity". (Make sure to specify the proxy port number in decimal, not hexadecimal, which is Registry Editor's default numeric type.)
Check if your computer has a system proxy configured (run netsh winhttp show proxy). 0patch Agent will honor system proxy settings.
Reason #3: TLS1.0 not allowed
Note: this issue only applies to Windows 7, Windows 8, Server 2008 R2 and Server 2012.
According to https://docs.microsoft.com/en-us/windows/win32/winhttp/option-flags, only SSL3 and TLS1.0 are enabled in Windows 7 and Windows 8 by default. This likely also applies to their server counterparts, Server 2008 R2 and Server 2012. Our Agent is using the default system settings and selects TLS 1.0 just as any other WinHTTP-based app on the same computer would. This works as long as TLS 1.0 is enabled on the computer (which it is by default). However, one can disable TLS 1.0 manually or via Group Policy, or install a product which disables TLS 1.0 such as Internet Information Services.
The solution to this is presented in this article, which provides a downloadable "Easy Fix" that creates a registry value DefaultSecureProtocols under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp, and sets it to 0xA00. This instructs all WinHTTP applications (including 0patch Agent) that they should be using TLS 1.1 or TLS 1.2. (To download the "Easy Fix", find the Easy Fix section in the article, then click the blue Download button.)
If you're seeing "WINHTTP_CALLBACK_STATUS_FLAG_SECURITY_CHANNEL_ERROR" in 0patchService.log under c:\ProgramData\0patch\Logs\, we recommend downloading and running the "Easy Fix" app mentioned above.
Reason #4: Expired Sectigo root certificate
Note: this issue primarily applies to Windows XP and Server 2003, but some users had certificate-related problems on newer Windows systems and installing correct root certificates helped.
Details: 0patch Agent can't connect to server due to expired Sectigo root certificate
If none of the above helped you solve the problem, please email email@example.com and provide the following information:
- Are you trying to (1) register 0patch Agent manually by typing in email and password to 0patch Console, or (2) installing it silently using Account Key?
- Attach 0patchConsole.log and 0patchService.log from C:\ProgramData\0patch\Logs (or C:\Documents and Settings\All Users\Application Data\0patch\Logs on older Windows)
Mine has gone much longer than 60 minutes, it has been yellow all morning this Friday March 27, 2020. I'll wait and see if it clear up before making a request. Thanks for all your support!
This began with me this afternoon March 27, 2020 on both my computer and my husband's. I do know a new patch was installed yesterday afternoon, perhaps that had some negative effect?
Thank you, Mitja. I'll submit a request if it continues.
March 27, 2020 - two hours later 0Patch is now syncing again. I did a User Invoked Sync to get things going and it seems ok - the same on my husband's computer.
orddepot You're likely affected by this one: https://0patch.zendesk.com/hc/en-us/articles/360012914299