quarkusio/quarkus · error · ConfigurationException

You must provide either a valid username/password pair for B

Error message

You must provide either a valid username/password pair for Basic authentication OR only a valid API key for ApiKey authentication. Both methods are currently enabled.

What it means

RestClientBuilderHelper.applyAuthentication() rejects configurations that enable both Basic auth (username/password) and ApiKey auth simultaneously. The Elasticsearch low-level REST client builder supports only one authentication method, so a ConfigurationException is thrown when both quarkus.elasticsearch.username and quarkus.elasticsearch.api-key are present.

Source

Thrown at extensions/elasticsearch-rest-client/runtime/src/main/java/io/quarkus/elasticsearch/restclient/lowlevel/runtime/RestClientBuilderHelper.java:131

                .setSniffIntervalMillis((int) config.discovery().refreshInterval().toMillis());

        // https discovery support
        if ("https".equalsIgnoreCase(config.protocol())) {
            NodesSniffer hostsSniffer = new ElasticsearchNodesSniffer(
                    client,
                    ElasticsearchNodesSniffer.DEFAULT_SNIFF_REQUEST_TIMEOUT, // 1sec
                    ElasticsearchNodesSniffer.Scheme.HTTPS);
            builder.setNodesSniffer(hostsSniffer);
        }

        return builder.build();
    }

    private static void applyAuthentication(HttpAsyncClientBuilder httpClientBuilder, ElasticsearchConfig config) {
        boolean hasBasic = config.username().isPresent();
        boolean hasApiKey = config.apiKey().isPresent();
        if (hasBasic && hasApiKey) {
            throw new ConfigurationException("You must provide either a valid username/password pair for Basic " +
                    "authentication OR only a valid API key for ApiKey authentication. Both methods are currently " +
                    "enabled.");
        }
        if (!"https".equalsIgnoreCase(config.protocol()) && (hasBasic || hasApiKey)) {
            LOG.warn("Transmitting authentication information over HTTP is unsafe as it implies sending sensitive " +
                    "information as plain text over an unencrypted channel. Use the HTTPS protocol instead.");
        }
        if (hasBasic) {
            BasicCredentialsProvider credentialsProvider = new BasicCredentialsProvider();
            credentialsProvider.setCredentials(
                    new AuthScope(null, null, -1, null, null),
                    new UsernamePasswordCredentials(config.username().get(), config.password()
                            .map(String::toCharArray).orElse(null)));
            httpClientBuilder.setDefaultCredentialsProvider(credentialsProvider);
        } else if (hasApiKey) {
            String apiKey = config.apiKey().get();
            Header apiKeyHeader = new BasicHeader(HttpHeaders.AUTHORIZATION, "ApiKey " + apiKey);
            httpClientBuilder.setDefaultHeaders(Collections.singleton(apiKeyHeader));

View on GitHub (pinned to e1c734241f)

Solutions

Remove quarkus.elasticsearch.username/password and keep only quarkus.elasticsearch.api-key
Or remove quarkus.elasticsearch.api-key and keep username/password
Audit env vars/CI secrets (ELASTICSEARCH_USERNAME, ELASTICSEARCH_API_KEY) so only one scheme is set

Example fix

// before
quarkus.elasticsearch.username=elastic
quarkus.elasticsearch.password=secret
quarkus.elasticsearch.api-key=abc123
// after
quarkus.elasticsearch.api-key=abc123

Defensive patterns

Strategy: validation

Validate before calling

String user = System.getProperty("quarkus.elasticsearch.username", System.getenv("QUARKUS_ELASTICSEARCH_USERNAME"));
String key = System.getProperty("quarkus.elasticsearch.api-key", System.getenv("QUARKUS_ELASTICSEARCH_API_KEY"));
if (user != null && key != null) throw new IllegalStateException("Set only one of username/password or api-key");

Try / catch

try { startApp(); }
catch (ConfigurationException e) {
  if (e.getMessage().contains("Basic") && e.getMessage().contains("ApiKey")) { /* fix application.properties */ }
  else throw e;
}

Prevention

Keep exactly one auth scheme in application.properties per environment
Audit CI/CD secrets for both ELASTICSEARCH_USERNAME and ELASTICSEARCH_API_KEY
When migrating auth schemes, delete the old keys

When it happens

Trigger: Setting both quarkus.elasticsearch.username (and password) and quarkus.elasticsearch.api-key in application.properties; also stale config left behind when switching auth schemes.

Common situations: Migrating from Basic to API-key auth without removing username/password; copying config snippets from different environments; CI secrets injecting both variables.

Understand the failure class

Authentication and authorization failures — expired tokens, bad credentials, and missing scopes.

Related errors

AI-assisted analysis of quarkusio/quarkus@e1c734241f (2026-09-05). Data as JSON: /api/errors/692f7c6ffe43f3c7. Report an issue: GitHub.