SonarQube SSL certificate expired

PKIX path building failed in the scanner or a browser warning on https://sonar.example.com means the SonarQube listener certificate is past notAfter, blocking quality gates—not your coverage numbers.

Engineering leads searching sonarqube ssl certificate expired see pipeline steps fail at sonar-scanner or Gradle Sonar plugins when the server HTTPS identity expired. SonarQube runs on JVM HTTP connectors; many teams terminate TLS on nginx, Traefik, or ALB while others bind certs directly in sonar.properties.

Because scanners run unattended in CI, expiry surfaces as sudden mass job failure without a human opening the UI. Treat Sonar webhook callbacks and OIDC login endpoints as additional hostnames on the same or different certificates.

Plugins pulled from the SonarQube marketplace during analysis still rely on healthy HTTPS to your server base URL for API callbacks—do not assume only the scanner binary talks TLS. New-code definitions and branch parameters do not change which certificate terminates sonar.host.url; keep that hostname at the center of renewal tickets.

Large monorepos may fan out dozens of parallel scanner jobs—one expired leaf fails the entire quality gate matrix, which looks like “Sonar is down” in aggregate dashboards even though the JVM process is running. Distinguish transport failures from analysis rule failures by checking whether the scanner log shows SSL exceptions before it prints rule violation counts.

Quality gate failures block merges organization-wide—treat TLS renewal as a release incident with explicit scanner re-run criteria before merge unfreezes. Unfreeze merges only after a green scanner log is attached to the ticket.

Delegating admin URLs to internal DNS while CI uses external names is a recurring foot-gun—keep a single canonical list of scanner-facing hostnames in the certificate inventory.

Policy-as-code gates that query Sonar APIs inherit the same TLS failures as scanners—verify those automation accounts too before closing. Capture scanner CLI version and JVM vendor in tickets—PKIX error wording varies slightly.

First response

Capture CI logs showing SSL exceptions, the sonar.host.url value, and whether scanners use self-signed trust flags. Test TLS from a runner subnet, not only from an admin laptop on VPN.

Archive openssl s_client output for the URL in SONAR_HOST_URL. Check reverse-proxy cert separately from Sonar’s embedded connector if both exist in your architecture.

Compare with Jenkins HTTPS certificate expired when pipelines fail at multiple DevOps tools the same night.

Export SonarQube sonar.application.home path from systemd or container env so responders know where embedded trust stores live. If SAML or LDAP admin login still works while scanners fail, you have strong evidence the breakage is inbound TLS on the scanner URL—not directory services.

What this error means

Browsers and JVM-based scanners validate server certificate dates during TLS. Expired material aborts before SonarQube token authentication. Webhooks to GitHub or GitLab also fail TLS client validation if your Sonar outbound trust store references expired intra-cluster certs—a distinct issue from inbound expiry but similar logs.

SonarQube Community vs Data Center does not change inbound PKIX rules. Kubernetes Helm charts may mount TLS secrets into nginx sidecars; stale mounts survive chart upgrades without pod restart.

Portfolio management plugins and governance reports pull historical data over the same HTTPS session cookies admins use—expiry blocks executives before it blocks scanners if they open dashboards during incidents.

Common causes

Ingress cert renewed via cert-manager while an internal sonar.corp DNS name still points to an old VM certificate. sonar.web.javaAdditionalOpts or proxy headers misconfigured after cert swap, masking the real error until strict clients fail.

Wildcard cert on *.tools.example.com expired; Sonar moved to a dedicated hostname still covered by the old wildcard in documentation but not in SAN. Database and Elasticsearch sidecars are healthy while only HTTPS fronting expired—on-call misattributes to “Sonar outage” generically.

SonarQube Data Center Edition adds multiple application nodes behind a load balancer; each ingress attachment must present the same renewed chain or sticky scanners fail unpredictably. Developer Edition Docker images bind TLS inside the container unless you front with a proxy—document which model your SONARQUBE_IMAGE uses in runbooks. Azure DevOps and GitLab CI include Sonar tasks that cache plugin downloads from the same HTTPS host—expiry blocks quality gates before compile errors surface.

Confirm from the outside

Match the URL in failing CI logs character for character, including trailing slashes and path prefixes some scanners append. Test from the same outbound NAT as GitHub-hosted runners if applicable. If admin UI works while scanners fail, compare hostnames—split-horizon DNS often causes that pattern.

openssl s_client -connect sonar.example.com:443 -servername sonar.example.com </dev/null 2>/dev/null | openssl x509 -noout -dates -subject -issuer

