Troubleshooting Qualys Cloud Agent Connectivity Issues v 1.

0
The purpose of this document is to provide Qualys Cloud Agent users the ability to troubleshoot and effectively
eliminate common Cloud Agent connectivity issues. Leverage this resource with internal teams, and should these
methods not be effective, do engage Qualys Support by navigating to the Customer Support Portal (Help > Contact
Support in Qualys Cloud Applications)

Each customer is a part of a Qualys Shared Cloud Platform, and the Cloud Agents will connect to the Cloud Agent
Public Server corresponding with the subscription their Qualys Platform is located in. The list of different Platform
URLs is shared below.

Qualys Shared Platform URL’s

US Platform 1: https://qagpublic.qg1.apps.qualys.com
US Platform 2: https://qagpublic.qg2.apps.qualys.com
US Platform 3: https://qagpublic.qg3.apps.qualys.com
EU Platform 1: https://qagpublic.qg1.apps.qualys.eu
EU Platform 2: https://qagpublic.qg2.apps.qualys.eu
IN Platform 1: https://qagpublic.qg1.apps.qualys.in
CA Platform 1: https://qagpublic.qg1.apps.qualys.ca
AE Platform 1: https://qagpublic.qg1.apps.qualys.ae

Outbound connection to these URL’s respective to your platform is required over TCP 443.

*Note: Have Anti-Virus, EDR, or HIPS software installed? Our Cloud Agent User Guides (Help > Resources) discuss
which files, directories, and processes to exclude or whitelist in all security software installed on the system in
order to prevent conflicts with the Cloud Agent.

Qualys Cloud Agent Log File Locations:

Windows: C:\ProgramData\Qualys\QualysAgent
Windows XP/2003: C:\Documents and Settings\All Users\Application Data\Qualys\QualysAgent
Linux: /var/log/qualys/qualys-cloud-agent.log
Unix: /var/opt/qualys/qualys-cloud-agent.log
MacOS: /var/log/qualys/qualys-cloud-agent.log

*Note: Please inspect the log files in the above locations for troubleshooting purposes. It is recommended to
navigate to the very last entries logged to get current health/status of the cloud agent. Only 20MB of the most
recent cloud agent activity is retained. The most current log file on record contains 10MB of the most up to
date data, once 10MB is reached, an archive log is created. Throughout the cloud agent’s lifecycle, these logs will
be overwritten. Archive logs are located in the same directories listed above and are useful for inspecting historical
errors. There can be up to ten archive logs (1 MB each) for Windows Cloud Agents and five archive logs (2 MB
each) for Linux/Unix/Mac agents.

Cloud Agent Health Dashboard Links:

These links provide helpful dashboard and reporting mechanisms which can assist you and your team to monitor
Qualys Cloud Agent activity and health.

https://discussions.qualys.com/docs/DOC-6440-dashboarding-and-reporting
Most Common Windows Agent Communication Errors Reported
Detailed below are the most common communication errors logged by Windows Cloud Agents followed by a brief
description of why the error is reported. Additionally, a Microsoft link has been provided in case
other WinHTTP errors are reported that are not listed on this page.

*Note: These errors logged by the cloud agent are parsed from Microsoft. These are not Qualys errors.

Microsoft Link: https://support.microsoft.com/en-us/help/193625/info-wininet-error-codes-12001-through-

12156

12002 (Warning) - ERROR_WINHTTP_TIMEOUT

This error indicates that the agent has resolved the DNS name of the cloud endpoint but cannot establish a
connection to that endpoint. One reason for this is intermittent or faulty connectivity between the client and the
cloud. Also, slow or congested networks and some firewall rules may also intermittently cause this error

12007 (Warning) - ERROR_WINHTTP_NAME_NOT_RESOLVED

This error indicates that the agent cannot resolve the FQDN of the cloud endpoint. This often indicates a network
route issue between the client and the cloud which can be attributed to no network interfaces available on the
client, no connectivity to DNS servers, or a misconfigured cloud endpoint FQDN.
This WinHTTP error causes the agent to connect to the cloud endpoint using a fallback (or backup) URI that has
been previously determined and stamped into the cloud agent. This is typically the same URI that the Agent used
when it was first installed on the client.

