Cannot verify server at

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.

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.

Appendix: 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)