Scanner reproduction:

sonar-scanner -Dsonar.host.url=https://sonar.example.com -Dsonar.login=token -X 2>&1 | grep -iE 'ssl|certificate|PKIX'

API probe:

curl -fsS -o /dev/null -w '%{http_code}\n' https://sonar.example.com/api/system/status

If TLS terminates on nginx in front:

curl -vI https://sonar.example.com 2>&1 | grep -Ei 'expire|SSL certificate'

Bitbucket Server and GitHub Enterprise webhooks retry TLS deliveries—check their admin UI delivery logs for SSL failures correlated with your Sonar cert dates. IDE plugins hitting SonarLint connected mode may use different hostnames than CI; openssl each variant.

How to read the output

Focus on notAfter first. Ensure SAN covers sonar.host.url hostname. Issuer rotation after moving from DigiCert to Let’s Encrypt requires updating any pinned corporate trust bundles used by scanners.

Fix checklist

1. Confirm which hop terminates TLS (ingress vs embedded connector).
2. OpenSSL each public hostname scanners use.
3. Renew and install full chain on that hop.
4. Restart SonarQube pods or systemd service after keystore changes.
5. Re-run scanner from a representative CI agent.
6. Validate GitHub/GitLab webhook deliveries post-fix.
7. Remove temporary sonar.scanner.skipCertificateValidation if added in panic.
8. Add monitoring on Sonar public URL with strict TLS verification.

After cutover, run analysis on a known-failing branch to confirm scanner transport before merging mass main builds. Capture webhook redelivery success counts from GitHub for at least one hour post-fix. Remove any sonar.branch experiments that pointed at HTTP-only legacy URLs during triage.

Portfolio aggregation dashboards may still show stale “last analysis” timestamps while TLS is broken—do not use them as health signals during the incident. If LDAPS to Active Directory for Sonar admin login uses a different cert, failures there mimic SSO outage; test each authentication path independently.

Pin sonar.host.url in a single shared CI variable repo so every pipeline references the same TLS identity your monitors watch. Re-run one branch analysis and confirm webhook delivery logs are green. Attach openssl serials to the change ticket.

When to use automation

Sonar uptime without TLS validation greenlights deploys that fail scanners. Use live TLS checks on sonar.host.url hostnames from outside the cluster. /check suits internet-facing installs.

Alert 30, 14, 7, and 1 days before expiry; use RDAP on related domains. DevOps chains benefit from monitoring Sonar alongside Nexus repository SSL certificate expired peers.

Quality gate automation should fail pipelines when /check detects sub-seven-day windows on sonar.host.url hostnames, giving platform teams runway before scanners hard-fail. Pair with Jenkins HTTPS certificate expired monitoring when the same ingress serves both tools.

SonarQube administrative traffic from support engineers often rides corporate VPN split tunnels—external monitoring still represents what SaaS webhooks and cloud CI experience without VPN overrides.

Branch analysis and pull request decoration depend on webhook return paths that also require valid TLS on your Sonar URL—after fixing certs, re-run a PR analysis to confirm decoration badges return. Elasticsearch certificates backing Sonar search are unrelated to inbound UI TLS but can delay restarts long enough to extend incidents if not planned separately.

Embedded reporting URLs in Confluence macros break when Sonar HTTPS fails—coordinate comms with documentation teams who may see the outage before developers do. Store serial numbers from openssl in change records so auditors can match renewal tickets to deployment timestamps.

Re-run Sonar’s background CE task health after cert changes—Compute Engine restarts sometimes lag web tier reloads, producing scary UI banners after TLS is already fixed. Keep a pinned browser tab on /api/system/health during verification for objective green status separate from subjective “looks fine” checks.

Long-term, store sonar.host.url in the same certificate inventory database as Jenkins and GitLab URLs so DevOps teams receive one combined renewal calendar. When Sonar sits behind mutual TLS at the ingress, verify client cert expiry separately—ingress mTLS plus expired server leaf produces layered errors that confuse on-call if runbooks only mention server renewal.

Training materials for developers should show how to read scanner SSL errors in Azure Pipelines, GitHub Actions, and GitLab job logs—reducing duplicate tickets when one platform team fixes TLS and others retry blindly.

Register sonar.host.url in monitoring with the same hostname scanners use, not an admin-only alias behind split DNS. Webhook-only URLs that differ from the scanner URL deserve their own TLS watch so quality gate automation and admin integrations recover together after renewal.