12029 (Warning) - ERROR_WINHTTP_CANNOT_CONNECT

This error indicates that the agent has resolved the DNS name of the cloud endpoint but cannot establish a
connection to that endpoint. One reason for this is that cloud endpoint URI may be incorrect or there is no
network route currently available between the client and the cloud.
This WinHTTP error causes the agent to connect to the cloud endpoint using a fallback (or backup) URI that has
been previously determined and stamped into the cloud agent. This is typically the same URI that the Agent used
when it was first installed on the client.

12030 (Warning) - ERROR_WINHTTP_CONNECTION_ERROR

This error indicates that the agent has resolved the DNS name of the cloud endpoint but cannot establish a
connection to that endpoint. Possible reasons for this error include firewall configurations that actively block or
disallow connections from the client to the cloud. Also, route issues that prevent TCP/IP connections from getting
created between client and cloud will also generate this error.
This WinHTTP error causes the agent to connect to the cloud endpoint using a fallback (or backup) URI that has
been previously determined and stamped into the cloud agent. This is typically the same URI that the Agent used
when it was first installed on the client.

12175 (ERROR_WINHTTP_SECURE_FAILURE)
This error is logged for the following reasons:
Error: WinHttp Security Failure: The function is unfamiliar with the Certificate Authority that generated the server's
certificate.
Error: Failed to send request to web service: (win32 code: 12175), "(winhttp code: 12175), One or more errors
were found in the Secure Sockets Layer (SSL) certificate sent by the server.".
How-to Troubleshoot common Windows Agent disconnection issues:
For these error codes listed below, the most common reason why these are reported by the cloud agent is due to
a brief or prolonged network disconnection to our platform:

winhttp code: 12002

winhttp code: 12007
winhttp code: 12029
winhttp code: 12030

Windows Log Examples:

Error: Failed to send request to web service: (win32 code: 12002), "(winhttp code: 12002)
Error: Failure while attempting to retrieve server response for a web request. Error: 12002
Error: Unable to communicate with the server. (win32 code: 12002), "(winhttp code: 12002)

Error: Failed to send request to web service: (win32 code: 12007), "(winhttp code: 12007)
Error: Failure while attempting to retrieve server response for a web request. Error: 12007
Error: Unable to communicate with the server. (win32 code: 12007), "(winhttp code: 12007)

Error: Failed to send request to web service: (win32 code: 12029), "(winhttp code: 12029)
Error: Failure while attempting to retrieve server response for a web request. Error: 12029
Error: Unable to communicate with the server. (win32 code: 12029), "(winhttp code: 12029)

Error: Failed to send request to web service: (win32 code: 12030), "(winhttp code: 12030)
Error: Failure while attempting to retrieve server response for a web request. Error: 12030
Error: Unable to communicate with the server. (win32 code: 12030), "(winhttp code: 12030)

If you do not utilize a proxy and the agent is to communicate to our platform directly via the internet
(WinHTTP error code: 12180), you can try the following the steps below to validate successful communication to
our platform from the impacted agent host:

1). Open a browser and navigate to your respective platform URL. As depicted by the attached screen shot for US
Platform 1 as an example, the arrows/boxes indicate that the connection is successful and secure. A 404 response
in this case is expected as the URL resolves to the platform LB.

2). Execute curl –v <platform URL>

Example for US Platform 1 (call and output):

