When setting up Sitecore 9 or 10, one of the most critical steps in the installation process is ensuring that your search provider is communicating securely. Configuring SSL for Solr is no longer an optional step; it is a requirement for the Sitecore Install Framework (SIF) and for the overall security of your local development environment. However, many developers find that even after following the official Solr documentation, they are still greeted by the dreaded "Not Secure" warning in Google Chrome.

In this guide, you will learn how to properly generate a self-signed certificate, import it into the correct Windows certificate stores, and configure Solr to use a Java KeyStore (JKS). By the end of this tutorial, you will have a fully trusted HTTPS connection for your Solr instance, eliminating browser warnings and ensuring smooth communication with Sitecore.

Why SSL for Solr is Required in Sitecore

Starting with Sitecore 9.0, the platform moved toward a secure-by-default posture. Because Sitecore communicates with Solr via web APIs, and often handles sensitive indexed data, HTTPS is the standard. Furthermore, the Sitecore Identity Server and various xConnect services require secure endpoints to function correctly.

If your Solr instance is not running over HTTPS, or if the certificate is not trusted by the machine running Sitecore, you will encounter errors during the SIF installation process or find that your search indexes refuse to initialize. The challenge usually lies in the fact that while Solr can be configured to use SSL, browsers like Chrome will only show a "green lock" if the certificate is issued by a Trusted Root Certification Authority.

Automating Certificate Generation and Trust

To bridge the gap between generating a certificate and making it trusted by your local machine, you can use PowerShell. The following script is a robust solution for creating a self-signed certificate and immediately placing it into the Trusted Root store of your local machine. This is a critical step because simply creating the certificate is not enough—Windows must be told to trust it.

#requires -Version 2.0

#region Exported Cmdlets

<#
    .SYNOPSIS
        Creates a self-signed certificate and copies it into the trusted store.
    .DESCRIPTION
        Creates a self-signed certificate and copies it into the trusted store.
    .PARAMETER DnsName
        The DNS name for which a certicate should be issued. eg mysite.local
    .EXAMPLE
        # New-TrustedSelfSignedCertificate mysite.local
        Description
        -----------
        Creates a self-signed certificate for mysite.local
#>
function New-TrustedSelfSignedCertificate {
    [CmdletBinding()]
    param (
        [Parameter(Position=0, ValueFromPipeline=$true, ValueFromPipelineByPropertyName=$true, Mandatory=$true)]
        [String] $DnsName,

        [switch] $LocalMachine = $false
    )

    process {

        $ErrorActionPreference = "Stop"

        $cert = New-SelfSignedCertificate -DnsName $DnsName -CertStoreLocation Cert:\LocalMachine\My

        if ($LocalMachine) {
            $CertLocation = "LocalMachine";
        } else {
            $CertLocation = "CurrentUser";
        }

        # Cert provider does not support Copy-Item, so we'll copy it manually
        $dstStore = New-Object System.Security.Cryptography.X509Certificates.X509Store("Root", $CertLocation)
        $dstStore.Open([System.Security.Cryptography.X509Certificates.OpenFlags]::ReadWrite)
        $dstStore.Add($cert)
        $dstStore.Close()
    }
}

#endregion

#region Module Interface
Export-ModuleMember New-TrustedSelfSignedCertificate
#endregion

This function creates the certificate in the LocalMachine\My store and then copies it to the Root store. By using the -LocalMachine switch, you ensure that any service running on the box (including IIS and Solr) can validate the certificate.

Creating the Solr JKS Keystore

Solr, being a Java-based application, uses a Java KeyStore (JKS) format rather than the standard Windows .pfx or .cer files. To make this easier, you can use a comprehensive automation script that handles the conversion between the Windows-friendly .p12 format and the Java-friendly .jks format.

Below is a script designed to be run on a machine where Solr is already installed. It uses the keytool.exe utility (found in your JRE/JDK bin folder) to generate the keystore.

param(
    [string]$KeystoreFile = 'solr-ssl.keystore.jks',
    [string]$KeystorePassword = 'secret',
    [string]$SolrDomain = 'localhost',
    [switch]$Clobber
)

$ErrorActionPreference = 'Stop'

### PARAM VALIDATION
if($KeystorePassword -ne 'secret') {
    Write-Error 'The keystore password must be "secret", because Solr apparently ignores the parameter'
}

if((Test-Path $KeystoreFile)) {
    if($Clobber) {
        Write-Host "Removing $KeystoreFile..."
        Remove-Item $KeystoreFile
    } else {
        $KeystorePath = Resolve-Path $KeystoreFile
        Write-Error "Keystore file $KeystorePath already existed. To regenerate it, pass -Clobber."
    }
}

