GFI Support Home Start a conversation Sign in
Start a conversation
  1. KerioConnect
  2. KB Articles
  3. Public Articles

Troubleshooting Kerio Anti-spam SSL Error 0x00000013 for nimbus.bitdefender.net

In This Article

Overview

Use this article when Kerio Anti-spam fails while initializing its HTTPS connection to nimbus.bitdefender.net and the Debug log repeatedly shows this exact message:

Kerio Anti-spam failed to use SSL connection with SSL error 0x00000013. Initialization failed.

This error can occur even when the anti-spam update package downloads and installs successfully. In that situation, the update download path is working, but the later Kerio Anti-spam cloud lookup to nimbus.bitdefender.net cannot complete because the affected server rejects the TLS certificate chain it receives.

The validated resolution for this symptom is to identify which DNS answer and TLS certificate chain the affected Kerio Connect host is using, then correct the DNS resolver or forwarder so the host reaches an endpoint that presents a publicly trusted certificate chain. A temporary Linux /etc/hosts override can be used only as a short-lived mitigation while the DNS layer is corrected.

Important: This is a Linux-focused procedure. The diagnostic logic applies to the affected Kerio Connect host, but non-Linux systems require equivalent operating-system commands for DNS lookup, TLS testing, service restart, and host override management.

Confirm This Article Applies

Continue with this article only when all of the following are true:

  • The Debug log contains {kerioantispam} entries and the exact error Kerio Anti-spam failed to use SSL connection with SSL error 0x00000013. Initialization failed.
  • The same log window shows that Kerio Anti-spam update files were downloaded and installed before initialization failed, for example Updates were successfully installed.
  • A TLS test from the affected host to nimbus.bitdefender.net:443 shows a certificate verification problem, such as OpenSSL verify code 19 / X509_V_ERR_SELF_SIGNED_CERT_IN_CHAIN.
  • Different resolvers or networks return different DNS answers for nimbus.bitdefender.net, or they lead to endpoints presenting different certificate chains.

Do not use this article as the primary procedure when the log shows a different component or a different failure stage, such as:

  • AntivirusModule.cpp update-server errors. Those are Kerio Antivirus update failures, not this Kerio Anti-spam initialization failure.
  • Kerio Anti-spam failed to get license information with result 0xc0000010 (BDANTISPAM_ERROR_CLOUD_NO_RESPONSE). That symptom points first to cloud endpoint reachability or response problems, not to the specific SSL verification code covered here.
  • General Kerio Connect server certificate import, web administration certificate, or client trust errors. Those involve the certificate Kerio Connect serves to users, not the certificate chain Kerio Connect receives from nimbus.bitdefender.net.

Prerequisites

  • Administrator access to the Kerio Connect Administration interface.
  • Shell access to the affected Kerio Connect host with permission to run DNS and TLS diagnostic commands.
  • Permission to restart Kerio Connect during a maintenance window or an approved troubleshooting window.
  • Access to the DNS resolver, forwarder, firewall, or upstream DNS configuration used by the affected Kerio Connect host.
  • Linux tools for the commands shown in this article: openssl, getent, and either dig or nslookup.

Solution

Confirm the Kerio Anti-spam Log Symptom

  1. Log in to the Kerio Connect Administration interface.
  2. Go to Logs > Debug.
  3. Right-click inside the log area and select Messages.
  4. Enable Kerio Anti-spam Processing. To correlate DNS and TLS behavior in the same troubleshooting window, also enable Network Connections and SSL and DNS Resolver.
  5. Click OK.
  6. Right-click the log area again and select Clear Log. Clearing the log before the test makes the next initialization attempt easier to read because old failures are not mixed with the current attempt.
  7. Restart Kerio Connect or wait for the next Kerio Anti-spam retry. On a Linux system that uses systemd, run: 
    sudo systemctl restart kerio-connect.service

    On an RPM-based system that uses the Kerio Connect init script, run:

    sudo /etc/init.d/kerio-connect restart
  8. Return to Logs > Debug and look for the Kerio Anti-spam sequence from the current attempt.

A matching failure usually looks like this pattern:

{kerioantispam} Going to update Kerio Anti-spam binaries...
{kerioantispam} Updates were successfully installed.
{kerioantispam} Going to use antispam binaries in "..."
{kerioantispam} Kerio Anti-spam failed to use SSL connection with SSL error 0x00000013. Initialization failed.
{kerioantispam} Kerio Anti-spam update attempt failed in ... ms.

Why this matters: The successful update lines prove that Kerio Connect can download and install the anti-spam package. The later 0x00000013 line narrows the problem to the SSL-protected Kerio Anti-spam initialization/cloud lookup stage, so changing unrelated antivirus-update settings or deleting local update files is unlikely to address the root cause.