curl –v https://qagpublic.qg1.apps.qualys.com
102306MBP15:~ rsweeney$ curl -v https://qagpublic.qg1.apps.qualys.com
* Rebuilt URL to: https://qagpublic.qg1.apps.qualys.com/
* Trying 64.39.104.93...
* TCP_NODELAY set
* Connected to qagpublic.qg1.apps.qualys.com (64.39.104.93) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
* CAfile: /etc/ssl/cert.pem
CApath: none
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
* ALPN, server accepted to use http/1.1
* Server certificate:
* subject: C=US; ST=California; L=Foster City; O=Qualys, Inc.; OU=Production;
CN=qagpublic.qg1.apps.qualys.com
* start date: Aug 1 00:00:00 2019 GMT
* expire date: Aug 1 12:00:00 2020 GMT
* subjectAltName: host "qagpublic.qg1.apps.qualys.com" matched cert's
"qagpublic.qg1.apps.qualys.com"
* issuer: C=US; O=DigiCert Inc; CN=DigiCert SHA2 Secure Server CA
* SSL certificate verify ok.
> GET / HTTP/1.1
> Host: qagpublic.qg1.apps.qualys.com
> User-Agent: curl/7.54.0
> Accept: */*
>
< HTTP/1.1 404 Not Found
< Date: Sat, 21 Mar 2020 16:08:30 GMT
< Content-Type: application/json
< X-Frame-Options: sameorigin
< X-XSS-Protection: 1; mode=block
< X-Content-Type-Options: nosniff
< Content-Length: 43
<
* Connection #0 to host qagpublic.qg1.apps.qualys.com left intact
{"code":404,"message":"HTTP 404 Not Found"}102306MBP15:~ rsweeney$

*Note: The highlighted 404 response is expected.

If a 404 response is not received, please check network connectivity/speed, firewalls, and any anti-virus / HIPS
software for any activity that could disrupt the agent service connection to the platform.

Once the connection is validated to be successful, if the agent is reporting a backoff multiplier, which is the
amount of time (in seconds) the agent must wait for connection retry, please stop and restart the cloud agent
service as this will refresh the multiplier and retry connection.

From a command window (run as admin), the following commands can be executed to stop and restart the Qualys
cloud agent service on Windows OS:

sc stop qualysagent
sc start qualysagent
12002
TLS 1.1+ to 1.0 inadvertently.)
How-to Troubleshoot WinHTTP 12175
This error code is received primarily for the following three reasons:

1). Not all of the certificates required for successful agent communication are installed within the Trusted CA
under the local computer account.
2). The necessary support for TLSv1.2 communication is missing on the host system. The Qualys cloud agent
currently requires TLSv1.2 support for communication.
3). Unsupported cipher suites are enabled on the impacted host system.

CERTIFICATES

The following is a screen shot which displays the three required certificates for successful agent communication on
US Platform 1 (derived from “Qualys Shared Platform URL’s” listed above) as example:

1). DigiCert Global Root CA (Root)

2). DigiCert SHA2 Secure Server CA (Intermediate)
3). Lease Certificate (Intermediate); *Note: this certificate is platform specific

The article links below assists with identifying if the proper certificates installed and if any of the certificates are
missing, please download the missing certificates and import into the Trusted CA under the local computer
account. The folder in which to import these are highlighted in the bold parenthesis above.

URL: https://qualys-secure.force.com/customer/s/article/000002857

Once the certificates are found to be installed, please stop and restart the agent service to reset the connection.

TLS Support

Qualys Agent connectivity using TLS 1.0 was deprecated in 2018. The Qualys Cloud Agent now requires TLS version
1.2 for communication. The following link discusses TLS 1.0 deprecation and the impacted legacy systems.

URL: https://qualys-secure.force.com/customers/articles/Knowledge/000002843

Any legacy software that does not support TLSv1.1+ will require updating prior to this change. If TLSv1.1+ is not
supported and the application is not updated, the application may cease to function on the date mentioned in the
table above. Please work with the appropriate vendor to confirm if TLSv1.1+ is natively supported or if a system
update is required prior to the change-over date.
For Cloud Agent deployments:

Cloud Agent Windows utilizes cryptographic protocol support provided by the Windows operating system. Older
Windows operating system (including Windows XP, Embedded Standard, Server 2003/SP2, Server 2008/SP1/SP2,
Vista and potentially others if explicitly configured) do not have TLS 1.1+ support on the operating system for
Cloud Agent to utilize.

(Cloud Agent on Windows 7, 8/8.1, 10, Server 2008 R2, 2012, 2016 and Linux, Mac, and AIX operating systems
support TLS 1.1+ and are not impacted, though network proxies may be stepping-down
Customers can utilize forward proxy servers to “step-up” the version of TLS from 1.0 to 1.1+ to continue running
Cloud Agent Windows on older Microsoft operating systems that only have support for TLS 1.0.

For those cases where a proxy server cannot be utilized, customers can use the Qualys network scanner to assess
the affected system until the conversions have been implemented.

Below is a Microsoft KB which assists with installing the proper KB’s and registry keys / values to enable TLS 1.2
support on the host system:

Microsoft Link: https://support.microsoft.com/en-in/help/4019276/update-to-add-support-for-tls-1-1-and-tls-1-2-

in-windows

*Note: Once the KB’s and registry keys/values have been added, the host system will require a reboot for the
changes to take effect.

CIPHER SUITE SUPPORT

Many legacy systems do not come equipped with the following cipher suites that are currently supported by the
Qualys Cloud Agent service.

Below is a screen shot of the current ciphers that are currently supported by an example platform. Leverage
“Qualys Shared Platform URL’s” list using the ssllabs tool to ensure your machine is able to communicate using the
platform available cipher suites.

URL: https://ssllabs.com
# TLS 1.2 (suites in server-preferred order)

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f) ECDH secp256r1 (eq. 3072 bits RSA)

FS 128 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030) ECDH secp256r1 (eq. 3072 bits
RSA) FS 256 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027) ECDH secp256r1 (eq. 3072 bits
RSA) FS WEAK 128 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028) ECDH secp256r1 (eq. 3072 bits
RSA) FS WEAK 256 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013) ECDH secp256r1 (eq. 3072 bits
RSA) FS WEAK 128 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014) ECDH secp256r1 (eq. 3072 bits
RSA) FS WEAK 256 TLS_RSA_WITH_AES_128_GCM_SHA256
(0x9c) WEAK 128

Please check the following location for current cipher suites enabled on the Windows system:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers

*Note: A system reboot is required for new ciphers enabled to take effect.

QGS and WinHTTP 12175

If customers utilize the Qualys Gateway Service (QGS) for agent communication, WinHTTP 12175 can be logged for
the following reasons:

1). QGS is enabled for Cache mode over port 8080 but the QGS certificates have not been installed on each of the
agent host systems impacted.
2). QGS proxy was set up as an https proxy rather than as a http proxy.

QGS User Guide: https://www.qualys.com/docs/qualys-gateway-service-user-guide.pdf

Windows Install Guide: https://www.qualys.com/docs/qualys-cloud-agent-windows-install-guide.pdf

• Cache Mode requires the certificate of each appliance to be installed on each host with Cloud
Agent that is to connect through that specific appliance.
• The QGS UI provides the gateway appliance’s certificate (.pem) for download, plus an optional
MSI installer to install on Windows hosts.

How-to Troubleshoot common Linux Agent

disconnection issues:

Common Errors

The below error logged by a Linux / Unix / MAC OS agent is equivalent to a Windows cloud agent reporting errors
12002, 12007, 12029, and 12030.

[Error]:Http request failed: Couldn't resolve host name: Couldn't resolve host 'qagpublic.qg1.apps.qualys.com'
[Warning]:Failed to connect to CloudAgent server - retry attempt: 1

Please follow same troubleshooting steps provided above to validate successful connection on the impacted agent
host. Once connection is deemed to be successful, please stop and restart the agent service.

Terminal Commands:

sudo systemctl stop qualys-cloud-agent

sudo systemctl start qualys-cloud-agent

For Known Certificate Issues on Linux / Unix, please

view the following user guides for further details:
Linux: https://www.qualys.com/docs/qualys-cloud-agent-linux-install-guide.pdf (start on page 23)
Unix: https://www.qualys.com/docs/qualys-cloud-agent-unix-install-guide.pdf (start on page 20)

EXAMPLE for OS RHEL 5.5:

[Error]:Http request failed:SSL peer certificate or SSH remote key was not OK: SSL certificate problem: unable to
get local issuer certificate
How To Troubleshoot Certificate issues:
openssl s_client -connect qagpublic.qg1.apps.qualys.com:443

For example, the Cloud agent installed on RHEL 5.4 and 5.5 may throw these errors while trying to communicate
with the Qualys Platform. This happens when the certificate files are not present on the host asset.

To fix this issue, you must either manually create the certificate files, and place them in the appropriate location on
the host asset OR copy from a working system and download onto the impacted host system.

Create The Certificates

Create the two cert files: cert1.crt and cert2.crt. Paste the contents in a text editor, and then save the file with the
extension “.crt”. For ease, the new DigiCert certificates are below (Note: These will change over time and the
“Qualys Shared Platform URL’s list will be able to show new certificates when accessed via browser)“:

Cert1

subject= /C=US/O=DigiCert Inc/CN=DigiCert SHA2 Secure Server CA

issuer= /C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Global Root CA

-----BEGIN CERTIFICATE-----
MIIElDCCA3ygAwIBAgIQAf2j627KdciIQ4tyS8+8kTANBgkqhkiG9w0BAQsFADBh
MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3
d3cuZGlnaWNlcnQuY29tMSAwHgYDVQQDExdEaWdpQ2VydCBHbG9iYWwgUm9vdCBD
QTAeFw0xMzAzMDgxMjAwMDBaFw0yMzAzMDgxMjAwMDBaME0xCzAJBgNVBAYTAlVT
MRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxJzAlBgNVBAMTHkRpZ2lDZXJ0IFNIQTIg
U2VjdXJlIFNlcnZlciBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB
ANyuWJBNwcQwFZA1W248ghX1LFy949v/cUP6ZCWA1O4Yok3wZtAKc24RmDYXZK83
nf36QYSvx6+M/hpzTc8zl5CilodTgyu5pnVILR1WN3vaMTIa16yrBvSqXUu3R0bd
KpPDkC55gIDvEwRqFDu1m5K+wgdlTvza/P96rtxcflUxDOg5B6TXvi/TC2rSsd9f
/ld0Uzs1gN2ujkSYs58O09rg1/RrKatEp0tYhG2SS4HD2nOLEpdIkARFdRrdNzGX
kujNVA075ME/OV4uuPNcfhCOhkEAjUVmR7ChZc6gqikJTvOX6+guqw9ypzAO+sf0
/RR3w6RbKFfCs/mC/bdFWJsCAwEAAaOCAVowggFWMBIGA1UdEwEB/wQIMAYBAf8C
AQAwDgYDVR0PAQH/BAQDAgGGMDQGCCsGAQUFBwEBBCgwJjAkBggrBgEFBQcwAYYY
aHR0cDovL29jc3AuZGlnaWNlcnQuY29tMHsGA1UdHwR0MHIwN6A1oDOGMWh0dHA6
Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEdsb2JhbFJvb3RDQS5jcmwwN6A1
oDOGMWh0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEdsb2JhbFJvb3RD
QS5jcmwwPQYDVR0gBDYwNDAyBgRVHSAAMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8v
d3d3LmRpZ2ljZXJ0LmNvbS9DUFMwHQYDVR0OBBYEFA+AYRyCMWHVLyjnjUY4tCzh
xtniMB8GA1UdIwQYMBaAFAPeUDVW0Uy7ZvCj4hsbw5eyPdFVMA0GCSqGSIb3DQEB
CwUAA4IBAQAjPt9L0jFCpbZ+QlwaRMxp0Wi0XUvgBCFsS+JtzLHgl4+mUwnNqipl
5TlPHoOlblyYoiQm5vuh7ZPHLgLGTUq/sELfeNqzqPlt/yGFUzZgTHbO7Djc1lGA
8MXW5dRNJ2Srm8c+cftIl7gzbckTB+6WohsYFfZcTEDts8Ls/3HB40f/1LkAtDdC
2iDJ6m6K7hQGrn2iWZiIqBtvLfTyyRRfJs8sjX7tN8Cp1Tm5gr8ZDOo0rwAhaPit
c+LJMto4JQtV05od8GiG7S5BNO98pVAdvzr508EIDObtHopYJeS4d60tbvVS3bR0
j6tJLp07kzQoH3jOlOrHvdPJbRzeXDLz
-----END CERTIFICATE-----
Cert2

subject= /C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Global Root CA

issuer= /C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Global Root CA

-----BEGIN CERTIFICATE-----
MIIDrzCCApegAwIBAgIQCDvgVpBCRrGhdWrJWZHHSjANBgkqhkiG9w0BAQUFADBh
MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3
d3cuZGlnaWNlcnQuY29tMSAwHgYDVQQDExdEaWdpQ2VydCBHbG9iYWwgUm9vdCBD
QTAeFw0wNjExMTAwMDAwMDBaFw0zMTExMTAwMDAwMDBaMGExCzAJBgNVBAYTAlVT
MRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5j
b20xIDAeBgNVBAMTF0RpZ2lDZXJ0IEdsb2JhbCBSb290IENBMIIBIjANBgkqhkiG
9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4jvhEXLeqKTTo1eqUKKPC3eQyaKl7hLOllsB
CSDMAZOnTjC3U/dDxGkAV53ijSLdhwZAAIEJzs4bg7/fzTtxRuLWZscFs3YnFo97
nh6Vfe63SKMI2tavegw5BmV/Sl0fvBf4q77uKNd0f3p4mVmFaG5cIzJLv07A6Fpt
43C/dxC//AH2hdmoRBBYMql1GNXRor5H4idq9Joz+EkIYIvUX7Q6hL+hqkpMfT7P
T19sdl6gSzeRntwi5m3OFBqOasv+zbMUZBfHWymeMr/y7vrTC0LUq7dBMtoM1O/4
gdW7jVg/tRvoSSiicNoxBN33shbyTApOB6jtSj1etX+jkMOvJwIDAQABo2MwYTAO
BgNVHQ8BAf8EBAMCAYYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUA95QNVbR
TLtm8KPiGxvDl7I90VUwHwYDVR0jBBgwFoAUA95QNVbRTLtm8KPiGxvDl7I90VUw
DQYJKoZIhvcNAQEFBQADggEBAMucN6pIExIK+t1EnE9SsPTfrgT1eXkIoyQY/Esr
hMAtudXH/vTBH1jLuG2cenTnmCmrEbXjcKChzUyImZOMkXDiqw8cvpOp/2PV5Adg
06O/nVsJ8dWO41P0jmP6P6fbtGbfYmbW0W5BjfIttep3Sp+dWOIrWcBAI+0tKIJF
PnlUkiaY4IBIqDfv8NZ5YBberOgOzW6sRBc4L0na4UU+Krk2U886UAb3LujEV0ls
YSEY1QSteDwsOoBrp+uvFRTp2InBuThs4pFsiv9kuXclVzDAGySj4dzp30d8tbQk
CAUw7C29C79Fv1C5qfPrmAESrciIxpg0X40KPMbp1ZWVbd4=
-----END CERTIFICATE-----

Use the following commands to append the contents of cer1.crt and cert2.crt at the end of /etc/pki/tls/certs/ca-
bundle.crt

cat cert1.crt >> /etc/pki/tls/certs/ca-bundle.crt

cat cert2.crt >> /etc/pki/tls/certs/ca-bundle.crt

Once the certificates are added, you will need to update the agent config to point the agent to the correct
certificate path based on system OS. Please see the following screen shot:
For RHEL systems, you can update the CentOS cafile path. Since the certificates were added to
/etc/pki/tls/certs/ca-bundle.crt, you point the cafile to this location.

If you want to use a non-default location, ensure that the directory path is added in the /etc/qualys/cloud-
agent/qagent.config file in the following manner:

{
"os": "CentOS",
"cafile": "<CustomizedPath>"
}

Restart the Cloud Agent Service for changes to take effect

SSL Handshake issue showing the following error:
You will see the following on the host, and please look below at the log error the correlates to
this behavior. When we see this, it is NOT a cert issue, please see the description below

2022-02-09 02:58:25.649 [qualys-cloud-agent][***]:[Information]:[************]Finished curl

request
2022-02-09 02:58:25.649 [qualys-cloud-agent][***]:[Error]:[**********]:Http request
failed:SSL connect error: OpenSSL SSL_connect: Connection reset by peer in connection to
qagpublic.qg1.apps.qualys.com:443

This is not a cert-based authentication issue. If the open SSL output showed the response, and
THEN we saw this error, then we would say there is a trust and cert issue. However, because
there is not cert presented, and because it's a reset, this is something on the internal network
side. To clarify, we do not perform certificate-based authentication to the platform. There is
nothing for the agent to present to the platform, the agent is only asking for the cert to be
presented. If it was trust issue, we would see that error due to the issuer being incorrect or not
provided.

In that screen shot, something on the client side network is stripping the cert out of the path.
This is on the remote side, and the fact that we do not see the Cert in the open SSL response,
validates the summary here.

So, this means that their network is either trying to block it, trying to examine it, or it needs to
go through the proxy, and we are not configured to send through the proxy with SSL.
Next Steps:

The customer will need to work with their network team and determine if this host needs to go
through a proxy or determine why their network is interfering with traffic on 443 and replicate
the network settings of the agents that are in fact working and connecting.

Open SSL test on the device.

The cert comes down as part of the handshake, and the handshake is not happening when we
see this error
The user that launches the open SSL needs to be able to see the certs and cert paths.

If it was a trust issue: We need to always verify the following

data first prior to case creation

When we see the following error as well, it confirms what we are seeing here on their network
side. The following error below is not relevant to the investigation, so to clarify, it's not an issue
of the certs being there or not.

2022-02-09 ******* [qualys-cloud-agent][*****Error]:[*******]:Http request failed:Problem

with the SSL CA cert (path? access rights?): error setting certificate verify locations: CAfile:
/etc/pki/tls/certs/ca-bundle.crt CApath: none
Other Common Connection Errors reported by our Cloud
Agent service:
HTTP 403 - Access Forbidden
This is typically logged when access to the platform via proxy is forbidden. Customer will need to engage network
and/or proxy teams to troubleshoot.

Linux/Mac Agent:
[Information]:Finished curl request
[Error]:Http request failed:HTTP response code said error: The requested URL returned error: 403 Forbidden
[Error]:Http request failed: error code: 403

Windows Agent:
Information: Http status code received: 403
Information: No more bytes available from server. 2080 bytes received.
Information: Web service call returned: 403

HTTP 404 - Page Not Found / Server Not Found

Indicates that the browser was able to communicate with a given server, but the server could not find what was
requested.

Linux/Mac Agent: [Error]:Http request failed: error code: 404

Windows Agent:
Information: Http status code received: 404
Information: No more bytes available from server. x bytes received.
Error: Web service call failed with error: 404

Troubleshooting Links:

Discussion: https://discussions.qualys.com/message/47147-re-error-404-with-cloud-
agent?commentID=47147#comment-47147
Qualys URL: https://qualys-secure.force.com/customers/articles/Knowledge/000003232

HTTP 503 – Service Unavailable

Please contact Qualys Technical support and inform them that the service is unavailable. This error will prevent
cloud agents from communicating to the platform.

Linux/Mac Agent:
[Information]:Finished curl request
[Error]:Http request failed: HTTP response code said error: The requested URL returned error: 503
Service Unavailable
[Debug]:Retry fail-over URI: skipped
[Error]:Http request failed: error code: 503

Windows Agent:
Information: Http status code received: 503
Information: No more bytes available from server. x bytes received.
Error: Web service call failed with error: 503