$P12Path = [IO.Path]::ChangeExtension($KeystoreFile, 'p12')
if((Test-Path $P12Path)) {
    if($Clobber) {
        Write-Host "Removing $P12Path..."
        Remove-Item $P12Path
    } else {
        $P12Path = Resolve-Path $P12Path
        Write-Error "Keystore file $P12Path already existed. To regenerate it, pass -Clobber."
    }
}

try {
    $keytool = (Get-Command 'keytool.exe').Source
} catch {
    $keytool = Read-Host "keytool.exe not on path. Enter path to keytool (found in JRE bin folder)"

    if([string]::IsNullOrEmpty($keytool) -or -not (Test-Path $keytool)) {
        Write-Error "Keytool path was invalid."
    }
}

### DOING STUFF

Write-Host ''
Write-Host 'Generating JKS keystore...'
& $keytool -genkeypair -alias solr-ssl -keyalg RSA -keysize 2048 -keypass $KeystorePassword -storepass $KeystorePassword -validity 9999 -keystore $KeystoreFile -ext SAN=DNS:$SolrDomain,IP:127.0.0.1 -dname "CN=$SolrDomain, OU=Organizational Unit, O=Organization, L=Location, ST=State, C=Country"

Write-Host ''
Write-Host 'Generating .p12 to import to Windows...'
& $keytool -importkeystore -srckeystore $KeystoreFile -destkeystore $P12Path -srcstoretype jks -deststoretype pkcs12 -srcstorepass $KeystorePassword -deststorepass $KeystorePassword

Write-Host ''
Write-Host 'Trusting generated SSL certificate...'
$secureStringKeystorePassword = ConvertTo-SecureString -String $KeystorePassword -Force -AsPlainText
$root = Import-PfxCertificate -FilePath $P12Path -Password $secureStringKeystorePassword -CertStoreLocation Cert:\LocalMachine\Root
Write-Host 'SSL certificate is now locally trusted. (added as root CA)'

Next Steps After Running the Script

Once the script has finished, you must perform the following manual steps to finalize the configuration:

  1. Move the Keystore: Copy the generated solr-ssl.keystore.jks file to your $SOLR_HOME\server\etc directory.
  2. Update Configuration: Open your solr.in.cmd file (usually located in your Solr bin directory) and add or uncomment the following lines:
set SOLR_SSL_KEY_STORE=etc/solr-ssl.keystore.jks
set SOLR_SSL_KEY_STORE_PASSWORD=secret
set SOLR_SSL_TRUST_STORE=etc/solr-ssl.keystore.jks
set SOLR_SSL_TRUST_STORE_PASSWORD=secret
  1. Restart Solr: Restart the Solr service for the changes to take effect.

Troubleshooting Common SSL Issues

Even with automation, you might encounter specific environmental issues. Here are two critical things to check if you still see security warnings:

Local Machine vs. Current User

When you import a certificate via the Windows Certificate Manager (certlm.msc), ensure you are importing it to the Trusted Root Certification Authorities under Local Machine. If you import it under "Current User," the certificate will work when you browse Solr in your browser, but the Solr service itself (and Sitecore's background processes) may fail to validate it because they run under different service accounts.

Duplicate Certificates

If you have been troubleshooting for a while, you may have multiple certificates with the same name (e.g., "localhost") in your Trusted Root store. Windows can sometimes get confused by these duplicates. It is best practice to open certlm.msc, search for any existing Solr or localhost certificates, delete the old ones, and then run your generation script fresh.

Frequently Asked Questions

Why do I have to use "secret" as the password?

While Solr technically allows different passwords, many developers have found that Solr occasionally ignores custom password parameters in certain versions when running on Windows. Using the default "secret" password for local development is a common community workaround to ensure compatibility across various Solr and Java versions.

Does this apply to Solr Cloud mode?

Yes. Whether you are running a single node or Solr Cloud, the SSL configuration remains largely the same. However, in Solr Cloud mode, you must ensure that all nodes in the cluster trust the same Root CA certificate so they can communicate with each other securely.

Wrapping Up

Configuring SSL for Solr is a foundational step in setting up a modern Sitecore environment. By using PowerShell to automate the creation and trusting of certificates, you eliminate the manual errors that lead to "Not Secure" warnings. Remember to always target the Local Machine store and keep your solr.in.cmd file updated with the correct keystore paths. With these steps completed, your Sitecore instance will be able to securely and efficiently communicate with its search indexes.