Capture the Certificate Chain from the Affected Host

Run the TLS test from the affected Kerio Connect host, not from an administrator laptop or a different network. The affected host is the only place that uses the same resolver, routing path, firewall inspection, and trust store as Kerio Connect.

openssl s_client -connect nimbus.bitdefender.net:443 \
  -servername nimbus.bitdefender.net \
  -verify_return_error </dev/null 2>&1 | egrep 'depth=|subject=|issuer=|Verify return code'

A healthy result verifies successfully and ends with:

Verify return code: 0 (ok)

A failing result for this article commonly shows a chain that is not publicly trusted by the affected host, for example a chain involving Gateway CA - Cloudflare Managed G1, and ends with a verification failure such as:

Verify return code: 19 (self signed certificate in certificate chain)

Why this matters: Kerio Connect logs the compact SSL error value, but the openssl s_client output shows the actual certificate chain and the verification result. That tells you whether Kerio Connect is failing because the host is receiving a certificate chain it cannot trust.

Compare DNS Answers from the Affected Resolver and Public Resolvers

From the affected Kerio Connect host, record the DNS answer returned by the host's configured resolver:

getent ahosts nimbus.bitdefender.net

Then compare the result with public resolvers:

dig @1.1.1.1 nimbus.bitdefender.net +short
dig @8.8.8.8 nimbus.bitdefender.net +short

If dig is not available, use nslookup:

nslookup nimbus.bitdefender.net 1.1.1.1
nslookup nimbus.bitdefender.net 8.8.8.8

Compare the returned CNAMEs and IP addresses with the TLS result from the previous section. The important question is not whether every resolver returns the same IP forever; backend pools can change. The important question is whether the affected host is consistently routed to an endpoint whose certificate chain fails verification while another resolver reaches an endpoint whose certificate chain verifies successfully.

Why this matters: The validated root cause was DNS-based steering to a backend pool that presented an untrusted chain. Testing only from a different network can hide the problem because another resolver may reach a different backend pool that presents a trusted certificate chain.

Fix the DNS Resolver or Forwarding Path

  1. Identify the DNS resolver or forwarding device used by the affected Kerio Connect host. On Linux, start by checking the resolver configuration and the address returned by the default lookup tools available on the host.
  2. Review the resolver, DNS forwarder, firewall DNS proxy, or upstream DNS service configuration that is returning the failing answer for nimbus.bitdefender.net.
  3. Correct the DNS path so nimbus.bitdefender.net resolves to an endpoint that you have verified from the Kerio Connect host with openssl s_client and Verify return code: 0 (ok).
  4. Flush DNS caches on the resolver or forwarding device according to that product's procedure. Also flush or restart any local resolver cache on the Kerio Connect host if one is present.
  5. Run the DNS and TLS tests again from the affected Kerio Connect host.
  6. Restart Kerio Connect and confirm that Kerio Anti-spam initializes successfully.
  7. If you do not administer the DNS resolver or forwarding device, stop after collecting the DNS and TLS evidence and provide it to the person or team that manages that DNS layer. Changing Kerio Connect settings alone will not correct a DNS answer that continues to send the host to a certificate-failing backend.

Why this works: Kerio Anti-spam connects to nimbus.bitdefender.net over HTTPS. If DNS consistently sends the Kerio Connect host to a backend that presents a chain the host can validate, the TLS handshake can complete and the Kerio Anti-spam cloud lookup can initialize.

What would go wrong if you skipped this step: If you only restart Kerio Connect or change local Kerio configuration while the resolver still returns the failing backend, Kerio Connect will continue receiving the same untrusted certificate chain and the 0x00000013 initialization failure will return.

Use a Temporary Linux Hosts-File Override Only When Immediate Mitigation Is Required

Warning: Use a hosts-file override only as a temporary mitigation. Backend IP addresses and pool membership can change, so a hardcoded IP can become wrong later. The durable fix is to correct DNS or forwarding behavior.

  1. Choose a candidate IP only after proving that it presents a trusted certificate chain for nimbus.bitdefender.net. Replace <trusted_pool_ip> with the candidate IP:
TRUSTED_POOL_IP="<trusted_pool_ip>"
openssl s_client -connect ${TRUSTED_POOL_IP}:443 \
  -servername nimbus.bitdefender.net \
  -verify_return_error </dev/null 2>&1 | egrep 'depth=|subject=|issuer=|Verify return code'

Continue only if the output ends with:

Verify return code: 0 (ok)
  1. Back up the current hosts file:
sudo cp /etc/hosts /etc/hosts.bak.$(date +%Y%m%d%H%M%S)
  1. Edit /etc/hosts with your preferred editor:
sudo vi /etc/hosts
  1. Add one line that maps the verified IP to the hostname:
<trusted_pool_ip> nimbus.bitdefender.net
  1. Confirm that the host now resolves nimbus.bitdefender.net to the pinned IP:
getent ahosts nimbus.bitdefender.net
  1. Run the normal hostname-based TLS test again. It must return Verify return code: 0 (ok):
openssl s_client -connect nimbus.bitdefender.net:443 \
  -servername nimbus.bitdefender.net \
  -verify_return_error </dev/null 2>&1 | egrep 'depth=|subject=|issuer=|Verify return code'
  1. Restart Kerio Connect:
sudo systemctl restart kerio-connect.service
  1. After permanent DNS remediation is complete, remove the /etc/hosts line and repeat validation. Do not leave the override in place indefinitely.

Why this works: The hosts-file entry bypasses the failing DNS answer on the Kerio Connect host and forces the hostname to a verified endpoint. This restores service quickly while the real DNS issue is being corrected.

What would go wrong if you used an unverified IP: Kerio Connect might still receive an untrusted certificate chain, or it might connect to an endpoint that is not currently intended to serve nimbus.bitdefender.net. Always verify the selected IP with SNI by using -servername nimbus.bitdefender.net before pinning it.

Do Not Use ValidateUpdateServer as the Primary Fix for This Symptom

The ValidateUpdateServer setting is associated with Kerio Antivirus update-server certificate validation. It is relevant when logs show Kerio Antivirus update failures such as AntivirusModule.cpp SSL certificate errors. For that different symptom, see Antivirus Plugin Is Failing to Update with SSL Certificate Errors.

This article covers a later Kerio Anti-spam initialization failure after the anti-spam update package has already installed. In the validated failure pattern, ValidateUpdateServer was already set to 0 and the 0x00000013 Kerio Anti-spam initialization error still occurred. That is why the correct path is to verify the affected host's TLS chain and DNS routing instead of assuming the antivirus-update workaround applies.

Validation

The issue is resolved when all of the following checks pass from the affected Kerio Connect host:

  • The TLS test to nimbus.bitdefender.net:443 ends with Verify return code: 0 (ok).
  • The Debug log no longer repeats Kerio Anti-spam failed to use SSL connection with SSL error 0x00000013. Initialization failed.
  • The Debug log shows successful Kerio Anti-spam initialization:
{kerioantispam} Kerio Anti-spam initialized.

Keep the Kerio Anti-spam Processing Debug log enabled only long enough to confirm the result. After validation, disable extra Debug log message types so troubleshooting logging does not add unnecessary load or noise.

When to Contact Support

Contact Support if the affected host still shows 0x00000013 after DNS correction, or if you cannot determine why the affected resolver is returning a certificate-failing backend. Include the following information so Support can compare the DNS, TLS, and Kerio log evidence from the same time window:

  • The Kerio Connect version and build number.
  • The operating system and version of the affected Kerio Connect host.
  • The full openssl s_client output from the affected host.
  • The output of getent ahosts nimbus.bitdefender.net from the affected host.
  • The output of dig or nslookup against at least two public resolvers, such as 1.1.1.1 and 8.8.8.8.
  • A Debug log excerpt from the same time window with Kerio Anti-spam Processing enabled.
  • Whether a proxy, firewall TLS inspection feature, DNS forwarder, or local hosts-file override is in use.
  • The timestamp and time zone for each capture.

Frequently Asked Questions

Why can one server see a trusted certificate while another sees a failing chain for the same hostname?

DNS and routing can steer different clients to different backend pools for the same hostname. That is why the TLS test must be run from the affected Kerio Connect host and compared with the DNS answer that host is actually using.

Can I permanently pin nimbus.bitdefender.net in /etc/hosts?

No. Treat the hosts-file entry as temporary. Backend IPs can change, and a hardcoded IP can become stale. Correct the resolver or forwarder, validate Kerio Anti-spam initialization, and then remove the hosts-file override.

Does this procedure require a Kerio Connect patch?

The validated 0x00000013 case was resolved by DNS/routing remediation and did not require a Kerio Connect patch. If your host still fails after it receives a publicly trusted chain, collect the evidence listed in When to Contact Support.

What if my error is 0xc0000010 instead of 0x00000013?

0xc0000010 (BDANTISPAM_ERROR_CLOUD_NO_RESPONSE) is a different Kerio Anti-spam initialization symptom. Start by testing network reachability from the affected host to the Bitdefender cloud endpoint and update endpoints instead of following this certificate-chain-specific procedure:

curl -v --connect-timeout 10 https://nimbus.bitdefender.net/
curl -v --connect-timeout 10 http://bda-update.kerio.com/
Choose files or drag and drop files
ai_initiated
atlas_studio
kb_automation
Was this article helpful?
Yes
No

  1. Ciprian Nastase

  2. Posted

Comments