Unable to contact Azure DevOps server - Hostname not verified

[a930wamu (Wasim)]

Hi everyone!
I have installed SonarQube Developer edition version 10.1.0.73491 on one of our UAT servers (Windows Server 2019). I am able to successfully install and browse it through chrome. We need to integrate SonarQube with AzureDevops on-premise server. I am getting “Unable to contact Azure DevOps server - Hostname not verified” error while trying to configure AzureDevops in SonarQube. The SSL configured for AzureDevops self singed which is signed by our compay’s own CA. Could anyone please guide how to resolve this issue?

[ganncamp (G Ann Campbell)]

Hi,

Welcome to the community!

You may be interested in these:

Azure DevOps analysis allow self-signed certificate connection

Using a Microsoft Azure DevOps Hosted Agent and a self-signed certificate is… pretty brave. Using self-signed certificates for internet-facing services is typically a bad idea If using self-signed certificates is a requirement, it might be better for you to manage your own build agent where you have full control over things like installing certificates that the system recognizes

SonarQube not Connecting to a self-signed certificate GitLab server

Hey there. You should be able to check the web.log of your instance for an error message (it may help to turn the logging in global Administration > System > Log Level up to DEBUG) and trying to validate your configuration once more. If you see an error like PKIX path building failed – it is definitely the result of using a self-signed certificate. Often, when a self-signed certificate is used, the truststore that Java uses (which runs your SonarQube instance) can’t trust that certificate. Adj…

Self signed certificate SonarScanner

The issue may not be in fact that the Java does not trust the certificate (with respect to who signed it), but that the certificate installed on as-git-pcrepo.pc.net does not pass a specific check that an underlying library uses which verifies the certificate. As a part of the upgrade of this library (okhttp), at some point it became no longer possible to verify a certificate with the hostname only declared in the CN. Hostnames now need to be defined as a SubjectAlternativeName in a certificat…

 
HTH,
Ann

[a930wamu (Wasim)]

Bundle of thanks. Using the certificate containing SubjectAlternativeName resolved my issue.