Invalid URL syntax in 'leaderUrl' when configuring Solr replication in version 8.4.11

Issue

After upgrading from Solr 7.4 to 8.4.11, replication fails to initialize on follower nodes with the following error:

org.apache.solr.common.SolrException: Invalid URL syntax in 'leaderUrl'

In Solr Admin UI, this may appear as the core being in an invalid_leader state. Logs may also show:

javax.net.ssl.SSLPeerUnverifiedException: Certificate for <hostname> doesn't match any of the subject alternative names

Diagnosis

This error typically occurs when:

• The Solr follower (formerly slave) is running a different major version than the leader

• The leaderUrl field points to a hostname not present in the SSL certificate SAN list

• Configuration from Solr 7.x was copied without proper normalization for 8.x

• A DNS alias or load balancer endpoint is used in the leaderUrl, which Solr cannot resolve for replication

To confirm:

• Check Solr versions on both leader and follower using:

curl -k "https://<host>:<port>/solr/admin/info/system"

Check the replication config block in solrconfig.xml for the follower

Test SSL connection from the follower to the leader:

openssl s_client -connect <leader-host>:8983

Environment

Fusion 5.x / Standalone Solr
Solr 8.4.11
Two-node setup using traditional replication (not SolrCloud)
SSL enabled
Basic authentication enabled

Cause

The replication architecture in Solr changed after version 7.x:

• Solr 7.x uses master/slave terminology

• Solr 8.x requires leader/follower instead

• Solr 8.x enforces stricter validation of leaderUrl, including certificate verification

• If a custom hostname (e.g., internal IP, FQDN, or DNS alias) is used that is not part of the SSL certificate’s Subject Alternative Name (SAN) list, replication fails with SSL errors

Resolution

1. Ensure both Solr nodes run the same version

Replication requires both the leader and follower to run the same Solr version. Upgrade both nodes to Solr 8.4.11.

On leader node:

<requestHandler name="/replication" class="solr.ReplicationHandler">
  <lst name="leader">
    <str name="replicateAfter">commit</str>
  </lst>
</requestHandler>

On follower node:

<requestHandler name="/replication" class="solr.ReplicationHandler">
  <lst name="follower">
    <str name="leaderUrl">https://<leader-host>:8983/solr/<core-name>/replication</str>
    <str name="pollInterval">01:00:00</str>
  </lst>
</requestHandler>

2. Verify leaderUrl uses valid hostname

• The hostname in leaderUrl must match one of the SAN entries in the SSL certificate used by the leader node.

• You can inspect the certificate using:

openssl s_client -connect <leader-host>:8983 | openssl x509 -noout -text

• If the hostname (e.g., liedcstapcwd001) is not listed in the SAN section, generate a new certificate including that value.

3. Avoid using load balancer URLs in replication

• Solr replication cannot resolve virtual hostnames or DNS-level failover endpoints like solrsearch.uat.pa.gov

• Instead, use the actual host FQDN or IP address of the leader node in leaderUrl

4. If copying configs between versions, verify these:

• solrconfig.xml is updated to use leader/follower, not master/slave

• core.properties file points to the correct instance directory

• Configs are placed under the expected structure: solr_home/<core-name>/conf/

• Remove any unused or nested conf/ directories to avoid misreads

5. Restart Solr and validate replication status

Use the following URL on each node to confirm role assignment:

curl -k "https://<host>:8983/solr/<core-name>/replication?command=details"

Look for:

• On leader: isLeader=true

• On follower: isFollower=true

6. Workaround for SAN mismatch (not recommended for production)

In testing or staging environments, disable certificate validation with a relaxed JVM truststore. Not recommended for production use. Instead, regenerate certificates properly.