GoogleContainerTools/jib · warning

Failed to connect to ${url} over HTTPS. Attempting again wit

Error message

Failed to connect to ${url} over HTTPS. Attempting again with HTTP.

What it means

FailoverHttpClient logs this warning when a plain HTTPS connection to a registry fails (e.g. SSL handshake or connect error) and the client automatically falls back to unencrypted HTTP for that URL. It signals degraded security: credentials may be sent over HTTP.

Source

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

        }
        logger.accept(LogEvent.warn(requestUrl + " failed and will NOT be retried"));
        return false;
      }
    };
  }

  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

1. Enable TLS on the registry or configure the registry as insecure explicitly (--allow-insecure-registries / sendCredentialsOverHttp) so the fallback is intentional
2. Fix the HTTPS endpoint: check certificate validity, TLS version, and that port 443 serves TLS (curl -v https://<url>)
3. Avoid sending real credentials over the plain-HTTP fallback; use a transport-secured proxy in front of the registry
4. If the registry must stay HTTP-only, restrict it to trusted/internal networks

Example fix

// before: registry only serves HTTP, credentials sent in clear
mvn jib:build -Djib.to.image=registry.local:5000/app
// after: explicitly acknowledge insecure registry
mvn jib:build -Djib.allowInsecureRegistries=registry.local:5000

// ensure the registry speaks HTTPS before building
openssl s_client -connect registry.local:443 -servername registry.local </dev/null | grep -q 'Verify return code: 0' && echo OK

try {
  jibBuild();
} catch (Exception e) {
  if (e.getMessage() != null && e.getMessage().contains("Attempting again with HTTP")) {
    log.warn("Credentials may have gone over plain HTTP; enable TLS on the registry");
  }
  throw e;
}

When it happens

Trigger: Calling any registry operation (pull/push) against a URL whose HTTPS endpoint is unreachable (TLS handshake failure, no HTTPS listener) when the client allows insecure/plain-HTTP failover (allowInsecureRegistries enabled or a registry configured as insecure).

Common situations: Private registries (e.g. old Docker registries, Harbor misconfig, local registries) that only serve plain HTTP on :5000; corporate TLS-inspecting proxies; testing against localhost registries without TLS.

Understand the failure class

Background: 'Something went wrong' / 'Request failed (500)' / 'HTTP error! status: 404' — what failed HTTP requests actually mean and how to find the real cause — this error's family across 28 libraries.

Related errors

• Cannot verify server at ${url}. Attempting again with no TLS
• Path does not start with forward slash (/): ${unixPath}
• Cannot create AbsoluteUnixPath from non-absolute Path: ${pat
• Cannot resolve against absolute Path: ${relativePath}
• platforms set cannot be empty

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