G DATA virus signatures could not be updated after the licence ran out

Fix it now

This message covers two quite different situations. Either the licence behind the installation has lapsed, or the licence is fine and something between the machine and the update server is in the way. The expiry date in the client settles it in seconds, and 12175 tells you it is the second one.

w32tm /resync
w32tm /query /status

1. Open the G DATA client and read the expiry date on its licence page. If it is in the past, stop here: the fix is a renewal, not a network change.
2. Restart Windows properly rather than using fast startup, then run the client as administrator and choose the update option. G DATA lists both as first steps for a client that cannot reach the update server.
3. Check the proxy in two places: in the client under Settings, Updates, Internet settings, and in Windows under Internet Options, Connections, LAN settings. Remove a proxy that this network does not need.
4. If you see 12175, open certmgr.msc and confirm the DigiCert Global Root CA certificate is present under Trusted Root Certification Authorities. That is G DATA’s own documented cause for a broken secure connection.
5. Run an update manually and read the result rather than assuming the previous error still applies.

Do not respond to a certificate error by disabling certificate validation anywhere. It trades a broken update channel for a worse problem, and it does not fix the missing root certificate.

If the signature date moves to today, you are done. If it does not, the next section separates the licence question from the network one and shows which of the four causes you have.

Why it happens

A security client that cannot update is in the most misleading state a security product reaches. It still loads, still scans, and still reports itself as running, while the data it scans with stops moving. Nothing on screen changes on the day it stops, which is why this is usually discovered weeks late.

Two of the numbers that travel with this message do have published meanings, and both come from Microsoft rather than from G DATA. 12175 is ERROR_WINHTTP_SECURE_FAILURE, and its published meaning is narrower than it is usually given: one or more errors were found in the SSL certificate sent by the server. That is a certificate fault specifically, not a general connection failure, which is why the fix begins with the machine’s trusted roots and its clock rather than with the firewall.

That reading lines up with what G DATA itself documents. Its published causes for a client that cannot reach the update server are a pending restart, missing administrator rights, general connectivity, a router or firewall blocking the path, conflicting security software or traffic-management tools, a misconfigured proxy, a missing DigiCert Global Root CA certificate, and an incorrect system time. Two of those eight are certificate-shaped, and they are exactly what 12175 reports.

1610 is the third number and belongs to neither category. It is a Windows Installer error, ERROR_BAD_CONFIGURATION, and its published meaning is that the configuration data for the product is corrupt. That is a repair job on the installation. It is not a licence problem and it is not a network problem, so if you have 1610 the rest of this article is the wrong reading.

Full reference

Deciding which problem you have

What the published numbers actually say

Reading 12175 as a generic connection failure is the mistake that costs the most time here, because it sends people to the firewall when the machine is telling them about a certificate. A missing root, an expired root, a clock far enough out that a valid certificate looks invalid, and an appliance substituting its own certificate all produce it. A firewall that simply drops the traffic produces something else.

Consumer clients and managed estates are not the same product

G DATA’s business solutions use access data, a user name and password entered on the ManagementServer, and G DATA documents entering those credentials as a distinct task. That is a real mechanism and a real thing to check on a managed estate. It is not how a consumer installation is set up, so on a home PC the useful checks are the licence date and the connection, not a hunt for stored credentials that were never there.

Where to look on a managed installation

• Check the ManagementServer rather than the client. G DATA documents restarting the G DATA Management Server service where automatic signature updates have stopped.
• Confirm the access data entered on the server is current for the licence you hold.
• Check that the clients are pointed at the server rather than at the internet, and that the server itself can reach G DATA.
• Treat one client failing and every client failing as different investigations; the first is the endpoint, the second is the server or the gateway.

How urgent is it

More urgent than it looks. The client that reports this is still scanning, so nothing on the machine appears wrong, and it is scanning with whatever data it last received. A week behind is a meaningful gap. A month behind is a machine that is protected against what was circulating in the spring. Fix the update path before you spend time on anything else the product is doing.

Every code this article covers

Confirm the fix worked

1. The client reports a signature date of today after a manual update.
2. The licence page shows an expiry date in the future.
3. An update runs on schedule without anyone triggering it by hand.
4. Where 12175 was the symptom, DigiCert Global Root CA is present under Trusted Root Certification Authorities and the clock is correct.
5. A full scan completes and the client reports itself as fully up to date afterwards.

Questions people ask about this