Cannot verify server at ${url}. Attempting again with no TLS

Error message

Cannot verify server at ${url}. Attempting again with no TLS verification.

What it means

FailoverHttpClient logs this warning when the HTTPS connection to a registry cannot be TLS-verified (untrusted/unknown certificate, self-signed CA) and the client retries the request with all TLS certificate verification disabled. It warns that the connection is no longer authenticated or secure.

Source

Thrown at jib-core/src/main/java/com/google/cloud/tools/jib/http/FailoverHttpClient.java:391

  }

  private HttpTransport getHttpTransport(boolean secureTransport) {
    HttpTransport transport =
        secureTransport ? secureHttpTransportFactory.get() : insecureHttpTransportFactory.get();
    synchronized (transportsCreated) {
      transportsCreated.add(transport);
    }
    return transport;
  }

  private void logHttpFailover(URL url) {
    String log = "Failed to connect to " + url + " over HTTPS. Attempting again with HTTP.";
    logger.accept(LogEvent.warn(log));
  }

  private void logInsecureHttpsFailover(URL url) {
    String log = "Cannot verify server at " + url + ". Attempting again with no TLS verification.";
    logger.accept(LogEvent.warn(log));
  }

  @VisibleForTesting
  public Deque<HttpTransport> getTransportsCreated() {
    return transportsCreated;
  }
}

View on GitHub (pinned to fb949e2676)

Solutions

Import the registry's CA certificate into the JVM truststore (keytool -importcert -alias <ca> -keystore $JAVA_HOME/lib/security/cacerts)
Fix the registry certificate (valid CA-signed, not expired, correct SANs)
Explicitly opt into insecure mode for this registry so the behavior is intentional and audited
Investigate unexpected MITM if the endpoint should have a valid public certificate

Example fix

// before: warning about unverifiable cert
mvn jib:build
// after: trust the internal CA
sudo keytool -importcert -file internal-ca.crt -alias internalCA -keystore $JAVA_HOME/lib/security/cacerts -storepass changeit

Defensive patterns

Strategy: validation

Validate before calling

// verify the registry certificate chains to a trusted CA
openssl s_client -connect registry.internal:443 -servername registry.internal </dev/null 2>/dev/null | openssl x509 -noout -issuer

Try / catch

try {
  jibBuild();
} catch (SSLHandshakeException e) {
  // after the 'no TLS verification' warning, fix trust rather than ignoring
  throw new ConfigurationException("Import the registry CA into the JVM truststore", e);
}

Prevention

Import internal CAs into $JAVA_HOME/lib/security/cacerts (or -Djavax.net.ssl.trustStore)
Monitor certificate expiry for internal registries
Prefer explicit insecure-registry opt-in over silently disabling TLS verification

When it happens

Trigger: A registry endpoint presents a certificate that fails Java's default trust validation (self-signed, private CA not in the JVM truststore, MITM proxy) while insecure-registries mode is enabled, triggering logInsecureHttpsFailover from the transport call path.

Common situations: Self-signed certificates on internal Harbor/Nexus registries; corporate proxy re-signing TLS; JVM truststore missing the internal CA; expired certificates on private registries.

Understand the failure class

SSL/TLS and certificate errors — how TLS handshakes and certificate validation fail.

Related errors

AI-assisted analysis of GoogleContainerTools/jib@fb949e2676 (2026-09-06). Data as JSON: /api/errors/1c08a20835bb398c. Report an issue: GitHub.